叠加网络还是直连路由？Cilium 两种数据路径的生产选型避坑指南

叠加网络还是直连路由Cilium 两种数据路径的生产选型避坑指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium在 Kubernetes 网络插件CNI的选型讨论中Cilium 几乎总被推到台前基于 eBPF 的数据平面、内建的 Service 负载均衡、Hubble 可观测性、还有被反复宣传的高性能。但真正到了生产落地绝大多数团队首先面对的并不是这些光环而是一个更朴素、却决定后续所有架构决策的问题——Pod 跨节点流量到底走叠加Overlay还是直连路由Direct/Native Routing这个选择不仅影响首包延迟和吞吐还牵扯到 MTU 计算、防火墙规则、NAT 行为、公有云 VPC 集成方式甚至决定你能否无缝使用 BBR、XDP 加速等进阶特性。本文结合 Cilium 仓库源码与社区一线实践网易数帆、腾讯云 TKE 的落地经验把两种数据路径的原理、差异与生产避坑点一次讲透。一、原理对比隧道网格 vs 内核路由Cilium 的数据路径选型在源码中对应一个非常直白的配置项routing-mode。在 pkg/option/config.go 中其取值被定义为一个三态枚举// RoutingModeNative specifies native routing mode RoutingModeNative native // RoutingModeTunnel specifies tunneling mode RoutingModeTunnel tunnel // RoutingModeHybrid specifies hybrid mode RoutingModeHybrid hybrid叠加模式Overlay / Tunneling默认选项值得注意的是叠加模式是 Cilium 的默认行为。官方文档在 Documentation/network/concepts/routing.rst 中明确写到When no configuration is provided, Cilium automatically runs in this mode并指出这是对底层网络基础设施要求最少的模式。其原理是所有 Cilium 节点之间形成一个UDP 封装的隧道网格mesh集群内跨节点的 Pod 流量全部通过 VXLAN 或 Geneve 封装后在底层 IP 网络上传送。封装协议与端口的默认值在源码中写得很清楚隧道设备名cilium_vxlan/cilium_geneve见 pkg/defaults/node.go默认端口VXLAN 8472/UDP、Geneve 6081/UDP见 pkg/defaults/defaults.go封装协议本身的枚举定义在 pkg/datapath/tunnel/tunnel.goconst ( // VXLAN specifies VXLAN encapsulation VXLAN EncapProtocol vxlan // Geneve specifies Geneve encapsulation Geneve EncapProtocol geneve )这种隧道网格的架构带来了几个关键特性底层网络完全不需要感知 PodCIDR节点只要 IP/UDP 可达即可Pod 地址空间不受底层限制新节点加入集群后自动并入网格。更妙的是VXLAN/Geneve 封装头部可以携带 Cilium 的安全身份Security Identity元数据远端节点收到封装包后可以直接读取身份省去一次身份查询——这是叠加模式下身份上下文随包传输的天然优化。直连路由模式Native Routing交给内核直连模式通过routing-mode: native启用。它的哲学截然相反放弃封装把非本节点 Pod 的流量直接交给 Linux 内核路由子系统如同本机进程发包一样处理。这意味着底层网络必须有能力路由 PodCIDR。官方文档用一张架构图描述了这种模型见 native_routing.pngPod 流量经 veth 进入宿主机再通过内核路由表直接转发到对端节点中间不经过任何隧道设备。需要强调的是直连路由并不等于放弃 eBPF。Cilium 的 eBPF 程序依然挂在 veth 与宿主机网络设备上负责策略执行、Service 负载均衡等只是跨节点转发这一跳从封装/解封装变成了内核路由。这也是为什么两种模式下都能用 eBPF 替换 kube-proxy——官方在 Documentation/network/kubernetes/kubeproxy-free.rst 中明确Ciliums eBPF kube-proxy replacement is supported in direct routing as well as in tunneling mode.二、源码视角MTU 与配置的真正差异两种模式最直接、也最容易被忽视的差异藏在MTU 计算里。在 pkg/mtu/mtu.go 中Cilium 精确量化了每种封装的字节开销// TunnelOverheadIPv{4,6} is an approximation for bytes used for tunnel // encapsulation. It accounts for: // IPv4 IPv6 // (Outer ethernet is not accounted against MTU size) // Outer IP header: 20B 40B // Outer UDP header: 8B 8B // Outer VXLAN header: 8B 8B // Original Ethernet: 14B 14B // --- --- // Total extra bytes: 50B 70B TunnelOverheadIPv4 50 TunnelOverheadIPv6 70也就是说VXLAN 模式下每个包比直连模式多消耗 50 字节IPv4 底层。默认 1500 字节的物理 MTU 下Pod 网卡 MTU 会被自动降为 1450。MTU 的连锁反应是真实存在的网易数帆在其 Cilium 落地实践中就专门处理过链路 MTU 适配问题社区里因Pod 间大包无法传输而排查 MTU 的案例也屡见不鲜。配置入口同样有明确分工。叠加模式涉及三个参数见 Documentation/network/concepts/routing.rsttunnel-protocol封装协议默认vxlanunderlay-protocol底层 IP 族默认autoIPv4 优先IPv6 兜底tunnel-port封装端口默认 8472VXLAN/ 6081Geneve。直连模式则要求必须配置ipv4-native-routing-cidr如10.0.0.0/8并配套以下可选项auto-direct-node-routes: true所有节点共享同一 L2 网络时由 Cilium 自动在各节点插入直达路由direct-routing-skip-unreachable: true配合 BGP 部署在多可用区场景下使用避免流量总是绕经 BGP 路由器。源码中的辅助函数把两种模式的语义边界刻画得很清晰pkg/option/config.go// TunnelingEnabled returns true if tunneling is enabled. func (c *DaemonConfig) TunnelingEnabled() bool { // We check if routing mode is not native rather than checking if its // tunneling because, in unit tests, RoutingMode is usually not set and we // would like for TunnelingEnabled to default to the actual default // (tunneling is enabled) in that case. return c.RoutingMode ! RoutingModeNative } // RequiresNativeRouting returns true if the agent needs to use native routing to implement some features. func (c *DaemonConfig) RequiresNativeRouting() bool { return c.RoutingMode RoutingModeNative || c.RoutingMode RoutingModeHybrid }注意这里有个容易被误解的点native 以外的模式都算叠加包括hybrid。混合模式hybrid在 Cilium 里意味着隧道与直连路由并存由 Cilium 根据目标自动选择封装或直连路径——社区实践中这种模式通常被用于默认叠加保证可达、特定 CIDR 走直连换取性能的折中场景。三、性能与运维差异不止是 50 字节吞吐与延迟直连更快但别只看基准叠加模式每包多 50 字节封装头、多一次隧道设备的进出首包延迟与吞吐上限天然吃亏。官方文档也坦承this results in a lower maximum throughput rate for a particular network connection。但官方同时给出了关键解法——巨型帧Jumbo Frames50 字节开销摊在 1500 字节上是 3.3%摊在 9000 字节上就只剩 0.6%差距被大幅抹平。而直连路由的真正性能红利更多来自与 eBPF 快速路径的叠加。比如带宽管理器Bandwidth Manager中的 BBR 拥塞控制官方在 Documentation/network/kubernetes/bandwidth-manager.rst 中说明带宽限制功能两种模式都支持但BBR for Pods 依赖 eBPF Host-Routing 且要求内核 5.18——eBPF 主机路由默认只在直连/混合模式下完整生效。这意味着如果追求极限吞吐与低延迟如数据库、缓存类中间件直连模式 eBPF 主机路由 BBR 是一条完整的性能链路。运维差异NAT、防火墙与网络策略叠加模式的物理网络无感是有代价的底层网络和防火墙必须放行 8472/UDPVXLAN或 6081/UDPGeneve。私有云或 IDC 里这往往意味着要协调网络团队在交换机/安全组上额外开端口而直连模式则没有隧道端口要求却要求全网路由可达 PodCIDR。MASQUERADE源地址伪装行为也截然不同。叠加模式下节点间隧道流量本身就需要正确处理源地址而直连模式依赖ipv4-native-routing-cidr划定不需要 NAT 的 Pod 网段见 Documentation/network/concepts/masquerading.rst。这个配置直接决定了直连模式下的 Pod 源 IP 能否原样到达对端——社区里有一个非常典型的坑某团队从 Cilium v1.8.1 升级到 v1.11.1 后业务 Pod 连 MySQL 突然报授权错误排查发现是升级后 clientIP 变成了节点 IPMASQUERADE 行为变化导致 MySQL 的 IP 白名单失效。这类问题在叠加/直连切换或版本升级时极易复现升级前必须核对ipv4-native-routing-cidr与 MASQUERADE 配置。可观测性两者都能享受有一点值得放心无论哪种模式Hubble 的流量观测、NetworkPolicy 的 L3/L4/L7 执行都是完整的。腾讯云 TKE 基于 Cilium 构建混合云容器网络的实践也验证了这一点——他们同时落地了 Overlay 与 Underlay 两套路径靠 Cilium 统一数据面实现了全链路网络打通与可观测性这正是 Cilium 相比隧道只能用 Flannel、直连只能上 Calico这类传统二分法方案的核心优势。四、生产选型建议与常见坑清单按环境选型的三条主线1. 公有云 VPC 内优先直连路由。云厂商 VPC 本身就是一个巨型 L2/L3 网络天然路由 PodCIDR。AWS 场景直接用ipam: eniPod 拿到的就是 VPC 内可直接路由的 ENI 辅助 IP连 SNAT 都省了GKE 场景官方提供了gke.enabled: true一键开启 native routing Kubernetes IPAM见 Documentation/network/concepts/routing.rst。此时叠加模式纯属浪费带宽。2. 自建 IDC / 多云混合 / 底层网络不可控默认叠加保证可达优先。只要节点间 IP/UDP 互通叠加模式就能工作不依赖任何网络团队配合。对于先跑起来再谈优化的中小集群这往往是性价比最高的起点。3. 既要又要混合模式过渡。如果一部分网段已打通路由、另一部分尚未打通可用routing-mode: hybrid平滑过渡不必一次性迁移全网。五个高频避坑点坑 1MTU 不匹配。叠加模式 Pod MTU 会减 50IPv4如果物理网络本身用了巨型帧但没同步配置或容器镜像里写死了 MTU会出现小包正常、大包黑洞的诡异故障。排查命令顺手看下ip link与路由 MTU 是否一致。坑 2防火墙漏放隧道端口。叠加模式部署完成后跨节点不通十有八九是 8472/UDP或 6081被安全组/防火墙拦截。腾讯云 TKE 混合云实践中就专门处理过 VPC 与 IDC 网络互访的放行问题。坑 3直连模式的 PodCIDR 路由缺失。直连模式要求底层网络路由 PodCIDR要么靠云 VPC 路由表、要么靠 BGP、要么靠auto-direct-node-routes仅限单一 L2 网络。跨可用区/跨二层域时误开auto-direct-node-routes流量会绕错路径此时应改用 BGP direct-routing-skip-unreachable。坑 4升级引发的 MASQUERADE 行为漂移。直连模式下升级 Cilium 或调整ipv4-native-routing-cidr后务必复核 Pod 间流量的源 IP 是否保持原样尤其是数据库、Redis 等有 IP 白名单/授权机制的中间件。坑 5内核版本与特性的隐性绑定。叠加模式对内核要求相对宽松但直连 BBR eBPF 主机路由等组合对内核版本5.18有硬性要求。选型时先确认集群节点的内核版本分布否则想开开不了比开错了更尴尬。这也是网易数帆等一线团队反复强调的 Cilium 落地前提eBPF 特性高度依赖内核务必先做版本清单核对。结语叠加与直连本质不是谁更先进的路线之争而是可达性优先与性能优先之间的工程权衡。Cilium 的巧妙之处在于它把这种权衡做成了运行时配置routing-modetunnel-protocolipv4-native-routing-cidr让团队可以在同一套 eBPF 数据面下按环境切换、按网段混合。理解了封装开销、MTU 计算、NAT 语义与内核版本约束这四条主线生产选型就不容易踩坑了。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考