为什么我们要自主开发一个稳定可靠的容器网络

BoCloud 博云容器云 BeyondFabric 研发团队近期将围绕功能设计、架构设计、性能设计、易用性设计等方面对 2.0 版本展开一系列讨论。本篇是该系列的第一篇文章，重点介绍 BeyondFabric 2.0 的功能增强及架构设计理念。

在过去的几年里，随着 Kubernetes 赢得了容器编排之争，企业业务开始全面向 Kubernetes 切换，众多新的企业软件已经默认以 Kubernetes 形态交付。同时技术上围绕 Kubernetes 的创新点也是层出不穷，其中以容器网络举例，现在 Kubernetes 官网登记在册的 CNI 已经有近 30 种，可以算的上百家争鸣、各有所长了。

博云从 2014 年就开始帮助企业落地容器云平台，其中的网络模型则使用了设计优良又有着广泛应用的 Calico 。 Calico 简单易用、适配性强、性能优秀、稳定可靠的特点对构建一个大规模的 Kubernetes 集群非常有帮助，但随着企业开始使用 Kubernetes 承载越来越多的业务，如何融入现网环境，如何增强安全审计等问题开始凸显出来。时至今日，企业对容器网络的要求越来越高，有些甚至已经超出了 CNI 的范畴。 Calico 开始出现了一些水土不服，例如，落地容器云时经常提到以下问题：

• IP 地址是业务的代名词，能支持固定 IP 吗？

• 外部服务能不通过负载均衡器直接调用容器云里提供的服务吗？

• BGP? 设备比较老啦，开 BGP 怕影响性能，网络部门阻力重重，该怎么办？

• 能支持限速吗？多租户环境下还是很重要的。

• 支持多租户吗？不同的租户要求不能互相访问。

• 网络性能如何？业务流量大了以后会不会导致集群状态不稳定？

• 企业内部现网已经有了大量监控和分析工具，容器网络当前是个黑洞，出了问题怎么办？

• 有些场景需要 overlay ，有些场景需要 underlay ，能同时支持吗？（ ps: calico 这个其实做的很好了，只是 BGP 落地时接受度不高）

相信这几年落地容器云时大家都会或多或少的碰到这些问题，并且类似的问题还有不少。针对以上问题，技术社区也出现过类似 Macvlan 之类的解决方案，将容器网络直接与企业二层网络打通，为容器提供了很好的性能和连通性。 Macvlan 虽然可以算是一个不错的过度方案，但也有其技术缺陷，社区活跃度也不高。

到 2018 年初的时候，如何缓解企业在落地私有容器云平台时遇到的网络阻力，已经发展成了一个非常重要又急迫的问题。对市面上主流的 CNI 插件进行了广泛的调研后，发现主流的 CNI 插件对以上需求的支持并不理想，难以同时满足如上的网络需求，集中体现在内外网互通、管理业务网络分离、灵活的网络隔离机制、易于运维管理和调试等问题上，于是博云容器云（ BeyondContainer ）研发团队决定基于 openVswitch(OVS) 自研一个 Kubernetes CNI 插件来解决这些痛点问题，并命名为 BeyondFabric 。

选择 OVS 的原因是，在主流的二层网络方案 bridge 、 macvlan 、 OVS 中， OVS 的功能更加丰富，同时在主流的云技术平台中有着大量的应用，经受了足够的考验。 2018 年底，博云发布了 BeyondFabric 的 1.0 版本，此时正逢企业大量落地容器云的初期。 BeyondFabric 1.0具有简单易用、支持underlay模式、支持固定IP地址、性能损耗低等特性，重点解决微服务上云过程中集群内外互相直接通信的问题，使得企业落地容器云平台的复杂度大大降低。**_业务迁移到容器云后几乎感知不到基础设施从虚拟化到容器化变更带来的变化。_ 这种部署模式可以很好的支持中间件和数据库在 Kubernetes 集群外部署，应用跑在 Kubernetes 集群内，或者微服务系统注册中心在虚拟机环境下部署但微服务跨集群内外部署，等需要 Kubernetes 内外直接互通的场景。

一年多来， BeyondFabric 1.0版本在多个客户的生产环境中稳定运行，完美的支持了物理环境以及vmware、openstack等虚拟化环境 。随着 BeyondContainer 2.3 版本的发布， BeyondFabric 迎来了 2.0 版本。在 2.0版本里，网络功能更加丰富、同时在可扩展性、可用性等方面有了很大增强。
**
BeyondFabric 2.0功能增强**

在 2.0 版本中，我们针对企业所需的很多重要特性进行了增强，例如支持 overlay 部署、租户隔离、安全增强等，为企业落地容器云、更多业务实现数字化转型助力。

2.0 版本中引入了呼声很高的 overlay 部署模式，采用了目前应用最广、生态建设最全面的 VXLAN 协议。 Overlay 模式相对 Underlay 模式虽然性能差一些，但其与物理网络解耦、 IP 地址空间巨大等特点非常契合如今微服务弹性、灵活的特点。在 overlay 模式下，集群外部默认将无法直接访问 pod 的 IP 地址，此时建议通过 Ingress 将服务暴露出去；同时， BeyondFabric 将每个节点作为分布式 egress 网关以满足 pod 访问外部网络的需求。

在安全性方面， BeyondFabric2.0 支持了租户隔离、 NetworkPolicy 、 pod-security 等特性。

l 租户隔离

