Kubernetesコンテナの動作原理を1つの記事で理解する

1. Kubernetesコンテナの概要

コンテナは、ホスト オペレーティング システム (またはカーネル) を効果的に仮想化し、アプリケーションの依存関係を同じマシン上で実行されている他のコンテナから分離します。コンテナが登場する前は、複数のアプリケーションが同じ仮想マシン (VM) にデプロイされていた場合、共有依存関係に変更を加えると異常な事態が発生し、トラブルシューティングが困難になる可能性がありました。

コンテナは、コンテナ エンジンと、アプリケーションとその依存関係のパッケージであるコンテナ イメージという 2 つの主要な部分を通じてこの問題を解決します。コンテナ エンジンはコンテナ内でアプリケーションを実行し、ホスト上で実行されている他のアプリケーションから分離します。これにより、アプリケーションごとに個別のオペレーティング システムを実行する必要がなくなり、リソースの使用率が向上し、コストが削減されます。

Kubernetes を学び始めたとき、各 Pod に IP アドレスが割り当てられる仕組みや、コンテナ化された後にマイクロサービスが適切に機能する仕組みについて、十分に理解していませんでした。おそらく、各コンポーネントの概念と、それらがどのように独立して動作するかをある程度理解できるでしょう。ただし、特定のコンテキストではこれらのコンポーネントが相互にどのように関連しているかが明確でない場合があります。たとえば、CNI プラグインが何であるかはわかっていますが、Kubernetes に関係するコンポーネントがどのように相互に呼び出すかはわかりません。したがって、Kubernetes クラスター内のさまざまなコア コンポーネントとそれらがどのように連携されているかを理解した上で、実際のビジネス環境で効果的なメンテナンスを実行し、各コンテナが設定された環境変数に基づいて正しく実行できるようにすることが特に重要です。

現在の Kubernetes エコシステムには複数のネットワーク ソリューションがあり、コンテナ ランタイム環境にもさまざまなオプションがあります。この記事では、Kubernetes オーケストレーション アーキテクチャ全体の観点からコンテナ操作の基本原則を説明し、コンテナ エコシステムの関連知識を誰もがより深く理解できるようにします。

2. CRI (コンテナ ランタイム インターフェース) アーキテクチャ

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

まず、Containerd の CRI プラグイン アーキテクチャを簡単に見てみましょう。

CRI プラグインは、Kubernetes コンテナ ランタイム インターフェース (CRI) の実装です。 Containerd と Kubelet は同じノード上で実行されます。 Containerd 内の CRI プラグインは、Kubelet からのすべての CRI サービス要求を処理し、Containerd の内部構造を使用してコンテナとコンテナ イメージを管理します。

CRI プラグインは Containerd を使用して、コンテナのライフサイクル全体とすべてのコンテナ イメージを管理します。以下に示すように、CRI は CNI (Container Network Interface) を通じて Pod ネットワークを管理します。

上記の構造図に基づいて、CRI プラグインが Kubelet に基づいてコンテナを作成し、Pod プロセスを実行する方法を整理してみましょう。

1. Kubelet は CRI ランタイム サービス API を介して CRI プラグインを呼び出して Pod を作成します。

2. CRI は Containerd Internal を使用して特別なサンドボックス コンテナを作成および起動し、そのコンテナを Pod の Cgroups および NameSpace 名前空間に配置します。

3. CRI CNI を使用して Pod のネットワーク名前空間を構成します。

4. 次に、Kubelet は CRI イメージ サービス API を介して CRI プラグインを呼び出して、アプリケーション コンテナ イメージをプルします。イメージがノード上に存在しない場合、CRI はさらに Containerd を使用してイメージをプルします。

5. 次に、Kubelet は CRI ランタイム サービス API を介して CRI を呼び出し、プルされたコンテナ イメージを使用して Pod 内にアプリケーション コンテナを作成して起動します。

6. CRI は Containerd Internal を使用してアプリケーション コンテナを作成し、それを Pod の Cgroup と NameSpace に配置してから、Pod の新しいアプリケーション コンテナを起動します。これらの手順を実行すると、Pod とそれに対応するアプリケーション コンテナが作成され、実行されます。

