Kubernetes コンテナ ネットワーク モデルの分析

クラウド ネイティブは、クラウドとネイティブの 2 つの部分で構成される技術システムまたはエコシステムと考えることができます。クラウドとは、アプリケーションが従来のデータセンターではなくクラウドに配置されることを意味します。ネイティブとは、アプリケーションが最初からクラウド環境を念頭に置いて設計され、クラウド向けに設計され、クラウドで最適に実行され、クラウド プラットフォームの弾力性と分散の利点を最大限に活用して発揮することを意味します。

[[435838]]

クラウド ネイティブの代表的なテクノロジー システムには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。この記事では、主にコンテナ技術に基づくコンテナ オーケストレーション エコシステム K8S のネットワーク トラフィック モデルを分析し、クラウド ネイティブ エコシステムにおけるコンテナ技術の応用と実装について、誰もがより深く理解できるようにします。

Kubernetes はフラットなアドレス空間、非 NAT ネットワーク構造に基づいており、ホストとコンテナ間のポート マッピングは必要ありません。このネットワーク モデルの主な特徴は、ホストとコンテナー間でポートをマッピングする必要がなくなることです。まず、全体的なアーキテクチャ トポロジ モデルを見てみましょう。

コンテナ ネットワークには主に次のアドレスが関係します。

• ノード IP: 物理マシンのアドレス。
• Pod Ip: Kubernetes の最小のデプロイメント単位は Pod です。 Pod には 1 つ以上のコンテナを含めることができます。簡単に言えば、コンテナには独自の個別のアドレスがありません。これらは Pod のアドレスとポート範囲を共有します。
• ClusterIp: サービスの IP アドレス。仮想 IP アドレスであるため、外部ネットワークはアドレスに対して ping を実行できません。このアドレスを担当するネットワーク デバイスはありません。内部実装では、Iptables ルールを使用してローカル ポートにリダイレクトし、バックエンド Pod にバランスを取ります。 Kubernetes クラスター内の内部アクセスにのみ使用されます。
• パブリック IP: クラスター IP 範囲プール内のサービス オブジェクトに割り当てられた IP は内部的にのみアクセスでき、アプリケーション内のレイヤーとして適しています。このサービスがフロントエンド サービスとして使用され、クラスター外部の顧客にサービスを提供する準備ができている場合は、このサービスにパブリック IP を提供する必要があります。

コンテナネットワークトラフィックモデル

1. POD内のコンテナ間の通信

Pod 内のコンテナは、「localhost」を介して相互に通信できます。同じネットワーク名前空間を使用します。コンテナ自体の場合、ホスト名はそのポッドの名前になります。 Pod 内のすべてのコンテナは同じ IP アドレスとポート空間を共有するため、接続を受信する必要があるコンテナごとに異なるポートを割り当てる必要があります。つまり、Pod 内のアプリケーションはポートの使用を自ら調整する必要があります。

内部実装メカニズム: 同じポッド内のコンテナは実際には同じ名前空間を共有するため、同じ IP とポート空間を使用します。名前空間は、Pause と呼ばれる小さなコンテナーによって実装されます。 Pod が作成されるたびに、最初に Pause コンテナが作成されます。その後、Pod 内の他のコンテナは、Pause コンテナのネットワーク スタックを共有して外部 Pod と通信します。したがって、同じ Pod 内のすべてのコンテナでは、表示されるネットワーク ビューは同じになります。コンテナ内に表示されるアドレス、つまり Pod アドレスは、実際には Pause コンテナの IP アドレスです。全体的なモデルは次のとおりです。

2. 同一ホスト上のPOD間の通信

各ノード上の各ポッドには独自の名前空間があります。同じホスト上の Pod はどのように相互に通信するのでしょうか?通信のために 2 つの Pod 間で Vet ペアを確立できますが、コンテナが複数ある場合は、Vet をペアで確立するのは非常に面倒です。 N 個のポッドがある場合、n(n-1)/2 個の Veth ペアを作成する必要がありますが、これはスケーラビリティが非常に低くなります。これらの Veth ペアを集中転送ポイントに接続できれば、それらを均一に転送するのが非常に便利になります。この集中転送ポイントは、以下に示すように、ブリッジと呼ばれることが多いものです。

3. ホスト間のPOD間の通信

現在、ネットワーク上の 2 つのエンドポイント間の相互通信には、主に 2 つのソリューションがあります。1 つはアンダーレイ直接相互通信に基づくもので、両者が互いのルーティング情報を持っている必要があり、ルーティング情報はアンダーレイ パス上に存在する必要があります。 1 つは、トンネルを介した相互通信を実現するオーバーレイ ソリューションに基づいています。アンダーレイ層では、ホストに到達可能であることを確認するだけで十分です。代表的なネットワーク ソリューションとしては、Calico (ダイレクト モード) や Macvlan などがあります。後者には、オーバーレイ、OVS、フランネル、ウィーブが含まれます。この記事では、Flannel プラグインと Calico プラグインについて簡単に紹介します。

フランネルプラグイン

Flannel は CoreOS によって開発されたプロジェクトであり、コンテナ間およびホスト間のネットワークを改善するために設計された、コンテナ オーケストレーション システムにおけるネットワーク ファブリックの最も成熟した例の 1 つです。

