pod-overview.md

reviewers	title	content_template	weight	card
erictune	Podの概要	templates/concept	10	name weight コンセプト 60

{{% capture overview %}} このページでは、Kubernetesオブジェクトモデルにおけるデプロイ可能な最小単位である Pod の概要を説明します。 {{% /capture %}}

{{% capture body %}}

Pod を理解する

Pod は Kubernetesにおける基本的なビルディングブロックです。Kubernetesオブジェクトモデルにおいて作成やデプロイを行う、最小かつ最も単純な単位です。Podは、クラスタ上で実行されるプロセスを表します。

Podは、単一のアプリケーションコンテナ(場合によっては複数のコンテナ)、ストレージリソース、ユニークなネットワークIP、およびコンテナの実行を制御するオプションをカプセル化します。Podは、デプロイの単位を表します: Kubernetesにおけるアプリケーションの単一インスタンス 単一のコンテナ、または密結合およびリソースを共有している少数のコンテナ群で構成されます。

Docker は、Kubernetes Podのコンテナランタイムとして最もよく使われています。他のコンテナランタイムもサポートされています。

KubernetesクラスタにおけるPodの主要な用途は、次の2つです:

• 単一のコンテナを実行するPod "1 Pod 1コンテナ" モデルは、Kubernetesの最も一般的な利用法です。このケースでは、Podを単一のコンテナのラッパーとみなします。Kubernetesは、コンテナを直接管理するのではなく、Podを管理します。
• 協調する複数のコンテナを実行するPod Podは、一箇所に配置され、密結合しリソースを共有するコンテナ群で構成されたアプリケーションをカプセル化します。一箇所に配置されたコンテナ群のそれぞれは、単一で高凝集なサービスユニットです。1つのコンテナが共有ボリュームからファイルを公開する一方で、別の "サイドカー" コンテナが、ファイルのリフレッシュや更新を行います。Podは、これらのコンテナやストレージリソースを合わせ、単一の管理可能なエンティティにラップします。

Kubernetes Blog には、Podの利用法についていくつかの情報があります:

• The Distributed System Toolkit: Patterns for Composite Containers
• Container Design Patterns

個々のPodの目的は、あるアプリケーションの一つのインスタンスを実行することです。アプリケーションを水平にスケールさせたい場合(複数のインスタンスで実行など)は、複数のPodを、各インスタンスに1つずつ使います。Kubernetesでは、これを一般的に レプリケーション と呼びます。レプリケーションされたPodは、通常、コントローラと呼ばれる抽象化されたグループが作成され、管理されます。Podとコントローラ を参照してください。

Podはどのように複数のコンテナを管理しているのか

Podは、高凝集なサービス単位を構成するような、協調する複数の(コンテナ)プロセスをサポートするよう設計されています。Pod内のコンテナは、クラスタ上で同一の物理または仮想マシンに配置され、スケジューリングされます。コンテナ間で、リソースや依存を共有し、相互に通信し、終了するタイミングや方法を調整します。

Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram:

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

Pods provide two kinds of shared resources for their constituent containers: networking and storage.

Networking

Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers inside a Pod can communicate with one another using localhost. When containers in a Pod communicate with entities outside the Pod, they must coordinate how they use the shared network resources (such as ports).

Storage

A Pod can specify a set of shared storage volumes. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See Volumes for more information on how Kubernetes implements shared storage in a Pod.

Working with Pods

You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a Node in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the pod is evicted for lack of resources, or the Node fails.

{{< note >}} Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted. {{< /note >}}

Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a Controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See Pods and Controllers for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.

Pods and Controllers

A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.

Some examples of Controllers that contain one or more pods include:

• Deployment
• StatefulSet
• DaemonSet

In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

Pod Templates

Pod templates are pod specifications which are included in other objects, such as Replication Controllers, Jobs, and DaemonSets. Controllers use Pod Templates to make actual pods. The sample below is a simple manifest for a Pod which contains a container that prints a message.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

Rather than specifying the current desired state of all replicas, pod templates are like cookie cutters. Once a cookie has been cut, the cookie has no relationship to the cutter. There is no "quantum entanglement". Subsequent changes to the template or even switching to a new template has no direct effect on the pods already created. Similarly, pods created by a replication controller may subsequently be updated directly. This is in deliberate contrast to pods, which do specify the current desired state of all containers belonging to the pod. This approach radically simplifies system semantics and increases the flexibility of the primitive.

{{% /capture %}}

{{% capture whatsnext %}}

• Learn more about Pod behavior:
  • Pod Termination
  • Pod Lifecycle {{% /capture %}}