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