前提知識:

• WASM： WebAssembly（略称Wasm）は、プラットフォームに依存しない低レベルのバイナリ命令形式であり、最新のウェブブラウザで実行でき、JavaScriptなどの他のウェブ技術と併用できる新しいタイプの仮想マシン技術です。移植性の高いコンパイルターゲットとして設計されており、さまざまなプログラミング言語のコードをWebAssemblyバイトコードにコンパイルでき、ウェブブラウザで迅速に読み込んで実行できます。

WebAssemblyは、Webアプリケーション、特にJavaScriptのような高水準言語で記述された複雑なWebアプリケーションにおけるパフォーマンスの問題に対処するために設計されました。JavaScriptのようなスクリプト言語と比較して、WebAssemblyは実行速度が速く、パフォーマンスとセキュリティに優れており、計算負荷の高い高性能グラフィック処理に適しています。WebAssemblyはWebブラウザだけでなく、デスクトップアプリケーションやモバイルアプリケーションなど、他の環境でも実行できるため、汎用性と移植性に優れた仮想マシン技術と考えられています。

スタックベースの仮想マシンは、命令のオペランドがスタックにプッシュされ、命令自体はスタックの最上位要素に対して動作する仮想マシンアーキテクチャの一種です。つまり、仮想マシンはスタックを使用してデータとオペランドを格納し、命令はスタックの最上位のデータに基づいて実行されます。

• WASI: WebAssembly System Interface (略称 WASI) は、一般的なシステム インターフェイスを提供する標準化された API インターフェイスであり、WebAssembly プログラムをさまざまなオペレーティング システムやハードウェア プラットフォームで実行し、ファイル システム、ネットワーク、タイマーなどの基盤となるオペレーティング システムのリソースや機能にアクセスできるようにします。
• eBPF （Extended Berkeley Packet Filter）は、カーネルレベルの仮想マシン技術であり、ユーザー定義のプログラムコードをカーネルに動的に挿入して実行とイベントの相関関係を確立し、カーネルソースコードを変更することなくカーネルの機能を強化します。eBPF は、カーネル空間とユーザー空間の両方でイベントを監視および分析できるため、効率的なパフォーマンス分析、ネットワークパケットのキャプチャ、セキュリティ監視、リソース管理が可能になります。

eBPFは、カーネルに様々なフック関数を登録することで機能します。これらのフック関数は特定のイベントが発生するとトリガーされ、それらのイベントを処理するeBPFプログラムを実行します。eBPFプログラムは、ユーザー空間で記述され、カーネルローダーによってカーネルにロードされる特殊なバイトコード形式です。eBPFプログラムはカーネルデータ構造にアクセスし、データを変更またはフィルタリングできます。

クラウドネイティブ環境では、eBPF にはさらに多くの利点があります。

関連するイベントの種類:

関数への入口/出口: kprobe、kretprobe、uprobe、uretprobe
トレースポイント: / sys / kernel / debug / tracing / events
パフォーマンスイベント
Linux セキュリティ モジュール インターフェース
ネットワークインターフェース: XDP
ソケットとその他のネットワークフック

• Bcc: bcc (BPF Compiler Collection) は、eBPF (extended Berkeley Packet Filter) プログラムを生成するためのツールセットです。ユーザーが eBPF プログラムを容易に作成およびデバッグできるように、高水準のツールとライブラリのセットを提供します。

スターシップアーキテクチャ

1. エージェント

├── cmd エントリ関数

├── デプロイヤーはeBpf+wasmモジュールをデプロイする

├── ドライバーランタイムモジュール

├── ebpf eBpf関連

├── proc-infoはプロセス情報を収集します

└── wasm wasmは情報を処理する

2つの主な機能:

1. モジュール管理。モジュールは eBpf+wasm を指します。

2. プロセス情報の報告。

エージェントの識別子はNodeNameとエージェントPodIDです。これら2つはKubernetesから注入されます。

さらに、bcc ツールとプロセス監視のためにホストの / と /sys がマウントされます。

ebpf プログラムを使用してプロセスを監視する必要があるため、権限が必要です。

エージェントが起動すると、まず以前にデプロイされたTricorderProbesトラップをクリアします。次に、プログラムはlinux_headersパッケージのInit関数を使用して、BCCのLinuxヘッダーファイルを初期化します。その後、gRPCはapi-serverに接続し、pgに接続し、プロセス情報を取得するためのループを開始し、モジュールのデプロイを処理するためのループを開始します。

エージェントコンテナはホストの /sys パスにマウントされているため、ノード上のすべてのプロセスに関する情報を収集できます。この場合、grabProcessInfo 関数はホストの /sys/fs/cgroup ディレクトリを検索し、ノード上のすべてのプロセスに関する情報を収集します。

モジュールがデプロイされると、ポーリングが開始されます。1. eBPF からデータを読み取ります。2. データを WASM にコピーします。3. WASM から結果を読み取ります。4. JSON 結果を PG に書き込みます。

2. APIサーバー

├── cmd エントリ関数

├── gRPC はデプロイとプロセスの gRPC 呼び出しを処理します。

├── httpはHTTPルートを定義し、dao

├── メタネイティブKubernetes監視リソース

├── pb protobuf の定義

├── テスト

├── ユーティリティツール

└── wasm 翻訳

現在、StatefulSet としてデプロイされていますが、ボリューム タイプは emptyDir であるため、毎回新しい tricorder.db ファイルが作成されます。

その後起動時に初期化されます。

API サーバーの主な機能には、エージェント管理、管理モジュールの展開、ノードプロセス情報の取得、データの表示、データの永続化 (SQLite) などがあります。

モジュールのデプロイ中、各エージェントのモジュールインスタンスが正常に永続化されると、条件がトリガーされ、その時点で各エージェントへのデプロイが実行されます。同時に、エージェントがデータを保存するための対応するデータテーブルがPostgreSQLに作成されます。

api-server のデプロイメントでは、すべてのリソースに対する権限を持つ api-server という名前の sa が使用されます。

API サーバーは、現在以下を含むネイティブ Kubernetes リソースも監視します。

これらのリソースは Informer を通じて監視され、API サーバーは監視情報を PG に同期します。

APIサーバーはポッドインフォーマーを使用して各ノード上のポッドを監視し、これらのコンテナIDをエージェントに送信してプロセス情報を取得します。取得した情報はPostgreSQLに保存されます。