Linux SRE 生产运行手册：Kubernetes 节点网络故障排查

场景

某生产 Kubernetes 集群中的一个 Linux 工作节点突然出现 Pod 无法互相通信的情况，导致部分微服务不可用。节点状态显示 NotReady。

症状

• kubectl get nodes 显示节点状态为 NotReady
• kubectl describe node <node> 显示 Ready 条件为 False，Reason 为 KubeletNotReady
• 该节点上运行的 Pod 处于 ContainerCreating 或 CrashLoopBackOff 状态
• ping 或 curl 到其他 Pod IP 超时
• 节点上 kubelet 日志反复出现网络相关错误

诊断步骤

1. 检查 kubelet 状态 bash systemctl status kubelet journalctl -u kubelet -n 100 --no-pager 常见错误：Failed to get pod status: no such file or directory 或 network plugin is not ready: cni config uninitialized

2. 检查容器运行时（如 containerd） bash crictl info crictl pods 确认运行时是否正常连接 CNI 插件。

3. 检查 CNI 插件配置 bash cat /etc/cni/net.d/*.conf ls -la /opt/cni/bin/ 确认配置文件存在且语法正确，二进制文件未缺失。

4. 检查网络接口和路由 bash ip a ip route bridge fdb show 确认网桥（如 cni0）存在，eth0 连接正常。

5. 检查 iptables 规则 bash iptables -L -n -t nat iptables -L -n -t filter 注意是否有意外丢包或规则冲突。

6. 检查内核 /var/log/syslog 或 dmesg bash dmesg -T | tail -20 grep -i error /var/log/syslog | tail -30 检查网卡驱动、MTU 问题。

7. 测试基本网络连通性 bash ping <gateway> curl -I http://<pod-ip>:<port> 如果网关不可达，可能是物理链路问题；如果网关可达但 Pod IP 不可达，则问题出在容器网络层。

风险控制

• 避免在业务高峰期进行重启操作：事先评估影响范围，必要时先 kubectl cordon 和 drain 节点。
• 不要随意重启网络服务：如 systemctl restart networking 可能中断所有连接。
• 备份配置文件：修改 /etc/cni 或 /etc/kubernetes 下的配置前先备份。
• 单台验证：先在非生产节点复现操作，确认无误后再应用于生产。

回滚方案

• 如果修改了 CNI 配置文件，恢复至备份版本并重启 kubelet： bash cp /etc/cni/net.d/10-flannel.conflist.bak /etc/cni/net.d/10-flannel.conflist systemctl restart kubelet
• 如果重启了 kubelet 造成更严重问题，可重新托管节点： bash systemctl stop kubelet crictl ps -aq | xargs crictl rm systemctl start kubelet
• 若怀疑内核参数改动导致问题，恢复 sysctl 默认值： bash sysctl -p /etc/sysctl.conf.bak

验证步骤

• 确认节点状态变为 Ready： bash kubectl get nodes
• 确认 Pod 状态恢复正常： bash kubectl get pods -o wide --all-namespaces
• 测试 Pod 间通信： bash kubectl exec -it <pod> -- curl http://<other-pod-ip>:<port>
• 检查应用层监测指标（如 HTTP 200 响应）。

何时提交 OpsGlobal 工单

• 上述基本诊断未能定位问题，且影响持续超过 15 分钟。
• 发现内核崩溃、硬件故障（如 NIC 错误、PCIe 错误）。
• 需要协助修改 CNI 插件版本或内核网络参数。
• 节点完全失联且无法 SSH。

OpsGlobal 提供 7×24 小时远程支持，随时上传诊断日志，快速恢复服务。