K8s Pod 状态何时会为 Failed

最近在梳理 Kubelet 的源码实现，整理了下 Pod 状态转换的逻辑。

Kubelet 介绍

Kubelet 主要负责 Pod 状态的维护和更新，其中触发同步事件的来源有三种

api：指 watch apiserver 获得的更新
file：static pod 场景
http：static pod 场景

Kubelet 主要分为以下模块

PLEG
- 即Pod Lifecycle Event Generator。其维护着存储Pod 信息的cache，从运行时获取容器的信息，并根据前后两次信息对比，生成对应的PodLifecycleEvent，通过eventChannel发送到kubelet syncLoop进行消费，最终由kubelet syncPod完成Pod的同步，维护着用户的“期望”。
ProberManager
- 负责探测 Pod 状态，主要的状态来源就是 ProberManager。
StatusManager
- 负责将 Pod 状态同步致 APIServer。
VolumeManager
- 维护真实挂载与期望挂载的一致性。
PodManager
- PodManager 在 Kubelet 中负责内存中 Pod 及 mirrorPod 的维护，任何在本节点上创建或删除操作都会同步更新 PodManager，即可以认为 PodManager 中存储了本节点上运行的 Pod 的信息。这里要对mirrorPod 做下说明，在 kubernetes 中，如果是 static pod，则由 Kubelet 直接创建，这时系统很难管理这部分 Pod；所以系统会在 Kubelet 中创建一个 static pod 对应的 mirrorPod，来表示 static pod。
PodWorkers

处理 Pod 同步。核心方法 managePodLoop() 间接调用 kubelet.syncPod() 完成 Pod 的同步
- 如果 Pod 正在被创建，记录其延迟
- 生成 Pod 的 API Status，即 v1.PodStatus：从运行时的 status 转换成 api status
- 记录 Pod 从 pending 到 running 的耗时
- 在 StatusManager 中更新 pod 的状态
- 杀掉不应该运行的 Pod
- 如果网络插件未就绪，只启动使用了主机网络（host network）的 Pod
- 如果 static pod 不存在，为其创建镜像（Mirror）Pod
- 为 Pod 创建文件系统目录：Pod 目录、卷目录、插件目录
- 使用 VolumeManager 为 Pod 挂载卷
- 获取 image pull secrets
- 调用容器运行时（container runtime）的 #SyncPod() 方法

何时会进行 Pod 状态刷新？

一般情况下是 ProbeManager 会定时探测 container 的状态（如未配置 ReadinessProbe，默认上报 Success），然后调用 StatusManager 接口刷新到 APIServer，最终展示给用户。
某些特殊场景会直接修改 Pod 状态，如 Pod 被驱逐，节点关闭等。

何时 Pod 会失败？

以下情况会修改 Pod Phase 为 Failed。

Pod Phase 是否为 Failed 由 containerStatus.State 决定（源码参考）。
- initContainers 中某个 Container 为 Terminated 或者 Waiting（LastTerminationState.Terminated 不为空），且 Exsit Code 不等于0。
- 所有 containers 都为 Terminated 或者 Waiting（LastTerminationState.Terminated 不为空），且存在一个以上 Pod Exsit Code 不等于0，此时如果 Pod 重启策略为 RestartPolicyNever，则会将 Pod Phase 置为 Failed。
其他特殊场景
- Pod 遭驱逐时（spec.activeDeadlineSeconds 被设置且到期或资源不够被抢占或 API 调用）（源码参考 & 源码参考 & 源码参考）。
- 创建 Pod 时准入检查失败（源码参考）。
- 节点 shutdown 时（源码参考）。