アンビエントメッシュのご紹介

本日、私たちは「アンビエントメッシュ」とその参照実装を発表できることを嬉しく思います。これは、簡素化された運用、より広範なアプリケーションとの互換性、およびインフラストラクチャコストの削減を目的とした、新しいIstioデータプレーンモードです。アンビエントメッシュにより、ユーザーはサイドカープロキシを使用せずに、インフラストラクチャに統合されたデータプレーンを利用するオプションが提供されます。同時に、Istioの中核機能であるゼロトラストセキュリティ、テレメトリ、トラフィック管理は維持されます。今後数ヶ月で本番環境対応を目指して開発中のアンビエントメッシュのプレビューをIstioコミュニティと共有します。

Istioとサイドカー

Istioのアーキテクチャを特徴づけるものとして、設立当初からサイドカーの使用がありました。サイドカーとは、アプリケーションコンテナと共に展開されるプログラム可能なプロキシです。サイドカーにより、オペレーターはアプリケーションの大幅な変更とその関連コストを必要とせずに、Istioのメリットを享受できます。

サイドカーはアプリケーションのリファクタリングよりも大きな利点がありますが、アプリケーションとIstioデータプレーンとの完全な分離を実現するわけではありません。そのため、いくつかの制限があります。

• 侵入性 - サイドカーは、Kubernetesポッドの仕様を変更し、ポッド内のトラフィックをリダイレクトすることによって、アプリケーションに「注入」する必要があります。その結果、サイドカーのインストールまたはアップグレードにはアプリケーションポッドの再起動が必要になり、ワークロードに支障をきたす可能性があります。
• リソースの未利用化 - サイドカープロキシは関連するワークロード専用であるため、各ポッドの最悪ケースの使用状況に合わせてCPUとメモリのリソースをプロビジョニングする必要があります。これは、クラスター全体のリソースの未利用化につながる可能性のある、大きな予約に追加されます。
• トラフィックの遮断 - Istioのサイドカーが通常行うトラフィックキャプチャとHTTP処理は計算コストが高く、準拠していないHTTP実装を持つ一部のアプリケーションを破壊する可能性があります。

サイドカーにはその役割がありますが（後述）、より侵襲性が低く、より簡単なオプションが必要であり、多くのサービスメッシュユーザーにとってより適していると考えています。

レイヤーのスライス

従来、Istioは、基本的な暗号化から高度なL7ポリシーまで、すべてのデータプレーン機能を単一のアーキテクチャコンポーネントであるサイドカーに実装していました。実際には、これはサイドカーをオールオアナッシングの提案にします。ワークロードが単純なトランスポートセキュリティのみを必要とする場合でも、管理者はサイドカーの展開とメンテナンスの運用コストを支払う必要があります。サイドカーは、ユースケースの複雑さに合わせてスケールしない、ワークロードあたりの固定運用コストを持っています。

アンビエントデータプレーンは異なるアプローチを取ります。Istioの機能を2つの異なるレイヤーに分割します。基本的には、トラフィックのルーティングとゼロトラストセキュリティを処理するセキュアオーバーレイがあります。必要に応じて、その上にL7処理を有効にして、Istioの機能の全範囲にアクセスできます。L7処理モードはセキュアオーバーレイよりも負荷が高いですが、それでもインフラストラクチャのアンビエントコンポーネントとして実行され、アプリケーションポッドの変更は必要ありません。

このレイヤー化されたアプローチにより、ユーザーはIstioをより段階的に導入し、メッシュなし、セキュアオーバーレイ、完全なL7処理に必要に応じて、名前空間ごとにスムーズに移行できます。さらに、異なるアンビエントレイヤーで実行されているワークロード、またはサイドカーを使用しているワークロードはシームレスに相互運用するため、ユーザーは時間とともに変化する特定のニーズに基づいて機能を自由に組み合わせることができます。

アンビエントメッシュの構築

Istioのアンビエントデータプレーンモードは、Kubernetesクラスターの各ノードで実行される共有エージェントを使用します。このエージェントはゼロトラストトンネル（またはztunnel）であり、その主な役割はメッシュ内の要素を安全に接続および認証することです。ノードのネットワークスタックは、参加しているワークロードのすべてのトラフィックをローカルのztunnelエージェントにリダイレクトします。これにより、Istioのデータプレーンの懸念事項とアプリケーションの懸念事項が完全に分離され、最終的にオペレーターはアプリケーションを妨げることなく、データプレーンの有効化、無効化、スケーリング、およびアップグレードが可能になります。ztunnelはワークロードトラフィックのL7処理を実行しないため、サイドカーよりもはるかに軽量です。この複雑さと関連するリソースコストの大幅な削減により、共有インフラストラクチャとして提供することが容易になります。

