docker & containerd 14
下面我帮你把**“问题现象 + 技术判断 + 根因结论”整理成一版可以直接用于排障汇报/事故复盘的结构**。
一、问题现象（你当前的完整描述整理版）
1. Node 状态异常
-
Node lifecycle 已被 controller 判死（NotReady / Unknown → Dead）
-
node id16 已失联或被判定不可用
2. Pod / 调度异常
-
期望 Pod 数量：3
-
实际运行 Pod 数量：2
-
部分 Pod 无法调度
-
部分 Pod 处于异常状态（containerd create / pending）
3. kubelet 状态异常
-
kubelet 日志显示 failed
-
kubelet 无法正常上报 node status
-
kubelet pprof 接口无响应（hang）
4. container runtime 异常
-
containerd 部分容器处于 create 状态卡住
-
容器生命周期无法推进（create / start 阻塞）
5. API / 网络访问异常（节点侧）
-
访问 Kubernetes API 超时
-
rsync 操作超时（节点内或节点间同步失败）
-
说明用户态网络/IO调用已经异常
6. etcd 侧表现
-
curl etcd：没有 node 信息
-
但 Pod 信息仍部分正常
👉 表示：
-
etcd 集群健康
-
node status 未更新 / 已过期
-
不是 etcd 故障
7. 网络基础状态
-
k8s 节点 conntrack 无阻塞
-
排除 conntrack 表满 / NAT 问题
二、关键技术判断（核心结论）
🚨 这是一个“节点级系统性卡死”，不是 Kubernetes 层问题
从现象组合来看，问题不在：
-
❌ etcd
-
❌ API server
-
❌ conntrack / 网络
-
❌ scheduler / controller
🔥 真正故障层级在：
Node OS kernel / IO / runtime 阻塞导致 kubelet + containerd 全链路 hang
三、故障链路还原（非常关键）
可以还原成如下链路：
Node（id16）发生底层阻塞↓
disk / kernel / filesystem IO stall↓
containerd create / snapshot 阻塞↓
kubelet runtime API hang↓
pprof 无响应↓
node status 无法上报 API server↓
controller 判定 Node NotReady → Dead↓
Pod 无法调度 / 部分 Pod 丢失
四、为什么这些现象是“同一个根因”
1. kubelet failed + pprof 无响应
👉 说明 kubelet 不是 crash，而是卡在 syscall / runtime 调用
2. containerd create 卡住
👉 runtime 已被 IO / kernel 阻塞
3. rsync 超时
👉 用户态 IO 已整体异常（不是 K8s API问题）
4. API 超时（节点侧）
👉 网络栈还活着，但进程无法正常调度请求
5. etcd 没 node 信息
👉 kubelet 没有成功续约 node lease
6. conntrack 正常
👉 排除 L4 网络 tracking 问题
五、根因归类（结论级）
⭐ 最可能根因（按概率排序）
1️⃣ 节点 IO hang / disk latency spike（最高概率）
典型：
-
磁盘 IO 卡死
-
ext4/xfs journal stuck
-
云盘 latency spike
-
inode / fs error retry
2️⃣ kernel soft lock / system stall
表现：
-
kubelet / containerd / rsync 全 hang
-
D 状态进程
-
pprof 无响应
3️⃣ containerd runtime deadlock（次级）
-
snapshotter 卡死
-
overlayfs hang
但无法解释 rsync + pprof 全挂，所以不是主因
六、为什么 controller 判死是“结果不是原因”
Node lifecycle controller 判定逻辑：
node lease 超时（kubelet未续约）↓
node status 不更新↓
判定 NotReady / Unknown↓
最终 marked Dead
👉 所以：
controller 判死只是“节点已经无法通信”的结果
七、关键结论（一句话版本）
🚨 id16 发生的是 节点级 kernel / IO hang 导致 kubelet + containerd + 用户态 IO 全面阻塞，从而触发 Node lifecycle 判死
八、当前问题优先级（运维视角）
🔴 P0（生产事故级）
-
node 已失联
-
kubelet hang
-
runtime hang
🟠 P1（影响）
-
Pod 不可调度
-
daemonset 异常
-
副本不一致
九、建议处理方式（标准恢复路径）
✔ 1. 立即隔离节点
kubectl drain id16 --ignore-daemonsets --delete-emptydir-data
✔ 2. 删除 node
kubectl delete node id16
✔ 3. 重建节点（必须）
-
不建议尝试 restart kubelet / containerd
-
因为问题在 kernel / IO 层
✔ 4. 重点检查底层存储
重点排查：
-
disk latency
-
filesystem error
-
cloud volume status
-
inode exhaustion
十、如果要做“根因定位”（建议下一步）
你只需要给我这三样，我可以帮你精确定位到“是哪一种 hang”：
-
dmesg -T | tail -200 -
iostat -x 1（10秒） -
containerd last 50 lines
如果你后续要写事故复盘，我也可以帮你把这一段整理成：
-
RCA（Root Cause Analysis）
-
时间线
-
影响面
-
改进措施（Preventive actions）
可以直接上生产事故报告级别。