Kubernetes PodでIPアドレスを取得する方法

Kubernetes ネットワーク モデルの主要な要件の 1 つは、各 Pod に独自の IP アドレスがあり、クラスター内のすべての Pod がこの IP アドレスを使用して通信できることです。このネットワーク モデルを実装するネットワーク プロバイダーは複数あります (flannel、calico、canal など)。

Kubernetes でネットワークを設定する方法は複数あり、コンテナ ランタイムにも複数のオプションがあります。この記事では、ネットワーク プロバイダーとして Flannel を使用し、コンテナー ランタイムとして Containerd を使用します。

1. 背景コンセプト

1. コンテナネットワーク: 非常に簡単な概要

コンテナ ネットワークの仕組みを説明する非常に優れた投稿がいくつかあります。背景として、ここでは Linux ブリッジ ネットワークとパケット カプセル化を含む単一のアプローチを使用して、非常に高レベルの概要を説明します。ここでは詳細は省略します。

2. 同じホスト上のコンテナ

同じホスト上で実行されているコンテナが IP アドレスを介して相互に通信する方法の 1 つは、Linux ブリッジを使用することです。 Kubernetes (および Docker) の世界では、これを実現するために veth (仮想イーサネット) デバイスが作成されました。この veth デバイスの一方の端はコンテナ ネットワーク名前空間に接続され、もう一方の端はホスト ネットワーク上の Linux ブリッジに接続されます。同じホスト上のすべてのコンテナでは、この veth ペアの一端が Linux ブリッジに接続され、ブリッジを介して IP アドレスを使用して相互に通信できます。 Linux ブリッジにも IP アドレスが割り当てられ、ポッドから別のノードへの出力トラフィックのゲートウェイとして機能します。

3. 異なるホスト上のコンテナ

異なるホスト上で実行されているコンテナが IP アドレスを介して相互に通信する方法の 1 つは、パケットのカプセル化を使用することです。 Flannel は、元のパケットを UDP パケットにラップして宛先に送信する vxlan を通じてこの機能をサポートします。

Kubernetes クラスターでは、Flannel は各ノードに VXLAN デバイスといくつかのルーティング テーブル エントリを作成します。異なるホスト上のコンテナに送信される各データ パケットは、vxlan デバイスを通過し、UDP パケットにカプセル化されます。宛先では、カプセル化されたパケットが取得され、パケットはターゲット Pod にルーティングされます。

注: これは、コンテナ間のネットワークを構成する方法の 1 つにすぎません。

4. CRIとは何ですか?

CRI (Container Runtime Interface) は、kubelet がさまざまなコンテナ ランタイムを使用できるようにするプラグイン インターフェイスです。さまざまなコンテナ ランタイムが CRI API を実装しており、ユーザーは Kubernetes インストールで任意のコンテナ ランタイムを使用できます。

5. CNI とは何ですか?

CNI プロジェクトは、Linux コンテナーに共通のプラグインベースのネットワーク ソリューションを提供する仕様で構成されています。また、Pod ネットワークを構成するときにさまざまな機能を実行するさまざまなプラグインも含まれています。 CNI プラグインは CNI 仕様に準拠した実行可能ファイルであり、次の投稿ではいくつかのプラグインについて説明します。

2. Pod IPアドレスを持つノードにサブネットを割り当てる

すべてのポッドに IP アドレスが必要な場合は、クラスター全体のすべてのポッドに一意の IP アドレスがあることを確認することが重要です。これは、各ノードに一意のサブネットを割り当て、そこからそのノード上の IP アドレスをポッドに割り当てることによって実現されます。

1. ノード IPAM コントローラ

nodeipam が kube-controller-manager の --controllers コマンドライン フラグにオプションとして渡されると、クラスター CIDR (クラスター ネットワークの IP 範囲) から各ノードに専用のサブネット (podCIDR) が割り当てられます。これらの podCIDR は分離したサブネットであるため、各ポッドに一意の IP アドレスを割り当てることができます。

Kubernetes ノードが最初にクラスターに登録されると、podCIDR が割り当てられます。クラスター内のノードに割り当てられた podCIDR を変更するには、ノードを登録解除してから再登録し、まず Kubernetes コントロール プレーンに構成の変更を適用する必要があります。 podCIDR は次のコマンドを使用してノードを一覧表示できます。

 $ kubectl get no <nodeName> -o json | jq '.spec.podCIDR' 10.244.0.0/24

2. Kubelet、コンテナ ランタイム、CNI プラグイン - これらを組み合わせる方法

ポッドがノードにスケジュールされると、ポッドを起動するためにいくつかの処理が行われます。このセクションでは、ポッドのネットワークの構成に関連するやり取りのみに焦点を当てます。

ノード上でポッドがスケジュールされると、次のやり取りによってネットワークが構成され、アプリケーション コンテナが起動されます。

3. コンテナランタイムとCNIプラグイン間の相互作用

各ネットワーク プロバイダーには、コンテナ ランタイムが起動時にポッドのネットワークを構成するために呼び出す CNI プラグインがあります。コンテナ ランタイムとして containerd を使用する場合、Containerd CRI プラグインは CNI プラグインを呼び出します。各ネットワーク プロバイダーは、ポッド ネットワークを構成するために各 Kubernetes ノードにエージェントもインストールします。ネットワーク プロバイダー エージェントがインストールされると、CNI 構成が付属するか、ノード上に構成が作成され、CRI プラグインはそれを使用して、呼び出す CNI プラグインを決定します。

CNI 構成ファイルの場所は構成可能で、デフォルトは /etc/cni/net.d/ です。 CNI プラグインは、クラスター管理者によって各ノードに配布される必要があります。 CNI プラグインの場所も設定可能で、デフォルト値は /opt/cni/bin です。

