容器网络选 overlay 还是 underlay，核心看三个维度：部署环境、性能要求、运维复杂度，简单说，跨主机集群、多租户隔离、快速扩展首选 overlay；物理机裸金属、低延迟高吞吐、需要固定 IP 直通网络选 underlay。
先搞清楚 overlay 和 underlay 到底差在哪
业内专家指出，理解这两种网络模型的关键在于封装，overlay 网络在现有物理网络之上再构建一层虚拟网络，数据包被封装在 VXLAN、Geneve 等隧道协议里传输，underlay 网络则直接用物理网络基础设施，IP 地址、路由、VLAN 都依赖底层硬件,容器和虚拟机一样拥有真实网络身份。
用一个生活场景类比：overlay 像是你在城市上空修了一条高架桥，不堵车但要多绕一段路；underlay 像是直接跑地面道路，距离短但红绿灯多，这里没有绝对优劣,只有合用与不合用。
| 对比维度 | overlay | underlay |
|---|---|---|
| 网络隔离 | 逻辑隔离，租户数量大 | 物理/VLAN 隔离，受限于硬件 |
| 性能开销 | 有额外封装解封装损耗 | 接近裸机性能 |
| 固定 IP | 较难实现 | 天然支持 |
| 跨网段通信 | 容易，随集群漂移 | 依赖底层路由配置 |
| 运维复杂度 | 控制面独立，易管理 | 需与网络团队协作 |
| 典型场景 | Kubernetes 多集群、云原生 | 传统中间件、高性能计算 |
overlay 适合哪些场景：多集群、动态迁移、租户隔离
跨主机通信是 overlay 的主场
如果你的容器分布在多台物理机上，且每台机器的网段不连续，overlay 几乎是最省心的方案，它屏蔽了底层网络差异，Pod 的 IP 在全局范围内唯一且可以自由迁移，比如你在简米云买了三台 ECS，它们分属不同 VPC 子网，用 Flannel 或 Calico 的 VXLAN 模式，一条命令就能让这些机器上的 Pod 互相通信,不需要去云控制台配置路由表。
具体操作路径：安装 Calico 并切换 IPIP 模式，或者使用 Flannel 的 VXLAN 后端，然后在集群层面配置 NetworkPolicy 做访问控制,整个过程网络团队几乎不用介入。
多租户隔离是 overlay 的强项
Kubernetes 平台要出租给不同业务团队，每个团队需要有独立的网络空间，overlay 的 VXLAN VNI 可以轻松支持数千个租户，而传统 VLAN 最多只有 4096 个，实际可用量还远低于这个数字，行业共识认为，在自建 PaaS 平台或混合云管理场景中，overlay 是构建安全隔离边界的首选方案。
某电商公司在双十一大促前临时扩容，新增的 2000 个 Pod 在 10 分钟内全部调度完成，每个 Pod 自动获得独立 IP，不同业务的网络策略互不干扰，这种弹性是 underlay 很难做到的,因为底层交换机的配置变更周期往往以天为单位。
容器编排工具的原生集成度 overlay 更高
Kubernetes 社区对 overlay 支持非常成熟，CNI 插件文档齐全，出现问题有大量公开排障案例，你搜索“容器网络该用 overlay 还是 underlay 看什么场景”时，看到的多数实践分享也都基于 overlay，因为它在开发测试、持续交付、微服务治理这些场景下确实省事。
underlay 适合哪些场景：固定 IP、高性能、物理机部署
固定 IP 需求让 underlay 无法替代
很多传统中间件，比如数据库、消息队列、注册中心，它们对 IP 有强依赖，应用配置里写死了数据库地址，如果容器重启后 IP 变了，连不上的就是生产事故，underlay 网络让容器直接使用物理网段的 IP，地址由 DHCP 服务器分配，或者管理员手动指定，集群外部的负载均衡器、防火墙规则、数据库白名单都能直接沿用原有配置。
以某银行交易系统为例，容器化改造后仍然使用 underlay 模式，每个容器分配固定的内网 IP，审计系统通过 IP 就能追踪所有访问记录，金融行业的合规要求决定了他们不能接受动态 IP 带来的追踪盲区。
高性能计算和低延迟场景必须用 underlay
overlay 的封装解封装过程会消耗 CPU 资源，增加几微秒到几十微秒的延迟，对普通 Web 应用影响不大，但对高频量化交易、实时风控、视频转码这些场景，每一微秒都对应真金白银，underlay 让数据包直接经过网卡和交换机，不经过额外隧道处理,性能接近裸机。
某视频直播平台用 underlay 部署了推流网关集群，实测 P99 延迟比之前用 overlay 时降低了38%（据该平台技术博客公开分享）,这个差距在节假日高峰期会被放大。
物理机部署和边缘计算更倾向 underlay
如果你的容器直接跑在物理机上，而不是虚拟机里，underlay 会省掉一层虚拟化开销，边缘计算场景中，边缘节点的网络环境往往复杂且不可控，操作人员也有限，underlay 的简单路由模型更容易维护，直接给每台边缘设备配置好 IP 和路由规则，容器启动即联网,不依赖中心节点做隧道协商。
overlay 和 underlay 混合使用是常态
不要被非黑即白的思维框住，一个典型的中大型企业集群，往往核心数据库用 underlay，业务无状态服务用 overlay，通过节点亲和性和 CNI 策略将不同 Pod 调度到对应网络模式的节点池里。
实操步骤示例：
- 创建一个节点池
pool-underlay，打上标签network=underlay - 在节点池上安装 Calico 的 BGP 模式，直接宣告容器路由
- 另一个节点池
pool-overlay使用 VXLAN 模式 - 部署数据库 StatefulSet 时指定
nodeSelector: network=underlay - 部署 Web 服务时指定
nodeSelector: network=overlay
这种混合架构避免了“一刀切”带来的问题：数据库享受裸金属性能，业务应用获得弹性调度能力，但代价是网络排查的复杂度提升你需要同时熟悉 BGP 路由和 VXLAN 隧道报文，建议使用 Cilium 这类统一控制面的 CNI 插件来降低切换成本。
针对业务场景选型的具体决策清单
- 你的业务对网络延迟敏感吗？比如交易系统、游戏实时对战，如果是，优先 underlay。
- 你的 Pod 数量会动态暴增吗？比如活动大促、批量任务，如果是，overlay 的自愈和弹性更有优势。
- 你的运维团队懂底层网络吗？如果只熟悉 Kubernetes，没有专职网络工程师，overlay 的学习曲线更平滑。
- 你是否有外部系统需要直接访问 Pod IP？比如监控系统、第三方供应商接口，如果有，underlay 更容易打通网络策略。
- 你的云平台是否有裸金属实例可选？大多数公有云 VPC 内的裸金属机型支持开启 VPC-CNI 直通，这本质上是给容器提供 underlay 网络。
在多云和混合云环境中，overlay 是唯一能让集群跨云协同的方案，你能把公有云、私有云的节点放进同一个集群，Pod 之间通过隧道通信，不依赖某一家云厂商的网络插件，据统计，采用多云架构的中大型企业中有相当一部分选择 overlay 作为唯一建设标准，因为维护多套 underlay 网络的开销太大。
网络选型怎么影响成本和运维
网络模型的抉择会对你的云账单和人力成本产生实际影响，overlay 模式下流量会经过隧道封装，云平台对此一般不额外收费，但额外的 CPU 消耗意味着你需要在集群里预留更多计算资源，underlay 模式对带宽利用更充分，但跨可用区通信可能需要额外购买专线或云企业网产品，价格方面因厂商和地区而异,例如北上广深等一线城市的数据中心带宽成本明显高于西南地区。
运维层面的差异更直接：overlay 出了问题你只需要看 CNI 插件的日志和隧道状态；underlay 出了问题你可能要拉上网络团队一起查交换机配置，如果你的公司没有网络工程师岗位，建议你优先 overlay。
Q&A 模块
overlay 网络和 underlay 网络哪个更适合 Kubernetes 默认选型
对大多数基于 Kubernetes 的常规应用来说，overlay 是更稳妥的默认选型，它配置简单、扩容不依赖底层网络变更、多租户隔离能力强，只有在明确存在低延迟要求、固定 IP 依赖或物理机直通需求时，才需要切换为 underlay 方案。
容器网络用 overlay 模式会不会导致排查问题很麻烦
会增加排查入口，但不一定更麻烦，overlay 的流量路径多了一层隧道封装，抓包时不能只抓物理网卡上的镜像，还需要在 veth 对或隧道接口上进行流量镜像，工具方面，tcpdump 加 -n 参数直接查看外层报文，ethtool 检查隧道接口的状态，大部分问题集中在 MTU 不一致导致的包转发失败，只要记住一条排查顺序：先看 Node 层连通性，再看隧道接口状态，最后看 Pod 路由表,多数问题都能定位。