Ztunnelはサービスメッシュの中核機能であるゼロトラストを実現します。名前空間でアンビエントモードを有効にすると、セキュアオーバーレイが作成されます。これにより、HTTPの終了または解析を行わずに、ワークロードにmTLS、テレメトリ、認証、およびL4承認が提供されます。

アンビエントモードが有効になり、セキュアオーバーレイが作成された後、名前空間はL7機能を使用するように構成できます。Virtual Service API、L7テレメトリ、およびL7承認ポリシーなど、Istio機能の完全なセットを実装できます。このモードで動作する名前空間は、1つ以上のEnvoyベースのウェイポイントプロキシを使用して、その名前空間のワークロードのL7処理を処理します。Istioのコントロールプレーンは、クラスター内のztunnelを構成して、L7処理を必要とするすべてのトラフィックをウェイポイントプロキシに渡します。重要な点として、Kubernetesの観点から見ると、ウェイポイントプロキシは他のKubernetesデプロイメントと同様に自動スケーリングできる通常のポッドです。これにより、ユーザーのリソース節約が大幅に期待できます。ウェイポイントプロキシは、オペレーターが期待する最大最悪ケースの負荷ではなく、サービスを提供する名前空間の実時間トラフィック需要に合わせて自動スケーリングできるためです。

アンビエントメッシュは、mTLSを介したHTTP CONNECTを使用してセキュアートンネルを実装し、パスにウェイポイントプロキシを挿入します。これはHBONE（HTTPベースのオーバーレイネットワーク環境）と呼ばれるパターンです。HBONEは、独自のTLSよりもクリーンなトラフィックのカプセル化を提供すると同時に、一般的なロードバランサーインフラストラクチャとの相互運用性を可能にします。コンプライアンスのニーズを満たすために、デフォルトでFIPSビルドが使用されます。HBONE、その標準ベースのアプローチ、およびUDPやその他の非TCPプロトコルに関する計画の詳細については、今後のブログで提供します。

単一のメッシュでサイドカーモードとアンビエントモードを混在させても、システムの機能やセキュリティ特性に制限は導入されません。Istioコントロールプレーンは、選択された展開モデルに関係なく、ポリシーが適切に適用されることを保証します。アンビエントモードは、より良い人間工学と柔軟性を備えたオプションを導入するだけです。

ローカルノードでL7処理を行わない理由

アンビエントモードは、ノード上の共有ztunnelエージェントを使用し、メッシュのゼロトラストの側面を処理します。一方、L7処理は、別途スケジュールされたポッド内のウェイポイントプロキシで行われます。なぜ間接処理を使用し、ノード上の共有フルL7プロキシを使用しないのでしょうか？これにはいくつかの理由があります。

• Envoyは本質的にマルチテナントではありません。そのため、共有インスタンスで複数の制約のないテナントからのL7トラフィックの複雑な処理ルールを混在させることにセキュリティ上の懸念があります。L4処理に厳密に制限することで、脆弱性の表面積を大幅に削減します。
• ztunnelによって提供されるmTLSとL4機能は、ウェイポイントプロキシで必要なL7処理と比較して、はるかに小さいCPUとメモリフットプリントが必要です。ウェイポイントプロキシを共有名前空間リソースとして実行することにより、名前空間とそのコストのニーズに基づいて個別にスケーリングすることができ、関連のないテナントに不当に分散されることはありません。
• ztunnelの範囲を縮小することにより、明確に定義された相互運用性契約を満たすことができる他のセキュアートンネル実装に置き換えることができます。

しかし、追加のホップはどうでしょうか？

アンビエントモードでは、ウェイポイントは必ずしもサービスを提供するワークロードと同じノード上にあるとは限りません。一見するとパフォーマンス上の問題のように見えるかもしれませんが、レイテンシは最終的にIstioの現在のサイドカー実装と一致すると確信しています。専用の性能に関するブログ投稿で詳しく説明しますが、ここでは2点に要約します。

• 実際、Istioのネットワークレイテンシの大部分はネットワークから発生するわけではありません（最新のクラウドプロバイダーは非常に高速なネットワークを備えています）。代わりに、最大の原因は、Istioが高度な機能セットを実装するために必要な集中的なL7処理です。各接続に対して2つのL7処理ステップ（サイドカーごとに1つ）を実装するサイドカーとは異なり、アンビエントモードはこれら2つのステップを1つに統合します。ほとんどの場合、この処理コストの削減により、追加のネットワークホップが相殺されると予想されます。
• ユーザーは、最初のステップとしてゼロトラストセキュリティ体制を有効にするためにメッシュを展開し、必要に応じてL7機能を選択的に有効にすることがよくあります。アンビエントモードを使用すると、必要がない場合にL7処理のコストを完全に回避できます。

