Pod Lifecycle 容器组生命周期

[pacoxu]

学习（读代码）前的理解

1.1. Pod 生命周期

1. 调用 APIServer 创建 Pod
2. Scheduler 监控到 Pod 没有 NodeName，进行节点分配
3. Kubelet 根据节点分配情况，通过 CRI 创建 Pod 的容器实例
4. 调用 APIServer 删除 Pod
5. 先标记 Pod Delete TimeStamp
6. Kubelet 获取到之后开始删除容器实例
7. 删除成功后，上报 Pod 删除成功

1.2. 推测、猜想

1. 猜测--force --grace-period 的时候可能表现不一样
2. 猜测有特殊的 finalizer 可能有不同表现。
3. 节点驱逐发生的情况，Pod删除请求可能是 kubelet 发出的。
4. 一般场景，rs 发起创建和删除 pod 的请求。
5. StaticPod 可能有所不同，应该是kubelet 发起的 Pod Create，并且 NodeName是默认有的，不会触发调度。
6. Kubelet webhook 跟 pod 的逻辑关系

1.3. 创建过程再细化一些（根据经验）

根据之前的排错经验。

1. Pod 创建失败的情况

• • 权限不足
• • QoS 限制： 不允许创建 best effort pod 或者 limit range 不符合要求

2. Pod 在 ApiServer 创建好

• • Static Pod 自带 Node Name 会跳过下面一步
• • 早期版本指定 NodeName 的情况也会跳过下一步

3. 调度器标记 Pod 可以调度的节点

• • 无法调度，等待 1s、2s、4s 直到 5分钟检查
• • max pod 达到上限之后，是调度失败，还是调度后无法启动？

4. 对应节点上的 Kubelet 获取到这个信息，使用 CRI 去创建容器

• • Pause 容器
• • • 资源限制太小导致 Pause 容器无法启动
• • • 网络： 首先创建 Pause 容器，并且做网络相关的初始化 使用的是本地 CNI
• • • • 如果 CNI 为 SDN 或者公有云，放行规则如何发送？
• • 存储： 挂载和绑定存储使用 CSI（没有挂载会跳过）
• • Pull 镜像： 拉取镜像超时、失败、无权限、已存在镜像等情况
• • init 容器
• • 创建和运行 应用容器
• • • 执行 PostStart
• • SideCar （Istio、Knative等）

5. 启动后

• • Liveness 检查，可能会被 Kill
• • OOM Kill
• • Evicted

	Type     Reason     Age                 From                      Message
调度	Normal   Scheduled             default-scheduler         Successfully assigned default/spring-46phs-deployment-5dd8d6646-98hdh to dce-10-7-177-10
镜像 Pull	Normal   Pulled     2m49s               kubelet, dce-10-7-177-10  Container image "10.7.177.84/daocloud/spring-boot-sample@sha256:4e5103142322abd40e466716cf98e45950546762b1dda6d164844ed6e4b1a11b" already present on machine
创建容器	Normal   Created    2m48s               kubelet, dce-10-7-177-10  Created container user-container
启动容器	Normal   Started    2m46s               kubelet, dce-10-7-177-10  Started container user-container
SideCar 镜像 Pull	Normal   Pulled     2m46s               kubelet, dce-10-7-177-10  Container image "10.7.177.84/kube-system/knative-serving-queue:v0.17.3" already present on machine
创建 Sidecar 容器	Normal   Created    2m46s               kubelet, dce-10-7-177-10  Created container queue-proxy
启动 Sidecar 容器	Normal   Started    2m44s               kubelet, dce-10-7-177-10  Started container queue-proxy
Readiness 检查	Warning  Unhealthy  2m (x2 over 2m20s)  kubelet, dce-10-7-177-10  Readiness probe failed: probe returned not ready
	Warning  Unhealthy  39s (x4 over 100s)  kubelet, dce-10-7-177-10  Readiness probe failed: failed to probe: Get "http://127.0.0.1:8012": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

1.4. 删除过程

Terminating →  Terminated → 清理掉

2. 学习过程

2.1. Deployment 创建 Pod 过程 

