繊毛の紹介

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

Clilium プロジェクトは現在、Cilium、Hubble、Tetragon の 3 つのプロジェクトで構成されています。

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

Ciliumは、Isovalentによって開発され、2015年にオープンソース化されて以来、絶大な人気を博しています。GitHubでは14,000以上のスター、500人以上のコントリビューター、そしてCiliumコミュニティSlackには14,000人以上の登録ユーザーを誇ります。さらに重要なのは、Ciliumがメディア、金融、検索など、様々な業種の組織で本番環境に広く導入されていることです。AWS、Microsoft、Googleの3大クラウドプロバイダーは、現在、KubernetesサービスでCiliumをサポートしています。Ciliumは2021年10月にCNCFインキュベータに参加し、2022年10月に卒業しました。卒業は、あらゆるCNCFプロジェクトにとって重要なマイルストーンであり、持続可能なコントリビューターコミュニティ、広範な採用、そしてあらゆるクラウドスケールスタックにおいてCiliumが期待される要素になりつつあることを示しています。

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

Kubernetesの最大の強みは、その動的な性質にあります。これにより、サービスをオンデマンドでスケーリングし、問題発生時にはポッドとサービスを適切な状態に再編成できます。例えば、ノードに障害が発生した場合、Kubernetesはクラスター内の別のノードでポッドを自動的に再起動し、損失を補います。しかし、この動的な性質は、IPアドレスがクラスター全体で再割り当てされ、再利用されるため、従来のネットワークにとって課題となります。人間のオペレーターにとっては、どのIPアドレスが特定のワークロードに一致するかを推測できなくなるため、可観測性の問題が生じます。さらに、基盤となるネットワークスタックの一部のコンポーネントは、IPアドレスの継続的な再利用を想定して設計されていないため、大規模なパフォーマンス問題につながります。

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

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

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

Ciliumはiptablesではなく、eBPFマップでポッドのエンドポイントを追跡します。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 はボーダーゲートウェイプロトコル (BGP) もサポートしており、Kubernetes サービスのルートをクラスター外のネットワークインフラストラクチャに簡単にアドバタイズできます。Cilium は、外部サービスとの統合時に双方向の通信を提供します。

クラスターメッシュ

Ciliumと外部のレガシーワークロードの統合については既に説明しましたが、複数のKubernetesクラスターの場合はどうでしょうか？あるクラスターから別のクラスターへの接続を、それぞれ別の外部サービスとして扱う必要があるでしょうか？複数のCilium対応Kubernetesクラスターを組み合わせ、Ciliumのアイデンティティモデルを非常に巧みに活用することで、マルチクラスターサービスの構成を容易にすることができます。CiliumはこのマルチクラスターサポートをClusterMeshと呼んでいます。

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

クラスター間のフェイルオーバーが簡素化されるのは、Cilium ClusterMesh のメリットの一つに過ぎません。Cilium ClusterMesh では、様々な実世界のマルチクラスターユースケースをより簡単に実装できます。Cilium ClusterMesh のセットアップは、Cilium 対応クラスターを相互に認識させるだけで済みます。Cilium CLI ツールを使えば、このプロセスは驚くほどシンプルになります。実際、Cilium プロジェクトのクイックスタートガイドを使えば、わずか数分で米国東部と西部リージョンにまたがるグローバルサービスフェイルオーバーの Cilium ClusterMesh を起動できました。最初の試みまでは、Azure AKS について全く知識がありませんでした。

ネットワークの可観測性

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

Kubernetes クラスター内のネットワークの可観測性は非常に複雑になります。ポッドが絶えず出入りし、スケールアップとスケールダウンの際に内部 IP アドレスがワークロード間で再割り当てされるため、パケットフローの監視は困難です。クラスター内の IP アドレスでパケットをトレースしようとしても無駄です。ノード上で eBPF 駆動型の tcpdump を実行しても不十分です。IP アドレスとポートをワークロードと照合することは困難であり、特に Kubernetes 自体が診断対象の問題を解決しようとポッドを迅速に再調整する可能性があるためです。では、マイクロサービスやネットワークポリシーのいずれかに障害が発生した場合、どのように可観測性を実現すればよいのでしょうか。

Ciliumの強力なツール、Hubbleをご紹介します。Hubbleは動的IPアドレスのノイズを除去し、ネットワークフローとKubernetes IDを表示するため、Podとサービスが相互に、そして外部とどのように通信しているかを明確に把握できます。Cilium上に構築されたHubbleは、クラス最高のコンテナネットワーク可観測性プラットフォームであり、レイヤー3と4の詳細なフロー情報だけでなく、レイヤー7のHTTPやgRPCなどのプロトコルフローの詳細も表示します。

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

