Cilium: eBPF に基づく効率的なクラウド ネイティブ ネットワークと ServiceMesh ソリューション

Ciliumについて

Cilium は、革新的なカーネル テクノロジー eBPF をベースにしたオープン ソースのクラウド ネイティブ ネットワーキング ソリューションであり、ワークロードに対して高性能で安全かつ監視可能なネットワーク接続を提供します。 eBPF テクノロジーは、カスタム プログラムをカーネルに接続するイベントを提供することで、アプリケーションに強力な機能を提供します。 Cilium プロジェクトでは、コンテナ クラスターを効果的に管理できる eBPF の機能を活用した複数のプログラムを開発しました。

現在、Clilium プロジェクトには、Cilium、Hubble、Tetragon の 3 つのプロジェクトが含まれています。

これは、コンテナ ネットワーク クラウドが直面している 3 つの主要な課題、つまり接続性、可観測性、セキュリティを解決します。

Cilium はもともと Isovalent によって作成され、2015 年にオープンソース化されて非常に人気を博しました。 GitHub スターは 14,000 人以上、貢献者は 500 人以上、Cilium コミュニティ Slack には 14,000 人以上のユーザーが登録されています。さらに重要なのは、Cilium がメディア、金融、検索など、さまざまな垂直業界の組織によって実稼働環境に広く導入されていることです。 3 大クラウド プロバイダーである AWS、Microsoft、Google は現在、Kubernetes サービス製品で Cilium をサポートしています。 Cilium は 2021 年 10 月に CNCF インキュベーションに参加し、2022 年 10 月に卒業しました。卒業ステータスは、あらゆる CNCF プロジェクトにとって大きなマイルストーンであり、プロジェクトに持続可能な貢献者コミュニティがあり、広く採用されており、あらゆるクラウド スケール スタックの期待される一部になりつつあることを示しています。

クラウドネイティブ接続の拡大

Kubernetes の最大の利点はその動的な性質であり、これにより、オンデマンドでサービスを拡張し、問題が発生したときに Pod とサービスを目的の状態に調整することができます。たとえば、ノードに障害が発生した場合、Kubernetes はクラスター内の別のノード上のポッドを自動的に再起動して、その損失を補います。ただし、このダイナミズムにより、IP アドレスがクラスター全体で再割り当てされ、再利用されるため、従来のネットワークでは問題が発生します。人間のオペレーターにとっては、どの IP アドレスが特定のワークロードに一致するかについて推測することができなくなるため、可観測性の問題が発生します。基盤となるネットワーク スタックでは、特定のコンポーネントが IP アドレスを継続的に再利用するように設計されていなかったため、パフォーマンスに大きな問題が発生しました。

Cilium は、Linux カーネルのさまざまなポイントに eBPF プログラムを挿入し、IP アドレスの代わりに Kubernetes ID を使用し、ネットワーク スタックの一部をバイパスしてパフォーマンスを向上させる、クラウド ネイティブ時代に適した接続レイヤーを提供します。

Kubernetes では、Pod は通常、独自のネットワーク名前空間を実行します。つまり、パケットはネットワーク スタックを 2 回 (Pod 名前空間で 1 回、ホストで 1 回) 通過する必要があります。 Cilium を使用すると、ホスト スタックの重要な部分をバイパスできるため、パフォーマンスが大幅に向上します。フラッシュと同じように、超高速です。

上の図からわかるように、Cilium はネットワーク スタック内の iptables をバイパスできます。これは Kubernetes の動作を考慮して設計されたコンポーネントではなく、Kubernetes の動的な性質により、iptables のパフォーマンスが大幅に低下することがよくあります。多数のノード、ポッド、サービスを含む大規模なクラスターでは、通常、ポッドの増減に応じて更新する必要がある iptables フィルターと転送ルールが多数存在します。さらに悪いことに、iptables では、1 つのルールを変更すると、テーブル全体が書き換えられます。デプロイメントが拡大するにつれて、ポッドが作成または破棄されるたびにルールの収束にかかる時間が長くなり、大規模に正しく動作するのに大幅な遅延が発生します。

