Overlay 与 Underlay：Kubernetes 跨节点网络怎么选
从一条跨节点 Pod 流量出发，讲清封装网络、原生路由、BGP、MTU 和云网络之间的关系。
很多 Kubernetes 网络文章一上来就比较 Flannel、Calico 和 Cilium，最后列出一张功能表。真正到了选型时，这张表往往帮不上忙。因为最先要回答的问题不是“选哪个插件”，而是“跨节点的 Pod 包准备怎么走”。
假设 Pod A 在节点 1，Pod B 在节点 2。A 发出的包离开自己的 network namespace 后，必须穿过节点间网络。这里有两条基本路线：
- 把 Pod 包再包一层，用节点 IP 在底层网络里运输，到目标节点后拆包。
- 让底层网络直接认识 Pod 网段，按路由把原始 Pod 包送到目标节点。
前一条通常叫 Overlay，后一条常被称作 Underlay 或 Native Routing。两个名字容易让人误会。Overlay 并没有离开底层网络，它只是叠在 Underlay 之上。Underlay 也不等于“每个 Pod 都拿到一块物理网卡的 IP”。只要 Pod 地址可以被现有网络直接路由，静态路由、BGP、云厂商的 ENI/路由集成都可能实现原生转发。
Kubernetes 真正要求的是什么
Kubernetes 规定的是网络模型，不替你规定实现方式。每个 Pod 有自己的 IP；同一 Pod 内的容器通过 localhost 通信；不同节点上的 Pod 应当能够互通。CNI 插件负责把这个模型落到 Linux 网络和具体基础设施上。
所以 Overlay 和原生路由都可以满足 Kubernetes。差别在于，底层网络看到的究竟是节点地址还是 Pod 地址，以及路由信息由谁维护。
Overlay：先装进隧道，再穿过节点网络
Overlay 模式下，跨节点流量大致这样走：
Pod A
→ veth
→ 节点 1 的 CNI 数据路径
→ 封装为 VXLAN / Geneve / IP-in-IP
→ 底层网络按节点 IP 转发
→ 节点 2 解封装
→ Pod B底层交换机和路由器不需要知道 Pod 网段，只要节点之间能通，并且防火墙允许隧道协议即可。这是 Overlay 最现实的价值：把容器网络和机房、VPC 的路由管理解耦。没有权限修改上游路由，或云网络无法学习大量 Pod 前缀时，Overlay 往往更容易落地。
代价也很具体。封装会增加报头，实际可用 MTU 变小。如果节点网卡是 1500，而 Pod 仍按 1500 发包，跨节点流量可能发生分片，甚至在路径 MTU 探测失效时表现为“大包不通、小包正常”。排障时还要同时观察内层 Pod 包和外层隧道包，抓错接口就会以为流量消失了。
VXLAN 端口也不能只凭记忆判断。IANA 分配的标准 UDP 端口是 4789，但不同实现可能因历史兼容使用其他端口。例如一些 Linux 和容器网络实现长期使用 8472。实际值应以当前 CNI 配置、节点上的 VXLAN 设备和防火墙规则为准，不能把“VXLAN 的标准端口”直接当成“某个插件的默认端口”。
原生路由：让网络知道 Pod 在哪里
原生路由不再给跨节点 Pod 包增加隧道头。节点把包交给 Linux 路由系统，底层网络根据 Pod CIDR 或具体地址找到目标节点：
Pod A
→ veth
→ 节点 1 路由
→ 底层三层网络
→ 节点 2 路由
→ Pod B路由信息可以由多种方式提供。小环境可以写静态路由；自建机房常用 BGP，把各节点的 Pod 网段发布给路由反射器或 ToR；部分公有云 CNI 则直接给 Pod 分配 VPC 可路由地址，依靠云网络完成转发。这几种实现都属于“底层可路由”，却不是同一套东西。尤其不能把 Calico 的 BGP 模式和云厂商原生 CNI 混为一谈：前者重点是传播路由，后者还牵涉云网卡、地址配额和云控制面的限制。
原生路由少了一层封装，路径更直观，Pod 源地址也更容易在网络设备上被观察和利用。换来的责任是路由治理。谁发布路由，谁撤回路由，节点离线后多久收敛，路由表能承受多少前缀，上游网络团队是否愿意接管 Pod 地址，这些问题都要有明确答案。
BGP 也不是“高级版 Underlay”的同义词。它只是分发可达性信息的协议。BGP 可以传播原生 Pod 路由，也可以服务于某些 Overlay 或对外发布 Service 地址。选型时应把“是否封装”和“如何传播路由”拆开看。
两种模式怎么选
如果底层网络不归 Kubernetes 团队管理，或云平台不允许方便地传播 Pod 路由，Overlay 通常更省协调成本。它把复杂度留在节点和 CNI 内部，适合先把集群稳定跑起来。
如果团队掌握机房三层网络，已有成熟 BGP、路由反射和网络监控体系，原生路由会更自然。这里的前提不是“网络同事会配 BGP”，而是路由发布、收敛、容量和变更都已经被当成生产系统管理。
还有一种常见的折中：同一子网内走原生路由，跨子网时再封装。Calico 的 cross-subnet 模式就是这种思路。它减少不必要的隧道流量，又不要求所有上游路由器都理解 Pod 网段。
不要只用“性能更好”做决定。多数业务的瓶颈未必在封装本身，网络可维护性却每天都要面对。更有用的比较项包括：
| 问题 | Overlay | 原生路由 |
|---|---|---|
| 底层是否需要认识 Pod 网段 | 不需要 | 需要 |
| 节点间要求 | 节点可达，隧道协议放行 | Pod 网段可路由 |
| MTU 管理 | 需要扣除封装开销 | 路径通常更直接 |
| 路由控制面 | 主要由 CNI 维护隧道和映射 | 静态路由、BGP 或云网络负责 |
| 排障视角 | 内层包、外层包都要看 | 重点看路由、邻居和策略 |
| 组织成本 | 对上游网络依赖较少 | 需要网络和平台团队共同治理 |
上线前真正值得检查的六件事
第一，Pod、Service、节点和组织现有网段不能重叠。地址冲突不会在安装时都暴露，常常等到访问某个具体网段才出现。
第二，按真实路径校准 MTU，并用不同大小、带 DF 标记的包做验证。不要只看 ping 默认的小包。
第三，确认安全组和防火墙放行的是当前实现真正使用的协议与端口。
第四，明确 SNAT 的位置。Pod 访问集群外部时是否保留源地址，会直接影响日志、ACL 和回程路由。
第五，验证路由撤回和节点故障。正常连通只证明配置能工作，节点突然消失后的收敛才决定生产可用性。
第六，把可观测性一起设计。Overlay 至少要能关联隧道端点和 Pod；原生路由则要能查到路由来源、下一跳和 BGP 会话状态。
Overlay 和原生路由没有统一答案。它们是在不同地方支付复杂度：Overlay 把复杂度放在节点数据路径、封装和 MTU 上；原生路由把复杂度放在地址规划、路由控制面和跨团队协作上。知道自己的团队更有能力维护哪一边，比记住某个插件的宣传口号重要。