第5章 ポッド ポッド
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
以前の章では、アプリケーションをコンテナ化する方法について説明したが、コンテナ化されたアプリケーションの実際のデプロイでは、複数のアプリケーションを1つのアトミックユニットにコロケートし、1つのマシンにスケジューリングしたい場合が多い。
このようなデプロイの典型的な例を図5-1に示す。この例では、Webリクエストを処理するコンテナと、ファイルシステムをリモートのGitリポジトリと同期するコンテナで構成されている。
図5-1. 2つのコンテナと共有ファイルシステムを持つPodの例
最初は、ウェブサーバとGitシンクロナイザーを一つのコンテナにまとめたくなるかもしれない。 しかし、よく考えてみれば、分離する理由は明らかだ。まず、この二つのコンテナではリソースの使い方が大きく異なる。例えばメモリだ。ウェブサーバはユーザのリクエストに応えるものなので、常に利用可能でレスポンスが良いようにしたい。一方、Gitシンクロナイザーはユーザにはあまり向いておらず、「ベスト・エフォート」のサービス品質を持っている。
Gitシンクロナイザーがメモリー・リークを起こしたとしよう。Gitシンクロナイザーがウェブサーバーに使いたいメモリーを使い切らないようにしなければならない。
このようなリソースの分離は、まさにコンテナが実現するために設計されたものだ。つのアプリケーションを2つのコンテナに分離することで、信頼性の高いウェブサーバの運用を保証することができる。
もちろん、2つのコンテナはかなり共生している。あるマシンでWebサーバをスケジュールし、別のマシンでGitシンクロナイザをスケジュールするのは意味がない。 その結果、Kubernetesは複数のコンテナをPodと呼ばれる単一の原子単位にグループ化する。(名前付けはDockerコンテナのテーマであるクジラにちなんだもので、Podはクジラのグループでもあるからだ)。
注
複数のコンテナを1つのPodにグループ化することは、Kubernetesに導入された当初は賛否両論、あるいは混乱を招くように思われたが、その後、インフラをデプロイするさまざまなアプリケーションで採用されるようになった。例えば、いくつかのサービスメッシュ実装では、アプリケーションのPodにネットワーク管理を注入するために2つ目のサイドカーコンテナを使用している。
KubernetesにおけるPod
Podは、同じ実行環境で動作するアプリケーションコンテナとボリュームの集合体である。 コンテナではなくPodは、Kubernetesクラスタにおける最小のデプロイ成果物である。つまり、Pod内のコンテナはすべて常に同じマシンに配置される。
Pod内の各コンテナは独自のcgroupで実行されるが、Linuxの名前空間をいくつか共有している。
同じPodで実行されるアプリケーションは、同じIPアドレスとポート・スペース(ネットワーク名前空間)を共有し、同じホスト名(UTS名前空間)を持ち、System V IPCまたはPOSIXメッセージキュー(IPC名前空間)上でネイティブのプロセス間通信チャネルを使用して通信できる。 ...