Kubernetes 中没有租户的概念，但企业在落地过程中租户又是一个非常重要的概念。社区里相应的工作组在这方面的探讨及验证工作也一直在进行中。在已有的 Kubernetes 集群中，网络隔离通常有几种手段，例如通过 networkpolicy 实现，但很多网络插件的 NetworkPolicy 依赖效率较低的 Iptables 规则，同时当 NetworkPolicy 数量增加后对日常运维工作带来了很大难度。有的 L2 的 CNI 插件可以通过结合物理网络实现隔离，这种隔离方式虽然强度很高，但非常不灵活。在 BeyondFabric 2.0 中，我们引入了 CNI 规范中没有提及的 “ 租户 ” 概念，同时为了尽量减少和 Kubernetes 的耦合性，我们简单的将一组 namespaces 视为一个租户，同一个租户的 namespace 都携带有同样 id 的注解。一个 namespace 下的资源只能访问带有相同 id 的其他 namespace 下的资源，例如 pod 、 service 等。默认情况下所有 namespace 都不带有这条注解，因此所有的 namespace 下的业务实例默认是没有租户隔离的。如果平台管理员需要配置租户隔离，仅需给相应的 namespace 设置注解即可，非常简单。

l 支持基于 OVS ACL的 NetworkPolicy

NetworkPolicy 是 Kubernetes 内置的 “ 防火墙 ” 规则， fabirc 利用 OVS 的 ACL 实现了全部的 NetworkPolicy spec 。用户可以按需的配置相应的 networkpolicy 规则，为了简化使用， BeyondFabric 还针对 networkpolicy 提供了 debug 工具。

l 支持 pod-security

BeyondFabric 在转发流量时会检查报文的 IP 及 MAC 地址，如果发生 IP 地址伪装等行为，则直接丢弃该报文。

核心架构设计

Kubernetes 正在进入越来越多的数据中心，企业里也会有越来越多的业务往 Kubernetes 集群进行迁移。网络对于容器云平台的稳定性、扩展性的影响非常大。对于一个 CNI 插件而言，好用易用、功能丰富是非常重要的，它很大程度上消除了容器云平台的落地阶段的痛点。但对一个需要长期运行、按需扩展、规模越来越大、承载业务越来越多的基础平台而言，它还需要具备简单、稳定可靠、高可扩展性、高可用性的特点。

01场景丰富，同时支持 underlay和 overlay

BeyondFabric同时支持underlay和overlay网络，企业可以根据需求自主选择。例如有的企业在容器云平台选型时采用了 overlay 网络，而对业务系统的调用关系及部署拓扑提出了很高的要求；有的企业现网 IP 地址空间比较少，可以选择 overlay 网络。 overlay 和 underlay 有各自的应用场景，不是互相替代的关系，相反很多企业在落地容器云平台时，可能同时需要两种场景。

**02全分布式，消除中央控制器，提升扩展性和可用性
**
随着越来越多的业务实现容器化， Kubernetes 集群的规模会越来越大。 BeyondFabric采用了全分布式设计，无中心节点，集群中的所有节点是对等的关系，任何一个节点或服务下线不会对其他节点产生影响。*这种全分布式的架构设计带来了众多好处，例如 No SPOF 、消除单点潜在的性能瓶颈、提升可扩展性、可用性。

03不预下发，流表按需生成，提升查询性能

对于单个节点上的 fabric-node 服务而言，流表的数量是限制集群扩展性的关键因素。如果针对集群上运行的每一个业务实例设置流表条目，那么对集群网络的性能、扩展性、可维护性都会造成很大影响。而对于业务系统而言，其实单个节点上的业务实例和其他节点的业务实例之间交互是非常有限的，因此超过 80% 的流表条目其实是不需要的。因此 BeyondFabric采取了按需生成流表的设计，即fabric-node启动时仅包含少量的默认流表，随着所在节点上启动的业务实例开始和其他实体建立网络连接，表项随之建立；随着业务实例的消亡，表项随之删除。这种设计很好的提升了集群的扩展性及单节点的流表查询性能，对集群的网络收敛也有很好的效果。与之对应的，网络连接的第一个报文在建立表项的过程中会有毫秒级别的延迟，后续报文会随着表项的建立而快速转发或丢弃。

04用户友好，灵活的 trace工具

在使用 CNI 的过程中，人们往往会问：出现了问题，如何快速 debug ？确实，网络的重要性和复杂性都给运维人员带了了很大的压力。网络管理人员普遍对传统网络比较了解，企业里一般也有专业的网络监控分析平台。可当传统网络叠加上 Kubernetes 容器网络生态 (CNI) 、 network namespace 、 networkpolicy 等新概念时，不管是网络管理人员还是已有的网络分析平台都需要重新去适应。这时候，一个灵活的 trace 工具就会非常重要。针对网络流量异常的情况，可以给定源地址及目的地址， BeyondFabric工具自动构造报文并进行发送到链路上进行测试，在报文通路上的关键节点进行数据采集，最终汇总出可能的故障点。 针对 Kubernetes 内置的 “ 防火墙 ”NetworkPolicy ，当对象多了以后 debug 的困难度很高，因此 BeyondFabric trace 工具支持了对 NetworkPolicy 进行了支持，对链路上可能的规则进行逐一检查以判断是否允许通行。

选型建议

BeyondFabric overlay/underlay 之间的选型建议其实也适用于其他 CNI ，主要从内外通信机制、性能损耗、是否与物理网络解耦、高级功能等方面进行取舍。很多时候，其实企业里会建立多套集群，每套集群可能选择不同的网络解决方案。

即将到来的BeyondFabric 2.1版本

BeyondFabric 2.0 版本在功能、扩展性方面迎来了众多的加强，为构建具备企业特性、真正生产大规模可用的 Kubernetes 集群做好准备。在即将到来的 2.1 版本中，我们将围绕性能、稳定性、可用性进一步进行优化：

l 进一步优化控制面性能。

l 支持更多的封装协议。

l 更好用、可视化的 trace 工具。

l 对网络进行全方面监控，并对接主流的流量分析平台。