クラウドにおけるスケーリング：Istio Ambient vs. Cilium
大規模環境でのパフォーマンスの詳細分析
Istioの導入を検討しているユーザーからよく寄せられる質問は、「IstioはCiliumと比べてどうなのか？」というものです。Ciliumは当初、ネットワークポリシーを含むL3/L4機能のみを提供していましたが、最近のリリースではEnvoyを使用したサービスメッシュ機能とWireGuard暗号化が追加されました。Istioと同様に、CiliumはCNCFのGraduatedプロジェクトであり、コミュニティで長年利用されてきました。
表面上は同様の機能セットを提供しているにもかかわらず、2つのプロジェクトのアーキテクチャは大きく異なっており、最も顕著な違いは、カーネルでL4トラフィックを処理および暗号化するためのCiliumのeBPFとWireGuardの使用と、ユーザー空間でL4トラフィックを処理するためのIstioのztunnelコンポーネントとの対比です。これらの違いにより、Istioが大規模環境でCiliumと比較してどのように動作するのかについて、多くの憶測が飛び交っています。
2つのプロジェクトのテナントモデル、セキュリティプロトコル、基本的なパフォーマンスについては多くの比較が行われてきましたが、エンタープライズ規模での完全な評価はまだ公開されていません。理論的なパフォーマンスを強調するのではなく、IstioのアンビエントモードとCiliumを実際に試用し、レイテンシ、スループット、リソース消費などの主要な指標に焦点を当てました。現実的な負荷シナリオで負荷を高め、活気のあるKubernetes環境をシミュレートしました。最後に、AKSクラスターのサイズを1,000ノード、11,000コアまで拡張し、これらのプロジェクトが大規模環境でどのように動作するかを理解しました。その結果、それぞれが改善できる領域が明らかになったと同時に、Istioが明確な勝者であることも示されました。
テストシナリオ
IstioとCiliumの限界を試すために、それぞれ100個のポッドでバックアップされた500個の異なるサービスを作成しました。各サービスは個別の名前空間にあり、そこにはFortioロードジェネレータークライアントも1つ含まれています。コロケートされたクライアントからのノイズを排除するために、クライアントを100台の32コアマシンのノードプールに制限し、残りの900台の8コアインスタンスをサービスに割り当てました。
Istioテストでは、Istioのアンビエントモードを使用し、すべてのサービス名前空間にウェイポイントプロキシを配置し、デフォルトのインストールパラメータを使用しました。テストシナリオを類似させるために、CiliumではWireGuard暗号化、L7プロキシ、ノード初期化など、いくつかのデフォルト以外の機能を有効にする必要がありました。また、各名前空間にHTTPパスベースのルールを持つCiliumネットワークポリシーを作成しました。どちらのシナリオでも、1秒ごとにランダムに1つのサービスを85〜115インスタンスにスケーリングし、1分ごとに1つの名前空間のラベルを付け直すことで、チャーンを生成しました。正確な設定と結果の再現方法については、私のメモを参照してください。
スケーラビリティスコアカード
使用リソースを考慮すると、Istioはコアあたり2178クエリを処理したのに対し、Ciliumは1815クエリであり、20%の向上です。
- Ciliumの減速：Ciliumは、デフォルトのインストールパラメータでは低いレイテンシを誇っていますが、L7ポリシーや暗号化などのIstioの基本機能を有効にすると、大幅に減速します。さらに、CiliumのメモリとCPU使用率は、メッシュにトラフィックが流れていない場合でも高く推移しました。これは、特にクラスターが拡大するにつれて、クラスター全体の安定性と信頼性に影響を与える可能性があります。
- **Istio、安定したパフォーマンス:** 一方、Istioのアンビエントモードは、暗号化のオーバーヘッドが追加された場合でも、安定性と適切なスループットの維持に強みを発揮しました。テストではIstioはCiliumよりも多くのメモリとCPUを消費しましたが、負荷がかかっていない状態では、CPU使用率はCiliumのごく一部に落ち着きました。
舞台裏：違いの理由
これらのパフォーマンスの違いを理解する鍵は、各ツールのアーキテクチャと設計にあります。
- Ciliumの制御プレーンの難問：Ciliumは各ノードで制御プレーンインスタンスを実行するため、クラスターが拡大するにつれてAPIサーバーの負荷と設定のオーバーヘッドが増加します。これにより、APIサーバーが頻繁にクラッシュし、Ciliumが準備完了状態ではなくなり、クラスター全体が応答しなくなることがありました。
- Istioの効率性の優位性：Istioは、集中型制御プレーンとIDベースのアプローチにより、設定を合理化し、APIサーバーとノードの負担を軽減します。重要なリソースは、設定の処理ではなく、トラフィックの処理と保護に向けられます。Istioは、制御プレーンで使用されないリソースをさらに活用して、ワークロードが必要とする数のEnvoyインスタンスを実行しますが、Ciliumはノードあたり1つの共有Envoyインスタンスに制限されます。
さらに深く掘り下げる
このプロジェクトの目的はIstioとCiliumのスケーラビリティを比較することですが、いくつかの制約により直接比較が困難になります。
レイヤー4は必ずしもレイヤー4ではない
IstioとCiliumはどちらもL4ポリシーの適用を提供していますが、APIと実装は大きく異なります。CiliumはKubernetes NetworkPolicyを実装しており、ラベルと名前空間を使用してIPアドレスとの間のアクセスをブロックまたは許可します。IstioはAuthorizationPolicy APIを提供し、各リクエストの署名に使用されるTLS IDに基づいて許可と拒否を決定します。ほとんどの多層防御戦略では、包括的なセキュリティのためにNetworkPolicyとTLSベースのポリシーの両方を利用する必要があります。
すべての暗号化が同じように作成されるわけではない
CiliumはFIPS互換の暗号化にIPsecを提供していますが、L7ポリシーやロードバランシングなどの他のほとんどのCilium機能はIPsecと互換性がありません。CiliumはWireGuard暗号化を使用する場合の機能互換性がはるかに優れていますが、WireGuardはFIPS準拠の環境では使用できません。一方、IstioはTLSプロトコル標準に厳密に準拠しているため、デフォルトで常にFIPS準拠のmTLSを使用します。
隠れたコスト
Istioは完全にユーザー空間で動作しますが、CiliumのL4データプレーンはeBPFを使用してLinuxカーネルで動作します。リソース消費量のPrometheusメトリックはユーザー空間リソースのみを測定するため、Ciliumが使用するすべてのカーネルリソースはこのテストでは考慮されていません。
推奨事項：ジョブに適したツールの選択
では、評決はどうでしょうか？それは、具体的なニーズと優先順位によって異なります。純粋なL3/L4ユースケースで暗号化の必要がない小規模クラスターの場合、Ciliumは費用対効果が高く、パフォーマンスの高いソリューションを提供します。ただし、大規模クラスターで安定性、スケーラビリティ、高度な機能に重点を置く場合は、代替のNetworkPolicy実装と併せてIstioのアンビエントモードを使用することをお勧めします。多くのお客様は、多層防御戦略のために、CiliumのL3/L4機能とIstioのL4/L7および暗号化機能を組み合わせて使用することを選択しています。
クラウドネイティブネットワーキングの世界は常に進化していることを忘れないでください。IstioとCiliumはどちらも改善とこれらの課題への取り組みを続けているため、両方の開発に注目してください。
会話を続けましょう
IstioのアンビエントモードまたはCiliumを使用したことがありますか？あなたの経験や洞察は何ですか？以下のコメント欄であなたの考えを共有してください。お互いから学び、エキサイティングなKubernetesの世界を一緒にナビゲートしましょう！