リソースオーバーヘッド

全体的に見て、Istioのアンビエントモードは、ほとんどのユーザーにとって、より少なく、より予測可能なリソース要件を持つと予想されます。ztunnelの限定的な責任により、ノード上の共有リソースとして展開できます。これにより、ほとんどのユーザーに必要なワークロードごとの予約が大幅に削減されます。さらに、ウェイポイントプロキシは通常のKubernetesポッドであるため、サービスを提供するワークロードの実時間トラフィック需要に基づいて動的に展開およびスケーリングできます。

一方、サイドカーは、各ワークロードの最悪のケースを想定してメモリとCPUを予約する必要があります。これらの計算は複雑なため、実際には管理者は過剰プロビジョニングする傾向があります。これにより、高い予約によって他のワークロードのスケジューリングが妨げられるため、ノードが過小利用されることになります。アンビエントモードのノードあたりの固定オーバーヘッドの低さと動的にスケールされるウェイポイントプロキシにより、集約されたリソース予約が大幅に削減され、クラスタの効率的な使用が可能になります。

セキュリティはどうですか？

根本的に新しいアーキテクチャには、セキュリティに関する疑問が当然生じます。アンビエントモードのセキュリティに関するブログでは詳細に説明していますが、ここでは要約します。

サイドカーは、それがサービスを提供するワークロードと共存するため、1つの脆弱性によってもう一方が侵害される可能性があります。アンビエントメッシュモデルでは、アプリケーションが侵害されたとしても、ztunnelとウェイポイントプロキシは、侵害されたアプリケーションのトラフィックに対して厳格なセキュリティポリシーを適用できます。さらに、Envoyは世界最大のネットワーク事業者によって使用されている成熟した実績のあるソフトウェアであるため、それが動作するアプリケーションよりも脆弱である可能性は低いです。

ztunnelは共有リソースですが、実行されているノード上のワークロードのキーのみにアクセスできます。したがって、そのブラスト半径は、暗号化のためにノードごとのキーに依存する他の暗号化されたCNIと同程度です。また、ztunnelのL4のみの限定的な攻撃対象領域と、前述のEnvoyのセキュリティ特性を考慮すると、このリスクは限定的で許容範囲内であると考えています。

最後に、ウェイポイントプロキシは共有リソースですが、1つのサービスアカウントのみにサービスを提供するように制限されています。これは、今日のサイドカーと同等です。ウェイポイントプロキシが1つ侵害された場合、そのウェイポイントに関連付けられた資格情報が失われ、それ以外何も影響を受けません。

これはサイドカーの終焉ですか？

決してそうではありません。アンビエントメッシュは今後多くのメッシュユーザーにとって最適な選択肢になると考えていますが、コンプライアンスやパフォーマンスチューニングなど、専用のデータプレーンリソースが必要なユーザーにとっては、サイドカーは引き続き良い選択肢です。Istioは引き続きサイドカーをサポートし、重要な点として、アンビエントモードとのシームレスな相互運用を可能にします。実際、本日リリースするアンビエントモードコードは、すでにサイドカーベースのIstioとの相互運用をサポートしています。

詳細はこちら

短いビデオを見て、ChristianがIstioアンビエントモードのコンポーネントを実行し、いくつかの機能をデモする様子をご覧ください。

参加方法

本日リリースしたのは、Istioのアンビエントモードの初期バージョンであり、現在も活発に開発中です。これをより広いコミュニティと共有し、2023年の本番環境への準備を進める中で、より多くの人々がその形成に関わってくれることを楽しみにしています。

ソリューションの形成に役立つ皆様からのフィードバックをいただければ幸いです。アンビエントモードをサポートするIstioのビルドは、ダウンロードして試すことができます。Istio Experimentalリポジトリにあります。不足している機能と作業項目のリストは、READMEで確認できます。ぜひお試しいただき、ご意見をお聞かせください！

アンビエントメッシュのローンチに貢献してくれたチームに感謝します！

• Google: Craig Box、John Howard、Ethan J. Jackson、Abhi Joglekar、Steven Landow、Oliver Liu、Justin Pettit、Doug Reid、Louis Ryan、Kuat Yessenov、Francis Zhou
• Solo.io: Aaron Birkland、Kevin Dorosh、Greg Hanson、Daniel Hawton、Denis Jannot、Yuval Kohavi、Idit Levine、Yossi Mesika、Neeraj Poddar、Nina Polshakova、Christian Posta、Lin Sun、Eitan Yarmush