concepts/workloads/pods/pod/

Pods

pods是kubernetes中创建和管理的最小可部署计算单元。

• What is a Pod?
• Motivation for Pods
• Uses of pods
• Alternatives considered
• Durability of pods (or lack thereof)
• Termination of Pods
• Privileged mode for pod containers
• API Object

What is a Pod?

一个 pod是一个或多个[容器](https://kubernetes.io/docs/concepts/overvi... is kubernetes/why containers)（如Docker containers）组成，具有共享存储/网络，以及如何运行容器的规范。pod的内容总是在一个共享的上下文中共同定位和调度。pod对特定于应用程序的“逻辑主机”进行建模（它包含一个或多个相对紧密耦合的应用程序容器），在容器前世界中，在同一物理或虚拟机上执行意味着在同一逻辑主机上执行。

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.k8s支持多种容器,docker是使用最多

pod的共享上下文是一组Linux namespaces, cgroups,和潜在的其他隔离方面——与隔离docker容器相同。在pod的上下文中，各个应用程序可能应用了进一步的子隔离。

.pod中的容器共享一个ip地址和端口空间，并且可以通过“localhost”找到彼此。它们还可以使用标准进程间通信（如systemv信号量或posix共享内存）相互通信。不同pod中的容器具有不同的ip地址，如果没有[特殊配置](https://kubernetes.io/docs/concepts/policy... security policy/)，ipc将无法进行通信。这些容器通常通过pod ip地址相互通信。

pod中的应用程序还可以访问共享的卷，这些卷被定义为pod的一部分，并可以安装到每个应用程序的文件系统中。

根据docker结构，pod被建模为一组具有共享名称空间和共享文件系统卷的docker容器。

与单个应用程序容器一样，pod被认为是相对短暂（而不是持久）的实体。正如[pod lifecycle](https://kubernetes.io/docs/concepts/worklo... lifecycle/)中所讨论的，pod被创建、分配一个唯一的id（uid），并被调度到节点，节点在这些节点上一直保留到终止（根据重启策略）或删除。如果一个节点死了，那么调度到该节点的pod将在超时后被调度删除。给定的pod（由uid定义）不会“重新调度”到新节点；相反，它可以被相同的pod替换，如果需要，甚至可以使用相同的名称，但可以使用新的uid（请参阅[复制控制器](https://kubernetes.io/docs/concepts/worklo... controller/)了解更多信息细节）。

当某个东西的生命周期和一个pod相同时，比如说一个卷，这意味着只要这个pod（带那个uid）存在，它就存在。如果出于任何原因删除了该pod，即使创建了相同的替换，相关的东西（例如卷）也会被销毁并重新创建。

Pod diagram

一个多容器pod，包含一个文件拉取器和一个web服务器，该服务器使用一个持久卷在容器之间共享存储。

Motivation for Pods

Management

pods是多个协作过程模式的一个模型，它们形成了一个内聚的服务单元。它们通过提供比其组成应用程序集更高级别的抽象来简化应用程序部署和管理。pod充当部署、水平扩展和复制的单元。对pod中的容器自动处理托管（协同调度）、共享命运（例如终止）、协调复制、资源共享和依赖关系管理。

Resource sharing and communication

pods支持数据共享和组件间的通信。
pod中的应用程序都使用相同的网络名称空间（相同的ip和端口空间），因此可以“找到”彼此并使用“localhost”进行通信。因此，pod中的应用程序必须协调端口的使用。每个pod在一个平坦的共享网络空间中都有一个ip地址，该空间与网络上的其他物理计算机和pod完全通信。

pod中的容器将系统主机名视为与为pod配置的“name”相同。在Networking部分有更多关于这个的内容。

除了定义在pod中运行的应用程序容器外，pod还指定一组共享存储卷。卷使数据能够在容器重新启动后存活，并在pod内的应用程序之间共享。

Uses of pods

pod可用于托管垂直集成的应用程序堆栈（例如lamp），但它们的主要动机是支持同一位置、共同管理的助手程序，例如：

• content management systems, file and data loaders, local cache managers, etc. 内容管理系统、文件和数据加载程序、本地缓存管理器等。
• log and checkpoint backup, compression, rotation, snapshotting, etc. 日志和检查点备份、压缩、旋转、快照等。
• data change watchers, log tailers, logging and monitoring adapters, event publishers, etc. 数据更改监视程序、日志跟踪程序、日志和监视适配器、事件发布程序等
• proxies, bridges, and adapters 代理、网桥和适配器
• controllers, managers, configurators, and updaters 控制器、管理器、配置器和更新器

Individual Pods are not intended to run multiple instances of the same application, in general. 一般来说，单个pod不打算运行同一应用程序的多个实例。

有关详细说明，请参见分布式系统工具包：组合容器的模式.

Alternatives considered

为什么不在一个（docker）容器中运行多个程序呢？

1. Transparency. Making the containers within the Pod visible to the infrastructure enables the infrastructure to provide services to those containers, such as process management and resource monitoring. This facilitates a number of conveniences for users. 透明度。使pod中的容器对基础设施可见，使基础设施能够向这些容器提供服务，例如流程管理和资源监视。这为用户提供了许多便利。
2. Decoupling software dependencies. The individual containers may be versioned, rebuilt and redeployed independently. Kubernetes may even support live updates of individual containers someday.分离软件依赖关系。单个容器可以独立地进行版本控制、重建和重新部署。kubernetes甚至可能支持个别容器的实时更新。
3. Ease of use. Users don’t need to run their own process managers, worry about signal and exit-code propagation, etc.使用方便。用户不需要运行自己的进程管理器、担心信号和退出代码传播等。
4. Efficiency. Because the infrastructure takes on more responsibility, containers can be lighter weight.效率。因为基础设施承担了更多的责任，所以集装箱可以更轻。

为什么不支持基于关联的容器协同调度？

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的大部分好处，例如资源共享、ipc、保证命运共享和简化管理。

Durability of pods (or lack thereof)

pods不打算被视为持久的实体。它们无法在调度失败、节点故障或其他逐出（例如由于缺少资源或在节点维护的情况下）中生存。

一般来说，用户不需要直接创建pod。他们几乎应该总是使用控制器，即使是单例的，例如, Deployments. 控制器提供具有群集作用域的自我修复，以及复制和推出管理。控制器，如 StatefulSet也可以为有状态的pod提供支持。

在集群调度系统中，使用集合api作为面向主要用户的原语是比较常见的，包括 Borg, Marathon, Aurora, and Tupperware.

pod作为一个原语暴露出来，以便:

• scheduler and controller pluggability 调度器和控制器可插拔性
• support for pod-level operations without the need to “proxy” them via controller APIs 支持POD级操作，无需通过控制器API“代理”它们
• decoupling of Pod lifetime from controller lifetime, such as for bootstrapping 将pod生存期与控制器生存期分离，例如用于引导
• decoupling of controllers and services — the endpoint controller just watches Pods 控制器和服务的分离-端点控制器只监视pod
• clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the “pod controller” kubelet级功能与集群级功能的清晰组合-kubelet实际上是“pod控制器”
• high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching. 高可用性应用程序，预计pod将在终止之前被替换，当然也会在删除之前被替换，例如在计划的逐出或图像预取的情况下。

Termination of Pods 终止pods

.因为pod代表集群中节点上正在运行的进程，所以当不再需要这些进程时（与被kill信号猛烈杀死和没有机会清理相比），允许它们优雅地终止是很重要的。用户应该能够请求删除并知道进程何时终止，同时也能够确保删除最终完成。当用户请求删除pod时，系统会在强制终止pod之前记录预期的宽限期，并向每个容器中的主进程发送一个术语信号。宽限期结束后，kill信号将发送到这些进程，然后pod将从api服务器中删除。如果在等待进程终止时重新启动kubelet或容器管理器，则将在整个宽限期内重试终止。

An example flow:

1. User sends command to delete Pod, with default grace period (30s)用户发送命令删除pod，默认宽限期（30s）
2. The Pod in the API server is updated with the time beyond which the Pod is considered “dead” along with the grace period. api服务器中的pod随着pod被视为“死亡”的时间以及宽限期而更新。
3. Pod shows up as “Terminating” when listed in client commands POD在客户机命令中列出时显示为“终止”
4. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process. （与3同时）当kubelet看到由于设置了2中的时间而将pod标记为终止时，它开始pod关闭过程。
   1. If one of the Pod’s containers has defined a preStop hook, it is invoked inside of the container. If the preStop hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period. 如果pod的其中一个容器定义了一个 preStop hook则在容器内部调用它。如果“prestop”钩子在宽限期到期后仍在运行，则调用步骤2时会有一个小（2秒）的延长宽限期。
   2. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a preStop hook if the order in which they shut down matters.向容器发送术语信号。注意，并非吊舱中的所有集装箱都会同时收到术语信号，如果它们关闭的顺序很重要，则每个集装箱可能都需要一个“预停止”挂钩。
5. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.(与3同时）pod从服务的终结点列表中移除，并且不再被视为复制控制器正在运行的pod集的一部分。缓慢关闭的pod不能继续充当负载平衡器（如服务代理）将其从循环中移除。
6. When the grace period expires, any processes still running in the Pod are killed with SIGKILL. 当宽限期到期时，pod中仍在运行的任何进程都会被sigkill杀死。
7. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client.kubelet将通过设置宽限期0（立即删除）完成删除api服务器上的pod。pod从api中消失，不再从客户端可见。

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. You must specify an additional flag --force along with --grace-period=0 in order to perform force deletions.默认情况下，所有删除操作在30秒内都是正常的。kubectl delete命令支持--grace period=`选项，允许用户覆盖默认值并指定自己的值。值“0”[强制删除]](https://kubernetes.io/docs/concepts/worklo...) 必须指定附加标志“-force”和“--grace period=0”。

Force deletion of pods

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 API server 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.强制删除pod定义为立即从集群状态和etcd中删除pod。执行强制删除时，api服务器不会等待kubelet确认pod已在其运行的节点上终止。它会立即删除api中的pod，以便可以使用相同的名称创建新的pod。在节点上，设置为立即终止的吊舱在被强制杀死之前仍然会有一个小的宽限期。

强制删除可能对某些吊舱有潜在危险，应谨慎执行。如果是statefulset pods，请参阅r deleting Pods from a StatefulSet.

Privileged mode for pod containers

Any container in a Pod can enable privileged mode, using the privileged flag on the security context 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中的任何容器都可以使用容器规范的安全上下文上的“privileged”标志启用特权模式。这对于希望使用Linux功能（如操作网络）的容器非常有用堆栈和访问设备。容器内的进程获得的权限与容器外的进程几乎相同。使用特权模式，将网络和卷插件编写为不需要编译到kubelet中的单独pod应该更容易。

Note: Your container runtime must support the concept of a privileged container for this setting to be relevant.容器运行时必须支持特权容器的概念，才能与此设置相关。

API Object

Pod is a top-level resource in the Kubernetes REST API. The Pod API object definition describes the object in detail

pod是kubernetes rest api中的顶级资源。PODAPI对象定义详细描述了该对象。

Feedback

Was this page helpful?

本作品采用《CC 协议》，转载必须注明作者和本文链接