kubernetes concepts -- Pod Overview

This page provides an overview of Pod, the smallest deployable object in the Kubernetes object model.

Pod是Kubernetes 对象模型中最小的可部署对象。

Understanding Pods

A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents a running process on your cluster.

A Pod encapsulates an application container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources.

Pod是用户能够建立或部署的最小、最简单的单元，是kubernetes最基础的基石。一个Pod表明k8s集群的一个运行进程。

一个Pod包含了一个或多个应用容器、持久化资源、一个独特的网络IP、管理容器运行的参数。一个Pod表明了部署的一个单元：kubernetes某个应用的一个实例，Pod中可能会包含一个或多个容器，这些容器紧密关联、共享资源。

 

Docker is the most common container runtime used in a Kubernetes Pod, but Pods support other container runtimes as well.

Docker是Pod中最广泛应用的容器技术，可是Pods还支持其余容器技术。

Pods in a Kubernetes cluster can be used in two main ways:

• Pods that run a single container. The “one-container-per-Pod” model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
• Pods that run multiple containers that need to work together. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service–one container serving files from a shared volume to the public, while a separate “sidecar” container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.

使用Pods的方法：

• 运行一个单一容器。“one-container-per-Pod”是最普通的用例。此时，你能够把Pod看作是对单一容器的封装，k8s直接管理Pod而不是容器。
• 运行多个须要相互协助的容器。一个Pod能够封装一个应用，该应用可包括多个同地协做、共享资源的容器。这些同地协做的容器能够组成一个紧密内聚的服务单元，一个容器从共享volume提供文件做为公共文件，同时旁边一个独立的容器刷新或更新这些文件。Pod将这些容器和存储资源封装称为一个单独的可管理的实体。

The Kubernetes Blog has some additional information on Pod use cases. For more information, see:

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

Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as replication. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See Pods and Controllers for more information.

每一个Pod应该被用来运行一个给定应用的单实例。若是你想对应用进行扩缩容（如运行多个实例），你应该用多个Pods，一个Pod对应一个实例。在kubernetes，这被称为副本。副本Pods一般被做为一个抽象总体Controller，被同时建立和管理。

How Pods manage multiple Containers

Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.

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:

注意，在一个Pod中放置多个同地协做和管理的容器是相对高级的用例。只有当这些容器是紧密耦合的状况下，用户才能使用这个模式。例如，你可使用一个容器做为web服务器，该容器使用共享volume中的文件，一个单独的sidecar容器从远端更新这些文件。

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

Pods提供两种共享资源：网络和持久化。

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).

每一个Pod都有一个独特的IP地址。Pod中的每一个容器都共享这个网络名称空间，包括IP地址和网络端口。Pod中的多个容器可使用localhost进行相互通讯。当Pod中的容器与Pod外的实体通讯时，他们必须对网络资源（如端口）进行协商。

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.

一个Pod能够制定一些共享存储卷。Pod中的全部容器均可以使用这些共享卷，运行这些容器共享数据。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.

不多直接建立Pods，在设计时Pod就被定位成短时的、一次性的实体。当Pod被用户或Controller建立时，kubernetes会在一个节点上安排运行这个Pod。这个Pod会一直运行，直到进程被终止，如pod被删除、缺乏资源Pod被收回、节点挂掉。

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.

重启Pod中的容器不等于重启Pod。

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.

Pod没有自我修复功能。若是Kubernetes将Pod安排在某个挂掉的节点上运行，或者安排失败，这个Pod就被删除了。同理，当资源匮乏或节点维护，Pod也会被删除。kubernetes使用更高级别的抽象对象Controller来管理Pod实例。所以，虽然能够直接使用Pod，可是更通常的操做是使用Controller来管理Pod。

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.

Controller能够建立、管理多个Pods、在集群上处理副本、扩缩容、自我修复。例如，若是一个节点挂掉了，controller对自动在另外一个节点上建立相同的Pod。

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.

通常状况下，controller使用Pod template建立Pods。

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.

Pod templated是Pod的详细说明，其余对象如Replication Controller、Job、DaemonSet都会用到Pod templateds。Controllers使用Pod templdates建立Pods。下面的例子是一个简单的Pod模板，包含一个打印信息的容器。

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.

除了声明当前全部副本的目标状态，Pod templdates就像cookie cutters。cookie一旦被切掉，就与cutter没有任何关系。其中不会有任何纠缠。Pod template的后续更改或者使用另一个template，都与已经建立的Pod没有任何关系。后续被建立的Pods会被相应修改。

What’s next

• Learn more about Pod behavior:
  • Pod Termination
  • Other Pod Topics