K8s Pod 启动慢排查手册 + 一键诊断脚本（Bash + kubectl，覆盖 5 个典型瓶颈）

背景

生产 K8s 集群里 Pod 启动慢是最常见的运维痛点之一，但排查路径往往散落在各团队的经验里：有人先看镜像拉取，有人先怀疑调度，有人直接 grep 节点日志。缺乏一份系统化的排查手册和可复现的诊断脚本，导致同类问题反复花 1–2 小时才定位到根因。

本任务需要一份可落地的排查手册 + 配套诊断脚本，让一线 SRE 拿到一个 Pod 名称后，10 分钟内跑完全链路诊断、拿到结构化报告，直接指向最可能的瓶颈。

最终要什么

1. Markdown 排查手册（.md，≥1500 字）

按「现象 → 可能原因 → 排查命令 → 修复方案」四段式组织，覆盖以下 5 个典型瓶颈，每个瓶颈至少 2 条可直接复制运行的 kubectl 命令：

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

手册中须包含 ≥3 个实际案例（现象描述 → 排查过程 → 根因 → 修复），案例应来自真实的 K8s 1.27+ 环境（containerd 运行时）。

2. Bash 诊断脚本（.sh，≥100 行）

• 输入：Pod 名称 + Namespace（可选 --json 输出）
• 自动执行检查项：
  1. Pod 事件时间线（解析 kubectl describe / kubectl get events）
  2. 镜像拉取耗时（从事件中提取拉取开始/结束时间）
  3. Init 容器状态与各自耗时
  4. 调度时间（created → scheduled 事件时间差）
  5. 探针配置（startup/liveness/readiness）与失败次数
  6. 卷挂载状态（Pending / Mounting 卡住）
  7. 目标节点资源余量（allocatable vs requested）
• 输出：结构化报告（人类可读 + --json 两种模式）
• 约束：兼容 kubectl 1.25+；不依赖 jq（用 awk/sed/grep 解析）；含 shebang 与 --help

3. README.md

说明脚本用法、依赖（仅 kubectl）、输出格式说明、已知限制。

输入与上下文

• 目标 K8s 版本：1.27+，容器运行时 containerd
• 脚本运行环境：有 kubectl 权限（可访问目标 Namespace 的 pod / event / pv / pvc / node）
• 手册中所有命令须在 kubectl 1.27+ 下可直接复制运行（不要引用已废弃的 flag）

交付格式

• 1 份 Markdown 排查手册（.md）
• 1 个 Bash 脚本（.sh，可执行）
• 1 份 README.md
• 以上 3 个文件作为交付物附件上传