CiliumとHubbleを組み合わせることで、ネットワークの監視や問題の診断に非常に役立つ、多種多様なメトリクス、トレース、ログが得られます。これらのデータをGrafanaに抽出して簡単に可視化することで、ネットワークに関する様々な疑問にすぐに答えることができます。例えば、特定のサービスまたはすべてのクラスターの4xx HTTPレスポンスレートを知りたい場合や、パフォーマンスが最も低いサービス間のリクエスト/レスポンスのレイテンシを知りたい場合、Hubbleメトリクスが役立ちます。

ランタイムセキュリティ：可観測性と強制

しかし、コンテナのセキュリティはネットワークポリシーだけに関連するものではありません。コンテナランタイムもセキュリティポリシーの恩恵を受けます。Tetragonは、eBPFを用いたランタイムセキュリティの可観測性と実装に重点を置いています。Tetragonは、以下のようなセキュリティ上重要なイベントを幅広く検出し、報告することができます。

• プロセス実行イベント。
• システム コール アクティビティ。
• ネットワークやファイル アクセスなどの I/O アクティビティ。

TetragonはeBPFドライバ向けの最初のセキュリティツールではありませんでしたが、コンテナセキュリティに多くの新機能をもたらしました。他のプロジェクトがシステムコールにフックしているように見える場合、システムコールパラメータがカーネルに到達する前に上書きされる「Check-Time to Use」脆弱性の影響を受ける可能性があります。Ciliumのエンジニアはカーネル内部に関する知識を活用し、この問題の影響を受けないポイントでイベントにフックしました。

Tetragon のトレースポリシーを使用すると、監視するカーネルイベント、一致条件の定義、アクションの実行を設定できます。さらに重要なのは、Tetragon が Kubernetes ID に基づいてコンテキスト情報を提供することです。たとえば、特定のファイルまたはディレクトリへのアクセスを検出する場合、どのプロセス（どの実行ファイルを実行しているか）とどのポッドがファイルにアクセスしたかを正確に記録する `TracingPolicy` を設定できます。ファイルアクセスが完了する前に違反プロセスを終了するポリシーを設定することもできます。これは非常に強力で、コンテナセキュリティにまったく新しいアプローチを追加し、コンテナによって露出される攻撃対象領域を制限するのに役立ちます。Shazam のように、Tetragon はソロモンの知恵に恵まれ、豊富な知識と行動を決定する判断力を備えています。

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

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

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

以下は、Cilium サービスメッシュの仕組みを詳細に解説したブログ記事からのベンチマーク比較です。Cilium Envoy フィルターを実行する単一ノード規模の Envoy プロキシ（茶色）と、Istio Envoy フィルターを実行する双方向の自動車 Envoy モデル（青）の HTTP 処理における典型的なレイテンシコストを示しています。黄色は、プロキシと HTTP 処理がない場合のベースラインレイテンシを表しています。

Cilium Service Meshは、各Podにサイドカーとして接続するのではなく、各ノードのエージェントの一部として実行されるEnvoyネットワークプロキシを使用することで、このレイテンシ改善を実現しています。ただし、この改善は網羅的なものではありません。Ciliumは、ネットワークトラフィックをノード全体のEnvoyプロキシにリダイレクトする前に、eBPFを可能な限り活用しています。これは、ワイルドキャットに匹敵する、印象的なワンパンチ、あるいはツーパンチの組み合わせであり、ブルートフォースではなくタイミングとテクノロジーを活用して、望ましい結果を得ることができます。

これは新しいアプローチではありません。Ciliumでは長年にわたり、レイヤー7対応のネットワーク戦略を実装するためにEnvoyが使用されてきました。サイドカーフリーのサービスメッシュを実現するために、CiliumはKubernetesに完全準拠したIngressおよびGateway API実装のサポートに加え、Cilium内でEnvoyの全機能を公開する低レベルCRDも提供しています。現在サイドカーベースのサービスメッシュを使用しており、各Podにサービスメッシュサイドカーをデプロイすることに伴うリソースコストが気になり始めている方は、よりリソース効率の高い代替手段としてCilium Service Meshを検討する良い機会です。

Kubernetesだけではない

CiliumはKubernetesクラスタの文脈で議論されてきましたが、Kubernetesだけにとどまりません。Ciliumがもたらす接続性、可観測性、そしてセキュリティのメリットは、Kubernetes以外のワークロードでも実現可能です。例えば、Ciliumはスタンドアロンのロードバランサとして使用でき、実際の本番環境で大きなメリットが実証されています。