Pods are the smallest deployable units of computing that can be created and managed in Kubernetes.php
A pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers. A pod’s contents are always co-located and co-scheduled, and run in a shared context. A pod models an application-specific 「logical host」 - it contains one or more application containers which are relatively tightly coupled — in a pre-container world, they would have executed on the same physical or virtual machine.html
While Kubernetes supports more container runtimes than just Docker, Docker is the most commonly known runtime, and it helps to describe pods in Docker terms.node
The shared context of a pod is a set of Linux namespaces, cgroups, and potentially other facets of isolation - the same things that isolate a Docker container. Within a pod’s context, the individual applications may have further sub-isolations applied.linux
Containers within a pod share an IP address and port space, and can find each other via localhost
. They can also communicate with each other using standard inter-process communications like SystemV semaphores or POSIX shared memory. Containers in different pods have distinct IP addresses and can not communicate by IPC without special configuration. These containers usually communicate with each other via Pod IP addresses.git
一個Pod中的容器共享IP地址和端口空間,可使用localhost通訊。還可使用標準inter-process 通訊,好比System V semaphores或POSIX共享內存。不一樣Pods上的容器的IP地址不一樣,不能直接用IPC通訊,除非進行特殊設置。這些容器可使用Pod IP地址通訊。github
Applications within a pod also have access to shared volumes, which are defined as part of a pod and are made available to be mounted into each application’s filesystem.web
In terms of Docker constructs, a pod is modelled as a group of Docker containers with shared namespaces and shared volumes.docker
Like individual application containers, pods are considered to be relatively ephemeral (rather than durable) entities. As discussed in life of a pod, pods are created, assigned a unique ID (UID), and scheduled to nodes where they remain until termination (according to restart policy) or deletion. If a node dies, the pods scheduled to that node are scheduled for deletion, after a timeout period. A given pod (as defined by a UID) is not 「rescheduled」 to a new node; instead, it can be replaced by an identical pod, with even the same name if desired, but with a new UID (see replication controller for more details).apache
When something is said to have the same lifetime as a pod, such as a volume, that means that it exists as long as that pod (with that UID) exists. If that pod is deleted for any reason, even if an identical replacement is created, the related thing (e.g. volume) is also destroyed and created anew.bootstrap
Pod內的全部應用均可以使用共享volumes,共享volumes是做爲Pod的一部分,每一個應用的文件系統上都被掛載了。
以Docker爲例,pod做爲docker容器的模型,共享了namespaces和shared volumes。
每一個Pod在被建立時,都被賦值了一個unique ID(UID)
若是說某個東西的生命週期和pod相同,好比volume,意思是隻要pod存在,這個東西就存在。若是pod被刪除了,即便出現了相同的替代pod,這個東西也會被消耗重建。
A multi-container pod that contains a file puller and a web server that uses a persistent volume for shared storage between the containers.
閃圖是一個多容器pod,包含一個file puller和一個web server,在容器之間使用persistent volume用來共享存儲。
Pods are a model of the pattern of multiple cooperating processes which form a cohesive unit of service. They simplify application deployment and management by providing a higher-level abstraction than the set of their constituent applications. Pods serve as unit of deployment, horizontal scaling, and replication. Colocation (co-scheduling), shared fate (e.g. termination), coordinated replication, resource sharing, and dependency management are handled automatically for containers in a pod.
Pod是一種將多個相互協做的進程組成聚合的服務單元的模型,經過提供對多個應用的多個抽象,簡化了應用的部署和管理。Pod是做爲部署、水平擴展、副本的管理單元。Pod中的多個容器相互寫做、共享生命週期、副本一致、資源共享、依賴管理等功能都是自動由Pod管理的。
Pods enable data sharing and communication among their constituents.
The applications in a pod all use the same network namespace (same IP and port space), and can thus 「find」 each other and communicate using localhost
. Because of this, applications in a pod must coordinate their usage of ports. Each pod has an IP address in a flat shared networking space that has full communication with other physical computers and pods across the network.
The hostname is set to the pod’s Name for the application containers within the pod. More details on networking.
In addition to defining the application containers that run in the pod, the pod specifies a set of shared storage volumes. Volumes enable data to survive container restarts and to be shared among the applications within the pod.
Pod中的多個應用共享數據和通訊資源。
一個Pod中的全部應用使用相同的網絡空間(IP和port域),可使用localhost相互通訊。所以一個pod中的應用必須協商ports的使用。每一個pod都有一個IP地址,能夠與網絡中的其餘物理機和pods相互通訊。
pod的hostname就是pod的名稱。
pod能夠設置一些shared storage volumnes,容許容器重啓後讀取服務,容器間共享數據。
Pods can be used to host vertically integrated application stacks (e.g. LAMP), but their primary motivation is to support co-located, co-managed helper programs, such as:
Individual pods are not intended to run multiple instances of the same application, in general.
For a longer explanation, see The Distributed System ToolKit: Patterns for Composite Containers.
Why not just run multiple programs in a single (Docker) container?
Why not support affinity-based co-scheduling of containers?
That approach would provide co-location, but would not provide most of the benefits of pods, such as resource sharing, IPC, guaranteed fate sharing, and simplified management.
Pods aren’t intended to be treated as durable entities. They won’t survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
In general, users shouldn’t need to create pods directly. They should almost always use controllers even for singletons, for example, Deployments). Controllers provide self-healing with a cluster scope, as well as replication and rollout management. Controllers like StatefulSet can also provide support to stateful pods.
The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including Borg, Marathon, Aurora, and Tupperware.
Pod is exposed as a primitive in order to facilitate:
Because pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a pod the system records the intended grace period before the pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired the KILL signal is sent to those processes and the pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
優雅地關閉pod,首先發送TERM信號,超過等待時間後發送KILL信號。
An example flow:
preStop
hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.By default, all deletes are graceful within 30 seconds. The kubectl delete
command supports the --grace-period=<seconds>
option which allows a user to override the default and specify their own value. The value 0
force deletes the pod. In kubectl version >= 1.5, you must specify an additional flag --force
along with --grace-period=0
in order to perform force deletions.
Force deletion of a pod is defined as deletion of a pod from the cluster state and etcd immediately. When a force deletion is performed, the apiserver does not wait for confirmation from the kubelet that the pod has been terminated on the node it was running on. It removes the pod in the API immediately so a new pod can be created with the same name. On the node, pods that are set to terminate immediately will still be given a small grace period before being force killed.
Force deletions can be potentially dangerous for some pods and should be performed with caution. In case of StatefulSet pods, please refer to the task documentation for deleting Pods from a StatefulSet.
From Kubernetes v1.1, any container in a pod can enable privileged mode, using the privileged
flag on the SecurityContext
of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don’t need to be compiled into the kubelet.
能夠操控網絡堆棧、操做設備。容器中的進程幾乎享有容器外進程的全部特權。單獨的pod更容易地寫入網絡和卷
If the master is running Kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state. If user calls kubectl describe pod FooPodName
, user can see the reason why the pod is in pending state. The events table in the describe command output will say: Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'
若是master的版本高,可是node的版本低,使用特權模式的pods會處於pending狀態。
If the master is running a version lower than v1.1, then privileged pods cannot be created. If user attempts to create a pod, that has a privileged container, the user will get the following error: The Pod "FooPodName" is invalid. spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'
若是master的版本低,特權pods建立時會報錯。
Pod is a top-level resource in the Kubernetes REST API. More details about the API object can be found at: Pod API object.