Alibaba Cloud コンテナネットワークデータリンクのパノラマ分析 (7): Terway DataPath V2 (Terway≥1.8.0)

オープンソースの中国コミュニティチームは、共有の名のもとに、オープンソースの中国コミュニティの背後にあるストーリーを伝える初のライブブロードキャストを行いました。」

著者：カイユウ

序文

近年、クラウドネイティブのエンタープライズインフラストラクチャの傾向はますます強くなり、初期の IaaS から現在のマイクロサービスに至るまで、きめ細かい改良と可観測性に対する顧客の要求がますます強くなっています。顧客の高性能化と高密度化に対応するために、コンテナネットワークは高速で開発、進化しており、必然的に顧客のクラウドネイティブネットワークの可観測性に対して非常に高いしきい値と課題をもたらします。クラウドネイティブネットワークの可観測性を向上させ、顧客や第一線の学生がビジネスリンクの可読性を向上しやすくするために、ACK Industrial Research と AES は共同で、顧客と学生を支援する一連のクラウドネイティブネットワークデータプレーンの可観測性を確立しました。フロントラインとバックラインの従業員は、クラウドネイティブネットワークアーキテクチャシステムを理解し、クラウドネイティブネットワークの可観測性のしきい値を簡素化し、顧客の運用とメンテナンスとアフターセールスの学生が困難な問題に対処するエクスペリエンスを最適化し、ネットワークのリンクの安定性を向上させます。クラウドネイティブネットワーク。

コンテナネットワークを鳥瞰すると、コンテナネットワーク全体は、ポッドネットワークセグメント、サービスネットワークセグメント、ノードネットワークセグメントの 3 つの部分に分割できます。これら 3 つのネットワークは相互接続とアクセス制御を実現する必要がありますが、実装のための技術原則は何でしょうか?リンク全体とは何ですか?また制限は何ですか?フランネルとターウェイの違いは何ですか?さまざまなモードでのネットワークパフォーマンスはどのようなものですか?これらは、コンテナ構築前にお客様自身のビジネスシナリオに基づいて選択する必要があり、構築完了後に関連するアーキテクチャを変更することはできないため、お客様は各アーキテクチャの特性を十分に理解する必要があります。たとえば、次の図は簡略化された図です。Pod ネットワークは、同じ ECS 内の Pod 間のネットワーク相互運用性と制御を実現する必要があり、また、SVC にアクセスする Pod のバックエンドは同じ ECS 内にある場合もあれば、異なる ECS 内の Pod 間のアクセスも実現する必要があります。これらの異なるモードでは、データリンク転送モードが異なり、ビジネス側からのパフォーマンス結果も異なります。

この記事は、[コンテナネットワークデータリンクのパノラマ分析] の第 7 部であり、主に Kubernetes Terway DataPath V2 モードのデータプレーンリンクの転送リンクを紹介します。まず、さまざまなシナリオにおけるデータプレーンの転送リンクを特定します。さまざまなシナリオにおけるアクセスリンクのデータサーフェスパフォーマンスは、コンテナネットワークのジッター、顧客の運用とメンテナンス、および Alibaba Cloud に遭遇した場合に、転送リンクを深く理解することによって、ビジネスアーキテクチャをさらに最適化するのに役立ちます。学生は、どのリンクポイントが展開されているかを手動で展開して観察し、問題の方向性と原因をさらに特定できます。

シリーズ 1: Alibaba Cloud コンテナネットワークデータリンクのパノラマ分析 (1) - Flannel

シリーズ 2: Alibaba Cloud コンテナネットワークデータリンクのパノラマ分析 (2) - Terway ENI

シリーズ 3: Alibaba Cloud コンテナネットワークデータリンクのパノラマ分析 (3) - Terway ENIIP

シリーズ 4: Alibaba Cloud コンテナネットワークデータリンクのパノラマ分析 (4) - Terway IPVLAN+EBPF

シリーズ 5: Alibaba Cloud コンテナネットワークデータリンクのパノラマ分析 (5) - Terway ENI-Trunking

シリーズ 6: Alibaba Cloud コンテナネットワークデータリンクのパノラマ分析 (6) - ASM Istio

Terway DataPath V2 パターンアーキテクチャ設計

