作者 BoCloud博云·2020-07-17 12:20

其它·博云

关注8

为啥Underlay才是容器网络的最佳落地选择

字数 2411阅读 1237评论 0赞 0

**导语：**

几年前，当博云启动自研容器网络研发的时候，除了技术选型的考虑，我们对于先做 Underlay 还是 Overlay 网络也有过深度的 讨论 。当时的开源社区以及主流容器厂商，多数还是以 Overlay 网络方案为主，但在我们对众多客户真正需求的深入了解之后，发现部分客户对容器内外网络直通有着非常强烈的需求。思虑再三，我们决定还是先做 Underlay 网络（后来又做了Overlay）。随着行业与公司自身的发展，我们建设实施的项目越来越多，这让我们对容器网络的思考也越来越深入，从而观点也越来越清晰：

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

**01**

**从需求出发，考虑容器网络方案**
![](/home/attachment/202007/17/923097_159495950211558.png)

如上图所示，这是目前企业微服务容器化部署的典型场景，也是驱动我们做 Underlay网络的直接原因：

1. 服务部署在Kubernetes集群内部（如图：服务1、服务2）；
  1. 数据库、注册中心、Redis、MQ等组件部署在集群之外；
  1. 部分服务也可能部署在集群之外, 比如容器平台试用阶段（如图：服务3）

这些服务和组件，需要能直接互联互通。

如若需要满足以上需求，最简单有效的方案就是直接把 Kubernetes 内外网络打通，也就是采用 Underlay 网络模式。

当然，如上需求也有别的办法可以解决。比如，细化分析服务和组件间的流量，采用ingress、egress，包括改写应用代码等方式，在特定情况下，这也是可以用的。然而，一方面，这些都是特定场景下的特定解决方案，缺乏一定的通用性；另一方面，容易出现配置复杂、引入额外风险、出错难以定位等问题。远远没有通过Underlay网络直接将内外网打通这么简单有效。

还有另外的办法就是将所有服务和组件都放入Kubernetes集群内部，但是这种方案仍是针对特定场景的非通用方案，很难保证企业所有的应用都在一个Kubernetes集群里。

同样，对于容器内外网络直接互联互通的需求场景还有：

* 特定用途的Kubernetes集群对外提供服务。比如专门用作提供PaaS中间件服务的Kubernetes集群、专门用作CI/CD服务的Kubernetes集群、专门用作提供大数据服务的Kubernetes集群等；
  * 跨多集群的服务/组件互联互通；
  * 为了在试点阶段降低风险，部分服务跑在集群内、部分服务跑在集群外 等场景。

**02**

**与虚拟机对比，从容器本质考虑容器网络方案**

在容器的应用实践过程中，除了应用场景，我们也从底层基础设施的角度对容器进行了持续的思考。

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

因此，从底层角度看，对容器网络的需求跟虚拟机是一致的。那么，虚拟机网络的落地模式是怎样的呢?

![](/home/attachment/202007/17/923097_159495951617078.png)

如上图右侧部分所示，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网络才是容器网络的正确打开方式。**

点击 [BoCloud博云_以创新云技术 为效率而进化](https://link.zhihu.com/?target=http%3A//www.bocloud.com.cn/home) ，获取更多产品及案例信息。

PaaS 容器容器网络

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

作者其他文章

国产化云平台如何实现多云管控，黄河云来“打样儿”
评论 0 · 赞 0

CNI 这么多，怎么选？| 容器网络系列第 1 期
评论 0 · 赞 0

博云：Kubernetes 近年影响最大版本发布，这几点值得关注
评论 0 · 赞 0

信创云管理平台，头部券商解决异构云资源管理的关键
评论 0 · 赞 0

直播预告 | 浅谈：云原生和容器的定义与关系
评论 0 · 赞 0

CasaOS：一个docker容器应用的可视化Portal

快手诚招数据库paas平台开发工程师（Java）（北京）

内网环境下让容器上网，并制作一个httpd容器

一文搞懂使用 Buildpack 替代 Dockerfile 进行容器镜像构建

K8S Pod解析

为啥Underlay才是容器网络的最佳落地选择

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料