TUN デバイスの魔法 - フランネル UDP モード

みなさんこんにちは。私は次男です。 「トロイの木馬 - 図解 VXLAN コンテナ ネットワーク通信ソリューション」という記事で、次兄が次のような鳥瞰図を描いてくれました。これは、Flannel VXLAN モードに基づいて実装された K8s Overlay ネットワーク モデルに必要なさまざまなネットワーク デバイスをまとめたもので、主にこれらのデバイス間のデータ フローに焦点を当てています。しかし、その記事にはいくつかの欠点があります (Versailles):

• 添付の図では、これらのネットワーク デバイスとプロトコル スタックの相対的な位置があまりよく示されていません。
• コンテナにとって、ネットワーク名前空間は非常に重要な分離方法ですが、この図ではその重要性が十分に示されていません。
• この記事では、重要なネットワーク パケット カプセル化ノードについて明確に説明されていません。ローカル ルーティングに従って、cni0 は Pod a から送信された要求を flannel.1 に転送します。具体的に何が起こるのでしょうか?
• この図は、Flannel VXLAN モード用に作成されています。効率性を高めるために、VXLAN モードでは、すべてのカプセル化とカプセル化解除が VXLAN カーネル モジュールによって実行されることがわかっています。なぜなら、本質的には目に見えず、実体がなく、したがってより抽象的だからです。 K8s Overlay ネットワーク モデルはすでにかなり複雑であり、これを学習して理解することはさらに困難になります。

図1: フランネルに基づくオーバーレイネットワークモデルのデバイス関係図

新たな視点

私の次兄はとても思いやりのある人なので、特別に下の絵を描いてあげました。別の視点から見ると、いくつかの重要な側面が強調されます。

• 各 Pod には独自のネットワーク名前空間があり、したがって独自のルーティング テーブル + iptables があります。これは、図の 2 つのデータ パス 1.1 ~ 1.3 と 2.9 ~ 2.11 に明確に示されています。各ノードに複数のルーティング テーブルと iptables があることがわかります。このノードには複数のネットワーク名前空間があるため、これは簡単に説明できます。
• コンテナは本質的にプロセスであることを強調するために、各ポッド内のコンテナを最上位のユーザー状態の位置に描画します。
• リンク層には、veth、bridge、eth0、tun など、いくつかの種類のネットワーク デバイスが表示されます。これらはすべて、オーバーレイ ネットワーク モデルに欠かせない重要なデバイスです。しかし、その機能が何であれ、それらはすべてリンク層に配置する必要があります。そうですね、自分のポジションを見つけることが大切です。
• この図は、Flannel UDP モード用に作成されています。図 1 の VXLAN カーネル モジュールを tun デバイスと flannel デーモンに分解し、ユーザー モードに移動すると、データのカプセル化とカプセル化解除が実行される正確な場所とデータ フローの方向を明確に確認できます。 Flannel UDP モードは効率の問題によりエンジニアリングの価値はありませんが、私たちの研究には最適です。

図2: デバイスとプロトコルスタックの関係図

図 2 では、ポッド a の IP アドレスは 10.244.0.2 で、ポッド b の IP アドレスは 10.244.1.3 です。左の図では、ブリッジ cni0 に IP アドレス 10.244.0.1 が割り当てられており、右の図では、ブリッジの IP アドレスは 10.244.1.1 です。すべては図 1 と同じままですが、視点が変わっただけです。この話は、左側のポッド a のコンテナが右側のポッド b にリクエストを開始するところから始まります。つまり、src IP は 10.244.0.2、dest IP は 10.244.1.3 です。 1.x は、コンテナ内でのネットワーク パケットの生成から、ネットワーク パケットがネットワーク カードから送信されるまでの、ノード 1 上の完全なプロセスを表します。同様に、2.x は、ネットワーク カードが要求を受信して​​から、その要求が最終的に Pod b のコンテナーに送信されるまでの、ノード X 上の完全なプロセスを表します。この図は応答プロセスを示していないため、図内の矢印はすべて一方向になります。実際、すべての矢印を反転することが応答プロセスです。これからの道は曲がりくねった山道ですので、お座りください、親愛なるお客様。もうすぐ出発します。

