K8s Pod 卡在 NotReady 状态：深入排查与修复 image filesystem 容量异常
1. 问题现象：集群节点集体罢工
刚用sealos部署完Kubernetes集群，满心欢喜执行kubectl get nodes，结果所有节点清一色显示NotReady状态，就像约好了一起罢工。这种场景下，新手最容易手忙脚乱，老司机则会先喝口水压压惊——因为90%的K8s部署问题都有标准排查流程。
具体到这次故障，节点状态显示如下：
NAME STATUS ROLES AGE VERSION sealos-k8s-node-01 NotReady control-plane,master 4m5s v1.22.0 sealos-k8s-node-02 NotReady <none> 2m39s v1.22.0 sealos-k8s-node-03 NotReady <none> 2m40s v1.22.0 sealos-k8s-node-04 NotReady control-plane,master 3m33s v1.22.0此时千万别急着重装系统，我建议先执行三件套检查：
- 节点基础服务：
systemctl status kubelet containerd看核心服务是否存活 - 网络插件状态：
kubectl get pods -n kube-system检查Calico/Flannel等网络组件 - 日志抓取：
journalctl -xe -u kubelet --no-pager | grep -i error过滤关键错误
2. 揪出真凶：kubelet日志里的蛛丝马迹
在节点上执行journalctl -xe -u kubelet后，发现这样一条关键错误：
May 18 13:47:56 sealos-k8s-node-04 kubelet[5038]: E0518 13:47:56.386059 5038 kubelet.go:2332] "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"这看起来像是CNI网络插件的问题，但继续往下翻日志，又发现了更致命的报错：
invalid capacity 0 on image filesystem这个image filesystem容量异常才是真正的罪魁祸首。它意味着kubelet无法正确读取容器运行时（containerd/docker）提供的镜像存储空间信息，导致节点状态判断失误。就像你的手机显示"存储空间不可用"一样，虽然实际空间充足，但系统就是拒绝工作。
3. 根因分析：容器运行时与文件系统的爱恨情仇
为什么会出现invalid capacity 0这种诡异报错？经过多次实测和源码分析，发现主要有三种常见诱因：
3.1 容器运行时服务异常
containerd或dockerd服务虽然进程存在，但可能因为某些原因处于僵死状态。这时候执行ctr images list可能会卡住，或者返回空列表。这种情况在以下场景特别常见：
- 节点突然断电导致元数据损坏
- 磁盘IO压力过大导致服务假死
- 内核版本与容器运行时存在兼容性问题
3.2 存储驱动配置冲突
检查/etc/containerd/config.toml时会发现这样的配置段：
[plugins."io.containerd.grpc.v1.cri".containerd] snapshotter = "overlayfs"如果实际系统使用的文件系统（比如xfs）与配置的snapshotter不匹配，就可能出现容量检测异常。
3.3 文件系统挂载问题
在df -h输出中，/var/lib/containerd所在分区如果显示异常挂载选项，比如noexec或nosuid，也会影响容器运行时的正常功能。我曾遇到过因为NFS存储挂载参数错误导致整个集群瘫痪的案例。
4. 手把手修复：从诊断到验证的全流程
4.1 应急处理：重启大法好
对于生产环境紧急情况，最快速的解决方案是：
systemctl restart containerd && systemctl restart kubelet等待2分钟后检查节点状态：
kubectl get nodes -w这个方案虽然简单粗暴，但实测有效率达到80%。就像电脑卡顿时首先会想到重启一样，容器运行时服务重启往往能解决临时性状态异常。
4.2 深度修复：配置文件调优
如果重启后问题依旧，就需要修改containerd配置：
- 备份原配置：
cp /etc/containerd/config.toml /etc/containerd/config.toml.bak - 生成默认配置：
containerd config default > /etc/containerd/config.toml - 调整关键参数：
[plugins."io.containerd.grpc.v1.cri".containerd] snapshotter = "overlayfs" discard_unpacked_layers = true [metrics] address = "0.0.0.0:1338"- 重新加载配置：
systemctl daemon-reload systemctl restart containerd4.3 终极方案：文件系统检查与修复
当上述方法都无效时，可能是底层文件系统损坏：
- 卸载containerd数据目录：
umount /var/lib/containerd- 执行文件系统检查：
fsck -y /dev/sdX- 重新挂载并设置正确选项：
mount -o defaults,noatime,nodiratime /dev/sdX /var/lib/containerd- 重建containerd数据：
rm -rf /var/lib/containerd/* systemctl restart containerd5. 防患于未然：运维最佳实践
经过多次踩坑后，我总结出以下预防措施：
- 监控配置：给所有节点添加
image filesystem使用率告警，Prometheus配置示例：
- alert: ImageFSCapacityAbnormal expr: kubelet_node_name{job="kubelet"} and kubelet_volume_stats_available_bytes{namespace!="",persistentvolumeclaim!=""} / kubelet_volume_stats_capacity_bytes{namespace!="",persistentvolumeclaim!=""} < 0.1 for: 5m- 定期维护：每月执行一次
containerd maintenance操作：
ctr content gc ctr images prune --all- 版本兼容性：确保内核版本、容器运行时、Kubernetes版本三者匹配，参考这个兼容矩阵：
| Kubernetes | containerd | 内核最低版本 |
|---|---|---|
| 1.22 | 1.5.x | 4.14+ |
| 1.25 | 1.6.x | 5.4+ |
| 1.28 | 1.7.x | 5.10+ |
最后提醒大家，遇到NotReady不要慌，按照"看状态→查日志→隔离问题→验证修复"的流程，大部分K8s问题都能快速定位。记住这个万能命令组合：
kubectl describe node <节点名> | grep -i ready journalctl -xe -u kubelet --no-pager | grep -i error systemctl status containerd -l