底座与前置

容器不是轻量虚拟机，是被内核圈起来的一组进程。这个认知决定了你后面所有排障的方向。

• →说清 namespace 隔离了什么、cgroup 限制了什么，以及两者都管不到什么
• →解释镜像分层与写时复制，判断容器磁盘占用为什么和镜像大小对不上
• →在宿主机上找到某个容器进程的真实 PID、cgroup 路径与挂载点

kubelet 自己不会跑容器，它通过 CRI 指挥 containerd。这条链路断在哪，节点就 NotReady 在哪。

• →画出 kubelet → CRI → containerd → runc 的完整调用链
• →用 crictl 直接排查 kubectl 看不到的容器状态
• →解释 pause 容器的作用，以及 Pod 内容器为什么能共享网络

内核参数、cgroup 驱动、时间同步、swap —— 这些没对齐，集群会以各种诡异的方式间歇性出问题。

• →给一台新机器跑完上线前的 OS 检查清单
• →解释为什么 systemd cgroup 驱动必须和 containerd 保持一致
• →判断 conntrack、文件句柄、内核版本是否够撑住目标 Pod 密度

集群卡顿、频繁选主、apiserver 超时，追到底常常是一块不合格的盘。这条线部署前就能用 fio 测出来。

• →用 fio 复现 etcd 的 WAL 写入模式，并读懂 sync percentiles 输出
• →说清哪些存储介质绝对不能给 etcd 用，以及为什么
• →部署后用 PromQL 持续盯住 fsync、backend commit 与选主次数

几个控制面、几段网络、节点怎么命名 —— 这些在装机之前定下来，后面两年都不用返工。

• →按地区、集群、DNS、节点四层规则给一套新集群命名
• →规划 Pod / Service / 节点三段网络，并算出它们够撑多大规模
• →决定控制面节点数、是否复用负载均衡节点、GPU 节点怎么分组

同样是「三台管理节点 + 若干计算节点」，配错 CPU、网卡或盘位，跑起来的差距是数量级的。

• →给控制面、CPU 计算、GPU 计算三类节点各开一份合理配置
• →说清 GPU 节点上 NUMA、网卡与 GPU 的亲和性为什么影响训练性能
• →判断什么场景需要 RoCE / InfiniBand，什么场景以太网就够