Elastic Network Interface (ENI) は、複数の補助 IP を構成する機能をサポートしています。ENI マルチ IP モードは、インスタンスの仕様に従って、1 つの Elastic Network Interface (ENI) に 6 ～ 20 の補助 IP を割り当てることができます。これにより、ポッドのデプロイメントのサイズと密度が大幅に向上します。ネットワーク接続に関して、Terway は現在 veth ペアポリシールーティングと IPVLAN の 2 つのソリューションをサポートしていますが、コミュニティは cilium v1.12 以降、データプレーンの一貫性を統合するために IPVLAN のサポートを放棄しました。 ACK 進化はコミュニティと一致しており、クラウドネイティブ機能の統合が促進され、差別化が軽減されます。 v1.8.0 以降、Terway は IPvlan トンネルアクセラレーションをサポートしなくなりましたが、DataPath V2 を使用してデータプレーンを統合します。

ポッドによって使用される CIDR ネットワークセグメントは、ノードの CIDR と同じネットワークセグメントです。

ポッド内にはネットワークカード eth0 があり、eth0 の IP はポッドの IP です。このネットワークカードの MAC アドレスは、コンソール上の ENI の MAC アドレスと一致しません。同時に、複数の ethx が存在します。これは、ENI に接続されたネットワークカードがポッドのネットワーク名前空間に直接接続されていないことを意味します。

Pod には eth0 を指すデフォルトルートのみが存在します。これは、Pod が任意のアドレスセグメントにアクセスするとき、eth0 が統合された入り口と出口になることを意味します。

同時に、ECS 上には複数の ethx ネットワークカードがあります。これは、ENI に接続されたネットワークカードがポッドのネットワーク名前空間に直接マウントされていないことを意味します。

OS Linux ルーティングを通じて、ポッド IP 宛てのすべてのトラフィックがポッドに対応する calixx 仮想カードに転送されることがわかります。したがって、ECS OS とポッドのネットワーク名前空間は、完全なインバウンドおよびアウトバウンドのリンク構成を確立しています。

ENI マルチ IP の実装では、これは ACK コンテナネットワークデータリンク (Terway ENIIP) [ 2]の原理に似ており、Terway ポッドは Daemonset を通じて各ノードにデプロイされます。 terway-cli マッピングコマンドを使用すると、ノードに接続されている ENI の数、MAC アドレス、および各 ENI の IP を取得できます。

ポッドが SVC にアクセスするために、コンテナはさまざまなメソッドを使用してポッドが配置されている ECS レイヤーにリクエストを転送し、ECS の netfilter モジュールが SVC IP の解決を実装します。ただし、途中でカーネルプロトコルスタックを経由して、Podのネットワーク名前空間からECSのOSのネットワーク名前空間へデータリンクを切り替える必要があるため、仕組みがあると必然的にパフォーマンスの低下が発生します。高い同時実行性と高いパフォーマンスを追求すると、お客様のニーズに完全に応えられない可能性があります。 SVC アドレス変換のためにポッド内に eBPF をデプロイする IPVLAN モードと比較して、DataPath V2 モードの eBPF は各ポッドの calixxx ネットワークカードをリッスンして、ポッドとポッドのアクセスを高速化し、ポッドのアクセスのアドレスをSVC IP のリンクアクセラレーションについては、Terway ネットワークプラグインの使用を参照してモデルを比較できます[ 3]。

BPF ルーティング

5.10 カーネルの後、Cilium には eBPF ホストルーティング機能と 2 つの新しいリダイレクトメソッド、bpf_redirect_peer および bpf_redirect_neigh が追加されました。

bpf_redirect_peer

データパケットは、ホストの lxc インターフェイスを経由せずに、veth ペア Pod のインターフェイス eth0 に直接送信されるため、データパケットが CPU バックログキューに入る回数が減り、より良い転送パフォーマンスが得られます。
bpf_redirect_neigh

ポッド出力トラフィックの送信元 MAC アドレスと dst MAC アドレスを入力するために使用されます。トラフィックはカーネルのルートプロトコルスタック処理を通過する必要はありません。

したがって、Terway DataPath V2 モデル全体は次のように要約できます。

現在、低バージョンのカーネル (4.2 より前) は eBPF アクセラレーションをサポートしていません。Aliyun2 は部分的なアクセラレーション機能を取得でき、Aliyun3 は完全なアクセラレーション機能を取得できます。
ノードはポッドにアクセスするためにホストのプロトコルスタックを経由する必要がありますが、SVC へのポッドアクセスはホストのプロトコルスタックを経由しません。
DataPath V2 モードでは、ポッドが SVC IP にアクセスすると、SVC IP はポッドの veth ペア calixxx ネットワークカード上の eBPF によって SVC バックエンドポッドの IP に変換され、データリンクはホストプロトコルスタックをバイパスします。つまり、SVC IP は送信元ポッドの veth ペアでのみキャプチャされますが、宛先ポッドも、宛先ポッドが配置されている ECS もキャプチャされません。

