kubernetes-handbook/concepts/pod.md

11 KiB
Raw Blame History

Pod解析

Pod是kubernetes中可以创建的最小部署单元。

V1 core版本的Pod的配置模板见Pod template

什么是Pod

Pod就像是豌豆荚一样它由一个或者多个容器组成例如Docker容器它们共享容器存储、网络和容器运行配置项。Pod中的容器总是被同时调度有共同的运行环境。你可以把单个Pod想象成是运行独立应用的“逻辑主机”——其中运行着一个或者多个紧密耦合的应用容器——在有容器之前这些应用都是运行在几个相同的物理机或者虚拟机上。

尽管kubernetes支持多种容器运行时但是docker依然是最常用的运行时环境我们可以使用docker的术语和规则来定义Pod。

Pod中共享的环境包括Linux的namespacecgroup和其他可能的隔绝环境这一点跟docker容器一致。在Pod的环境中每个容器中可能还有更小的子隔离环境。

Pod中的容器共享IP地址和端口号它们之间可以通过localhost互相发现。它们之间可以通过进程间通信,例如SystemV信号或者POSIX共享内存。不同Pod之间的容器具有不同的IP地址不能直接通过IPC通信。

Pod中的容器也有访问共享volume的权限这些volume会被定义成pod的一部分并挂载到应用容器的文件系统中。

根据docker的结构Pod中的容器共享namespace和volume不支持共享PID的namespace。

就像每个应用容器pod被认为是临时非持久的实体。在Pod的生命周期中讨论过pod被创建后被分配一个唯一的UIUID调度到节点上并一致维持期望的状态知道被终结根据重启策略或者被删除。如果node死掉了分配到了这个node上的pod在经过一个超时时间后会被重新调度到其他node节点上。一个给定的pod如UID定义的不会被“重新调度”到新的节点上而是被一个同样的pod取代如果期望的话甚至可以是相同的名字但是会有一个新的UID查看replication controller获取详情未来一个更高级别的API将支持pod迁移

Volume跟pod有相同的生命周期当其UID存在的时候。当Pod因为某种原因被删除或者被新创建的相同的Pod取代它相关的东西例如volume也会被销毁和再创建一个新的volume。

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的动机

管理

Pod是一个服务的多个进程的聚合单位pod提供这种模型能够简化应用部署管理通过提供一个更高级别的抽象的方式。Pod作为一个独立的部署单位支持横向扩展和复制。共生协同调度命运共同体例如被终结协同复制资源共享依赖管理Pod都会自动的为容器处理这些问题。

资源共享和通信

Pod中的应用可以共享网络空间IP地址和端口因此可以通过localhost互相发现。因此pod中的应用必须协调端口占用。每个pod都有一个唯一的IP地址跟物理机和其他pod都处于一个扁平的网络空间中它们之间可以直接连通。

Pod中应用容器的hostname被被设置成Pod的名字。

Pod中的应用容器可以共享volume。Volume能够保证pod重启时使用的数据不丢失。

Pod的使用

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

通常单个pod中不会同时运行一个应用的多个实例。

详细说明请看: The Distributed System ToolKit: Patterns for Composite Containers.

其他替代选择

为什么不直接在一个容器中运行多个应用程序呢?

  1. 透明。让Pod中的容器对基础设施可见以便基础设施能够为这些容器提供服务例如进程管理和资源监控。这可以为用户带来极大的便利。
  2. 解耦软件依赖。每个容器都可以进行版本管理独立的编译和发布。未来kubernetes甚至可能支持单个容器的在线升级。
  3. 使用方便。用户不必运行自己的进程管理器,还要担心错误信号传播等。
  4. 效率。因为由基础架构提供更多的职责,所以容器可以变得更加轻量级。

为什么不支持容器的亲和性的协同调度?

这种方法可以提供容器的协同定位能够根据容器的亲和性进行调度但是无法实现使用pod带来的大部分好处例如资源共享IPC保持状态一致性和简化管理等。

Pod的持久性或者说缺乏持久性

Pod在设计支持就不是作为持久化实体的。在调度失败、节点故障、缺少资源或者节点维护的状态下都会死掉会被驱逐。