他のソリューションと比較すると、Flannel はインストールと構成が比較的簡単です。これは単一のバイナリ ファイル Flanneld としてパッケージ化されており、多くの一般的な Kubernetes クラスター デプロイメント ツールと多くの Kubernetes ディストリビューションでは、デフォルトで Flannel をインストールできます。 Flannel は、Kubernetes クラスターの既存の Etcd クラスターを使用して API 経由で状態情報を保存できるため、専用のデータ ストアは必要ありません。ワークフロー図は次のとおりです。

基本的なプロセスは次のとおりです。

1. アドレスの割り当て

Flanneld が初めて起動されると、etcd から構成された Pod ネットワーク セグメント情報を取得し、このノードに未使用のアドレス セグメントを割り当てて、flanneldl.1 ネットワーク インターフェイスを作成します (flannel1 など、他の名前を持つ場合もあります)。 Flannel は、割り当てられた Pod ネットワーク セグメント情報を /run/flannel/docker ファイルに書き込みます (ファイル名は k8s のバージョンによって異なります)。その後、Docker はこのファイル内の環境変数を使用して docker0 ブリッジを設定し、このアドレス セグメントがこのノードに属するようにします。

2. ルーティング

各ホスト上で、Flannel は flanneld と呼ばれるデーモン プロセスを実行し、カーネル内にルーティング テーブルを作成します。

3. データプレーンのカプセル化

Flannel は外部のカプセル化アドレスを認識した後、メッセージをカプセル化します。送信元は独自の物理 IP アドレスを使用し、宛先はピアの Vxlan 外部 Udp ポート 8472 を使用します (UDP カプセル化でデフォルトの宛先ポートとして 8285 が使用される場合、これについては後述します)。ピアはポートを監視するだけで済みます。ポートはメッセージを受信すると、そのメッセージを Flannedld プロセスに送信します。このプロセスは、カプセル化のためにメッセージを Flanned インターフェイスに送信し、次にローカル ルーティング テーブルを照会して宛先アドレスを取得します。

Flannel 関数は、内部的に次の 3 つの異なるバックエンド実装をサポートしています。

• Host-gw: 2 つのホストが同じネットワーク セグメントに存在する必要があり、クロスネットワークをサポートしていないため、大規模な展開には適していません。
• UDP: カーネルが Vxlan をサポートしていない場合、またはデバッグに使用されない限り、使用はお勧めしません。非推奨となりました。
• Vxlan: Vxlan カプセル化。Flannel は Vxlan テクノロジーを使用して、相互に通信できる各ノードの Pod ネットワークを作成します。使用されるポートは Udp 8472 です (パブリック クラウド AWS などではこのポートを開く必要があります)。

Calico プラグイン

Calico は 3 つのルーティング モードをサポートしています。

• 直接: メッセージをカプセル化せずにルーティング転送します。
• Ip-In-Ip: Calico のデフォルトのルーティング モード。データ プレーンは IP カプセル化を使用します。
• Vxlan: vxlan カプセル化。

この記事では主にダイレクト モードを紹介します。ダイレクト モードでは、ソフト ルーティングを使用して BGP を確立し、コンテナ ネットワーク セグメントをアナウンスします。これにより、ネットワーク全体のすべてのノードとネットワーク デバイスが相互にルーティング情報を持ち、アンダーレイを介して直接転送します。 Calico 実装の全体的な構造は次のとおりです。

データ通信プロセスは次のとおりです。データ パケットは最初に veth デバイスから他のポートに送信され、ホスト マシン上の Cali から始まる仮想ネットワーク カードに到着します。この端に到達すると、ホスト マシン上のネットワーク プロトコル スタックにも到達し、ルーティング テーブルを照会して転送します。ローカル マシンは Bird を介して RR と BGP ネイバー関係を確立するため、ローカル コンテナ アドレスが RR に送信され、ネットワーク内の他のノードに反映されます。同様に、他のノードのネットワーク アドレスもローカル マシンに送信され、Felix プロセスによって管理されてルーティング テーブルに送信されます。メッセージがルーティング ルールに一致すると、正常に転送できます。より複雑な Iptables ルールについては、スペースの制限により、今回は分析しません。

4. クラスタ内のサービスクラスタIPと外部アクセス

Serice および外部通信シナリオの実装には、多くの iptables 転送原則が関係します。これらを簡単に紹介します。

ポッドとサービスの通信: ポッドが互いの IP アドレスを認識している場合、ポッドは IP アドレスを介して直接通信できます。 Kubernetes クラスターでは、Pod が頻繁に破棄および作成される可能性があるため、Pod の IP アドレスは固定されません。この問題を解決するために、Service は Pod にアクセスするための抽象化レイヤーを提供します。バックエンドの Pod がどのように変更されても、サービスは外部サービスを提供する安定したフロントエンドとして機能します。同時に、サービスは高可用性と負荷分散機能も提供します。サービスは、リクエストを適切なポッドに転送する役割を担います。

外部通信: Pod IP またはサービス クラスター IP のいずれであっても、Kubernetes クラスター内でのみ表示されます。外部の世界では、これらの IP は非公開です。 Kubernetes は、外部が Pod と通信するための 2 つの方法を提供します。

NodePort: サービスは、クラスター ノードの静的ポートを通じて外部にサービスを提供します。外部からは以下の方法でサービスにアクセスできます。

LoadBalancer: サービスは、クラウド プロバイダーが提供するロード バランサーを使用して外部にサービスを提供します。クラウド プロバイダーは、ロード バランサーのトラフィックをサービスに送信する責任を負います。