Calico-node启动失败：从Back-off重启到install-cni容器网络故障的深度排查与修复

1. 问题现象当Calico-node开始仰卧起坐那天早上刚到公司就发现Kubernetes集群监控面板一片飘红。仔细一看好几个calico-node Pod正在玩仰卧起坐——不断重启状态显示Back-off restarting failed container。这场景就像你反复按下电脑开机键但每次到登录界面就蓝屏重启。通过kubectl get pods -n kube-system查看时会发现calico-node的状态类似这样NAME READY STATUS RESTARTS AGE calico-node-abc12 0/1 Init:CrashLoopBackOff 5 3m最让人头疼的是这种网络组件的故障往往会产生连锁反应。很快我就发现一些微服务Pod开始出现网络不通的问题就像城市主干道突然瘫痪导致各个小区都成了孤岛。2. 第一现场从日志中寻找蛛丝马迹2.1 查看Pod标准输出日志我的第一反应是查看Pod日志这就像医生看病要先看化验单kubectl logs calico-node-abc12 -n kube-system -c install-cni果然发现了关键报错[ERROR][1] cni-installer: Unable to create token for CNI kubeconfig errorPost https://172.17.0.1:443/api/v1/namespaces/kube-system/serviceaccounts/calico-node/token: dial tcp 172.17.0.1:443: connect: network is unreachable这个错误就像快递员抱怨找不到送货地址。172.17.0.1是Kubernetes的Service IP相当于整个集群的邮政总局。现在快递员连总局都找不到自然无法投递包裹。2.2 深入检查Pod详情接下来用kubectl describe做全面体检kubectl describe pod calico-node-abc12 -n kube-system在Events区域发现了重要线索Warning BackOff 2m (x5 over 3m) kubelet Back-off restarting failed container Normal Pulled 2m (x6 over 5m) kubelet Container image already present Warning Failed 2m (x6 over 5m) kubelet Error: failed to start container install-cni:这提示install-cni这个初始化容器出了问题。它相当于网络系统的装修队负责在每个节点上布置网络基础设施CNI配置和二进制文件。如果装修队进不了场后面的工作自然无法开展。3. 网络连通性测试揪出断点3.1 节点间基础网络测试首先检查节点间的基础网络就像测试电话线是否通畅# 测试节点到Master的连通性 curl -k https://MASTER_IP:6443如果返回403状态码反而是好事说明TCP连接是通的只是没有权限访问就像打通了电话但被拒接。但如果出现Connection refused或Network is unreachable那就是更底层的网络问题了。3.2 Service网络层测试接下来测试Service网络这是Kubernetes内部的快递系统# 测试访问API Server的Service IP curl -vk https://172.17.0.1:443当看到network is unreachable时我意识到问题可能出在以下方面kube-proxy服务异常快递公司停摆iptables规则错误快递分拣系统故障节点路由表缺失道路封闭4. 深度排查解剖网络三层结构4.1 检查kube-proxy状态kube-proxy相当于集群的交通指挥中心我首先检查它的运行状态# 查看kube-proxy日志 kubectl logs -n kube-system $(kubectl get pods -n kube-system -l k8s-appkube-proxy -o name) # 重启kube-proxy谨慎操作 docker restart kube-proxy但发现问题依旧说明不是简单的服务卡死。就像重启交通信号灯没能解决堵车问题那可能是道路本身出了问题。4.2 对比路由表这时我决定对比健康节点和故障节点的路由表# 查看路由表 route -n # 健康节点的路由表示例 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.10.1 0.0.0.0 UG 100 0 0 eth0故障节点上果然缺少了默认路由这就好比城市的所有出口都被封死车辆只能在内部打转。Calico依赖路由表来建立Pod间的通信通道没有默认路由就像没有GPS导航数据包根本找不到目的地。5. 根治方案修复路由表5.1 临时修复方案对于紧急恢复可以手动添加默认路由# 添加默认路由替换为你的实际网关IP route add default gw 192.168.10.1 # 确认路由已添加 route -n但要注意这就像用创可贴处理伤口重启后就会失效。我在生产环境中就遇到过节点重启后网络再次瘫痪的尴尬情况。5.2 永久解决方案更可靠的方法是排查为什么节点会丢失路由。常见原因包括网络管理服务(NetworkManager)与网络脚本冲突云平台DHCP配置问题系统升级导致的网络配置重置对于CentOS/RHEL系统可以检查以下配置# 确保网络接口配置正确 cat /etc/sysconfig/network-scripts/ifcfg-eth0 | grep GATEWAY如果是云环境可能需要检查云平台的网络配置。比如在AWS中需要确保子网有正确的路由表关联到互联网网关。6. 预防措施构建健壮的容器网络经过这次教训我总结了几点预防经验监控预警对calico-node Pod设置健康检查当重启次数超过阈值时触发告警初始化检查在节点启动脚本中加入路由表验证逻辑文档沉淀将排查流程整理成runbook类似这样1. 检查Pod状态和日志 2. 验证节点网络连通性 3. 检查kube-proxy服务 4. 对比路由表 5. 检查系统网络配置混沌工程定期模拟网络故障进行演练确保团队熟悉处理流程那次故障后我给团队定了个规矩任何节点重启后第一件事就是检查路由表和calico-node状态。这就像飞行员起飞前的检查清单看似简单却能避免大问题。现在每次看到calico-node平稳运行都会想起那个手忙脚乱的早晨——这就是成长的代价吧。