Terway DataPath V2 モードのコンテナネットワークデータリンク分析

コンテナネットワークの特性に基づいて、Terway datapathv2 モードのネットワークリンクは、Pod IP を使用した外部サービスの提供と SVC を使用した外部サービスの提供という 2 つの大きな SOP シナリオに大別できます。これはさらに 11 の異なる小さな SOP シナリオに細分化できます。 .SOPシナリオ。

これら 15 のシナリオのデータリンクを組み合わせて結合すると、これらのシナリオは次の 8 つの典型的なシナリオに要約できます。

Pod IP にアクセスし、同じノードから Pod にアクセスします。
Pod IP へのアクセス、同じノード上の Pod 間の相互アクセス (Pod は同じ ENI に属します)
Pod IP へのアクセス、同じノード上の Pod 間の相互アクセス (Pod は異なる ENI に属します)
Pod IP へのアクセス、異なるノード間の Pod 間の相互アクセス
クラスター内のポッドによってアクセスされる SVC クラスター IP/外部 IP、SVC バックエンドポッドおよびクライアントポッドは同じ ECS および ENI に属します
クラスター内のポッドによってアクセスされる SVC クラスター IP/外部 IP、SVC バックエンドポッドおよびクライアントポッドは同じ ECS に属しますが、異なる ENI
クラスター内のポッドによってアクセスされる SVC クラスター IP/外部 IP、SVC バックエンドポッド、クライアントポッドは異なる ECS に属します
クラスターの外部から SVC 外部 IP にアクセスする

シナリオ 1: ポッド IP にアクセス、同じノードからポッドにアクセス (同じノードのノードアクセスバックエンド SVC ClusterIP を含む)

環境

nginx2-7ff4679659-xkpmm はノード xxx.10.0.1.219 に存在し、IP アドレスは 10.0.0.2 です。

カーネルルーティング

nginx2-7ff4679659-xkpmm、IP アドレス 10.0.0.2、ホスト内のコンテナーの PID は 5630、コンテナーネットワーク名前空間にはコンテナー eth0 を指すデフォルトルートがあります。

ECS OS のコンテナ eth0 の対応する veth ペアは cali10e985649a0 です。ECS OS には、ポッド IP を指すルートがあり、ネクストホップは calixxx であることがわかります。各ポッドの veth1。

次のコマンドを実行すると、nginx2-7ff4679659-xkpmm が eth2 アクセサリネットワークカードに割り当てられています。

kubectl --kubeconfig kubeconfig -n kube-system exec -it terway-eniip-v5v2p -c terway -- terway-cli マッピング

まとめ

ECS の eth0 は、nginx2-7ff4679659-xkpmm から返されたデータをキャプチャしましたが、送信されたデータはキャプチャしませんでした。

ECS の eth1 も、nginx2-7ff4679659-xkpmm から返されたデータをキャプチャしましたが、送信されたデータはキャプチャしませんでした。

cali10e985649a0 は、送受信されたパケットをキャプチャできます。

その後のサマリーには、データパケットの観測結果は表示されなくなります。

データリンク転送図 (Aliyun2&Aliyun3):

リンク全体は ECS とポッドのネットワークプロトコルスタックを通過します。
リクエストリンク全体は次のとおりです: ECS OS -> calixxx -> ECS Pod eth0

シナリオ 2: ポッド IP にアクセス、同じノード上のポッド間の相互アクセス (ポッドは同じ ENI に属します)

環境

nginx2-7ff4679659-xkpmm、IP アドレス 10.0.0.2 および centos-5bf8644bcf-jqxpk、IP アドレス 10.0.0.13 が xxx.10.0.1.219 ノードに存在します。

カーネルルーティング

centos-5bf8644bcf-jqxpk、IP アドレス 10.0.0.13、ホスト内のコンテナーの PID は 126938、コンテナーネットワーク名前空間にはコンテナー eth0 を指すデフォルトルートがあります。