Cilium は、iptables の代わりに、eBPF マップ内のポッド エンドポイントを追跡します。これらはカーネルに保存されるデータ構造であり、Cilium の eBPF プログラムがアクセスして、各ネットワーク パケットをどこに送信するかを効率的に決定できます。

Cilium アイデンティティベースのネットワークポリシー

従来の Kubernetes ネットワーク ポリシーは iptables フィルターに基づいており、同じスケーリングの問題に悩まされています。 Cilium は異なるアプローチを採用し、Kubernetes ラベルを使用して Pod にセキュリティ ID を割り当てます (Kubernetes がラベルを使用して各サービスに割り当てられた Pod を識別する方法と同様)。ネットワーク ポリシーは eBPF マップとして表現され、ネットワーク トラフィックが Cilium 管理ノードに出入りするときにこれらのマップから超高速検索を実行し、パケットを許可するか拒否するかを決定できます。これらの eBPF プログラムは非常に小さく、超高速です。

Cilium を使用すると、アプリケーションに対応した L7 ポリシーを作成できます。たとえば、特定の API エンドポイントで特定の HTTP REST メソッドのみを許可するように、Pod 間のアクセスを制限するポリシーを記述できます。トラフィックがクラスター外部と通信する必要がある場合は、完全修飾ドメイン名または IP アドレスに基づいてトラフィックをフィルタリングすることもできます。

透過的な暗号化

ポリシーの適用は、Cilium が提供するネットワーク セキュリティの唯一の側面ではありません。ゼロ トラスト ネットワーキングは急速にベスト プラクティスとなり、透過的な暗号化はおそらくすべてのネットワーク トラフィックが暗号化されることを保証する最も簡単な方法です。スイッチを切り替えるだけで、Cilium がトラフィックが通過する IPsec または WireGuard 接続を作成することができます。 eBPF の魔法により、これはカーネル レベルで行われるため、アプリケーションはトラフィックを暗号化するために変更を加える必要がありません。

レガシーインフラストラクチャとの統合

Cilium を使用すると、コンテナ化されたクライアントとサービスをレガシー インフラストラクチャに簡単に接続できます。 Kubernetes Pod からのネットワーク トラフィックは、データ センターのサーバー ラック内の仮想マシンで実行されている従来のサービスへの疑似ランダム IP アドレスからのトラフィックのように見えます。従来のファイアウォール インフラストラクチャでは、敵と味方を区別できるように、静的 IP アドレスを処理することが求められます。 Cilium には、固定 IP アドレスを持つ特定の出口ノードを介して従来のサービスのトラフィックをルーティングする出力ゲートウェイの概念があります。一方、Cilium は Border Gateway Protocol (BGP) もサポートしており、クラスター外部のネットワーク インフラストラクチャへの Kubernetes サービスのルートを簡単にアナウンスできます。 Cilium は、外部サービスとの統合に関して、さまざまな機能を提供します。

クラスターメッシュ

Cilium を外部のレガシー ワークロードと統合することについてはすでに説明しましたが、複数の Kubernetes クラスターについてはどうでしょうか?あるクラスターから別のクラスターへの接続を別の外部サービスとして扱う必要がありますか?複数の Cilium 対応 Kubernetes クラスターをグループ化し、Cilium の ID モデルを非常に優れた方法で活用して、マルチクラスター サービスの構成を支援することができます。 Cilium では、このマルチクラスター サポートを ClusterMesh と呼んでいます。

Cilium ClusterMesh を使用すると、Kubernetes アノテーションを使用してグローバル サービスを指定でき、Cilium は必要に応じて暗号化されたトラフィックを使用して、複数のクラスターに存在するグローバル サービスに関連付けられたサービス エンドポイントへのアクセスを負荷分散します。これらのグローバル サービスのサービス依存関係を指定して、リクエストをローカルに送信することを優先し (エンドポイントが正常な場合)、必要に応じて他のクラスターのリモート サービス エンドポイントにフェールオーバーすることができます。