通常用户不需要手动直接创建Pod而是应该使用controller例如Deployments即使时创建单个Pod的情况下。Controller可以提供集群级别的自愈功能、复制和升级管理。

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:

  • scheduler and controller pluggability
  • support for pod-level operations without the need to "proxy" them via controller APIs
  • decoupling of pod lifetime from controller lifetime, such as for bootstrapping
  • decoupling of controllers and services — the endpoint controller just watches pods
  • clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
  • 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, image prefetching, or live pod migration #3949

StatefulSet controller目前还是beta状态支持有状态的Pod。在1.4版本中被称为PetSet。在kubernetes之前的版本中创建有状态pod的最佳方式是创建一个replica为1的replication controller。

Pod的终止

因为Pod作为在集群的节点上运行的进程所以在不再需要的时候能够优雅的终止掉是十分必要的比起使用发送KILL信号这种暴力的方式。用户需要能够放松删除请求并且知道它们何时会被终止是否被正确的删除。用户想终止程序时发送删除pod的请求在pod可以被强制删除前会有一个优雅删除的时间会发送一个TERM请求到每个容器的主进程。一旦超时将向主进程发送KILL信号并从API server中删除。如果kubelet或者container manager在等待进程终止的过程中重启在重启后仍然会重试完整的优雅删除阶段。

示例流程如下:

  1. 用户发送删除pod的命令默认优雅删除时期是30秒
  2. 在Pod超过该优雅删除期限后API server就会更新Pod的状态为“dead”
  3. 在客户端命令行上显示的Pod状态为“terminating”
  4. 跟第三步同时当kubelet发现pod被标记为“terminating”状态时开始停止pod进程
    1. 如果在pod中定义了preStop hook在停止pod前会被调用。如果在优雅删除期限过期后preStop hook依然在运行第二步会再增加2秒的优雅时间
    2. 向Pod中的进程发送TERM信号
  5. 跟第三步同时该Pod将从该service的端点列表中删除不再是replication controller的一部分。关闭的慢的pod将继续处理load balancer转发的流量
  6. 过了优雅周期后将向Pod中依然运行的进程发送SIGKILL信号而杀掉进程。
  7. Kublete会在API server中完成Pod的的删除通过将优雅周期设置为0立即删除。Pod在API中消失并且在客户端也不可见。

删除优雅周期默认是30秒。 kubectl delete命令支持 —grace-period=<seconds> 选项允许用户设置自己的优雅周期时间。如果设置为0将强制删除pod。在kubectl>=1.5版本的命令中,你必须同时使用 --force--grace-period=0 来强制删除pod。

强制删除Pod

Pod的强制删除是通过在集群和etcd中将其定义为删除状态。当执行强制删除命令时API server不会等待该pod所运行在节点上的kubelet确认就会立即将该pod从API server中移除这时就可以创建跟原pod同名的pod了。这时在节点上的pod会被立即设置为terminating状态不过在被强制删除之前依然有一小段优雅删除周期。

强制删除对于某些pod具有潜在危险性请谨慎使用。使用StatefulSet pod的情况下请参考删除StatefulSet中的pod文章。

Pod中容器的特权模式

从kubernetes1.1版本开始pod中的容器就可以开启previleged模式在容器定义文件的 SecurityContext 下使用 privileged flag。 这在使用linux的网络操作和访问设备的能力时是很用的。同时开启的特权模式的Pod中的容器也可以访问到容器外的进程和应用。在不需要修改和重新编译kubelet的情况下就可以使用pod来开发节点的网络和存储插件。

如果master节点运行的是kuberentes1.1.或更高版本而node节点的版本低于1.1版本则API server将也可以接受新的特权模式的pod但是无法启动pod将处于pending状态。

执行 kubectl describe pod FooPodName可以看到为什么pod处于pending状态。输出的event列表中将显示 Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'

如果master节点的版本低于1.1无法创建特权模式的pod。如果你仍然试图去创建的话你得到如下错误

The Pod "FooPodName" is invalid. spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'

API Object

Pod是kubernetes REST API中的顶级资源类型。

在kuberentes1.6的V1 core API版本中的Pod的数据结构如下图所示

Pod Cheetsheet