Pod から Baidu にアクセスするときに VTEP が使用されますか?

みなさんこんにちは。私は次男です。

公開アカウントのフォロワーからプライベートメッセージが届き、次のような質問を受けました。「ポッドから外部ネットワークへのアクセス プロセスには VTEP が関係しますか?」関係する NAT の詳細は何ですか?

それをざっくり整理してこの記事を書きました。

公開アカウントに書き始めて半年ほどになります。ここで少し考えてみましょう。私にとって、各記事のトピックの選択、記事に含まれる知識ポイントの編集、研究、整理、執筆はすべてトレーニングのプロセスです。あなたにとっては、ほんの数分間の短い滞在です。私たちにとって、それはコミュニケーションのつながりです。利益はまったくなく、少しは誤った評判があるかもしれませんが、それは決して私の当初の意図ではありませんでした。

関連トピック

記事「​​Tun デバイスの魔法の使用 - フランネル UDP モード​​」では、Tun デバイスの助けを借りていくつかの高解像度の写真を描き、ポッドが相互に通信するときのデータ フロー、このデータ フロー プロセスに関係するネットワーク デバイス、およびこれらのデバイスが各ネットワーク パケットをそれぞれの位置で慎重に処理して移動する方法について友人と詳細に話し合いました。

その記事には、ポッド間のネットワーク通信のシナリオが含まれています。 K8s Overlay ネットワーク モデルでは、このプロセスでは、ポッドに出入りするトラフィックに対して NAT は必要ありません。 VXLAN を使用すると、トラフィックがカプセル化されるため、ホスト ネットワークは Pod トラフィックの詳細を気にしたり確認したりする必要がありません。

しかし、Pod が www.baidu.com などのインターネットにアクセスしようとすると、シナリオは異なります。まず、VXLAN はここでは役に立ちません。 VXLAN は、通信に関与する作業ノードの VTEP を使用して、それぞれパケットのカプセル化とカプセル化解除を実行します。明らかに、外部リモート サービスにはこれと同等の VTEP は存在しません。 2 番目に、VXLAN を使用する必要はありません。

実際、NAT がここで関係していることは、誰でも多かれ少なかれ推測したり漠然と感じたりすることができます。しかし、私は次のような詳細な質問をせずにはいられません。

• NATは本当に必要ですか?
• NAT が必要な場合、Pod a の観点から見ると、NAT では送信ネットワーク パケットの IP またはポートを変更するため、ネットワーク パケットが戻ってきたときに再度変更できるように、変更される前のこれらの接続の情報を記憶しておく必要があります。では、この接続情報はどこに記録されるのでしょうか?
• NAT プロセスはどこで行われますか?ポッド内ですか、それともホスト上ですか?具体的には、NAT が発生するとネットワーク パケットはどこに流れるのでしょうか?

まず最初の質問に答えると、トラフィックがホスト マシンから出るときに NAT が必ずしも必要というわけではありません。これは、K8s で使用されるネットワーク モデルによって異なります。たとえば、アンダーレイ モデルでは、NAT を使用する必要はありません。詳細については、次兄の「VPC と 3 つの K8s ネットワーク モデルのマルチ画像概要」をご覧ください。ただし、オーバーレイ モデルでは NAT が非常に必要となるため、この記事のシナリオはオーバーレイ モデルに限定されます。

さらに、この記事で説明する NAT はワーカー ノード レベルにのみ到達します。ネットワーク パケットが作業ノードを離れてから最終的に Baidu サーバーに到達するまでの間に、途中で複数の NAT を通過する可能性があることはわかっていますが、それを制御することはできません。しかし、次兄は「Wide Angle - Let's Talk About Underlay」という記事で、データセンターのネットワーク トポロジの高解像度の図を描きました。興味があれば開いて見てみてください。

さあ、本題に入りましょう。

ネットフィルター接続トラック

いつものように、NAT に関わる基本から始めます。

Netfilter conntrack は CT とも呼ばれ、接続追跡を意味します。追跡可能なプロトコルの接続状態を維持するカーネルモジュール (nf_conntrack) です。現在サポートされているプロトコルは、TCP、UDP、ICMP、DCCP、SCTP、GRE の 6 つだけです。

追跡に関しては、記録、検索、およびバックトラックのためのマークまたはマークのグループが必要です。ここで CT は、各ネットワーク パケット内の送信元 IP、宛先 IP、送信元ポート、宛先ポート、プロトコルの 5 つのパラメータで構成されるタグのセットを使用します。もっと簡単に言えば、CT は、これら 5 つのパラメータを使用して単方向接続を一意に識別できると考えています。これは一方向の接続であることに注意してください。ネットワーク通信には、送信と返信という 2 つの単方向接続が含まれます。

このマシンの CT レコードを表示するには、conntrack -L コマンドを使用できます。次の表に示すように、最初のエントリには出発方向と帰路方向の両方が記録されます。このような各レコードは、接続追跡エントリ (conntrack エントリ) と呼ばれます。

 # 接続トラック- L
 udp 17 172 src = 127.0.0.1 dst = 127.0.0.53 sport = 59837 dport = 53 src = 127.0.0.53 dst = 127.0.0.1 sport = 53 dport = 59837 [ 保証済み] mark = 0 use = 1
 tcp 6 5 TIME_WAIT src = 127.0.0.1 dst = 127.0.0.1 sport = 35074 dport = 2379 src = 127.0.0.1 dst = 127.0.0.1 sport = 2379 dport = 35074 [ 確実] mark = 0 use = 1