クラスター間のフェイルオーバーを簡素化することは単なる利点に過ぎません。Cilium ClusterMesh では、さまざまな実用的なマルチクラスターの使用例をはるかに簡単に実装できます。 ClusterMesh の設定は、Cilium 対応のクラスターを相互に認識させるだけで済みます。Cilium CLI ツールを使用すると、このプロセスが非常に簡単になります。実際、私は初めて試す前は Azure AKS について何も知らなかったのですが、Cilium プロジェクトのクイック スタート ガイドを使用して、Azure AKS で米国東部および西部リージョンにわたるグローバル サービス フェールオーバーを備えた Cilium ClusterMesh をわずか数分で起動することができました。

ネットワークの可観測性

これまではネットワーク接続とセキュリティに焦点を当ててきましたが、Cilium は大規模なネットワークの観測にも役立ちます。

Kubernetes クラスター内のネットワークの可観測性は非常に複雑になります。ポッドは絶えず出入りしており、内部 IP アドレスはスケールアップやスケールダウンに応じてさまざまなワークロード間で再配布されるため、パケット フローを観察することは困難です。クラスター内の IP アドレスでパケットをトレースしようとするのは無駄です。ノード上で eBPF 駆動の tcpdump を実行しても、IP アドレスとポートをワークロードに一致させることが困難な場合があり、特に Kubernetes 自体がポッドを迅速に再稼働させることで診断中の問題を修正しようとしている場合は、十分ではありません。マイクロサービスまたはネットワーク ポリシーのいずれかで問題が発生した場合、どのようにして可観測性を確保すればよいでしょうか?

繊毛のスーパーフレンド、ハッブルを紹介する時が来ました。 Hubble は動的 IP アドレス指定のノイズを除去し、Kubernetes ID とともにネットワーク フローを表示するため、ポッドとサービスが相互に、また外部とどのように通信しているかを明確に確認できます。 Hubble は Cilium を基盤として、ネットワーク レイヤー 3 およびレイヤー 4 フローだけでなく、HTTP や gRPC などのレイヤー 7 のプロトコル フローの詳細も表示できる、クラス最高のコンテナ ネットワーク観測プラットフォームを作成します。

Hubble UI はさらに一歩進んで、ネットワーク フローの詳細とともにサービス依存関係グラフのグラフィカルな表現を提供します。

Cilium と Hubble を組み合わせることで、ネットワークの監視や問題の診断に非常に役立つさまざまなメトリック、トレース、ログが公開されます。このデータを Grafana に取り込んで簡単に視覚化できるため、ネットワークに関するさまざまな質問に簡単に答えることができます。たとえば、特定のサービスまたはすべてのクラスターの 4xx HTTP 応答のレートを知りたい場合や、パフォーマンスが最も低いサービス間の要求/応答のレイテンシを知りたい場合は、Hubble メトリックがニーズを満たします。

ランタイムセキュリティ: 監視と強制

しかし、コンテナのセキュリティはネットワーク ポリシーだけではありません。コンテナ ランタイムもセキュリティ ポリシーの恩恵を受けます。 Tetragon は、eBPF を使用したランタイム セキュリティの監視と適用に重点を置いています。 Tetragon は、次のようなさまざまな安全上重要なイベントを検出し、報告できます。

• プロセス実行イベント。
• システムコールアクティビティ。
• ネットワークおよびファイル アクセスを含む I/O アクティビティ。

Tetragon は、eBPF を利用した最初のセキュリティ ツールではありませんが、コンテナ セキュリティに数多くの新しい機能をもたらします。他のプロジェクトが表面上はシステム コールにフックしている場合、システム コールへの引数がカーネルに到達する前に上書きされる可能性がある、チェック時間から使用時間までの脆弱性の影響を受けます。 Cilium のエンジニアはカーネル内部の知識を活用して、この問題の影響を受けないポイントのイベントにフックしました。