ECS OS のこのコンテナ eth0 に対応する veth ペアは calia7003b8c36c です。ECS OS には、Pod IP を指すルートがあり、ネクストホップは calixxx であることがわかります。各ポッドに veth1 が含まれます。

次のコマンドにより、nginx2-7ff4679659-xkpmm と centos-5bf8644bcf-jqxpk が terway によって同じ eth2 アクセサリネットワークカードに割り当てられていることを取得できます。

kubectl --kubeconfig kubeconfig -n kube-system exec -it terway-eniip-v5v2p -c terway -- terway-cli マッピング

まとめ

アリユン2：

ポッドに割り当てられたセカンダリネットワークカードは経由しません。
リンク全体がポッドのネットワークプロトコルスタックを通過し、リンクがポッドのネットワーク名前空間を通じてピアに転送されると、eBPF によって高速化され、OS プロトコルスタックがバイパスされます。
リクエストリンク全体は次のようになります: ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2。

アリユン3：

ポッドに割り当てられたセカンダリネットワークカードは経由しません。
リンク全体は、eBPF 入力経由で宛先ポッドに直接加速され、宛先ポッドの calixxx ネットワークカードは経由しません。
リクエストのリンク全体は次のとおりです。

方向: ECS Pod1 -> Pod1 calixxx -> ECS Pod2。
戻り方向: ECS Pod2 -> Pod2 calixxx -> ECS Pod1。

シナリオ 3: ポッド IP にアクセス、同じノード上のポッド間の相互アクセス (ポッドは異なる ENI に属します)

環境

xxx.10.0.1.219 ノードには 2 つのポッド ngxin3-55f5c67988-p4qnb と centos-5bf8644bcf-jqxpk があり、それぞれ IP アドレスは 10.0.0.251 と 10.0.0.13 です。

このノードの terway ポッドについては、terway-cli マッピングコマンドを使用して、2 つの IP (10.0.0.251 および 10.0.0.13) が異なる ENI ネットワークカードに属し、OS レベルで eth1 および eth2 とみなされていることを取得します。

カーネルルーティング

ngxin3-55f5c67988-p4qnb、IP アドレス 10.0.0.251、ホスト内のコンテナーの PID は 5630、コンテナーネットワーク名前空間にはコンテナー eth0 を指すデフォルトルートがあります。

ECS OS のこのコンテナ eth0 に対応する veth ペアは cali08203025d22 です。ECS OS には、Pod IP を指すルートがあり、ネクストホップは calixxx であることがわかります。各ポッドに veth1 が含まれます。

まとめ

アリユン2：

ポッドに割り当てられたセカンダリネットワークカードは経由しません。
リンク全体がポッドのネットワークプロトコルスタックを通過し、リンクがポッドのネットワーク名前空間を通じてピアに転送されると、eBPF によって高速化され、OS プロトコルスタックがバイパスされます。
リクエストリンク全体は次のようになります: ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2。

アリユン3：

ポッドに割り当てられたセカンダリネットワークカードは経由しません。
リンク全体は、eBPF 入力経由で宛先ポッドに直接加速され、宛先ポッドの calixxx ネットワークカードは経由しません。
リクエストのリンク全体は次のとおりです。
- 方向: ECS Pod1 -> Pod1 calixxx -> ECS Pod2。
- 戻り方向: ECS Pod2 -> Pod2 calixxx -> ECS Pod1。

シナリオ 4: ポッド IP へのアクセス、異なるノード間のポッド間の相互アクセス

環境

centos-5bf8644bcf-jqxpk は xxx.10.0.1.219 ノード上に存在し、IP アドレスは 10.0.0.13 です。

nginx1-7bcf4ffdb4-6rsqz は xxx.10.0.5.27 ノード上に存在し、IP アドレスは 10.0.4.121 です。

terway-cli show Factory コマンドを使用すると、IP 10.0.0.13 が centos-5bf8644bcf-jqxpk に属し、MAC アドレスが xxx.10.0.1.219 の 00:16:3e:0d:74:23 である ENI ネットワークカードを取得できます。。

同様に、nginx1-7bcf4ffdb4-6rsqz の IP 10.0.4.121 は、xxx.10.0.5.27 上の MAC アドレス 00:16:3e:0c:ef:6c を持つ ENI ネットワークカードに属します。

カーネルルーティング

nginx1-7bcf4ffdb4-6rsqz、IP アドレス 10.0.4.121、ホスト内のコンテナーの PID は 7745、コンテナーネットワーク名前空間にはコンテナー eth0 を指すデフォルトルートがあります。

