Ready 和「在正常工作」是两个命题

一句话总结

故障排查占 CKA 分值的 30%，是五个领域中最高的一项。诀窍只有一个：**从上到下逐层检查状态，找出叙事在哪一层中断。**Pod 状态是诊断起点。

流程图: 30% · 从上到下逐层检查状态，找出叙事在哪一层中断。 · 资源请求单位写错 · 500 个 core

为什么需要它

只看症状猜原因一定会出错。同样的“无法连接”，可能是 selector 拼错、scheduling 失败，也可能是 PVC 未绑定。因此要固定检查顺序。

Pod 状态	阻塞位置	首先检查
Pending	scheduler filter 阶段	describe 的 Events、资源请求、taint、nodeSelector、PVC binding
ContainerCreating	kubelet 准备 volume／network	volume mount、CNI、image
ImagePullBackOff	拉取 image	tag 拼写、registry 认证
CrashLoopBackOff	container 持续死亡	log、配置、probe
Running 但无流量	service 层	selector、Ready、port

表中最常见的是 Pending，其中最常见的又是资源请求单位写错。cpu: 500 不是 500 millicore，而是 500 个 core，必须写成 500m。memory: 2000Gi 也很可能是 2000Mi 的笔误。scheduler event 会这样提示。

0/3 nodes are available: 3 Insufficient cpu.

它如何运作

etcd backup 是控制平面 DR 的最后一道保险。

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d%H%M).db   --endpoints=https://127.0.0.1:2379   --cacert=... --cert=... --key=...
etcdctl snapshot status /backup/etcd-*.db --write-out=table

恢复有三条原则。

**不要覆盖现有 data-dir。**通过 --data-dir 解压到新路径，再修改配置，从该路径启动。
**恢复期间关闭 apiserver。**存活的 apiserver 若继续写入，会与恢复副本不一致。
**准确设置 --initial-cluster 和 peer URL（2380）。**如果已经丢失 quorum，先恢复为单节点，再逐个加入成员。

还必须明确：**quorum 防的是故障，不是误操作。**错误删除会立即复制到所有成员，只有 snapshot 能恢复到某个时间点。此外，etcd snapshot 不包含 PV 内的数据，应用数据需要 Velero 等其他手段。

在实际工作中会遇到的情况

案例 1——全都 Ready，却不能工作。家庭实验室安装 KubeVirt 后，组件状态全部为 AllComponentsReady，VM 却无法启动。拆开 virt-launcher Pod spec 后，发现缺少包含 init container 所需 binary 的 volume mount。用作者原话说，这是在同一集群第三次确认：“状态 Ready”与“实际能够工作”是不同命题。上层 status 字段只说明该控制器所知的范围。

**案例 2——存在 binary 与完成配置不是一回事。**安装 GPU Operator 时，看到节点有 nvidia-ctk binary，便关闭了 toolkit 安装。结果如下。

Failed to create pod sandbox: rpc error: code = Unknown
  desc = failed to get sandbox runtime: no runtime for "nvidia" is configured

Pod 甚至未能开始，不是 container 内部失败，而是卡在创建 sandbox 的阶段。检查发现 kubectl get runtimeclass 中存在 nvidia，节点上 grep -c nvidia /etc/containerd/config.toml 却为 0。RuntimeClass 只是 handler: nvidia 这个名称，实体必须在节点 runtime 配置中。重建时从 cri-dockerd 换为 containerd，该配置已经消失，主机 binary 只是过去的残留。

修复后，config.toml 仍为 0，因为配置位于 /etc/containerd/conf.d/99-nvidia.toml 这个 drop-in 文件。以为 grep 的一个位置就是全部，是第二个陷阱。

**案例 3——拥有 quorum 不代表不需要备份。**control plane 扩为三台、拥有三个 etcd 成员后，待办列表第二行仍是：“定期 etcd snapshot——quorum 防故障，不防误操作（误删）。”即使数据复制三份，一次错误的 kubectl delete 也会立即反映到全部三份。

后续实验要做什么

第一个实验会实际创建 etcd snapshot，对比备份前后资源，亲眼确认没有进入 snapshot 的内容，并记录恢复计划。第二个实验会亲自制造并修复五种故障：错误 image tag、资源请求单位错误、缺少 toleration、label 不匹配、超过 ResourceQuota、PDB 阻止 drain。修复前把症状保存到文件也是评分对象。