Tetragon のトレース ポリシーを使用すると、監視するカーネル イベントを構成し、一致する条件と実行するアクションを定義できます。さらに重要なことは、Tetragon は Kubernetes ID に基づいてコンテキスト情報を提供することです。たとえば、特定のファイルまたはディレクトリへのアクセスを検出する場合は、どのプロセス (どの実行可能ファイルが実行されているか) またはどのポッドがそのファイルにアクセスしたかを正確に示すログを出力する TracingPolicy を構成できます。ファイル アクセスが完了する前に問題のあるプロセスを終了するポリシーを構成することもできます。これは非常に強力であり、コンテナ セキュリティにまったく新しいアプローチを追加して、コンテナによって公開される攻撃対象領域を制限するのに役立ちます。シャザムと同様に、テトラゴンはソロモンの知恵に恵まれており、行動方法に関する豊富な知識と判断力を持っています。

Tetragon は、Cilium のネットワーク機能とは独立して使用できます。しかし、Tetragon と Cilium のスーパーヒーローのチームと、ネットワークとランタイム セキュリティのスーパーパワーを組み合わせれば、たとえば疑わしいネットワーク接続を開始したプロセスの完全な祖先を確認できるなど、何ができるか想像してみてください。

国境のない自動車サービスグリッド

Cilium は Kubernetes サービス間の接続を可能にするだけでなく、可観測性とセキュリティ機能も提供し、レイヤー 7 で動作できることが分かりました。これはサービス メッシュと非常によく似ていませんか?はい！現在、Cilium プロジェクトは、各ポッドにサイドカーを挿入せずにサービス メッシュ機能を提供できるようになり、サービス メッシュの効率が向上しています。どれくらい進歩しましたか?同じノード上のコンテナ間の HTTP レイテンシ処理への影響を見てみましょう。 HTTP プロキシの使用には常にコストがかかりますが、サイドカー パターンを使用する場合は、マイクロサービスが相互に通信し、トラフィックがイングレス サイドカー HTTP プロキシとエグレス サイドカー HTTP プロキシの両方を通過するため、料金が 2 倍になる可能性があります。ネットワーク パス内のプロキシの数を減らし、HTTP フィルターの種類を選択すると、パフォーマンスに大きな影響を与える可能性があります。

以下は、Cilium サービス メッシュの仕組みを詳しく説明したブログ投稿のベンチマーク比較です。Cilium Envoy フィルター (茶色) を実行する単一ノード スコープの Envoy プロキシと、Istio Envoy フィルター (青) を実行する双方向 Envoy モデルの HTTP 処理の一般的なレイテンシ コストを示しています。黄色は、プロキシと HTTP 処理が実行されていない場合のベースライン レイテンシです。

Cilium Service Mesh は、サイドカーとして各ポッドに接続されるのではなく、エージェントの一部として各ノードで実行される Envoy ネットワーク プロキシを使用することで、このレイテンシの改善を実現します。ただし、この改善は包括的なものではありません。Cilium は、ネットワーク トラフィックをノード全体の Envoy プロキシにリダイレクトする前に、eBPF を可能な限り使用するためです。これは、ワイルドキャットにふさわしい印象的なワンツーパンチのコンボであり、力任せではなくタイミングとテクニックを使って望む結果を得ることができます。

これは新しいアプローチではありません。Envoy は、レイヤー 7 対応のネットワーク ポリシーを適用するために、Cilium で長年使用されてきました。サイドカーフリーのサービス メッシュを実装するために、Cilium は、完全準拠の Kubernetes イングレスおよびゲートウェイ API 実装のサポートと、Cilium で Envoy の全機能を公開する低レベル CRD のサポートを拡張しました。現在、サイドカー ベースのサービス メッシュを使用しており、すべてのポッドにサービス メッシュ サイドカーをデプロイすることに伴うリソース コストの負担を感じ始めている場合は、よりリソース効率の高い代替手段として Cilium Service Mesh を検討する良い機会です。

Kubernetesだけではない

これまで Kubernetes クラスターのコンテキストで Cilium について説明してきましたが、Cilium は Kubernetes に限定されるものではありません。 Cilium が接続性、可観測性、セキュリティにもたらすメリットは、Kubernetes 以外のワークロードでも実現できます。たとえば、Cilium はスタンドアロンのロードバランサーとして使用でき、実際の運用環境で大きなメリットを示しています。