Pod生命周期说明

一、Pod生命周期

Pod对象从创建开始至终止退出之间的时间称为其生命周期，这段时间里的某个时间点，Pod会处于某个特定的运行阶段或相位（phase），以概括描述其在生命周期中所处的位置。Kubernetes为Pod资源严格定义了5种相位，并将特定Pod对象的当前相位存储在其内部的子对象PodStatus的phase字段上，因而它总是应该处于其生命进程中以下几个相位之一。

• Pending：API Server创建了Pod资源对象并已存入etcd中，但它尚未被调度完成，或仍处于从仓库中下载容器镜像的过程中。

• Running：Pod已经被调度至某节点，所有容器都已经被kubelet创建完成，且至少有一个容器处于启动、重启或运行过程中。

• Succeeded：Pod中的所有容器都已经成功终止且不会再重启。

• Failed：所有容器都已经终止，但至少有一个容器终止失败，即容器以非0状态码退出或已经被系统终止。

• Unknown：API Server无法正常获取到Pod对象的状态信息，通常是由于其无法与所在工作节点的kubelet通信所致。

需要注意的是，阶段仅是对Pod对象生命周期运行阶段的概括性描述，而非Pod或内部容器状态的综合汇总，因此Pod对象的status字段中的状态值未必一定是可用的相位，它也有可能是Pod的某个错误状态，例如CrashLoopBackOff或Error等。

Pod资源的核心职责是运行和维护称为主容器的应用程序容器，在其整个生命周期之中的多种可选行为也是围绕更好地实现该功能而进行，其生命周期如下图所示。

其中，初始化容器（init container）是常用的Pod环境初始化方式，健康状态检测（startupProbe、livenessProbe和readinessProbe）为编排工具提供了监测容器运行状态的编程接口，而事件钩子（preStop和postStart）则赋予了应用容器读取来自编排工具上自定义事件的机制。尽管健康状态检测也可归入较为重要的操作环节，但这其中仅创建和运行主容器是必要任务，其他都可根据需要在创建Pod对象时按需定义。

若用户给出了上述全部定义，则一个Pod对象生命周期的运行步骤如下：

 1）在启动包括初始化容器在内的任何容器之前先创建pause基础容器，它初始化Pod环境并为后续加入的容器提供共享的名称空间。

 2）按顺序以串行方式运行用户定义的各个初始化容器进行Pod环境初始化；任何一个初始化容器运行失败都将导致Pod创建失败，并按其restartPolicy的策略进行处理，默认为重启。

 3）待所有初始化容器成功完成后，启动应用程序容器，多容器Pod环境中，此步骤会并行启动所有应用容器，例如主容器和Sidecar容器，它们各自按其定义展开其生命周期；本步骤及后面的几个步骤都将以主容器为例进行说明；容器启动的那一刻会同时运行主容器上定义的PostStart钩子事件，该步骤失败将导致相关容器被重启。

 4）运行容器启动健康状态监测（startupProbe），判定容器是否启动成功；该步骤失败，同样参照restartPolicy定义的策略进行处理；未定义时，默认状态为Success。

 5）容器启动成功后，定期进行存活状态监测（liveness）和就绪状态监测（readiness）；存活状态监测失败将导致容器重启，而就绪状态监测失败会使得该容器从其所属的Service对象的可用端点列表中移除。

 6）终止Pod对象时，会先运行preStop钩子事件，并在宽限期（terminationGrace-PeriodSeconds）结束后终止主容器，宽限期默认为30秒。

 即：创建pause容器--运行init容器--启动应用主容器--PostStart--startupProbe--livenessProbe--readinessProbe--preStop

二、Pod创建和删除过程

1. 创建

Pod是Kubernetes的基础单元，其创建过程如下图所示：

 1）用户通过kubectl或其他API客户端提交Pod Spec给API Server。

 2）API Server尝试着将Pod对象的相关信息存入etcd中，待写入操作执行完成，API Server即会返回确认信息至客户端。

 3）Scheduler（调度器）通过其watcher监测到API Server创建了新的Pod对象，于是为该Pod对象挑选一个工作节点并将结果信息更新至API Server。

 4）调度结果信息由API Server更新至etcd存储系统，并同步给Scheduler。

 5）相应节点的kubelet监测到由调度器绑定于本节点的Pod后会读取其配置信息，并由本地容器运行时创建相应的容器启动Pod对象后将结果回存至API Server。

 6）API Server将kubelet发来的Pod状态信息存入etcd系统，并将确认信息发送至相应的kubelet。

 说明：几个关键点

• 所有组件通信都是通过API Server完成

• 提交、调度、运行等每个操作执行后结果都要进入存储到etcd中

• 各组件基于watcher机制通过API Server监听Pod资源状态

• 真正运行容器的是容器运行时，由kubelet通过CRI调用

• Controller Manager通过control loop使实际状态趋向于期望状态

2. 删除

Kubernetes可设置删除宽限期确保终止操作能够以平滑方式优雅完成，删除过程如下图所示：

 1）用户发送删除Pod对象的命令。

 2）API Server将Pod标记为Terminating状态，设置宽限期，并存入etcd。

 3）kubelet通过API Server监听到Pod对象转为Terminating状态的同时启动Pod关闭过程，发送TERM信号给容器运行时。

 4）（与第3步同时运行）端点控制器监听到Pod对象转为Terminating状态时将其从所有匹配到此端点的Service资源的端点列表中移除。

 5）如果当前Pod对象定义了preStop钩子句柄，在其标记为terminating后即会以同步方式启动执行；如若宽限期结束后，preStop仍未执行完，则重新执行第2步并额外获取一个时长为2秒的小宽限期。

 6）宽限期结束后，若存在任何一个仍在运行的进程，kubelet会直接发送SIGKILL信号，强制立即删除pod。

 7）API Server从etcd删除Pod对象从而完成删除操作，它变得对用户不再可见。

 说明：几个关键点

• Pod会首先标记为Terminating状态

• 端点控制器会从所有Service的端点列表中移除该Pod

参考说明：

以上内容均参考马哥《Kubernets 进阶实战 2》第四章 应用部署、运行与管理