ポッドで起こった物語

1.2 このロケーション ルーティング テーブル + iptables は、Pod 内のコンテナのネットワーク ルーティングを制御するために使用されます。 Pod a のコンテナでは、10.244.0.1 がゲートウェイの役割を果たし、図では 10.244.0.1 がブリッジ cni0 になります。以下は 1.2 のルーティング テーブルです。

 # Pod a のコンテナ上
$ ルート -n
宛先ゲートウェイ Genmask フラグ メトリック参照 Iface の使用
デフォルト 10.244.0.1 0.0.0.0 UG 0 0 0 eth0
 10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

もう一度強調する必要がある概念が 1 つあります。1.2 と 1.6 では異なるネットワーク名前空間に属する 2 つのルーティング テーブルがありますが、TCP/IP プロトコル スタックは 1 つだけです。つまり、プロトコル スタックの場合、同じデータ構造の異なるデータ インスタンスを処理するだけです。

完璧な移行

ネットワーク パケットが 1.4 に沿ってブリッジ cni0 に流れ込むと、ブリッジの特別な機能を使用して、ネットワーク パケットを 1 つのネットワーク名前空間から別のネットワーク名前空間に完全にジャンプするという魔法のような効果が得られます。

ブリッジはネットワーク ブリッジであり、その動作はレイヤー 2 スイッチに似ています。ネットワーク パケットの宛先 MAC アドレスがブリッジ自体であり、ブリッジに IP アドレスがある場合、ブリッジはネットワーク パケットがブリッジを作成したホストに送信される必要があると判断します。したがって、このネットワーク パケットはブリッジによってどのデバイスにも転送されず、処理のために上位層 (レイヤー 3) プロトコル スタックに直接渡されます。この処理には、ローカル ルーティング テーブルに基づいたルーティング クエリが含まれます。 1.6 のルーティング テーブルがその役割を果たし始めます。宛先 IP が 10.244.1.3 であるため、ネットワーク パケットは tun デバイス flannel.1 に送信する必要があります。

 # ホストマシン ノード 1
 $ ルート -n
宛先ゲートウェイ Genmask フラグ メトリック参照 Iface の使用
デフォルト 17.168.0.1 0.0.0.0 UG 0 0 0 eth0
 10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
 10.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 フランネル.1
 17.168.0.3 17.168.0.3 255.255.255.255UG 0 0 0 eth0

実は、1.4 ～ 1.5 にはさらに興味深い問題が関わってきます。たとえば、ネットワーク パケットは veth ペア間でどのように流れるのでしょうか?ブリッジ内でネットワーク パケットはどのように処理されますか?しかし、これはこの記事の焦点では​​ないので、後で説明します。しかし、まずは図3を載せておきます。この画像は、私の記事「画像を見てストーリーを書こう: veth データフローについて話しましょう」でご覧になったことがあるかもしれません。その記事の写真を元に橋の加工詳細を追加しました。この場所については、機会があれば後で詳しくお話ししたいと思います。

図3: veth + ブリッジネットワークパケット受信プロセスにおけるブリッジ処理の詳細

逆にやってみよう

ノード X がノード 1 からデータを受信すると、そのデータは 2.1 を経由して最終的に 2.11 に到達し、そこでポッド b がポッド a からのリクエストを受信します。ご覧のとおり、矢印の方向が異なることを除けば、図 2 の左側と右側の部分はほぼ同じです。はい、実際に絵を描くときは、貼り付け、コピーして、矢印の方向を一括変更するだけです。

右図の位置 2.6 と 2.10 にあるルーティング テーブルと iptables の機能は、左図のものと同じなので、ここでは繰り返しません。旅は困難でしたが、ついに到着しました。この記事はここで終わります。