Pod生命周期简洁版

Pod 的生命周期

Pod 的生命周期 官方文档链接

Pod的status字段是一个PodStatus的对象，PodStatus中有一个phase字段。无论是手动创建还是通过Deployment等控制器创建，Pod对象总是应该处于其生命进程中以下几个阶段（phase）之一。

• 挂起（Pending）：API Server创建了pod资源对象已存入etcd中，但它尚未被调度完成，或者仍处于从仓库下载镜像的过程中。
• 运行中（Running）：Pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成。
• 成功（Succeeded）：Pod中的所有容器都已经成功终止并且不会被重启
• 失败（Failed）：Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。即容器以非0状态退出或者被系统禁止。
• 未知（Unknown）：Api Server无法正常获取到Pod对象的状态信息，通常是由于无法与所在工作节点的kubelet通信所致。

注意：当一个 Pod 被删除时，它会被一些 kubectl 命令显示为Terminating。此Terminating状态不是 Pod 阶段之一。Pod 默认的正常终止的期限，默认为 30 秒。你可以使用该标志–force来强行终止pod。

Pod对象自从其创建开始至其终止退出的时间范围称为其生命周期。在这段时间中，Pod会处于多种不同的状态，并执行一些操作；其中，创建主容器（main container）为必需的操作，其他可选的操作还包括运行初始化容器（init container）、容器启动后钩子（post start hook）、容器的存活性探测（liveness probe）、就绪性探测（readiness probe）以及容器终止前钩子（pre stop hook）等，这些操作是否执行则取决于Pod的定义。如下图所示：

Pod是kubernetes的基础单元，理解它的创建过程对于了解系统运作大有裨益。如下图描述了一个Pod资源对象的典型创建过程。

• 用户通过kubectl或其他API客户端提交了Pod Spec给API Server。
• API Server尝试着将Pod对象的相关信息存入etcd中，待写入操作执行完成，API Server即会返回确认信息至客户端。
• API Server开始反映etcd中的状态变化。
• 所有的kubernetes组件均使用“watch”机制来跟踪检查API Server上的相关的变动。
• kube-scheduler（调度器）通过其“watcher”觉察到API Server创建了新的Pod对象但尚未绑定至任何工作节点。
• kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新至API Server。
• 调度结果信息由API Server更新至etcd存储系统，而且API Server也开始反映此Pod对象的调度结果。
• Pod被调度到的目标工作节点上的kubelet尝试在当前节点上调用Docker启动容器，并将容器的结果状态返回送至API Server。
• API Server将Pod状态信息存入etcd系统中。
• 在etcd确认写入操作成功完成后，API Server将确认信息发送至相关的kubelet，事件将通过它被接受。

删除 Pod的逻辑

当发起一个删除 Pod 的指令时 Pod 的删除逻辑是这样的：

• 调用 kube-apiserver 发起删除 Pod 请求，如果删除 Pod 时没有设置 grace period 参数那么就会使用 30 秒的默认值，否则就会使用用户指定的 grace period 进行优雅下线。
• kube-apiserver 接受到这个请求以后给相应的 Pod 标记为“删除状态”。其实 Pod 没有“删除状态”，此时 Pod 的 status 还是 Running 状态，所谓的“删除状态”只是 deletionTimestamp 和 deletionGracePeriodSeconds 字段会被设置，这时候 kubelet 或者 kube-proxy 监听到这样的 Pod 就会认为此 Pod 已经不能提供服务了，然后开始做相应的清理操作。
• 此时如果通过 Dashbord 查看 Pod 的状态是 Terminating ，其实 Terminating 也不是 Pod status 的字段的值。只是因为设置了 deletionTimestamp 和 deletionGracePeriodSeconds 字段所以 Dashbord 就会把 Pod 标记为 Terminating 状态。
• （和第三条同时发生）当 kube-proxy 监听到 Pod 处于 Terminating 状态时就把 Pod 从 Service 的 EndPoint 中摘掉，这样对外暴露的服务就摘掉了这个 Pod，防止新的请求发送到这个 Pod 上来。
• kubelet 监测到 Pod 处于 Terminating 状态的话会下线 Pod，下线的过程分成两个步骤。1. 执行 PreStop，2.杀死容器。第一步：如果 Pod 设置了 PreStop hook 的话 kubelet 监测到 Pod 处于 Terminating 状态后就会执行 PreStop 操作，执行 PreStop 设置的超时时间和删除 Pod 时指定的 grace period 一致(如果没设置默认是 30 秒)。
• PreStop 执行完以后还有第二步杀死容器，第二步也有超时时间，这个超时时间是 grace period 减去 PreStop 耗时。如果执行 PreStop 超时或者 grace period 减去 PreStop 耗时剩余的时间不够两秒(甚至可能是负数) kubelet 会强制设置成两秒。第二步的超时时间暂且称之为 tm2, kubelet 停止容器时执行的是 docker stop -t tm2 命令。所以 tm2 的逻辑是：首先发送 term 信号到容器的一号进程，如果容器在 tm2 时间内没有停止就强制发送 kill 信号杀死容器。
• kubelet 执行完 PreStop 和杀死容器两步以后会回调 kube-apiserver，把 Pod 从 kube-apiserver 中删除，这次的删除是真的删除，这时候通过 API 就再也看不到这个 Pod 的信息了。

参考文档：Pod 异常排查概述（腾讯云）