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:
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:
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