在部署和运维Kubernetes（K8s）集群时，网络问题是绕不开的一环。尤其是当服务之间无法正常通信、Pod跨节点访问失败时，排查到最后往往发现是路由表项出了问题。这就像你家WiFi信号明明满格，但视频却一直加载，最后发现是路由器的转发规则没配对。
路由表项为何关键
K8s集群中每个Node都是一台主机，Pod分布在不同的Node上，跨节点通信依赖于底层网络路由。CNI插件（如Calico、Flannel）会为每个节点配置路由表，确保发往某个Pod CIDR的数据包能正确转发到对应节点。一旦路由缺失或冲突，数据包就会“迷路”。
比如，你在Node A上启动一个Pod，IP是10.244.2.10，它属于Node B的子网。Node A需要知道：去10.244.2.0/24的数据包应该发给Node B。这个信息就靠路由表维护。如果Node A的路由表里没有这条记录，请求就会被丢弃或走默认网关，导致连接超时。
常见路由问题表现
典型现象包括：Pod能ping通同节点的其他Pod，但跨节点不通；Service可以访问本节点后端，但轮询到其他节点就失败；kubectl exec进入Pod后curl其他服务超时。
这时候可以登录出问题的节点，执行 ip route 查看路由表：
ip route show | grep 10.244正常情况下应看到类似：
10.244.1.0/24 via 192.168.1.11 dev eth0
10.244.2.0/24 via 192.168.1.12 dev eth0如果缺少某条记录，或者下一跳地址错误，基本就能锁定问题。
可能原因与处理方式
CNI组件异常是最常见原因。比如Flannel的flanneld容器崩溃，或Calico的felix进程未运行，都会导致路由无法同步。检查对应Pod状态：
kubectl get pods -n kube-system | grep -E "(flannel|calico)"如果发现异常，查看日志定位原因。有时候是证书过期，有时候是节点资源不足被驱逐。
另一个容易忽略的点是云平台安全组或VPC路由表。比如在阿里云或AWS上搭建自建K8s，即使节点内部路由正确，外部网络策略也可能拦截IPIP或VXLAN流量（协议号4或UDP 8472/4789），导致隧道无法建立，路由形同虚设。
还有一种情况是多网卡环境配置不当。有些服务器有多个网卡，CNI插件可能选错了接口发布路由。这时需要通过配置指定公网或内网网卡，例如Flannel中的--iface参数。
临时修复与验证
在确认问题后，可手动添加一条路由测试：
ip route add 10.244.3.0/24 via 192.168.1.13 dev eth0再从源Pod尝试ping目标Pod IP。若通了，说明确实是路由缺失。但这只是临时方案，重启后会丢失，必须修复CNI根本问题。
路由问题不像API Server宕机那么明显，它更像WiFi信号中间隔着一面承重墙，表面上一切正常，实际体验却卡顿不断。细致检查每台节点的路由表，结合CNI组件状态和网络策略，才能真正打通K8s的“任督二脉”。