K8s Pod 启动慢排查：5 个典型瓶颈的诊断与修复方法

背景

在生产 K8s 集群里，Pod 启动慢是最常见的运维痛点之一。虽然排查路径散落在各团队的经验里，但缺乏一份系统化的排查手册和可复现的诊断脚本，导致同类问题反复花 1–2 小时才能定位到根因。

现象

1. 镜像拉取慢：大镜像（>2GB）/ 私有 Registry 带宽瓶颈 / 多架构拉取。
2. Init 容器串行阻塞：多 Init 容器 / 依赖服务未就绪 / 死循环 Init。
3. 调度延迟：资源请求不匹配 / 亲和性约束过严 / 节点数不足 / 污点未容忍。
4. 就绪探针反复失败：startupProbe 未配 / 健康检查端点响应慢 / NetworkPolicy 拦截。
5. 卷挂载阻塞：NFS 慢挂载 / CSI 驱动超时 / 大 PV 首次格式化。

已尝试的排查与结果

• 镜像拉取：尝试使用 kubectl describe pod 查看事件，但无法定位具体瓶颈。
• Init 容器：怀疑是依赖服务未就绪，但未找到具体排查命令。
• 调度延迟：检查资源请求与节点资源，发现资源未匹配，但未进一步定位。
• 就绪探针：配置了 startupProbe，但未有效定位失败原因。
• 卷挂载：发现卷挂载阻塞，但未找到针对性命令。

期望得到的答案形态

1. Markdown 排查手册：按「现象 → 可能原因 → 排查命令 → 修复方案」四段式组织，覆盖上述 5 个瓶颈。
2. Bash 诊断脚本：输入 Pod 名称 + Namespace，自动执行检查项，输出结构化报告。
3. 案例说明：提供 3 个真实案例，说明排查过程与根因。

引用内容

• K8s 滚动更新卡在 Terminating：preStop 与 terminationGracePeriodSeconds 配错导致 Pod 优雅退出超时的排查与修正
• K8s Pod 容器顺序的隐形炸弹：sidecar 放第一位，崩一次就陪葬主容器 40 分钟
• 容器化之后，"启动顺序"还该不该由业务代码来兜？聊聊你的取舍
• K8s 滚动更新时老 Pod 卡 Terminating 5 分钟才被 SIGKILL，describe 看不出原因，该按什么顺序排查？
• K8s 节点磁盘打满后 Pod 全被驱逐但磁盘只降了 2%：容器日志 + 孤儿镜像 + 僵尸文件三层的排查与治本