Kubernetes コアテクノロジー Pod の詳細な説明と例

1. 概要

Pod は、k8s システムで作成および管理できる最小の単位です。これは、リソースオブジェクトモデル内でユーザーによって作成または展開される最小のリソースオブジェクトモデルです。これは、k8s 上でコンテナ化されたアプリケーションを実行するためのリソースオブジェクトでもあります。その他のリソースオブジェクトは、Pod オブジェクトの機能をサポートまたは拡張するために使用されます。たとえば、コントローラーオブジェクトは Pod オブジェクトを制御するために使用され、サービスまたは Ingress リソースオブジェクトは Pod 参照オブジェクトを公開するために使用され、PersistentVolume リソースオブジェクトは Pod にストレージを提供するために使用されます。k8s はコンテナーを直接処理するのではなく、Pod を処理します。ポッドは 1 つ以上のコンテナーで構成されます。

Pod は Kubernetes で最も重要な概念です。各ポッドには、「ルートコンテナ」と呼ばれる特別な一時停止コンテナがあります。 Pause コンテナに対応するイメージは、Kubernetes プラットフォームの一部です。各ポッドには、一時停止コンテナに加えて、密接に関連する 1 つ以上のユーザービジネスコンテナも含まれます。

2. 特徴

（１）資源の共有

Pod 内の複数のコンテナはストレージとネットワークを共有でき、論理ホストと見なすことができます。名前空間、cgroup、その他の分離されたリソースなどの共有。

複数のコンテナが同じネットワーク名前空間を共有するため、Pod 内の複数のコンテナは Pod の IP とポート名前空間を共有し、Pod 内の複数のコンテナは localhost を介して通信できます。注意する必要があるのは、異なるコンテナ間でポートの競合が発生しないように注意する必要があることです。異なるポッドには異なる IP が存在します。異なるポッド内の複数のコンテナは、IPC を使用して通信することはできません (特に指定がない限り)。通常、Pod の IP を使用して通信します。

Pod 内の複数のコンテナはストレージボリュームを共有できます。ストレージボリュームは Pod の一部として定義され、Pod 内のすべてのコンテナのファイルシステムにマウントできます。

（２）ライフサイクルが短い

ポッドはライフサイクルが比較的短いコンポーネントです。たとえば、ポッドが配置されているノードに障害が発生すると、そのノード上のポッドは他のノードにスケジュールされます。ただし、再スケジュールされたポッドはまったく新しいポッドであり、以前のポッドとは何の関係もないことに注意してください。

（３）フラットネットワーク

K8s クラスター内のすべての Pod は同じ共有ネットワークアドレス空間内にあるため、各 Pod には他の Pod の IP アドレスを通じてアクセスできます。

3. 分類

（１）普通のポッド

通常の Pod が作成されると、etcd に保存され、Kubernetes マスターによって特定のノードにスケジュールされ、バインドされます。次に、Pod に対応するノード上の kubelet プロセスが関連する Docker コンテナのグループにインスタンス化され、起動されます。デフォルトでは、ポッド内のコンテナが停止すると、Kubernetes は自動的にこの問題を検出し、ポッド内のすべてのコンテナを再起動します。ポッドが配置されているノードがダウンした場合、このノード上のすべてのポッドは他のノードに再スケジュールされます。

（２）スタティックポッド

静的ポッドは、kubelet によって管理され、特定のノード上にのみ存在するポッドです。これらは API サーバー経由で管理できず、ReplicationController、Deployment、または DaemonSet に関連付けることはできず、kubelet はヘルスチェックを実行することもできません。

4. ポッドの重要性

Pod は複数のコンテナを保存できます。 Docker を例に挙げてみましょう。 Docker では、コンテナで 1 つのアプリケーションのみを実行することを推奨しています。 Pod は複数のプロセスで設計されています。依存関係の高い 2 つのコンテナを同じ Pod に配置できます (たとえば、マイクロサービスプロジェクトが MySQL データベースを呼び出す場合、マイクロサービスコンテナと MySQL データベースコンテナを同じ Pod に配置します)。ネットワークは Pod 内で共有されるため、マイクロサービスはローカルデータに接続するのと同じように MySQL に接続し、ネットワーク IO が削減され、呼び出し効率が向上します。

5. ライフサイクルと再起動戦略

（１）ポッドの状態

州	説明する
保留中	API サーバーはポッドを作成しましたが、ポッド内の 1 つ以上のコンテナのイメージ (イメージのダウンロードプロセスを含む) はまだ作成されていません。
ランニング	ポッド内のすべてのコンテナが作成され、少なくとも 1 つのコンテナが実行中、開始中、または再起動中の状態になっています。
完了	ポッド内のすべてのコンテナが正常に終了し、再起動しません
失敗した	ポッド内のすべてのコンテナは終了しましたが、少なくとも 1 つのコンテナは終了に失敗しました
未知	ネットワーク障害などの何らかの理由でポッドステータスを取得できない

（２）ポッド再起動戦略

Pod の再起動ポリシーには、Always、OnFailure、Never が含まれます。デフォルト値は「常に」です。

戦略	説明する
いつも	コンテナに障害が発生すると、kubeletは自動的にコンテナを再起動します。
失敗時	コンテナの実行が停止し、実行中のコードが0でない場合、kubeletは自動的にコンテナを再起動します。
一度もない	コンテナの実行状態に関係なく、kubeletはコンテナを再起動しません。

（３）一般的な状態遷移

ポッド内のコンテナの数	ポッドの現在の状態	イベント	ポッド結果ステータス
			再起動ポリシー=常に	失敗時	一度もない
コンテナ1個	ランニング	コンテナは正常に終了しました	ランニング	成功しました	成功しました
コンテナ1個	ランニング	コンテナの終了に失敗しました	ランニング	ランニング	失敗
コンテナ2個	ランニング	1 つのコンテナが終了に失敗しました	ランニング	ランニング	ランニング
コンテナ2個	ランニング	コンテナはOOMによって強制終了される	ランニング	ランニング	失敗