容器集群网络方案 Underlay 与 Overlay 的选择，核心取决于业务对网络性能、运维成本和基础设施兼容性的真实需求：多数场景推荐 Overlay 以降低复杂度，但高吞吐或强隔离场景必须走 Underlay。
容器集群网络方案 Underlay 与 Overlay 怎么选
选型的第一步是理解两者本质,Underlay 直接依赖底层物理网络，容器 IP 即为宿主机 IP，网络路径由硬件交换路由决定；Overlay 则在物理网络之上构建虚拟隧道，容器 IP 独立于底层，通过 VXLAN、Geneve 等封装通信，两者没有绝对优劣，只有适合与否。
性能与开销：Underlay 零损耗，Overlay 有代价
Underlay 网络无额外封装，数据包直接走内核协议栈或硬件转发，延迟接近物理线速，Overlay 每包都要封装解封装，CPU 负担和网络头开销客观存在，据行业基准测试，纯软件 Overlay 方案可能带来 5%-15% 的吞吐下降，延迟增加几十微秒，但若使用智能网卡（SmartNIC）或 eBPF 绕过内核，Overlay 性能可以接近原生。
运维复杂度：Overlay 更灵活，Underlay 更依赖基础设施
- Overlay：容器 IP 与底层网络解耦，IP 地址规划自由，不依赖物理交换机配置；多租户隔离天然支持，网络策略在虚拟层实现，变更风险低。
- Underlay：容器直接占用物理网络 IP，VLAN 或路由规则需与硬件联动，网络团队和容器团队必须密切配合；IP 资源紧张时扩展困难，迁移成本高。
行业共识认为,对于大多数互联网企业和中小团队，Overlay 的运维友好度明显占优，尤其当集群规模超过 100 节点时。
容器网络 Underlay 与 Overlay 对比：场景决定取舍
高性能场景：裸金属容器与延时敏感业务
AI 训练、高性能计算、实时音视频等场景对网络延迟和吞吐极其敏感，Overlay 的封装开销和 CPU 中断可能成为瓶颈，Underlay 是最直接的选择，典型实现包括 Calico 的 BGP 模式、Macvlan/IPvlan，以及 SRIOV 直通，在金融交易系统中，使用 Underlay 将容器网络延迟压到 10 微秒以内是常见需求。
多云与混合云场景：统一网络抽象层
当容器集群跨机房、跨云部署时，Underlay 依赖底层云厂商的网络能力，路由打通、安全组配置往往耗时且不统一，Overlay 方案如 Flannel 的 VXLAN 模式、Cilium 的 Geneve 或 WireGuard 隧道，可以跨公有云、私有云建立统一容器网络平面，据统计，采用 Overlay 的多云集群，网络扩容时间从数天缩短到分钟级。
安全隔离与合规场景
金融、政务等合规要求高的行业，需要对容器网络做精细微隔离，Overlay 天然提供租户级虚拟网络，通过 NetworkPolicy 即可实现内外隔离，Underlay 要达成同样效果，需要依赖 ACL 或底层防火墙，配置粒度粗且难以动态调整，对于需要物理隔离的监管场景，Underlay 配合独立网卡更直接。
容器集群网络方案价格对比：隐性成本更关键
直接成本：软件免费，硬件费用差异大
主流容器网络方案如 Calico、Flannel、Cilium 均为开源免费，但 Overlay 的封装解封装会消耗 CPU 资源，当集群规模较大时，可能需要额外采购专用网卡（SmartNIC）或更高配置的服务器节点，若采用 Underlay，通常需要支持 BGP 的交换机或路由器，以及网络工程师的配置工时，一次性投入较高。
- Overlay 典型成本：CPU 算力占用（约 5% 核/节点），较大的内存占用（路由表缓存），可选的 SmartNIC 硬件。
- Underlay 典型成本：物理网络设备升级，IP 地址段消耗，网络运维人力投入，以及更长的变更窗口。
运维成本：Overlay 省心，Underlay 费力
多数团队的运维瓶颈不在硬件,而在网络策略的变更频率，Overlay 下，网络策略变更只需修改配置并重启 agent，无需通知网络团队，Underlay 的每次路由调整可能需要走工单流程，耗时以小时甚至天计，对于追求敏捷迭代的 DevOps 团队，Overlay 的隐性成本更低。
容器集群网络方案决策实操步骤
第一步：明确业务对网络性能的硬性要求
- 若业务涉及 DPDK、RDMA、GPU 直通，或要求延迟 <50μs，直接选择 Underlay（如 SRIOV、Macvlan）。
- 若业务只是普通微服务通信,对延迟不敏感，优先考虑 Overlay。
第二步：评估现有基础设施和团队能力
- 如果已有成熟的网络团队,且交换机支持 BGP/OSPF，Underlay 的落地阻力较小。
- 如果网络团队人手不足,或需要跨部门协调，Overlay 更能独立推进。
第三步：测试与验证（以 Cilium 为例）
- 部署一套 Overlay 测试集群：
cilium install，默认使用 Geneve 封装，观察性能数据。 - 对比测试 Underlay 模式：
cilium install --set tunnel=disabled，使用原生路由，需要在底层配置路由表。 - 使用
netperf或iperf3压测，记录吞吐和延迟差异，如果性能差距 <10%，建议接受 Overlay 的便利性。
第四步：考虑未来扩展性
- 集群可能跨区域、跨云吗？Overlay 更具扩展弹性。
- 是否需要大规模使用 NetworkPolicy？Overlay 的优势更明显。
容器集群网络方案常见问题
Overlay 网络性能损耗到底多大？
在纯软件模式下,Overlay 的封装解封装会带来约 5% 到 15% 的吞吐下降，延迟增加 20-50μs，但通过 eBPF 和智能网卡卸载，损耗可降至 1% 以内，对于多数业务场景，这种损耗可以忽略。
Underlay 方案是否一定需要物理网络改造？
不一定,在公有云环境下，使用 Calico 的 VPC 网络模式或 AWS VPC CNI 同样属于 Underlay，无需改造底层，只需利用云平台路由能力直接分配弹性网卡，但自建机房或私有云的 Underlay 通常需要网络设备配合。
能否同时使用 Underlay 和 Overlay？
可以,不少大规模集群采用混合模式：对性能敏感的核心服务使用 Underlay，普通服务使用 Overlay，Cilium 等方案支持节点级别的策略切换，实现方式是通过分配不同的 IP 池，并在路由规则上做区分，这种模式兼顾了性能与运维灵活性。
容器集群网络方案没有唯一答案,但多数场景下 Overlay 凭借更低运维门槛和更强扩展性成为首选；只有在对延迟或吞吐有极致要求，或需要直接绑定物理硬件时，才值得投入 Underlay 的实施成本，建议根据实际业务场景，用上述对比框架快速验证，而非盲目跟随技术潮流。