导语：
几年前，当博云启动自研容器网络研发的时候，除了技术选型的考虑，我们对于先做 Underlay 还是 Overlay 网络也有过深度的讨论。当时的开源社区以及主流容器厂商，多数还是以 Overlay 网络方案为主，但在我们对众多客户真正需求的深入了解之后，发现部分客户对容器内外网络直通有着非常强烈的需求。思虑再三，我们决定还是先做 Underlay 网络（后来又做了Overlay）。随着行业与公司自身的发展，我们建设实施的项目越来越多，这让我们对容器网络的思考也越来越深入，从而观点也越来越清晰：
01 从需求出发，考虑容器网络方案
如上图所示，这是目前企业微服务容器化部署的典型场景，也是驱动我们做 Underlay网络的直接原因：
- 服务部署在Kubernetes集群内部（如图：服务1、服务2）；
- 数据库、注册中心、Redis、MQ等组件部署在集群之外；
- 部分服务也可能部署在集群之外, 比如容器平台试用阶段（如图：服务3）
这些服务和组件，需要能直接互联互通。
如若需要满足以上需求，最简单有效的方案就是直接把 Kubernetes 内外网络打通，也就是采用 Underlay 网络模式。
当然，如上需求也有别的办法可以解决。比如，细化分析服务和组件间的流量，采用ingress、egress，包括改写应用代码等方式，在特定情况下，这也是可以用的。然而，一方面，这些都是特定场景下的特定解决方案，缺乏一定的通用性；另一方面，容易出现配置复杂、引入额外风险、出错难以定位等问题。远远没有通过Underlay网络直接将内外网打通这么简单有效。
还有另外的办法就是将所有服务和组件都放入Kubernetes集群内部，但是这种方案仍是针对特定场景的非通用方案，很难保证企业所有的应用都在一个Kubernetes集群里。
同样，对于容器内外网络直接互联互通的需求场景还有：
- 特定用途的Kubernetes集群对外提供服务。比如专门用作提供PaaS中间件服务的Kubernetes集群、专门用作CI/CD服务的Kubernetes集群、专门用作提供大数据服务的Kubernetes集群等；
- 跨多集群的服务/组件互联互通；
- 为了在试点阶段降低风险，部分服务跑在集群内、部分服务跑在集群外等场景。
02 与虚拟机对比，从容器本质考虑容器网络方案
在容器的应用实践过程中，除了应用场景，我们也从底层基础设施的角度对容器进行了持续的思考。
从基础设施的角度看容器：容器和虚拟机的本质都是一样的，是上层应用的承载基础设施。
因此，从底层角度看，对容器网络的需求跟虚拟机是一致的。那么，虚拟机网络的落地模式是怎样的呢?
如上图右侧部分所示，IaaS层的落地网络方案可以认为是有行业标准的，不管是基于VMware 还是 OpenStack，基本都是采用OVS（或类似OVS）的二层 Underlay 网络方案。
因此，从基础设施的角度往上看，容器网络采用跟 IaaS 类似的方案，即将虚拟机和容器放到同一个网络层面上，是最合理的选择。
PS：在公有云上，虚拟机都在VPC里，因此目前公有云的容器网络方案，也是主要采用将容器和虚拟机放到同一个VPC中，可以直接互联互通的方案。这也是对上述判断的典型证明。
同时，对于部分客户反馈的 Unberlay 网络占用 IP 地址过多的问题，从虚拟机和容器的对比角度，也可以获得合理的解释：如果使用虚拟机部署，占用 IP 地址数量与容器 Underlay 网络是一样的。IP 地址的数量是由应用数量决定的，使用容器并没有引入多余 IP 地址占用。另外，Ipv6已经开始规模落地，在Ipv6时代，IP 地址数量将不会是问题。
03 技术方案选型
容器典型的开源 Unberlay 网络选型方案有 Calico 和 MACVLAN，这两个方案的问题也比较明显：
Calico：需要在数据中心路由器（或三层交换机）打开 BGP 路由协议，而 BGP 是广域网的路由协议，一般在数据中心内部不会启动，低端三层交换机/路由器对齐的支持情况也有风险。
MACVLAN：几年前有部分客户采用此容器网络方案，MACVLAN最大的问题就是社区活跃度已经很低，一些问题长期没有在社区中解决。同时，面向未来的扩展性也比较差。
以上也是博云基于 OVS 自研 Underlay（也支持Overlay）网络的原因。
04 总结
在容器网络方案中，Overlay网络方案有着对底层网络要求低（落地过程不需要跟网络部门打交道）、落地容易、IP地址占用少等特点，也有自己适用的特性需求场景。但是随着越来越多的客户将 Kubernetes 和容器大规模应用到生产环境中，博云客户中选择使用 Underlay 网络模式的比例也越来越高。这让我们更加明确认识到：
内外直通的Underlay网络才是容器网络的正确打开方式。