conntrack エントリがどのようなものかを確認したので、レコードがどこで発生するかを見てみましょう。次の図では、ルート名前空間のルーティング + iptables に、楕円でマークされた 2 つの conntrack が表示されます。 1 つは PREROUTING チェーンの近くにあり、もう 1 つは OUTPUT チェーンの近くにあります。

これら 2 つのフック ポイントが接続追跡レコードを作成するのはなぜですか?これらは、新しい接続の最初のパケットが到着する最初の場所であるためです。

• PRE_ROUTING は、外部パケットまたはローカル マシン上の他のネットワーク ネームスペースから発信されたパケットが最初に到着する場所です。 eth0 から来るパケットは外部パケットですが、1.5 の cni0 ブリッジから来るパケットはローカル マシン上の他のネットワーク ネームスペースのパケットです。
• LOCAL_OUT は、ローカル マシンがルート ネットワーク ネームスペースを介して他の相手とアクティブに通信するときに、ネットワーク パケットが最初に到着する場所です。ここでの「相手」とは、外部サービス、またはローカル マシン上にあっても別のネットワーク名スペースを使用しているプロセスである可能性があります。

もちろん、新しく作成された conntrack エントリが新しい単方向接続に対応していること、およびこの接続の最初のパケットがまだ有効であり、さまざまな処理後に破棄されていないことを確認するために、LOCAL_IN および POSTROUTING で確認操作が実行されます。これはこの記事の焦点では​​ないので、省略します。

特別な状況がない限り、上記の conntrack エントリは、後で使用するために PREROUTING チェーンと OUTPUT チェーンに正常に記録されていると大まかに想定できます。

図1: Pod aから外部ネットワークにアクセスする際のデータフロー

NAT

接続追跡は、Kubernetes Service、ServiceMesh サイドカー、ソフトウェア 4 層ロード バランサー LVS/IPVS、Docker ネットワーク、OVS、iptables ホスト ファイアウォールなど、多くのネットワーク アプリケーションの基礎であり、これらはすべて接続追跡機能に依存しています。 NAT は CT とさらに切り離せない関係にあります。

上の図を使用して、Pod a が Baidu にアクセスしたときに、ネットワーク パケットがプロトコル スタックを通過し、ルーティング テーブルと iptables の組み合わせのアクションによって何が起こるかを確認してみましょう。

www.baidu.com の IP アドレスは 180.101.49.11 で、Pod a の IP アドレスは 10.244.0.2 です。

1.1: Pod a から開始されたリクエストは、1.1 から 1.5 まで送信されます。詳細については、私の次男がすでに「​​Tun デバイスの魔法の使用 - Flannel UDP モード​​」で説明しているので、ここでは省略します。

1.6:ブリッジがネットワーク パケットをネットワーク層に配信すると、ネットワーク パケットは 1.6 のルート ネットワーク名前空間で新たな旅を始めます。同様に、1.1 から 1.4 では、ネットワーク パケットは引き続き Pod a 自身のネットワーク名前空間内でのみ循環します。 1.5 では、ネットワーク パケットは 1 つのネットワーク名前空間から別のネットワーク名前空間に移動しました。

1.7:前のセクションで述べたように、ここでの conntrack は新しい接続を記録します。

1.8:ルーティング選択後、ネットワーク パケットはホスト マシンの eth0 から発信される必要があります。そこで、FORWARD チェーンをたどって POSTROUTING チェーンにたどり着きました。

1.9:次は NAT シーンです。以下の iptables ダンプと組み合わせると、ソース IP が CIDR 10.244.0.0/16 にあり、docker0 インターフェイスに送信されていない場合は、NAT が実行されることがわかります。 Pod a の送信元 IP アドレスをノード 1 の IP アドレスに変更します。

1.10:リンク層へのネットワーク パケットの送信を開始します。

1.11:ネットワーク パケットは eth0 からホストから送信されます。

 - A POSTROUTING - s 10.244.0.0 / 16 ! - o docker0 - j マスカレード

問題をもう一度見てみましょう

Pod が Baidu にアクセスするときの CT と NAT の介入の詳細を読んだ後、学生の質問「Pod a が Baidu にアクセスしたときに VTEP が介入しないのはなぜですか?」を整理してみましょう。

図 2 は、「Tun デバイスの魔法の使用 - Flannel UDP モード」という記事からの画像です。これは、ノード 1 の Pod a がノード X の Pod b にアクセスする際のデータ フローを詳しく説明しています。理解を容易にするために、Flannel VXLAN モードで使用される VTEP を、UDP モードで使用される tun デバイス + flannel デーモンの組み合わせに置き換えました。この変更は、元々カーネル状態にあったデータの解凍とカプセル化の操作をユーザー状態デーモンに移動するだけで、名前は変更されたものの、実質的な変更ではありません。

Pod a からリクエストが開始されると、外部ネットワークにアクセスするか別の Pod にアクセスするかに関係なく、図 1 および 2 の 1.1 から 1.5 までのプロセスは変更されません。

ネットワーク パケットが 1.5 からネットワーク層に入ると、ネットワーク パケットの宛先が変わります。

• Pod間の通信であれば、ネットワークパケットは図2の1.7～1.9を経由して流れ、その後に続くデータパケット処理を完了します。
• 対照的に、Pod が Baidu にアクセスすると、ネットワーク パケットは図 1 の 1.9 で NAT によって処理され、パケットのカプセル化プロセスや VTEP の介入なしに、1.11 で直接ホストから送信されます。

図2: ポッド間の通信時のデータフロー

上記がこの記事の全内容です。