Kubernetes ポッドはどのようにして IP アドレスを取得しますか?

ノート。 翻訳。: LinkedIn の SRE エンジニアによって書かれたこの記事では、次のポッドに IP アドレスを割り当てる必要があるときに発生する、Kubernetes の内部の魔法、より正確には CRI、CNI、および kube-apiserver の相互作用について詳しく説明しています。

基本的な要件の XNUMX つ Kubernetesネットワークモデル 各ポッドには独自の IP アドレスが必要であり、クラスター内の他のポッドはそのアドレスでポッドに接続できる必要があります。 このネットワーク モデルの実装を支援するネットワーク「プロバイダー」 (Flannel、Calico、Canal など) が多数あります。

私が最初に Kubernetes を使い始めたとき、ポッドが IP アドレスを正確にどのように取得するのかは完全にはわかりませんでした。 個々のコンポーネントがどのように機能するかを理解していても、それらが連携して動作することを想像するのは困難でした。 たとえば、CNI プラグインが何であるかは知っていましたが、正確にどのように呼ばれるかはわかりませんでした。 したがって、さまざまなネットワーク コンポーネントと、各ポッドが独自の一意の IP アドレスを取得できるようにする Kubernetes クラスター内でそれらがどのように連携するかについての知識を共有するために、この記事を書くことにしました。

コンテナーにさまざまなランタイム オプションがあるのと同じように、Kubernetes でネットワークを構成するにはさまざまな方法があります。 この出版物では、 フランネル クラスター内のネットワークを実行可能環境として編成する - コンテナ入り。 また、コンテナ間のネットワークがどのように機能するかを読者が知っていることを前提としているため、文脈を理解するために簡単に触れておきます。

いくつかの基本概念

コンテナとネットワーク: 概要

インターネット上には、コンテナがネットワーク上でどのように通信するかを説明した優れた出版物がたくさんあります。 したがって、ここでは基本概念の概要のみを説明し、Linux ブリッジの作成とパッケージのカプセル化を含む XNUMX つのアプローチに限定します。 コンテナ ネットワーク自体のトピックは別の記事に値するため、詳細は省略します。 特に洞察力に富んだ教育的な出版物へのリンクを以下に示します。

XNUMX つのホスト上のコンテナ

同じホスト上で実行されているコンテナ間で IP アドレスを介した通信を組織する XNUMX つの方法には、Linux ブリッジを作成することが含まれます。 この目的のために、仮想デバイスが Kubernetes (および Docker) で作成されます。 veth (仮想イーサネット)。 veth デバイスの一端はコンテナのネットワーク名前空間に接続し、もう一端はコンテナのネットワーク名前空間に接続します。 Linuxブリッジ ホストネットワーク上で。

同じホスト上のすべてのコンテナは、VETH の一端がブリッジに接続されており、それを介して IP アドレスを介して相互に通信できます。 Linux ブリッジには IP アドレスもあり、ポッドから他のノードに向かう送信トラフィックのゲートウェイとして機能します。

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

パケットのカプセル化は、異なるノード上のコンテナが IP アドレスを使用して相互に通信できるようにする XNUMX つの方法です。 Flannel では、テクノロジーがこの機会を担っています。 vxlan、元のパケットを UDP パケットに「パッケージ化」し、それを宛先に送信します。

Kubernetes クラスターでは、Flannel が vxlan デバイスを作成し、それに応じて各ノードのルート テーブルを更新します。 異なるホスト上のコンテナを宛先とする各パケットは、vxlan デバイスを通過し、UDP パケットにカプセル化されます。 宛先では、ネストされたパケットが抽出され、目的のポッドに転送されます。

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

CRIとは何ですか？

CRI (コンテナ ランタイム インターフェイス) kubelet がさまざまなコンテナー ランタイム環境を使用できるようにするプラグインです。 CRI API はさまざまなランタイムに組み込まれているため、ユーザーは好みのランタイムを選択できます。

CNIとは何ですか?

プロジェクトCNI それは表し 仕様 Linux コンテナ用のユニバーサル ネットワーク ソリューションを組織します。 さらに、それには以下が含まれます プラグイン, ポッド ネットワークを設定する際のさまざまな機能を担当します。 CNI プラグインは、仕様に準拠した実行可能ファイルです (いくつかのプラグインについては以下で説明します)。

ポッドに IP アドレスを割り当てるためのノードへのサブネットの割り当て

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

ノードIPAMコントローラ

時 nodeipam フラグパラメータとして渡される --controllers kube-コントローラー-マネージャー、クラスター CIDR (つまり、クラスター ネットワークの IP アドレスの範囲) から各ノードに個別のサブネット (podCIDR) を割り当てます。 これらの podCIDR は重複しないため、各ポッドに一意の IP アドレスを割り当てることが可能になります。

Kubernetes ノードには、最初にクラスターに登録するときに podCIDR が割り当てられます。 ノードの podCIDR を変更するには、ノードを登録解除してから再登録し、その間に Kubernetes 制御層構成に適切な変更を加える必要があります。 次のコマンドを使用して、ノードの podCIDR を表示できます。

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

Kubelet、コンテナ ランタイム、CNI プラグイン: すべての仕組み

ノードごとにポッドをスケジュールするには、多くの準備手順が必要です。 このセクションでは、ポッド ネットワークのセットアップに直接関連するものだけに焦点を当てます。