from https://pdf.us/2019/05/16/3407.html

https://zhuanlan.zhihu.com/p/111241212

调度 Normal Scheduled default-scheduler Successfully assigned default/spring-46phs-deployment-5dd8d6646-98hdh to dce-10-7-177-10 镜像 Pull Normal Pulled 2m49s kubelet, dce-10-7-177-10 Container image "10.7.177.84/daocloud/spring-boot-sample@sha256:4e5103142322abd40e466716cf98e45950546762b1dda6d164844ed6e4b1a11b" already present on machine 创建容器 Normal Created 2m48s kubelet, dce-10-7-177-10 Created container user-container 启动容器 Normal Started 2m46s kubelet, dce-10-7-177-10 Started container user-container SideCar 镜像 Pull Normal Pulled 2m46s kubelet, dce-10-7-177-10 Container image "10.7.177.84/kube-system/knative-serving-queue:v0.17.3" already present on machine 创建 Sidecar 容器 Normal Created 2m46s kubelet, dce-10-7-177-10 Created container queue-proxy 启动 Sidecar 容器 Normal Started 2m44s kubelet, dce-10-7-177-10 Started container queue-proxy Readiness 检查 Warning Unhealthy 2m (x2 over 2m20s) kubelet, dce-10-7-177-10 Readiness probe failed: probe returned not ready

Warning Unhealthy 39s (x4 over 100s) kubelet, dce-10-7-177-10 Readiness probe failed: failed to probe: Get "http://127.0.0.1:8012/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
1.4. 删除过程
Terminating → Terminated → 清理掉

学习过程

2.1. Deployment 创建 Pod 过程

from https://pdf.us/2019/05/16/3407.html

https://zhuanlan.zhihu.com/p/111241212

[pacoxu]

https://www.qikqiak.com/post/pod-init-container/

测试网络CNI 了解到

1. pod 创建后申请网络，会请求 CNI 分配 IP
2. 容器进程全部crash（Pause 容器也退出的情况），重新启动过程，会重新申请 IP

• • 重启场景
• • 关闭过程：pod IP 会被清理掉，回收 CNI 可以收到 del IP 请求
• • 启动过程：重新申请， 网络组件需要保证 同一个 pod uuid 下次分配的 IP 跟之前保持一致。（这里不是看 pod name 而是要看 uuid）

[pacoxu]

[pacoxu]

kubelet 逻辑 race 困境： 看PR和 Clayton 的解释比较详细，这里做个简单的梳理

kubernetes/kubernetes#102344
https://docs.google.com/document/d/1DvAmqp9CV8i4_zYvNdDWZW-V0FMk1NbZ8BAOvLRD3Ds/edit#

kubelet 需要处理什么？

1. sync pod status 到 apiserver
2. 杀pod 需要 kubelet 去处理，默认 有个 graceful 的协议；force kill 比较特别； static pod 也需要特殊处理。
3. kubelet 不是直接操作pod，而是通过 container runtime 管理，因此cri 封装

问题在哪？哪里容易 race ？

1. 如何区分 a) pod 没有running 的容器；b) pod 不能再启动 容器了？ Status Manager 的数据是否时最新的
2. 随着 临时容器和 sidecar 容器的增加，以及 init container，有些地方的逻辑忽略了对这些容器的处理。

造成什么结果

通常也不会造成太严重的问题，一般是 pod 清理的很慢，或者完全卡住了。

1. 部分情况下，重启kubelet 可以清理掉
2. 清理慢 如果涉及到一些资源回收，就会导致应用更新 非常缓慢，进而导致更多问题

解决方案

1. StatusManager 增强
2. 逻辑分离

• syncPod
• syncTerminatingPod
• syncTerminatedPod

3. sync loop 可以 abort

基本从以上几点解决问题，缩短 shutdown 时间

[pacoxu]

pos file in https://gist.github.com/pacoxu/77827e3f04c07d2cc75125bd36ab0f5e.

This is based on kubernetes 1.27-; after v1.28, the init container can be a sidecar container with the new update of restart policy always.

[pacoxu]