Podについて
PodはKubernetesの最小API単位です。より技術的に言えば、PodはKubernetesにおけるアトミックなスケジューリング単位です。しかし、なぜPodが必要なのでしょうか？この質問に答えるには、まずコンテナの本質を理解する必要があります。コンテナは本質的にプロセスです。そう、コンテナはクラウドコンピューティングシステムにおけるプロセスであり、コンテナイメージはこのシステムにおける「.exe」インストールパッケージです。このアナロジーでは、Kubernetesはオペレーティングシステムの役割を果たします。
プロセスとプロセスグループ
Linuxマシンにログインして、次のコマンドを実行してみましょう。
$ pstree -g
このコマンドは、システム上で現在実行中のプロセスのツリー構造を表示します。出力は次のようになります。
systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
| `-{gmain}(1984)
|-acpid(2044)
...
|-lxcfs(1936)-+-{lxcfs}(1936)
| `-{lxcfs}(1936)
|-mdadm(2135)
|-ntpd(2358)
|-polkitd(2128)-+-{gdbus}(2128)
| `-{gmain}(2128)
|-rsyslogd(1632)-+-{in:imklog}(1632)
| |-{in:imuxsock) S 1(1632)
| `-{rs:main Q:Reg}(1632)
|-snapd(1942)-+-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
ご覧のとおり、実際のオペレーティングシステムでは、プロセスは単独で実行されるのではなく、プロセスグループに編成されています。例えば、プログラム「rsyslogd」はLinuxでログ処理を担当します。rsyslogdのメインプログラム「main」と、それが使用するカーネルログモジュール「imklog」は、プロセスグループ1632に属しています。これらのプロセスは連携してrsyslogdプログラムの責務を果たします。Kubernetesは本質的にこの「プロセスグループ」という概念をコンテナ技術にマッピングし、このクラウドコンピューティング「オペレーティングシステム」における「ファーストクラス市民」にしています。Kubernetesがこのアプローチを採用したのは、Googleのエンジニアが、自身がデプロイするアプリケーションが「プロセスとプロセスグループ」に似た関係を示すことに気づいたためです。具体的には、これらのアプリケーションは緊密な連携を必要とし、同じマシン上にデプロイする必要がありました。「グループ」の概念なしにこのような運用関係を管理することは非常に困難です。rsyslogdを例に取ると、imklogモジュール、imuxsockモジュール、そしてrsyslogd自身のメイン関数プロセスの3つのプロセスで構成されています。これら3つのプロセスは同じマシン上で実行されなければなりません。そうでなければ、ソケットベースの通信やファイル交換に問題が生じます。
コンテナ間通信
上の図に示すように、このPodには2つのユーザーコンテナ（AとB）と1つのInfraコンテナが含まれています。Kubernetesでは、Infraコンテナは最小限のリソースを消費するように設計されており、「k8s.gcr.io/pause」という特別なイメージを使用します。このイメージは、アセンブリ言語で書かれた、永久に「一時停止」状態を維持するコンテナを表し、非圧縮サイズはわずか100〜200KBです。InfraコンテナがNetwork Namespaceを「保持」すると、ユーザーコンテナはこのnamespaceに参加できます。したがって、ホストマシン上でこれらのコンテナのNamespaceファイル（このファイルのパスは前述しました）を確認すると、それらはまったく同じ値を指していることがわかります。つまり、Pod内のコンテナAとBは「localhost」を使用して直接通信できます。これらはInfraコンテナと同じネットワークデバイスを認識します。Podには1つのIPアドレスしかなく、これはPodのNetwork Namespaceに関連付けられたIPアドレスです。当然ながら、他のすべてのネットワークリソースもPodごとに割り当てられ、そのPod内のすべてのコンテナで共有されます。PodのライフサイクルはInfraコンテナのみに紐づいており、コンテナAやBとは独立しています。さらに、同じPod内のすべてのユーザーコンテナについて、それらの入出力トラフィックはInfraコンテナを経由していると考えることができます。この点は非常に重要です。なぜなら、将来Kubernetes用のネットワークプラグインを開発する場合、主に注目すべきはPodのNetwork Namespaceの構成であり、各ユーザーコンテナがネットワーク設定をどのように利用するかではないからです。後者は重要ではありません。つまり、ネットワークプラグインがコンテナ内にパッケージや設定をインストールすることに依存している場合、それは実行可能なソリューションではありません。Infraコンテナイメージのルートファイルシステムはほぼ空であり、カスタマイズの余地はありません。逆に言えば、ネットワークプラグインはユーザーコンテナの起動状態を気にする必要はなく、Pod（つまりInfraコンテナのNetwork Namespace）の設定のみに集中すればよいのです。この設計により、ボリュームの共有もはるかに簡単になります。Kubernetesはすべてのボリューム設定をPodレベルで定義できます。その結果、ボリュームに対応するホストディレクトリはPodに固有のものとなり、Pod内の任意のコンテナはこのディレクトリをマウントすることを宣言するだけで済みます。このPodの設計思想は、コンテナ間に「超密接な関係」を生み出し、ユーザーに、単一のコンテナで複数の機能的に無関係なコンポーネントを含むアプリケーションを実行するよりも、それらをPod内の複数のコンテナとして表現する方が良いのではないかと考えるよう促すことを目的としています。この考え方を理解するには、単一のコンテナでは解決が難しいシナリオに適用してみてください。例えば、アプリケーションがコンテナ内の「/var/log」ディレクトリに継続的にログファイルを出力する場合を考えます。この場合、Pod内でボリュームをアプリケーションコンテナの「/var/log」ディレクトリにマウントできます。そして、同じPod内でサイドカーコンテナを実行し、そのコンテナも同じボリュームを自身の「/var/log」ディレクトリにマウントすることを宣言します。そこから、サイドカーコンテナの唯一の役割は、自身の「/var/log」ディレクトリからログファイルを継続的に読み取り、MongoDBやElasticsearchなどのストレージソリューションに転送することです。この設定により、基本的なログ収集メカニズムが確立されます。最初の例と同様に、このシナリオでのサイドカーの主な機能も、共有ボリュームを使用したファイル操作にあります。しかし、Podのもう一つの重要な特性である、Pod内のすべてのコンテナが同じNetwork Namespaceを共有することを見逃してはなりません。これにより、Podのネットワークに関連する多くの設定や管理タスクをサイドカーに委任でき、ユーザーコンテナにまったく干渉する必要がなくなります。この代表的な例がIstioサービスメッシュプロジェクトです。
まとめ
この議論では、Podが必要な理由について掘り下げました。本質的に、PodはKubernetesクラスター内の基本単位であり、1つ以上のコンテナ（通常はDockerコンテナ）をカプセル化します。これらのコンテナはネットワークとストレージリソースを共有します。プロセスとプロセスグループの観点から見ると、Podは軽量なプロセスグループと見なすことができます。これにより、複数の緊密に連携するプロセス（コンテナ）を一貫した単位としてデプロイ、スケーリング、管理できるようになり、複雑なアプリケーションのデプロイと運用が簡素化されます。次の記事では、Podについてより深く説明します。
Novita AIは、AIの野望を実現するためのオールインワンクラウドプラットフォームです。シームレスに統合されたAPI、サーバーレスコンピューティング、GPUアクセラレーションにより、AI駆動のビジネスを迅速に構築し、拡張するためのコスト効率の高いツールを提供します。インフラストラクチャの悩みを解消し、無料で始めましょう。Novita AIがあなたのAIの夢を現実にします。
おすすめの記事：
