website/content/ja/docs/concepts/workloads/pods/pod.md

reviewers, title, content_template, weight

reviewers	title	content_template	weight
	Pod	templates/concept	20

{{% capture overview %}}

Pod は、Kubernetesで作成および管理できる、デプロイ可能な最小のコンピューティング単位です。

{{% /capture %}}

{{% capture body %}}

Podとは

Pod は（クジラの小群やエンドウ豆のさやのように）、共有のストレージ/ネットワークを持つ1つ以上のコンテナ（例えばDockerコンテナ）、およびコンテナを実行する方法についての仕様です。Pod内のコンテナ群は常に同じ場所に配置され、協調してスケジューリングされ、共通のコンテキストで実行されます。Podは、アプリケーション固有の「論理ホスト」――やや密に結合した1つ以上のアプリケーション・コンテナを含むもの――をモデル化します。コンテナ以前の世界では、同じ物理または仮想マシン上で実行されることが、同じ論理ホスト上で実行されることを意味するでしょう。

Kubernetesは、Dockerだけでなくより多くのコンテナ・ランタイムをサポートしていますが、Dockerは最もよく知られているランタイムであり、Dockerの用語を使ってPodを説明することが可能です。

Pod内では、Linux namespaceやcgroupなどのDockerコンテナを分離する一連の要素と同じものがコンテキストとして共有されます。 Podのコンテキスト内で、個々のアプリケーションに更なる分離が適用されることがあります。

Pod内のコンテナはIPアドレスとポートの空間を共有し、 localhost を通じてお互いを見つけることができます 。 また、SystemVセマフォやPOSIX共有メモリなどの標準のプロセス間通信（IPC）を使用して互いに通信することもできます。 異なるPodのコンテナは異なるIPアドレスを持ち、特別な設定がなければIPCでは通信できません。 これらのコンテナは通常、Pod IPアドレスを介して互いに通信します。

Pod内のアプリケーションからアクセスできる共有ボリュームを、Podの一部として定義できます。 このボリュームは個々のアプリケーションのファイルシステムにマウント可能です。

Dockerの用語でいえば、Podは共有namespaceと共有ボリュームを持つDockerコンテナのグループとしてモデル化されています。

個々のアプリケーションコンテナと同様に、Podは（永続的ではなく）比較的短期間の存在と捉えられます。 Podのライフサイクルで説明しているように、Podが作成されると、一意のID（UID）が割り当てられ、（再起動ポリシーに従って）終了または削除されるまでNodeで実行されるようにスケジュールされます。 Nodeが停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に削除されます。 特定のPod（UIDで定義）は新しいNodeに「再スケジュール」されません。 代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます（詳細についてはReplicationControllerを参照してください）。

ボリュームなど、Podと同じ存続期間を持つものがあると言われる場合、それは（そのUIDを持つ）Podが存在する限り存在することを意味します。 そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの（例えばボリューム）も同様に破壊されて再作成されます。

{{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}}

file puller（ファイル取得コンテナ）とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用している。

Podを用いる動機

管理

Podは、まとまったサービスの単位を形成する複数の協調プロセスのパターンをモデル化したものです。 構成要素であるアプリケーションの集まりよりも高いレベルの抽象化を提供することによって、アプリケーションのデプロイと管理を単純化します。 Podは、デプロイや水平スケーリング、レプリケーションの単位として機能します。 Pod内のコンテナに対しては、同じ場所への配置（共同スケジューリング）、命運の共有（つまり停止）、協調レプリケーション、リソース共有や依存関係の管理が自動的に取り扱われます。

リソース共有と通信

Podは、構成要素間でのデータ共有および通信を可能にします。

Pod内のアプリケーションはすべて同じネットワーク名前空間（同じIPおよびポートスペース）を使用するため、 localhost としてお互いを「見つけて」通信できます。 このため、Pod内のアプリケーションはそれぞれ使用するポートを調整する必要があります。 各Podは、他の物理コンピュータやPodと自由に通信するためのフラットな共有ネットワーク空間上にIPアドレスを持ちます。

Pod内のアプリケーションコンテナのホスト名には、Podの名前が設定されます。 詳細はクラスターネットワークをご覧ください。