ポッドを特定のノードにスケジュールすると、次の一連のイベントがトリガーされます。

ヘルプ： Containerd CRI プラグインのアーキテクチャ.

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

各ネットワーク プロバイダーには独自の CNI プラグインがあります。 コンテナーのランタイムはそれを実行して、ポッドの起動時にネットワークを構成します。 Containerd の場合、CNI プラグインはプラグインによって起動されます。 コンテナー CRI.

さらに、各プロバイダーには独自のエージェントが存在します。 これはすべての Kubernetes ノードにインストールされ、ポッドのネットワーク構成を担当します。 このエージェントは CNI 構成に含まれているか、ノード上に個別に作成されます。 この設定は、CRI プラグインが呼び出す CNI プラグインを設定するのに役立ちます。

CNI 構成の場所はカスタマイズできます。 デフォルトでは入っています /etc/cni/net.d/<config-file>。 クラスター管理者は、各クラスター ノードに CNI プラグインをインストールする責任もあります。 それらの場所もカスタマイズ可能です。 デフォルトのディレクトリ - /opt/cni/bin.

Containerd を使用する場合、プラグイン構成とバイナリのパスはセクションで設定できます。 [plugins.«io.containerd.grpc.v1.cri».cni] в コンテナー構成ファイル.

ネットワークプロバイダーとして Flannel を使用しているので、その設定について少し説明しましょう。

• Flanneld (Flannel のデーモン) は通常、次のような DaemonSet としてクラスターにインストールされます。 install-cni として コンテナの初期化.
• Install-cni 作成します CNI設定ファイル (/etc/cni/net.d/10-flannel.conflist) 各ノード上で。
• Flanneld は vxlan デバイスを作成し、API サーバーからネットワーク メタデータを取得し、ポッドの更新を監視します。 ポッドが作成されると、クラスター全体のすべてのポッドにルートが配布されます。
• これらのルートにより、ポッドは IP アドレスを介して相互に通信できるようになります。

Flannel の作品についてさらに詳しく知りたい場合は、記事の最後にあるリンクを使用することをお勧めします。

以下は、Containerd CRI プラグインと CNI プラグイン間の相互作用の図です。

上で見られるように、kubelet は Containerd CRI プラグインを呼び出してポッドを作成し、次に CNI プラグインを呼び出してポッドのネットワークを構成します。 その際、ネットワーク プロバイダーの CNI プラグインは他のコア CNI プラグインを呼び出して、ネットワークのさまざまな側面を構成します。

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

ホスト上のコンテナ間のネットワーク通信のセットアップを支援するさまざまな CNI プラグインがあります。 この記事ではそのうちの XNUMX つについて説明します。

CNI プラグイン フランネル

Flannel をネットワーク プロバイダーとして使用する場合、Containerd CRI コンポーネントは CNI プラグイン フランネル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
      }
    }
  ]
}

Flannel CNI プラグインは、Flanneld と連携して動作します。 起動中に、Flanneld は podCIDR およびその他のネットワーク関連の詳細を API サーバーから取得し、ファイルに保存します。 /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 ブリッジ プラグインを設定して呼び出します。

CNI プラグイン ブリッジ

このプラグインは次の構成で呼び出されます。

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

初めて呼び出されたとき、次の Linux ブリッジが作成されます。 «name»: «cni0»、これは設定に示されています。 次に、ポッドごとに veth ペアが作成されます。 その一端はコンテナのネットワーク名前空間に接続され、もう一端はホスト ネットワーク上の Linux ブリッジに含まれます。 CNI プラグイン ブリッジ すべてのホスト コンテナをホスト ネットワーク上の Linux ブリッジに接続します。

veth ペアのセットアップが完了すると、Bridge プラグインはホストローカル IPAM CNI プラグインを呼び出します。 IPAM プラグイン タイプは、CRI プラグインが Flannel CNI プラグインを呼び出すために使用する CNI 設定で設定できます。

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

CNI コールをブリッジする ホストローカル IPAM プラグイン CNI 次の構成で:

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

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

ホストローカル 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 プラグインを呼び出して、ポッドのネットワークを構成します。 その結果、ポッドは IP アドレスを受け取ります。

これらすべてのやり取りの微妙な点やニュアンスを理解するのに時間がかかりました。 この経験が Kubernetes の仕組みをより深く理解するのに役立つことを願っています。 何か間違っている場合は、次のアドレスまでご連絡ください。 Twitter または住所で [メール保護]。 この記事の内容やその他の点について議論したい場合は、お気軽にお問い合わせください。 ぜひお話ししたいです!

リファレンス

コンテナとネットワーク

• コンテナ ネットワーキングの概要
• コンテナ ネットワーキングをわかりやすく説明する

フランネルはどのように機能しますか?

• フランネル ネットワーキングをわかりやすく解説
• Flannel を使用した Kubernetes - ネットワーキングを理解する

CRIとCNI

• CRI プラグインのアーキテクチャ
• CNI仕様
• CNI プラグイン

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes でのネットワーキングのための Calico: 概要と少しの経験";
• 「Kubernetes でのネットワークの図解ガイド」: パート 1 および 2 (ネットワーク モデル、オーバーレイ ネットワーク), パート 3 (サービスとトラフィック処理);
• «Container Networking Interface (CNI) - Linux コンテナのネットワーク インターフェイスおよび標準'。

出所： habr.com