クラウドネイティブテクノロジーKubernetesスケジューリングユニットポッドの使用の詳細な説明

k8s の最小のスケジューリング単位 --- pod

前回の記事では、k8s が解決できる問題を簡単に紹介しました。簡単に言うと、k8s が解決する問題は、コンテナのオーケストレーションとスケジューリングです。その核となる価値は、大規模クラスターで実行されるタスク間には実際にはさまざまな関係があることにあります。これらの関係の処理は、タスク オーケストレーションとシステム管理の最も難しい部分です。k8s は、この問題のために生まれました。

この文章は理解するのが難しいです。まずは既存の知識から始めて、それを解き明かしながらゆっくりと理解していきます。コンテナの本質はプロセスであり、次の 3 つの部分から構成されることはすでにわかっています。

コンテナがクラウド環境内のプロセスである場合、k8s はクラウド環境内のオペレーティング システムと考えることができます。

オペレーティング システムでは、プロセスは常に独立して実行されるわけではなく、プロセス グループとして実行されることがよくあります。実際にアプリケーションをデプロイする場合、アプリケーションは Docker コンテナ内で分離された形で実行されることはあまりありません。アプリケーション間にはさまざまな関係があります。場合によっては、バンドルと同様に、同じマシン上で実行し、相互にアクセスする必要があります。たとえば、2 つのコンテナがファイルを交換したり、特定の Linux 名前空間を共有したりする必要がある場合などです。このような関係を「超親密な関係」と呼びます。

上記の前提に基づいて、k8s は設計当初からこれを考慮に入れました。そのため、設計時にはコンテナを最小のスケジューリング単位として使用せず、新しい概念のポッドを k8s の最小のスケジューリング単位として使用しました。各ポッドには複数のコンテナを含めることができます。このように、コンテナにデプロイされたアプリケーションはバンドルされており、つまり、1 台のマシンにのみデプロイでき、デプロイは成功または失敗のいずれかであり、中間状態の可能性はありません。

Pod とコンテナの関係は何ですか?

Pod は論理的な概念であり、その本質は特定のリソースを共有するコンテナのグループであることに注意してください。正確に言うと、同じポッド内のコンテナは同じネットワーク名前空間を共有し、もちろんマウントされたボリュームなどのリソースも共有できます。

いわゆる共有は依存ではなく平等です。

2 つのコンテナ A と B があり、A が B に依存している場合は、A を B の後に起動する必要があります。 A と B のステータスが等しい場合、A と B の起動順序に厳密な要件はありません。これが真の共有です。では、共有ネットワーク リソースを事前に作成するのは誰でしょうか?

Pod に複数のアプリケーション コンテナが含まれている場合、これらのアプリケーション コンテナを関連付けるにはインフラ コンテナが必要です。次のようになります:

K8S では、インフラ コンテナーはリソースをほとんど消費しません。pause と呼ばれるイメージを実行するだけなので、pause コンテナーとも呼ばれます。占有するディスク サイズは 100 ～ 200 KB です。インフラの目的は、ネットワーク名前空間を作成し、アプリケーション コンテナ A とアプリケーション コンテナ B をこのネットワーク名前空間に追加することです。

ポッド内のコンテナ A とコンテナ B の場合:
1. localhost を使用して直接通信できます。
2. それらが認識するネットワーク デバイスは、インフラ コンテナーが認識するネットワーク デバイスとまったく同じです。
3. ポッドには IP アドレスが 1 つだけあり、これはポッドのネットワーク名前空間に対応する IP アドレスです。
4. もちろん、他のすべてのネットワーク リソースは 1 つの Pod と Pod 内のすべてのコンテナによって共有されます。
5. Pod のライフサイクルは Infra コンテナとのみ一致し、コンテナ A および B とは関係ありません。
6. 同じポッド内のすべてのユーザーコンテナについては、そのインバウンドおよびアウトバウンドトラフィックもインフラコンテナを介して完了するとみなすことができます。

この設計モードでは、同じボリュームをマウントするのは非常に簡単です。Pod の初期化 yaml ファイルでボリューム パラメータを構成するだけです。具体的な内容は後で共有します。

コンテナの場合、コンテナはアプリケーションではなく 1 つのプロセスのみを管理できます。アプリケーションをクラウドに移行する場合、アプリケーションをいくつかのプロセスに分割し、アプリケーション モジュール間に「超密接な関係」があるかどうかを検討する必要があります。超密接な関係にあるプロセスは 1 つの Pod にデプロイし、他のプロセスは別の Pod にデプロイすることができます。このアイデアを使用してアプリケーションを分割することは、コンテナ設計の本来の意図と一致しています。

上記は、クラウドネイティブテクノロジーKubernetesスケジューリングユニットポッドの使用に関する詳細な説明の詳細な内容です。Kubernetesスケジューリングユニットポッドの使用の詳細については、123WORDPRESS.COMの他の関連記事に注目してください。