ECS OS のこのコンテナ eth0 に対応する veth ペアは cali06cd16bb25f です。ECS OS には、Pod IP を指すルートがあり、ネクストホップは calixxx であることがわかります。各ポッドに veth1 が含まれます。

まとめ

アリユン2：

ホスト OS のネットワーク名前空間を通過しますが、プロトコルスタックリンクは eBPF によって高速化されます。
リンク全体は、クライアントポッドが属する ENI ネットワークカードから ECS の外に出て、宛先ポッドが属する ENI ネットワークカードから ECS に入る必要があります。
リクエストリンク全体は、ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2 calixxx -> ECS2 Pod2 です。

アリユン3：

リンク全体は、クライアントポッドが属する ENI ネットワークカードから開始し、ECS を通過して、宛先ポッドが属する ENI ネットワークカードから ECS に入る必要があります。
リクエストのリンク全体は次のとおりです。
- 方向: ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2。
- 回方向：ECS2 Pod2 -> ECS2 Pod2 calixxx -> ECS2 ENI ethx -> VPC -> ECS1 ENI ethx -> ECS1 Pod1。

シナリオ 5: クラスター内のポッドによってアクセスされる SVC クラスター IP/外部 IP、SVC バックエンドポッド、およびクライアントポッドは、同じ ECS および同じ ENI に属します。

環境

nginx2-7ff4679659-xkpmm、IP アドレス 10.0.0.2 および centos-5bf8644bcf-jqxpk、IP アドレス 10.0.0.13 が xxx.10.0.1.219 ノードに存在します。

このうち、nginx2-7ff4679659-xkpmm Pod は SVC nginx2 のエンドポイントです。

カーネルルーティング

カーネルルーティングはシナリオ 2 と似ているため、ここでは説明しません。

eBPF に関しては、datapathv2 では、eBPF は Pod 内ではなく OS レベルで calixxx ネットワークカードをリッスンします。 eBPF を呼び出す cilium の機能を使用すると、グラフィカルコマンドを通じて centos-5bf8644bcf-jqxpk と nginx2-7ff4679659-xkpmm の ID ID をそれぞれ 693 と 2702 として取得できます。

ポッドが terway-eniip-v5v2p として配置されている ECS の Terway ポッドを見つけて、Terway ポッドで cilium bpf lb list | 192.168.152.119 コマンドを実行して、クラスター IP 192.168.152.119 の eBPF に記録されたバックエンドを取得します。 :80 を 10.0 .0.2:80 とします。

まとめ

クライアント Pod centos-5bf8644bcf-jqxpk から SVC にアクセスします。

クライアントの centos-6c48766848-znkl8 calia7003b8c36c ネットワークカードの監視は、SVC IP とクライアントのポッド IP をキャプチャできます。

Pod centos-6c48766848-znkl8 が属する接続されたネットワークカードの ENI で観察すると、関連するトラフィックパケットがキャプチャされておらず、トラフィックがクライアントの calixx ネットワークカードから ENI への eBPF 変換を受けたことを示しています。

Pod nginx2-7ff4679659-xkpmmI の cali10e985649a0 観察では、centos と nginx の Pod IP のみがキャプチャできます。

Cilium は監視機能を提供します。 cilium Monitor --popular-to <エンドポイント ID> を使用すると、ソースポッド IP が SVC IP 192.168.152.119 にアクセスし、SVC バックエンドポッド IP 10.0.0.2 に解決されます。 SVC IP は tc 層で直接転送されます。

アリユン2：

リンク全体がポッドのネットワークプロトコルスタックを通過し、リンクがポッドのネットワーク名前空間を通じてピアに転送されると、eBPF によって高速化され、OS プロトコルスタックがバイパスされます。
リンクリクエスト全体は、ポッドによって割り当てられた ENI を通過しません。
SVC IP は、クライアントポッドの calixxx ネットワークカード上の eBPF を通じて SVC バックエンドポッドの IP に変換され、後続のノードは SVC IP をキャプチャできません。
リクエストリンク全体は次のようになります: ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2。

アリユン3：

