在运维 Kubernetes 集群时，偶尔会遇到 Pod 之间无法通信、服务访问超时的问题。排查到最后，发现根源出在节点的路由表上——这就是常说的 K8s 集群路由表项问题。
路由表到底管什么？
可以把路由表理解成一张“网络地图”。当一个节点要发数据包到某个 Pod，它得先查这张地图，看看该往哪里转发。Kubernetes 使用 CNI（如 Calico、Flannel）来管理 Pod 网络，这些插件会在每个节点上添加特定的路由规则。
比如，你用的是 Flannel，它通常会给每个节点分配一个 /24 的子网段，然后在主机路由表里加一条：
10.244.1.0/24 dev flannel.1 via 192.168.1.102这条规则的意思是：“所有发往 10.244.1.0/24 的流量，都通过 flannel.1 接口，经由 192.168.1.102 节点转发”。
常见问题场景
某天开发反馈，新部署的服务从其他节点访问不了，但本机 curl 却正常。第一反应是 Service 或 DNS 问题，可查了一圈都没毛病。这时候就得看看路由了。
登录目标节点执行：
ip route show | grep 10.244发现根本没有对应 Pod 所在子网的路由项。或者更隐蔽的情况：路由项存在，但下一跳 IP 是错的，指向了一个已经下线的节点。
为什么路由会丢或错？
一种情况是节点重启后 CNI 插件没完全拉起。比如 kubelet 启动太快，flanneld 还没配置好，kube-proxy 就开始工作了，导致部分路由没生效。
另一种是手动修改过网络配置，比如误删了 veth 设备或清空了路由表，而系统没有自动恢复机制。
还有的是跨可用区部署时，VPC 路由表和节点路由表没对齐，导致跨节点流量被丢弃。
怎么修？
最直接的办法是重启 CNI 组件。如果是 Flannel，可以删掉对应的 Pod：
kubectl delete pod -n kube-system -l app=flannel等它重建后，CNI 会重新配置接口和路由表。也可以登录节点手动触发脚本，比如运行 flanneld --init（具体命令依部署方式而定）。
如果只是个别路由缺失，临时方案是手动加一条：
ip route add 10.244.5.0/24 via 192.168.1.105 dev eth0但这只是应急，重启就没了，还得解决根本问题。
预防比抢救更重要
上线前检查 CNI 插件是否稳定支持当前 K8s 版本。生产环境尽量避免直接操作节点网络，所有变更走 CI/CD 流程。
定期巡检节点路由表一致性。可以用脚本遍历所有节点，核对分配的 Pod CIDR 是否都有对应路由。
监控也不能少。把关键路由的存在状态做成指标，接入 Prometheus，一旦异常立马告警。
别等到服务大面积抖动才去翻路由表，那时候压力可就大了。