アンダーレイにおけるUlti-Network Nsの応用について - このハンドブック

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

コンテナの場合、複数の名前空間テクノロジの重要性は強調しすぎることはありません。名前空間の出現により、コンテナが使用するホスト名、ネットワーク、マウント ポイントなどのリソースは分離され、パブリックから排他的になります。

技術の進歩は諸刃の剣である。マルチネームスペースベースのコンテナは、クラウド コンピューティング市場とクラウド コンピューティング インフラストラクチャ スタックをほぼ作り変えましたが、同時に急峻な学習曲線ももたらしました。

ネットワーク名前空間がその一例です。

今年の大学入試Ⅰの作文テーマを読みましたか？ 「基本手、素晴らしい手、常套手」は囲碁の3つの用語です。基本的な動きとは、チェスの原則に準拠した通常の動きを指します。素晴らしい動きとは、予想外の独創的な動きを指します。一般的な動きとは、合理的に見えても、全体的な観点から見ると通常は損害をもたらす動きを指します。初心者は基本的な動きから始めるべきです。基本的な動きの基礎をしっかり身に付けて初めて、チェスのスキルは向上します。初心者の中には、驚くべき動きを追求することに熱心で、より一般的に使用される基本的な動きを無視する人もいます。基礎スキルは土台であり、優れたスキルは創造です。一般的に言えば、自分の動きを深く理解している場合にのみ、素晴らしい動きをすることができます。そうしないと、必然的に下品な動きをすることになり、レベルを向上させることが難しくなります。

さあ、この記事では「基本の手」から始めましょう。次の記事では、「マスターストローク」の部分を見ていきます。この記事で説明した内容を少し変更し、アンダーレイでマルチネットワーク名前空間がどのように機能するかを見てみましょう。

マルチネットワーク名前空間

まず、次の図を参考にして、マルチネットワーク名前空間の一般的な使用方法を見てみましょう。以下のテキストでは、ネットワーク名前空間は network ns と記述されます。

図1: 複数のネットワークnsを含む環境

複数のネットワーク ns を含む環境です。これは 3 つの部分に分かれており、最上層は OS、中間層はネットワーク カード (物理または仮想)、最下層はネットワーク カードが接続されている外部 (物理) ネットワークです。

OS 部分には、ルート ネットワーク ns と、Pod が使用するその他のネットワーク ns が含まれます。

OS 部分には、eth や bridge (struct net_device) などのネットワーク デバイスも含まれます。図中の異なるネットワーク ns 内の eth は eth0 と呼ばれていますが、ルート ネットワーク ns 内の eth0 は他のネットワーク デバイスとは本質的に異なります。

• ルート ネットワーク ns の eth0 は、ネットワーク カードのソフトウェア抽象化であり、つまり外部デバイスに対応します。ネットワーク カードが物理カードである場合、eth0 にはデバイスを制御するための一連の機能も含まれます。
• 図中の他の eth0 とブリッジは、まったく存在しない仮想ネットワーク デバイスの抽象化です。簡単に言えば、それらは外部デバイスとやり取りしない単なるデータ構造です。これらのデータ構造の目的は、既存のコード ロジックと関数を可能な限り再利用することです。これらは、同じ OS 内でのプロセス間通信やユーザー モードおよびカーネル モードのデータ交換の媒体として使用できますが、外部通信には使用できません。たとえば、よく知られているループバック デバイスを使用すると、ローカル マシン上の 2 つのプロセス間のソケット通信が TCP/IP プロトコル スタックを完全に通過できるようになります。

ネットワーク名前空間

ネットワーク ns は、ネットワーク インターフェイス、ループバック デバイス、ネットワーク スタック、IP アドレス、ポートなどのネットワーク リソースを分離するために使用されます。その機能は構成可能なデータで構成されています。プロセスにとって、これらの要素は実際には、ネットワーク要求を開始して応答するための基本的な環境を構成します。ここでのいわゆる「ネットワーク スタック」には、ルーティング テーブル、ネットワーク フィルター、iptables ルールなどが含まれます。

Linux コンテナまたはホスト プロセスに表示される「ネットワーク スタック」は、実際にはそれぞれのネットワーク ns 内で分離されています。通信相手のネットワーク カード (一般的な veth ペアなど) も、対応する名前空間内で自然に分離されます。

よく言及される別のスタックとして、TCP/IP プロトコル スタックがあります。 TCP/IP プロトコル スタックはプログラムのコード部分、ネットワーク スタックはプログラムのデータ部分と考えることができます。当然のことながら、TCP/IP スタックは、プロセスやコンテナ、さらには qemu-kvm に基づく仮想マシンであっても、この OS 上のすべてのユーザーが共有する必要があります。すべてがホスト マシンのプロトコル スタックを共有しますが、ネットワーク スタックは各ネットワーク ns 専用です。