リンク全体がポッドのネットワークプロトコルスタックを通過し、リンクがポッドのネットワーク名前空間を通じてピアに転送されると、eBPF によって高速化され、OS プロトコルスタックがバイパスされます。
リンクリクエスト全体は、ポッドによって割り当てられた ENI を通過しません。
SVC IP は、クライアントポッドの calixxx ネットワークカード上の eBPF を通じて SVC バックエンドポッドの IP に変換され、後続のノードは SVC IP をキャプチャできません。
リンク全体は、eBPF 入力経由で宛先ポッドに直接加速され、宛先ポッドの calixxx ネットワークカードは経由しません。
リクエストのリンク全体は次のとおりです。
- 方向: ECS Pod1 -> Pod1 calixxx -> ECS Pod2。
- 戻り方向: ECS Pod2 -> Pod2 calixxx -> ECS Pod1。

シナリオ 6: クラスター内のポッドによってアクセスされる SVC クラスター IP/外部 IP、SVC バックエンドポッド、およびクライアントポッドは、同じ ECS に属しますが、ENI が異なります

環境

xxx.10.0.1.219 ノードには、IP アドレス 10.0.0.251 の ngxin3-55f5c67988-p4qnb と IP アドレス 10.0.0.13 の centos-5bf8644bcf-jqxpk があります。

このうち、ngxin3-55f5c67988-p4qnb Pod は SVC nginx3 のエンドポイントです。

カーネルルーティング

カーネルルーティングはシナリオ 3 と似ているため、ここでは説明しません。

eBPF に関しては、datapathv2 では、eBPF は Pod 内ではなく OS レベルで calixxx ネットワークカードをリッスンします。 eBPF を呼び出す cilium の機能を使用すると、グラフィカルコマンドを通じて centos-5bf8644bcf-jqxpk と ngxin3-55f5c67988-p4qnb の ID ID をそれぞれ 693 と 94 として取得できます。

ポッドが terway-eniip-v5v2p として配置されている ECS の Terway ポッドを見つけます。 Terway ポッドで cilium bpf lb list -A5 192.168.239.183 コマンドを実行すると、クラスター IP の eBPF に記録されたバックエンドを取得できます。 192.168.239.183:80 は 10.0.2:80 です。

まとめ

クライアント Pod centos-5bf8644bcf-jqxpk から SVC にアクセスします。

クライアントの centos-6c48766848-znkl8 calia7003b8c36c ネットワークカードの監視は、SVC IP とクライアントのポッド IP をキャプチャできます。

ポッド centos-6c48766848-znkl8 の接続されたネットワークカード ENI および ngxin3-55f5c67988-p4qnb の接続されたネットワークカード ENI で観察されると、関連するトラフィックがキャプチャされず、トラフィックがクライアントの calixx ネットワークカードから SVC 関連のトラフィックに変換されたことが示されています。 eBPF によるエンドポイントの後、宛先の calixxx ネットワークカードに直接短絡されます。

Pod ngxin3-55f5c67988-p4qnb が属する cali08203025d22 を観測すると、centos と nginx の Pod IP のみが取得できます。

Cilium は監視機能を提供します。 cilium Monitor --popular-to <endpoint ID> を使用すると、ソース Pod IP が SVC IP 192.168.239.183 にアクセスし、SVC バックエンド Pod IP 110.0.0.251 に解決されることを取得できます。 SVC IP は tc 層で直接転送されます。

以降のセクションで SVC IP アクセスが関係する場合、類似点がある場合は詳細な説明を省略します。

アリユン2：

ホスト OS のネットワーク名前空間を通過しますが、プロトコルスタックリンクは eBPF によって高速化されます。
リンクリクエスト全体は、ポッドによって割り当てられた ENI を通過しません。
SVC IP は、クライアントポッドの calixxx ネットワークカード上の eBPF を通じて SVC バックエンドポッドの IP に変換され、後続のノードは SVC IP をキャプチャできません。
リクエストリンク全体は、ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS2 Pod2 calixxx -> ECS2 Pod2 です。

アリユン3：

ポッドに割り当てられたセカンダリネットワークカードは経由しません。
リンク全体は、eBPF 入力経由で宛先ポッドに直接加速され、宛先ポッドの calixxx ネットワークカードは経由しません。
SVC IP は、クライアントポッドの calixxx ネットワークカード上の eBPF を通じて SVC バックエンドポッドの IP に変換され、後続のノードは SVC IP をキャプチャできません。
リクエストのリンク全体は次のとおりです。

方向: ECS Pod1 -> Pod1 calixxx -> ECS Pod2。
戻り方向: ECS Pod2 -> Pod2 calixxx -> ECS Pod1。

