AmbientとSidecarの共存におけるネットワークトラフィックパスの詳細分析
AmbientとSidecarの共存におけるトラフィックパスの詳細分析。
Istioには、AmbientモードとSidecarモードの2つのデプロイメントモードがあります。前者はまだ開発途上にあり、後者は従来のモードです。したがって、AmbientモードとSidecarモードの共存は通常のデプロイメント形式となり、このブログがIstioユーザーにとって役立つと考えられます。
背景
最新のマイクロサービスアーキテクチャでは、サービス間の通信と管理が不可欠です。この課題に対処するために、サービスメッシュ技術であるIstioが登場しました。Istioは、Sidecarを利用することで、トラフィック制御、セキュリティ、優れたオブザーバビリティを提供します。Istioの適応性と柔軟性をさらに向上させるために、Istioコミュニティは新しいモードであるAmbientモードの開発に着手しました。このモードでは、Istioは明示的なSidecarインジェクションに依存せず、ztunnelとWaypointプロキシを介してサービス間の通信とメッシュ管理を実現します。Ambientは、リソース消費の削減、デプロイの簡素化、設定オプションの柔軟性向上など、一連の改善をもたらします。Ambientモードを有効にすると、Podを再起動する必要がなくなり、Istioはさまざまなシナリオでより効果的に機能します。
Ambientを紹介および分析するブログは多数あり、このブログの参考資料セクションに記載されています。このブログでは、IstioのAmbientモードとSidecarモードにおけるネットワークトラフィックパスを分析します。
ネットワークトラフィックパスを明確にし、理解しやすくするために、このブログ記事では、対応する図を使用して以下の2つのシナリオを検討します。
- AmbientモードのサービスからSidecarモードのサービスへのネットワークパス
- SidecarモードのサービスからAmbientモードのサービスへのネットワークパス
分析に関する情報
この分析はIstio 1.18.2に基づいており、Ambientモードではリダイレクトにiptablesを使用しています。
Ambientモードの`sleep`からSidecarモードの`httpbin`へ
最初のシナリオのデプロイと設定
- `sleep`は名前空間fooにデプロイされます
- `sleep` PodはノードAにスケジュールされます
- `httpbin`は名前空間barにデプロイされます
- `httpbin` PodはノードBにスケジュールされます
- foo名前空間はAmbientモードを有効にします(foo名前空間にはラベル`istio.io/dataplane-mode=ambient`が含まれています)
- bar名前空間はSidecarインジェクションを有効にします(bar名前空間にはラベル`istio-injection: enabled`が含まれています)
上記の記述に基づくと、デプロイとネットワークトラフィックパスは次のようになります。
Ambientモードが有効になっている場合、ztunnelはistio-system名前空間にDaemonSetとしてデプロイされます。また、istio-cniとztunnelは、各ノードのztunnel PodとPodの両方にiptablesルールとルートを生成します。
Ambientモードが有効になっているPodに出入りするすべてのネットワークトラフィックは、ネットワークリダイレクトロジックに基づいてztunnelを経由します。ztunnelは、トラフィックを正しいエンドポイントに転送します。
Ambientモードの`sleep`からSidecarモードの`httpbin`へのネットワークトラフィックパスの分析
上記の図に従って、ネットワークトラフィックパスの詳細は以下のとおりです。
**(1)(2)(3)** `sleep`サービスのリクエストトラフィックは、`sleep` Podの`veth`から送信されます。iptablesルールとルートルールに従って、トラフィックはノード内の`istioout`デバイスにマークされ、転送されます。ノードAの`istioout`デバイスはGeneveトンネルであり、トンネルのもう一方の端は同じノードのztunnel Pod内にある`pistioout`です。
**(4)(5)** トラフィックが`pistioout`デバイスに到着すると、Pod内のiptablesルールがトラフィックをインターセプトし、Pod内の`eth0`インターフェースを介してポート`15001`にリダイレクトします。
**(6)** 元のリクエスト情報に基づいて、ztunnelはターゲットサービスのエンドポイントリストを取得できます。次に、`httpbin` Podの1つなど、エンドポイントへのリクエストの送信を処理します。最終的に、リクエストトラフィックはコンテナネットワークを介して`httpbin` Podに到達します。
**(7)** `httpbin` Podに到着したリクエストトラフィックは、iptablesルールによってインターセプトされ、Sidecarのポート`15006`を介してリダイレクトされます。
**(8)** Sidecarはポート15006を介して着信するインバウンドリクエストトラフィックを処理し、トラフィックを同じPod内の`httpbin`コンテナに転送します。
Sidecarモードの`sleep`からAmbientモードの`httpbin`と`helloworld`へ
2番目のシナリオのデプロイと設定
- `sleep`は名前空間fooにデプロイされます
- `sleep` PodはノードAにスケジュールされます
- `httpbin`は名前空間bar-1にデプロイされます
- `httpbin` PodはノードBにスケジュールされます
- `httpbin`のWaypointプロキシは無効になっています
- `helloworld`は名前空間bar-2にデプロイされます
- `helloworld` PodはノードDにスケジュールされます
- `helloworld`のWaypointプロキシは有効になっています
- WaypointプロキシはノードCにスケジュールされます
- foo名前空間はSidecarインジェクションを有効にします(foo名前空間にはラベル`istio-injection: enabled`が含まれています)
- bar-1名前空間はAmbientモードを有効にします(bar-1名前空間にはラベル`istio.io/dataplane-mode=ambient`が含まれています)
上記の記述に基づくと、デプロイとネットワークトラフィックパスは次のようになります。
Sidecarモードの`sleep`からAmbientモードの`httpbin`へのネットワークトラフィックパスの分析
`sleep` Pod(Sidecarモード)から`httpbin` Pod(Ambientモード)へのリクエストのネットワークトラフィックパスは、上記の図の上半分に示されています。
**(1)(2)(3)(4)** `sleep`コンテナは`httpbin`にリクエストを送信します。リクエストはiptablesルールによってインターセプトされ、`sleep` PodのSidecarのポート`15001`にリダイレクトされます。次に、Sidecarはリクエストを処理し、istiod(コントロールプレーン)から受信した設定に基づいてトラフィックをルーティングし、ノードBの`httpbin` Podに対応するIPアドレスにトラフィックを転送します。
**(5)(6)** リクエストがデバイスペア(`veth httpbin <-> httpbin Pod内のeth0`)に送信されると、iptablesルールとルートルールを使用してリクエストがインターセプトされ、`httpbin` Podが実行されているノードBの`istioin`デバイスに転送されます。ノードBの`istioin`デバイスと、同じノードのztunnel Pod内の`pistion`デバイスは、Geneveトンネルで接続されています。
**(7)(8)** リクエストがztunnel Podの`pistioin`デバイスに入ると、ztunnel Pod内のiptablesルールがトラフィックをインターセプトし、Pod内で実行されているztunnelプロキシのポート15008にリダイレクトします。
**(9)** ポート15008に着信するトラフィックはインバウンドリクエストと見なされ、ztunnelはリクエストを同じノードBの`httpbin` Podに転送します。
Waypointプロキシを介したSidecarモードの`sleep`からAmbientモードの`httpbin`へのネットワークトラフィックパスの分析
図の上部と比較して、下部は`sleep`、ztunnel、`httpbin` Pod間のパスにWaypointプロキシを挿入しています。Istioコントロールプレーンは、サービスメッシュのすべてのサービス情報と設定を保持しています。`helloworld` PodがWaypointプロキシでデプロイされると、`sleep` Pod Sidecarが受信する`helloworld`サービスのEDS設定が`envoy_internal_address`のタイプに変更されます。これにより、Sidecarを通過するリクエストトラフィックがHTTP Based Overlay Network (HBONE)プロトコルを介してノードCのWaypointプロキシのポート15008に転送されます。
WaypointプロキシはEnvoyプロキシのインスタンスであり、コントロールプレーンから受信したルーティング設定に基づいてリクエストを`helloworld` Podに転送します。トラフィックがノードDの`veth`に到達すると、前のシナリオと同じパスをたどります。
まとめ
Sidecarモードは、Istioを優れたサービスメッシュにしたものです。ただし、Sidecarモードでは、アプリコンテナとSidecarコンテナを同じPodで実行する必要があるため、問題が発生する可能性があります。Istio Ambientモードは、集中型プロキシ(ztunnelとWaypoint)を介してサービス間の通信を実装します。Ambientモードは、メッシュ内の各PodにSidecarが必要ないため、柔軟性とスケーラビリティが向上し、リソース消費が削減され、より正確な設定が可能になります。したがって、AmbientモードがIstioの次の進化形であることは間違いありません。Ambientモードはまだアルファ段階にあり、Sidecarモードが依然としてIstioの推奨モードですが、SidecarモードとAmbientモードの共存は非常に長い間続く可能性があります。Ambientモードがベータ版および将来のリリースに向けて進むにつれて、ユーザーはIstioサービスメッシュを実行および採用するためのより軽量なオプションを得ることができます。