Podで実行されるアプリケーションコンテナの定義に加えて、Podによって共有ストレージであるボリュームを複数設定することも可能です。 ボリュームを使用すると、データはコンテナの再起動後も存続し、Pod内のアプリケーション間で共有できます。

Podの用途

Podは、垂直に統合されたアプリケーションスタック（例：LAMP）をホストするために使用できます。 しかし、Podを使う主な動機は、次のように同じ場所に配置され、共に管理されるヘルパープログラムをサポートすることです。

• コンテンツ管理システム(CMS)、ファイルやデータのローダー、ローカルのキャッシュマネージャーなど
• ログとチェックポイントのバックアップ、圧縮、ローテーション、スナップショットなど
• データの変更を監視するもの、ログをtailするもの、ロギングおよび監視の補助プログラム、イベントを発行するものなど
• プロキシ、ブリッジ、およびアダプタ
• コントローラー、マネージャー、コンフィギュレーター、およびアップデーター

個々のPodは、一般に、同じアプリケーションの複数のインスタンスを実行することを目的としていません。

詳細については、The Distributed System ToolKit: Patterns for Composite Containers（分散システムツールキット：複合コンテナのパターン）を参照してください。

考えられる代替案

単一の（Docker）コンテナで複数のプログラムを実行しないのはなぜですか？

1. 透明性のため。Pod内のコンテナをインフラストラクチャから見えるようにすることで、インフラストラクチャはプロセス管理やリソース監視などのサービスをコンテナに提供できます。 これは、ユーザーに多くの便益を提供します。
2. ソフトウェアの依存関係を減らすため。 個々のコンテナは、独立してバージョン管理、再構築、および再デプロイできます。 Kubernetesはいつか個々のコンテナのライブアップデートをサポートするかもしれません。
3. 使いやすさのため。ユーザーは独自のプロセスマネージャーを実行する必要はありません。シグナルや終了コードの伝播などについて心配する必要はありません。
4. 効率のため。インフラストラクチャがより責任を負うため、コンテナはより軽量になります。

アフィニティ（結合性、親和性）ベースのコンテナの共同スケジューリングをサポートしないのはなぜですか？

このアプローチによって、コンテナの共同配置は提供されるでしょう。 しかし、リソース共有やIPC、保証された命運の共有、および簡素化された管理といったPodの利点のほとんどは提供されないでしょう。

Podの耐久性（またはその欠如）

Podは、耐久性のある存在として扱われることを意図していません。 スケジューリングの失敗や、Nodeの故障には耐えられません。 リソースの不足やNodeのメンテナンスといった場合に、追い出されて停止することもあり得ます。

一般に、ユーザーはPodを直接作成する必要はありません。 ほとんどの場合、対象がシングルトンであったとしても、Deploymentsなどのコントローラーを使用するべきです。 コントローラーは、レプリケーションとロールアウト管理だけでなく、クラスターレベルの自己修復機能も提供します。 StatefulSetようなコントローラーもステートフルなPodをサポートします。

主要なユーザー向けのプリミティブとして集合APIを使用することは、Borg、 Marathon、Aurora、Tupperwareなどのクラスタースケジューリングシステムで比較的一般的です。

Podは、以下のことを容易にするためにプリミティブとして公開されています。

• スケジューラーとコントローラーをプラガブルにする
• コントローラーAPIを介して「プロキシ」の必要なしに、Podレベルの操作をサポートする
• ブートストラップなどのために、コントローラーの寿命からPodの寿命を切り離す
• コントローラーとサービスを分離する――エンドポイントコントローラーはPodのみを監視する
• Kubeletレベルの機能とクラスターレベルの機能をきれいに組み合わせる――Kubeletは事実上「Podコントローラー」となる
• アプリケーションの可用性を高める。 即ち、計画的な追い出しやイメージのプリフェッチなどの場合に、Podが停止し削除される前に、必ず事前に入れ換えられることを期待する

Podの終了

