1. 节点NotReady的典型表现与初步诊断当你发现Kubernetes集群中某个节点突然变成NotReady状态时先别慌。这种情况我遇到过不下二十次大多数时候都能通过系统化的排查快速恢复。最典型的症状就是在执行kubectl get nodes时看到类似这样的输出NAME STATUS ROLES AGE VERSION worker-01 NotReady none 15d v1.30.3这时候第一反应应该是查看kubelet日志我习惯用journalctl来查看实时日志journalctl -u kubelet -f --no-pager在日志中你可能会看到这样的关键错误信息E0927 09:12:45.858367 53283 kubelet.go:2909] Container runtime network not ready networkReadyNetworkReadyfalse reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized这个错误明确告诉我们问题出在网络插件初始化失败。根据我的经验CNI插件问题导致的节点NotReady占这类故障的70%以上。接下来我会带你一步步深入排查就像侦探破案一样抽丝剥茧。2. CNI插件的基础检查2.1 检查CNI插件Pod状态首先确认CNI插件本身的运行状态。以最常用的flannel为例kubectl get pods -n kube-flannel -o wide kubectl get daemonset -n kube-flannel如果发现Pod异常比如CrashLoopBackOff状态就需要进一步查看日志kubectl logs -n kube-flannel flannel-pod-name --previous我遇到过几次因为节点IP变化导致flannel无法启动的情况这时候需要清理旧的flannel配置ip link delete cni0 ip link delete flannel.1 rm -rf /var/lib/cni/2.2 验证CNI配置文件即使CNI Pod运行正常配置问题也会导致初始化失败。检查CNI配置目录ls -la /etc/cni/net.d/ cat /etc/cni/net.d/10-flannel.conflist重点确认配置文件是否存在且权限正确通常需要644权限配置文件内容是否完整特别是网络段配置插件二进制文件是否存在ls -la /opt/cni/bin/ ls -al /usr/lib/cni/有一次我遇到一个奇葩问题/opt/cni/bin/下的插件二进制文件竟然被误删了解决方法就是从其他正常节点拷贝过来scp roothealthy-node:/opt/cni/bin/* /opt/cni/bin/3. Containerd与CNI的交互排查3.1 检查Containerd的CNI状态当CNI配置看起来都正常但问题依旧时就该检查容器运行时了。使用crictl工具crictl info | grep -A 5 -B 5 network典型错误输出可能是lastCNILoadStatus: cni config load failed: no network config found in /etc/cni/net.d: cni plugin not initialized这里有个关键点即使/etc/cni/net.d/下有配置文件Containerd也可能读不到。我遇到过几种情况Containerd没有权限读取配置目录配置文件格式错误导致解析失败Containerd缓存了旧的错误状态3.2 Containerd服务重启的正确姿势最简单的解决方案是重启Containerdsystemctl restart containerd但要注意几个细节重启顺序很重要先containerd后kubelet重启后要等待至少30秒让服务完全初始化最好同时重启kubeletsystemctl restart kubelet在我的生产环境中曾经因为没等containerd完全启动就重启kubelet导致问题反复出现。后来我养成了习惯重启后先用systemctl status containerd确认服务状态。4. 深入问题根源与高级排查4.1 检查CNI插件加载过程如果重启大法无效就需要更深入的排查。可以通过debug模式启动kubeletjournalctl -u kubelet -f -l --no-pager -p debug在日志中搜索CNI相关条目重点关注CNI配置加载时间点插件初始化错误详情与containerd的通信状态4.2 网络命名空间检查有时候问题出在容器的网络命名空间。可以这样检查# 列出所有容器 crictl ps -a # 查看容器网络命名空间 lsns -t net # 检查特定容器的网络配置 crictl inspect container-id | grep -i network曾经有个案例是旧的网络命名空间没清理干净导致新容器无法创建网络接口。解决方法就是手动清理ip netns list | xargs -I {} ip netns delete {}4.3 内核参数检查某些情况下还需要检查内核参数sysctl -a | grep -E bridge|ip_forward确保以下参数为1net.ipv4.ip_forward1net.bridge.bridge-nf-call-iptables15. 预防措施与最佳实践根据我处理这类问题的经验预防胜于治疗。以下是一些实用建议定期检查CNI插件版本老版本插件可能有已知bug/opt/cni/bin/flannel --version配置健康检查为CNI插件DaemonSet添加livenessProbelivenessProbe: exec: command: [/bin/sh, -c, ip a show cni0] initialDelaySeconds: 30 periodSeconds: 60资源预留确保kubelet和CNI插件有足够资源resources: requests: cpu: 100m memory: 100Mi日志轮转配置防止日志占满磁盘journalctl --vacuum-size100M关键指标监控建议监控以下指标kubelet_node_status_condition{conditionReady}containerd_cni_operations_totalflannel_network_errors_total最后分享一个真实案例某次集群升级后多个节点突然NotReady排查发现是新版containerd与旧版CNI插件不兼容。解决方案是同时升级CNI插件和containerd并在变更窗口进行操作。这提醒我们任何组件升级都要考虑兼容性最好先在测试环境验证。