Pod 一直处于 ContainerCreating 或 Waiting 状态

---

一 可能原因

1. Pod 配置错误
2. 挂载 Volume 失败
3. 磁盘空间不足
4. 节点内存碎片化
5. Limit 设置过小或单位错误
6. 拉取镜像失败
7. CNI 网络错误
8. controller-manager 异常
9. 安装 docker 时未完全删除旧版本
10. 存在同名容器

二 排查方法

2.1 检查 Pod 配置

1.检查是否打包了正确的镜像。
2.检查是否配置了正确的容器参数。

2.2 检查 Volume 挂载情况

通过检查 Volume 挂载情况，定位引发异常的真正原因。以下列出两种已知原因：

2.2.1 Pod 漂移导致未正常解挂磁盘

2.2.2 问题分析

在云托管的 K8S 服务环境下，默认挂载的 Volume 通常为一块存储类型的云硬盘。如果某个节点出现故障，导致 kubelet 无法正常运行或无法与 apiserver 通信，则到达时间阈值后就会触发该节点驱逐，自动在其他节点上启动相同的 Pod（Pod 漂移），被驱逐的节点无法正常运行及确定自身状态，故该节点的 Volume 也未正确执行解挂操作。
由于 cloud-controller-manager 需等待 Volume 正确解挂后，才会调用云厂商接口将磁盘从节点上解挂。因此，Pod 漂移会导致 cloud-controller-manager 在达到一个时间阈值后，强制解挂 Volume 并挂载到 Pod 最新调度的节点上。

2.2.3 造成影响

最终导致 ContainerCreating 的时间相对较长，但通常是可以启动成功的。

2.3 命中 K8S 挂载 configmap/secret 时 subpath 的 bug

1. 实践发现，当修改了 Pod 已挂载的 configmap 或 secret 的内容，Pod 中容器又进行了原地重启操作（例如，存活检查失败被 kill 后重启拉起），就会触发该 bug。

2. 如果出现了以上情况，容器将会持续启动不成功。报错示例如下：

$ kubectl -n prod get pod -o yaml manage-5bd487cf9d-bqmvm

lastState: terminated
containerID: containerd://e6746201faa1dfe7f3251b8c30d59ebf613d99715f3b800740e587e681d2a903
exitCode: 128
finishedAt: 2019-09-15T00:47:22Z
message: 'failed to create containerd task: OCI runtime create failed: container_linux.go:345:
starting container process caused "process_linux.go:424: container init
caused \"rootfs_linux.go:58: mounting \\\"/var/lib/kubelet/pods/211d53f4-d08c-11e9