Podは、クラスター内のNodeで実行中のプロセスを表すため、不要になったときにそれらのプロセスを正常に終了できるようにすることが重要です（対照的なケースは、KILLシグナルで強制終了され、クリーンアップする機会がない場合）。 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。 ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録し、各コンテナのメインプロセスにTERMシグナルが送信されます。 猶予期間が終了すると、プロセスにKILLシグナルが送信され、PodはAPIサーバーから削除されます。 プロセスの終了を待っている間にKubeletかコンテナマネージャーが再起動されると、終了処理は猶予期間の後にリトライされます。

フローの例は下のようになります。

1. ユーザーがデフォルトの猶予期間（30秒）でPodを削除するコマンドを送信する
2. APIサーバー内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される
3. クライアントのコマンドに表示されたとき、Podは「終了中」と表示される
4. （3と同時に）Kubeletは、2の期間が設定されたためにPodが終了中となったことを認識すると、Podのシャットダウン処理を開始する
   1. Pod内のコンテナの1つがpreStopフックを定義している場合は、コンテナの内側で呼び出される。 猶予期間が終了した後も preStop フックがまだ実行されている場合は、次に、短い延長された猶予期間（2秒）でステップ2が呼び出される
   2. コンテナにTERMシグナルが送信される。Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれに preStop フックが必要になることがある
5. （3と同時に）Podはサービスを提供するエンドポイントのリストから削除され、ReplicationControllerの実行中のPodの一部とは見なされなくなる。 ゆっくりとシャットダウンするPodは、（サービスプロキシのような）ロードバランサーがローテーションからそれらを削除するので、トラフィックを処理し続けることはできない
6. 猶予期間が終了すると、Pod内でまだ実行中のプロセスはSIGKILLで強制終了される
7. Kubeletは猶予期間を0（即時削除）に設定することでAPIサーバー上のPodの削除を終了する。 PodはAPIから消え、クライアントからは見えなくなる

デフォルトでは、すべての削除は30秒以内に正常に行われます。 kubectl delete コマンドは、ユーザーがデフォルト値を上書きして独自の値を指定できるようにする --grace-period=<seconds> オプションをサポートします。 値 0 はPodを強制的に削除します。 kubectlのバージョン1.5以降では、強制削除を実行するために --grace-period=0 と共に --force というフラグを追加で指定する必要があります。

Podの強制削除

Podの強制削除は、クラスターの状態やetcdからPodを直ちに削除することと定義されます。 強制削除が実行されると、apiserverは、Podが実行されていたNode上でPodが停止されたというkubeletからの確認を待ちません。 API内のPodは直ちに削除されるため、新しいPodを同じ名前で作成できるようになります。 Node上では、すぐに終了するように設定されるPodは、強制終了される前にわずかな猶予期間が与えられます。

強制削除は、Podによっては潜在的に危険な場合があるため、慎重に実行する必要があります。 StatefulSetのPodについては、StatefulSetからPodを削除するためのタスクのドキュメントを参照してください。

Podコンテナの特権モード

Kubernetes v1.1以降、Pod内のどのコンテナでも、コンテナ仕様の SecurityContext の privileged フラグを使用して特権モードを有効にできます。 これは、ネットワークスタックの操作やデバイスへのアクセスなど、Linuxの機能を使用したいコンテナにとって役立ちます。 コンテナ内のプロセスは、コンテナ外のプロセスで利用できるものとほぼ同じ特権を獲得します。 特権モードでは、ネットワークプラグインとボリュームプラグインを別々のPodとして作成する方が簡単なはずです。それらをkubeletにコンパイルする必要はありません。

マスターがKubernetes v1.1以降を実行しており、Nodeがv1.1より前のバージョンを実行している場合、新しい特権付きのPodはAPIサーバーに受け入れられますが、起動されません。 それらは保留状態になります。 ユーザーが kubectl describe pod FooPodName を実行すると、Podが保留状態になっている理由を確認できます。 describeコマンド出力のイベントテーブルには、次のように表示されます。 Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'

マスターがv1.1より前のバージョンを実行している場合、特権を持つPodは作成できません。 ユーザーが特権付きのコンテナを含むPodを作成しようとすると、次のエラーを受け取ります。 The Pod "FooPodName" is invalid. spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'

APIオブジェクト

PodはKubernetes REST APIのトップレベルのリソースです。 APIオブジェクトの詳細については、[Pod APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)を参照してください 。

{{% /capture %}}