コンテナ ランタイムとして containerd を使用する場合は、[plugins."io.containerd.grpc.v1.cri".cni] セクションの containerd 構成で CNI 構成と CNI プラグイン バイナリへのパスを指定できます。

ここではネットワーク プロバイダーとして Flannel について言及しているので、Flannel の設定方法について少し説明します。 Flanneld は Flannel デーモンであり、通常は install-cni を使用してデーモン セットおよび init コンテナーとして Kubernetes クラスターにインストールされます。 install-cni コンテナは各ノードに CNI 構成ファイルを作成します。 /etc/cni/net.d/10-flannel.conflistFlaneld は vxlan デバイスを作成し、apiserver からネットワーク メタデータを取得し、Pod の更新を監視します。 Pod が作成されると、クラスター全体のすべての Pod にルートが割り当てられ、Pod が IP アドレスを介して相互に接続できるようになります。 Flannel の仕組みの詳細については、公式の説明を参照することをお勧めします。

Containerd CRI プラグインと CNI プラグイン間の相互作用は、次のように視覚化できます。

前述のように、kubelet は Containerd CRI プラグインを呼び出してポッドを作成し、Containerd CRI プラグインは CNI プラグインを呼び出してポッドのネットワークを構成します。ネットワーク プロバイダー CNI プラグインは、他のベース CNI プラグインを呼び出してネットワークを構成します。 CNI プラグイン間の相互作用については以下で説明します。

3. CNIプラグイン間の相互作用

ホスト上のコンテナ間のネットワークを構成するのに役立つさまざまな CNI プラグインがあります。この記事では、3つのプラグインについて説明します。

Flannel CNI プラグイン Flannel をネットワーク プロバイダーとして使用する場合、Containerd CRI プラグインは CNI 構成ファイル (/etc/cni/net.d/10-flannel.conflist) を使用します。

 $ cat /etc/cni/net.d/10-flannel.conflist { "name": "cni0", "plugins": [ { "type": "flannel", "delegate": { "ipMasq": false, "hairpinMode": true, "isDefaultGateway": true } } ] }

Fannel CNI プラグインは、Flanneld と組み合わせて使用​​されます。 Flaneld が起動すると、apiserver から podCIDR とその他のネットワーク関連の詳細を取得し、/run/flannel/subnet.env ファイルに保存します。

 FLANNEL_NETWORK=10.244.0.0/16 FLANNEL_SUBNET=10.244.0.1/24 FLANNEL_MTU=1450 FLANNEL_IPMASQ=false

Flannel CNI プラグインは、/run/flannel/subnet.env の情報を使用して、ブリッジ CNI プラグインを設定および呼び出します。

1. ブリッジCNIプラグイン

Flannel CNI プラグインは、次の構成で Bridge CNI プラグインを呼び出します。

 { "name": "cni0", "type": "bridge", "mtu": 1450, "ipMasq": false, "isGateway": true, "ipam": { "type": "host-local", "subnet": "10.244.0.0/24" } }

Bridge CNI プラグイン "name": "cni0" が初めて呼び出されると、構成ファイルで指定されたコンテンツを使用して Linux ブリッジが作成されます。次に、各ポッドに対して veth ペアを作成します。ペアの一方の端はコンテナのネットワーク名前空間にあり、もう一方の端はホスト ネットワーク上の Linux ブリッジに接続されます。 Bridge CNI プラグインを使用すると、ホスト上のすべてのコンテナーがホスト ネットワーク上の Linux ブリッジに接続されます。

veth ペアが設定されると、ブリッジ プラグインはホストのローカル IPAM CNI プラグインを呼び出します。使用する IPAM プラグイン CNI 構成で CRI プラグインを構成して、Flannel CNI プラグインを呼び出すことができます。

2. ホストローカル IPAM CNI プラグイン

Bridge CNI プラグインは、次の構成でホストネイティブ IPAM CNI プラグインを呼び出します。

 { "name": "cni0", "ipam": { "type": "host-local", "subnet": "10.244.0.0/24", "dataDir": "/var/lib/cni/networks" } }

ホストローカル IPAM (IP アドレス管理) プラグインは、コンテナの IP アドレスを返し、サブネットに割り当てられた IP をホスト上のローカルの指定されたディレクトリに保存します。ファイルには、IP が割り当てられているコンテナ ID が含まれています。 dataDir/var/lib/cni/networks/<network-name=cni0>/<ip>/var/lib/cni/networks/<network-name=cni0>/<ip>

呼び出されると、ホストローカルIPAMプラグインは次のペイロードを返します。

 { "ip4": { "ip": "10.244.4.2", "gateway": "10.244.4.3" }, "dns": {} }

まとめ

Kube-controller-manager は各ノードに podCIDR を割り当てます。ノード上のポッドには、podCIDR のサブネット値に基づいて IP アドレスが割り当てられます。すべてのノード上の podCIDR は分離したサブネットであるため、各ポッドに一意の IP アドレスを割り当てることができます。

Kubernetes クラスター管理者は、kubelet、コンテナ ランタイム、ネットワーク プロバイダー エージェントを構成およびインストールし、各ノードに CNI プラグインを配布します。ネットワーク プロバイダー エージェントが起動すると、CNI 構成が生成されます。ポッドがノードにスケジュールされると、kubelet は CRI プラグインを呼び出してポッドを作成します。 containerd の場合、Containerd CRI プラグインは CNI 構成で指定された CNI プラグインを呼び出して、ポッド ネットワークを構成します。これらすべてにより、Pod は IP アドレスを取得します。

参考: https://ronaknathani.com/blog/2020/08/how-a-kubernetes-pod-gets-an-ip-address/