3. CNI（コンテナネットワークインターフェース）アーキテクチャ

別の CNCF プロジェクトとして、CNI (Container Network Interface) も Cloud Native Computing Foundation プロジェクトであり、Linux コンテナでネットワーク インターフェイスを構成するための仕様とライブラリ、およびサポートされている多数のプラグインで構成されています。 CNI は、コンテナのネットワーク接続と、コンテナが削除されたときに割り当てられたリソースを削除することのみに関係します。このため、CNI は幅広いサポートを提供し、仕様の実装も容易で、Linux コンテナ向けの共通のプラグインベースのネットワーク ソリューションを提供します。

一般的に、CNI は Kubernetes、Podman、CRI-O、rkt、Openshift、Cloud Foundry、Amazon ECS、Singularity、OpenSVC、Mesos などのコンテナ ランタイムで使用されます。コンテナまたはポッド自体には、最初はネットワーク インターフェースがありません。コンテナの実行中は、ADD、DEL、CHECK などの操作コマンドを使用して CNI プラグインを呼び出します。たとえば、ADD はコンテナーの新しいネットワーク インターフェイスを作成し、追加される内容の詳細を JSON 経由で効率的に CNI に渡します。

では、Kubernetes で CNI を通常どのように使用するのでしょうか?一般的に、選択する CNI プラグインは、以下に示すように、主に CNI 構成ファイルに基づいて決定されます。

1. 各ノードで CNI ファイル (/etc/cni/net.d/xxnet.conf) を構成します。ここで、xxnet.conf はネットワーク構成ファイルの名前を表します。

2. CNI 構成ファイルに基づいてバイナリ プラグインをインストールして展開します。

3. ノード上に Pod を作成した後、Kubelet は CNI 構成ファイルに従って、最初の 2 つの手順でインストールされた CNI プラグインを実行します。

4. 上記に基づいて Pod ネットワークを構成します。

4. CRIとCNIの相互作用モデル

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

CNI 構成ファイルの場所は構成可能で、デフォルトでは /etc/cni/net.d/<config-file> になります。クラスター管理者は、各ノードに CNI プラグインを提供する必要があります。 CNI プラグインの場所も設定可能で、デフォルト値は /opt/cni/bin です。

コンテナ ランタイムとして Containerd を使用する場合は、Containerd 構成の [plugins."io.containerd.grpc.v1.cri".cni] セクションで CNI 構成と CNI プラグイン バイナリへのパスを指定できます。 Flannel ネットワーク ソリューションを例に挙げてみましょう。 Flanneld は Flannel デーモンであり、通常は Kubernetes クラスターにデーモンとしてインストールされ、初期化コンテナーとして install-cni を使用します。 install-cni コンテナは、各ノードに CNI 構成ファイル /etc/cni/net.d/10-flannel.conflist を作成します。 Flanneld は Vxlan デバイスを作成し、Api サーバーからネットワーク メタデータを取得し、Pod の更新を監視します。 Pod が作成されると、クラスター全体のすべての Pod にルートが割り当てられ、Pod が IP アドレスを介して相互に接続できるようになります。

Containerd CRI プラグインと CNI プラグイン間の相互作用モデルを次の図に示します。

上記に基づいて、Kubelet は Containerd CRI プラグインを呼び出して Pod を作成し、Containerd CRI プラグインは CNI プラグインを呼び出して Pod のネットワークを構成します。ネットワーク プロバイダー CNI プラグインは、他のベース CNI プラグインを呼び出してネットワークを構成します。

5. コンテナ操作フローチャート

次に、Kubelet、Container Runtime、CNI プラグインがどのように連携し、相互に連携するかを見てみましょう。ポッドがノードにスケジュールされると、ポッドを開始するためにさまざまなイベント アクションがトリガーされます。ポッドがノード上でスケジュールされた後、次のやり取りによってネットワークが構成され、アプリケーション コンテナが起動します。詳細は以下の通りです。

最後に、以下に示すように、完全なコンテナ操作図を見てみましょう。

上記は、Kubernetes でコンテナが実行される方法に関する関連原則の分析です。