シナリオ 7: クラスター内のポッドによってアクセスされる SVC クラスター IP/外部 IP、SVC バックエンドポッド、およびクライアントポッドは異なる ECS に属しています

環境

centos-5bf8644bcf-jqxpk は xxx.10.0.1.219 ノード上に存在し、IP アドレスは 10.0.0.13 です。

nginx1-7bcf4ffdb4-6rsqz は xxx.10.0.5.27 ノード上に存在し、IP アドレスは 10.0.4.121 です。

このうち、nginx1-7bcf4ffdb4-6rsqz Pod は SVC nginx1 のエンドポイントです。

カーネルルーティング

ポッドは SVC のクラスター IP にアクセスし、SVC のバックエンドポッドとクライアントポッドは異なる ECS にデプロイされます。このアーキテクチャは、シナリオ 4: 異なるノード間のポッド間の相互アクセス[ 4]に似ていますが、このシナリオは SVC のクラスター IP にアクセスします。。クラスター IP の eBPF 転送については、シナリオ 5 とシナリオ 6 を参照してください。

まとめ

アリユン2：

ホスト OS のネットワーク名前空間を通過しますが、プロトコルスタックリンクは eBPF によって高速化されます。
リンク全体は、クライアントポッドが属する ENI ネットワークカードから ECS の外に出て、宛先ポッドが属する ENI ネットワークカードから ECS に入る必要があります。
リクエストリンク全体は、ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2 calixxx -> ECS2 Pod2 です。

アリユン3：

リンク全体は、クライアントポッドが属する ENI ネットワークカードから開始し、ECS を通過して、宛先ポッドが属する ENI ネットワークカードから ECS に入る必要があります。
リクエストのリンク全体は次のとおりです。
- 方向: ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2。
- 回方向：ECS2 Pod2 -> ECS2 Pod2 calixxx -> ECS2 ENI ethx -> VPC -> ECS1 ENI ethx -> ECS1 Pod1。

シナリオ 8: クラスターの外部から SVC 外部 IP にアクセスする

環境

nginx1-7bcf4ffdb4-6rsqz は xxx.10.0.5.27 ノード上に存在し、IP アドレスは 10.0.4.121 です。

SVCを記述することで、SVC nginxのバックエンドにnginx Podが追加されたことがわかります。 SVC のクラスター IP は 192.168.190.78 です。

カーネルルーティング

SLB コンソールでは、2 つのバックエンド nginx ポッドの ENI eni-j6cgs979ky3evxxx である lb-3nsj50u4gyz623nitxxx 仮想サーバーグループのバックエンドサーバーグループを取得できます。

クラスタの外側から見ると、SLB のバックエンド仮想サーバ群は SVC のバックエンド Pod が属する ENI ネットワークカードであり、イントラネットの IP アドレスが Pod のアドレスになります。

まとめ

アリユン2：

ExternalTrafficPolicy がローカルモードまたはクラスターモードの場合、SLB はポッドによって割り当てられた ENI のみを SLB 仮想サーバーグループにマウントします。
データリンクは、ポッドの Veth の calixxx ネットワークカードを通過します。
データリンク: クライアント -> SLB -> ポッド ENI + ポッドポート -> ECS1 Pod1 calixxx -> ECS1 Pod1 eth0。

アリユン3：

ExternalTrafficPolicy がローカルモードまたはクラスターモードの場合、SLB はポッドによって割り当てられた ENI のみを SLB 仮想サーバーグループにマウントします。
データリンクは、ECS に接続されたネットワークカード上の eBPF によって加速され、ポッドの Veth の calixxx ネットワークカードをバイパスし、ポッドのネットワーク名前空間に直接入ります。
データリンク: クライアント -> SLB -> ポッド ENI + ポッドポート -> ECS1 Pod1 eth0。

関連リンク：

[1] 非推奨の IPVLAN サポート

https://docs.cilium.io/en/v1.12/operations/upgrade/#deprecated-options

[2] ACKコンテナネットワークデータリンク(Terway ENIIP)

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dicate/user-guide/ack-network-fabric-terway-eniip

[3] Terwayネットワークプラグインを使用する

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dicate/user-guide/work-with-terway

[4] 異なるノード間の Pod 間の相互アクセスhttps://help.aliyun.com/zh/ack/ack-managed-and-ack-dicate/user-guide/ack-network-fabric-terway-eni-trunking # RS9Nc