次男は、上記の説明がまだ抽象的すぎることを知っていました。そこで下の絵を描きました。図 2 は、カーネル内のプロセスを記述する task_struct データ構造とネットワーク ns 間の構造関係を示しています。プロセス 1 とプロセス 2 は、ネットワーク カード eth0 を含むホスト ルート ネットワーク ns を共有します。 Pod 内のコンテナは、当然のことながら、Pod 独自のネットワーク ns 内に配置されます。しかし、コンテナは本質的には単なるプロセスです。図では Pod が完全に独自の eth1 を分離しているように見えますが、カーネルの観点からは、同じデータ構造を使用して、それとネットワーク ns の関係を記述します。

このデータ構造図を読んだ後、TCP/IP プロトコル スタックの次の 2 つの説明が混乱しないことを願っています。

• ネットワーク パケットがコンテナ内のネットワーク カードから流出する場合でも、コンテナを離れた後に他のネットワーク デバイスとやり取りする場合でも、カーネル TCP/IP プロトコル スタックを通過する必要があります。
• ネットワーク パケットがコンテナーに属しているか、ホストのネイティブ プロセスに属しているかに関係なく、カーネル TCP/IP プロトコル スタックの場合、これらのネットワーク パケットは異なるネットワーク NS に属しているだけです。

図2: ネットワーク ns と task_struct 構造の関係図

ネットワーク機器

図 1 の OS 部分にネットワーク デバイス eth0 とブリッジが含まれていることにお気づきでしょう。

このうち、eth0 はカーネル内のデータ構造 net_device によって表される物理ネットワーク カードを記述するために使用されます。 net_device には何が含まれていますか?図3に重要な部分をいくつか描いてみました。簡単に言うと、物理ネットワークカードを操作するために使用されるnetdev_ops（set _mac / ioctlなど）、バスアドレス、IRQなどのBSP関連の設定、特定のネットワークカードモデルに関連する受信/送信リングキュー、IPアドレス設定などが含まれます。

eth0 はネットワーク ns に属しているため、複数のネットワーク ns がある場合、複数の eth0 が存在する可能性があります (すべてが eth0 に名前変更されている場合)。

図3: net_deviceの内容の一部を示す概略図

ブリッジは、ネットワーク ブリッジとも呼ばれ、仮想レイヤー 2 対話型マシンです。仮想ネットワーク デバイス veth/tap と一緒に使用して、物理スイッチとそれに接続された RJ-45 ネットワーク プラグをエミュレートします。

図 4 に示す環境では、ブリッジによって単純なサブ LAN を形成でき、ブリッジに接続されたデバイスは物理 LAN と同様にレイヤー 2 を介して相互に通信できます。このような通信はブリッジを離れる必要はなく、通常は同じワークノード上の異なるポッドが相互に通信するときに発生します。

図4: veth + ブリッジで構成されたサブLAN

ネットワーク パケットの宛先 MAC アドレスがブリッジ自体であり、ブリッジに IP アドレスがある場合、ブリッジはネットワーク パケットがブリッジを作成したホスト宛てであると認識します。データ パケットはどのデバイスにも転送されず、処理のために上位層 (レイヤー 3) プロトコル スタックに直接送信されます。この処理には、ローカル ルーティング テーブルに基づいたルーティング クエリが含まれます。

上記のプロセスは、図5と併せて理解することができます。たとえば、Pod が Baidu にアクセスしたい場合、リクエストは図の赤い線に沿って流れます。赤い線をパイプと考えると、Pod のリクエストはパイプの一方の端から流れ込みます。パイプの流出端は、ホスト プロトコル スタックの IP 層に接続されます。 iptables とルーティング テーブルによって処理された後、最終的にホスト マシンの eth0 を介してマシンから送信されます。

この場合、ホストマシンの eth0 はブリッジのゲートウェイとみなすことができると言えば、同意しますか?

詳細にご興味がおありの場合は、「Pod から Baidu にアクセスするときに VTEP が使用されますか?」をお読みください。

図5: ブリッジはトラフィックをホストに渡してレイヤー3の処理を行います

図5をもう少し拡大してみましょう。図 5 のネットワーク ns 内のルーティング テーブル、iptables、eth0、ブリッジを見てみましょう。ブリッジが Pod の Baidu へのアクセス要求を処理するときにトラフィックをルート ネットワーク ns に送信する方法と、ホスト マシンをゲートウェイとして使用してトラフィックを外部ネットワークに送信する方法を見てみましょう。

図6: ブリッジ処理データフローの拡大図