kubernetes集群路由核心是协同cni插件、kube-proxy和服务入口三层机制：cni负责pod跨节点互通，kube-proxy实现service流量转发，ingress/gateway统一外部访问，手动配置静态路由易与k8s自动管理冲突。

Linux中配置Kubernetes集群路由，核心不是在系统层面手动加静态路由，而是理解并协同好三层关键路由机制：CNI网络插件的Pod间路由、kube-proxy维护的服务流量转发、以及面向外部的入口路由（如Ingress或Gateway）。直接用ip route硬配通常治标不治本，还容易和K8s自动管理冲突。

1. CNI插件决定Pod网络可达性

CNI（如Calico、Flannel、Cilium）负责为每个节点分配Pod子网，并确保跨节点Pod能互通。路由是否生效，取决于CNI是否正确注入路由规则到主机路由表：

• Calico默认使用BGP或VXLAN，在节点上生成ip route条目指向其他节点的Pod网段（如10.244.2.0/24 via 192.168.10.2 dev eth0）
• Flannel的host-gw模式会在各节点添加直连路由；VXLAN模式则依赖UDP封装，不显式写路由表
• Cilium原生路由（tunnel: disabled）要求你确认：所有节点在同一L2网络，且已启用--auto-direct-node-routes，否则需手动补路由或引入BGP daemon

2. kube-proxy控制Service流量分发

ClusterIP、NodePort等服务类型依赖kube-proxy将虚拟IP（VIP）映射到真实Pod IP。它不改系统路由表，但通过iptables或IPVS规则实现内核级转发：

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

• 检查是否启用IPVS模式：kubectl get cm -n kube-system kube-proxy -o yaml | grep mode，若为ipvs，可运行ipvsadm -ln查看实际转发规则
• 排查服务不通时，优先看kubectl get endpointslice -l kubernetes.io/service-name=xxx，确保后端Pod地址已同步，而非查ip route
• 不要手动删iptables链或清空IPVS规则——kube-proxy会定时重载，误操作反而导致服务中断

3. 外部访问靠Ingress或Gateway统一出口

用户从集群外访问应用，不应依赖节点路由，而应走七层入口层：

• Ingress需先部署Ingress Controller（如ingress-nginx），它本身是Deployment+Service（通常是LoadBalancer或NodePort），再通过Ingress资源定义域名/path规则
• Gateway API更现代，支持TCPRoute等，需部署兼容的GatewayClass控制器（如Envoy Gateway、Contour），再创建Gateway和对应TCPRoute/HTTPRoute资源
• 若用裸机环境，可通过HostNetwork模式让Ingress Controller监听宿主机端口，或配置反向代理（如Nginx）将80/443流量转发至Ingress Controller的NodePort

4. 特殊场景才需Linux层干预

仅当底层网络不符合K8s假设时，才需在宿主机做有限补充：

• 节点物理网卡不在默认路由路径上？用ip rule和策略路由指定特定源地址走指定接口
• 多网卡环境，kubelet需绑定正确IP：--node-ip=192.168.5.10启动参数必须与CNI配置的节点IP一致
• 调试时临时抓包，可用tcpdump -i any port 6443看API Server通信，但别长期依赖路由命令替代K8s原生机制