underlay网络,underlay和overlay

导语：

几年前，博云开始研发自研集装箱网络时，不仅考虑技术选型，对于是先做Underlay还是做Overlay网络也有很深的争论。尽管当时许多开源社区和主要容器制造商都以Overlay网络计划为中心，但在深入了解许多客户的真正需求后，我们发现有些客户对容器内外的网络直通有非常强烈的需求经过反复考虑，我们决定先建立Underlay网络。随着行业和公司自身的发展，我们建设和实施的项目越来越多，从而使我们对集装箱网络的思考越来越深，从而使观点也越来越清晰。

01 从需求出发，考虑容器网络方案

如上图所示，这是目前企业微服务器集装箱化部署的典型场景，也是建立Underlay网络的直接原因：

服务被部署在Kubernetes集群内部图：服务1、服务2 )；数据库、注册中心、Redis、MQ等组件配置在集群之外；服务和组件如容器平台试用阶段图)服务器3 )可能部署在群集之外，并且必须能够直接互连。

为了满足这些需求，直接连接Kubernetes内外的网络，即采用Underlay网络模型是最简单有效的方法。

当然，上述需求也有其他方法。例如，它可以在某些情况下使用，包括仔细分析服务和组件之间的流量，采用ingress、egress，重写APP应用代码等方式。然而，这些是特定场景下的特定解决方案，缺乏一定的通用性；另一方面，容易出现配置复杂、引入额外风险、不易出错等问题。没有通过Underlay网络直接连接内外网络那么简单有效。

此外，还可以将所有服务和组件放在Kubernetes群集中，但这种方案是针对特定场景的非通用方案，很难确保企业的所有APP都位于一个Kubernetes群集中。

同样，集装箱内外网络直接互联的需求场景包括：

特定用途的Kubernetes集群对外提供服务。例如，用于提供PaaS中间件服务的Kubernetes集群、用于提供CI/CD服务的Kubernetes集群、用于提供大数据服务的Kubernetes集群等。跨多个群集互连服务/组件；为了在试点阶段降低风险，一些服务在集群内跑，一些服务在集群外跑等场景。02与虚拟机对比，从容器本质考虑容器网络方案

在集装箱的应用实践过程中，不仅从应用场景，而且从基础设施的角度对集装箱进行了持续的思考。

从基础设施角度看容器：容器和虚拟机的本质都是一样的，是上层应用的承载基础设施。

因此，从底层的角度看，对容器网络的需求与虚拟机是一致的。那么，虚拟机网络的落地模式如何呢？

如上图的右侧部分所示，IaaS层的落地网络方案被认为是行业标准的，无论是基于VMware还是基于OpenStack，基本上都是采用OVS 或类似OVS )的双层Underlay网络方案

因此，从基础设施的角度来看，容器网络采用与IaaS相同的方案，将虚拟机和容器配置在同一个网络级别是最合理的选择。

PS :在公共云中，虚拟机都在VPC中，所以目前公共云的容器网络方案也主要采用容器和虚拟机可以放在同一个VPC中，直接互联的方案。这也是对上述判断的典型证明。

此外，针对部分客户反馈的Unberlay网络占用IP地址过多的问题，从虚拟机和容器的比较角度出发，如果使用虚拟机进行部署，则也需要使用与容器的Underlay网络相同的IP地址IP地址的数量取决于APP应用程序的数量，使用容器时没有引入额外的IP地址占用。另外，Ipv6已经开始规模落地，在Ipv6时代，IP地址的数量将不会成为问题。

03技术方案选型

集装箱的典型开源Unberlay网络选型方案有Calico和MACVLAN，这两个方案的问题也很明显：

Calico:必须在数据中心路由器或第3层交换机上打开BGP路由协议。另一方面，BGP是广域网的路由协议，通常不会在数据中心内部启动。低端第3层交换机/路由器的对齐支持情况也存在风险。

MACVLAN：几年前，一些客户采用了这个集装箱网络。 MACVLAN最大的问题是社区活跃度低，一些问题长期没有在社区解决。同时，面向未来的可扩展性也很差。

以上也是博云基于OVS自研UnderlayOverlay也支持)网络的理由。

04总结

在集装箱网络方案中，Overlay网络方案具有对底层网络要求低落地过程中不需要与网络部门打交道)、落地容易、IP地址占用少等特点，也有自己适用的特性需求场景。但是，随着越来越多的客户将Kubernetes和容器大规模应用于生产环境，博克云客户中选择Underlay网络模型的比例也越来越高。这将使以下内容更加明确：

内外直通的Underlay网络才是容器网络的正确打开方式。