干货 | 博云基于OVS自研容器网络插件在金融企业的落地实践

本文根据博云在dockerone社区微信群分享内容整理

过去几年博云在企业中落地容器云平台遇到了很多痛点，其中一个比较典型的痛点来自网络方面，今天很高兴跟大家聊聊这个话题并介绍下我们基于OVS自研的CNI插件——内部称之为fabric项目。

01

容器平台落地时网络方面的需求

从2013年左右Docker技术在开发者中流行起来，到如今kubernetes已经成为事实上的容器编排引擎，容器、微服务、DevOps互相支持互相促进，容器云平台的实际落地案例开始越来越多。特别是2018年以来，越来越多的企业开始思考如何利用容器云平台支持其生产场景最终提高生产效率。

不同于开发测试场景，生产场景上线一套平台或系统要求会严格很多。安全、监控、流程、现有系统集成、业务暴露等等的建设要求都要匹配上，否则不可能上线。在这个过程中，特别是在传统的金融类企业对监管要求严格的情况下，容器云平台落地时会碰到很多问题，这其中，最典型的一个需求就是容器云平台的网络建设，必须同时满足业务方，运维人员，安全人员，网络人员的诉求。

现在容器云平台大部分都是基于Kubernetes构建，市面上的CNI插件也非常多，各个企业现网的需求也有很大的不同，所以几乎不可能出现一种网络模型适配所有客户场景的情况。现在主流的比较成熟稳定的CNI比如calico在扩展性、稳定性等方面表现优秀，但在传统金融类企业落地时非常困难，经常需要对不同的需求做出妥协。

我们和多家客户进行了深入沟通，虽然需求有所差异，但总结下来主要的诉求包括：

• 在主流的二层组网的数据中心中，受限于硬件能力或管理复杂度，大部分客户不希望引入BGP等三层路由概念。

• 企业业务系统往往会在容器云平台内外同时同时部署，希望平台内外网络能够直接打通。

• IP地址是业务的身份识别，希望能够具备固定IP的能力，而且是可管理、可审计的IP地址。

• 管理网络和数据网络分离。

• 具备网络隔离能力，硬件隔离的强安全性和软件隔离的灵活性都需要。

• 网络模型应该尽量简单，易于掌控，易于调试。

• 高性能，低抖动的网络吞吐能力。

• 其他的高级特性，如双向限速、DPDK、overlay等。

我们对市面上主流的CNI插件进行了广泛的调研后，发现主流的CNI对以上“国产化”的需求的支持并不理想，主要的不满足点包括：

• 网络模型差异（三层VS二层，当然L2的方案也很多，OVS有流表等等高级功能，非常适合当今云化的环境），要适配现网环境、安全策略等。

• 云原生理念。主流的CNI较好的满足了云原生的概念，但客户的实际需求中其实是有些“anti-cloudnative”的，如何在cloudnative和anti-cloudnative之间做到平衡其实普遍缺少实践经验。

• 简单稳定可靠。这其实是非常重要的要考虑的点，厂商、企业都要有相应的人员能够掌控网络模型，毕竟网络作为云平台的底层，出现问题后影响太大。

我们针对网络建设的核心需求及社区现状综合分析之后，决定启动beyondFabric项目，目前该项目已经作为博云容器云平台重点支持的两个网络模型（calico/beyondFabric）之一，支撑了多家企业的生产系统的稳定运行。

02

BeyondFabric

BeyondFabric是我们自研的kubernetes CNI插件，利用etcd作为其数据存储单元，内置完善的IPAM能力，能够很好的满足前面提到的客户的核心诉求。因为BeyondFabric是基于二层网络设计的，同时针对特定需求做了很多优化，所以其在一部分场景下（特别是国内高度重视安全的金融类企业数据中心中）表现良好；但同时也决定了BeyondFabric不能适合于所有的场景，具体选择哪种CNI还是要根据自身情况作出评估。（实际上没有任何一种CNI能满足所有的场景需求。）

fabric经典模式示意图

从fabric的概念图中可以一目了然的看清楚云平台的网络拓扑，每个计算节点上安装一个OVS，并且作为一个单纯的虚拟交换机使用，容器通过veth pair连接到OVS的端口上从而自然的获得物理环境下的网络身份；在网络的层面上，容器、虚拟机、物理机是完全对等的。不论是网络管理人员还是业务人员都可以简单清晰的了解到网络的拓扑情况。而且在这种简化的部署模型中（同时也是使用度最广的模型）不包括控制器等复杂逻辑，提供了简单、高效、稳定的网络环境。

fabric的组件图

1. fabric是基于OVS的CNI插件，其具体职能为为POD组建网络并设置IP地址。

2. fabric-ctl负责网络及IP地址管理，通过RESTFUL API提供网络/IP的管理能力，如创建网络， 编辑网络，查找IP等。fabric-ctl本身是无状态的，所有状态信息存储到etcd中。

3. fabric-admin的主要使用人员为平台管理员或BOC运维人员，方便使用人员查看和管理网络及IPAM等。fabric-admin的命令行格式参考Kubectl。

在经典组网模式下，将ovs作为一个基本的虚拟交换机使用即可，非常简单。如果使用networkpolicy等隔离策略，需要在每个节点上引入一个分布式控制器。

网络管理能力

fabric项目除了CNI协议规定的组建容器网络的功能之外，还以restful API、annotation等方式额外提供了对网络的管理能力。通过界面集成后可以方便管理人员使用，如下图中的增加网络，查看网络，查看IP地址使用，固定IP等。

增加网络

查看网络

查看IP地址使用

固定IP地址

成熟度

接下来看一下fabric项目的成熟度，一个项目的成熟度是由很多方面决定的，除了fabric设计之初的简单网络模型，成熟的组件（无额外复杂组件，即使在做策略控制/overlay等场景下，也只是在每个节点上引入一个分布式控制器）之外，我们还做了以下几个方面的工作。

fabric-admin

考虑到软硬件层面的异常情况，例如kubelet或fabric的bug，环境（硬件损坏）等均可能对系统的正常运行造成不同程度的影响，所以提供了一个fabric-admin的工具，位于/opt/cni/bin目录下，其作用类似于文件系统的FSCK能力，为运行时管理提供保障。同时其命令行格式完全匹配kubectl，对熟悉kubernetes的用户非常友好。

例如可以查看pod的IP占用情况（示例输出已被截断） ：

同时，fabric-admin还提供了多种运行时管理能力支持，运行–help后可以提示： 

如同FSCK是文件系统成熟的重要标志，fabric-admin是beyondFabric项目成熟的有力保障！（fabric-admin虽然功能强大，但客户现网环境中还从来没有被使用过，也从侧面说明了fabric项目的成熟度）

• kubernetes社区CNI测试套件

因为fabric项目完全满足CNI协议规范，因此可以使用任意的CNI测试工具进行测试。我们的测试团队结合社区提供的CNI测试工具及k8s job对象等对beyondFabric进行了长时间的严格测试，测试结果证明fabric项目具备生产可用能力。

• 多种平台支持

私有云建设中，容器云平台一般运行在物理环境或vmware/openstack等虚拟化环境中。fabric对于这几种部署环境均能完善支持。对于网络环境复杂不易变更的场景下，fabric基于overlay可以显著减少环境依赖。

• 多个落地案例

博云容器云平台基于fabric已经有多个的落地案例，在可管理性、稳定性、性能等多个方面运行良好。

BeyondFabric性能

接下来看一下fabric的性能表现。由于fabric采用了稳定可靠的OVS作为其基本单元，所以从原理上讲其性能损耗应该是非常小的，我们在物理环境中基于万兆网络的性能测试也验证了这一点。图中可以看出pod-pod/pod-node的损耗较node-node约在5%左右。

博云容器云平台网络模型选型建议

然后我们来看一下选型建议。在客户落地容器云平台的过程中，我们会和客户进行大量沟通，其中一个很重要的沟通就是涉及业务方、安全人员、网络人员、运维人员的网络模型沟通。具体的选型建议如下表所示，最终的选型结果由所有涉及人员共同决定。

fabric项目的小结

OK，简单总结一下fabric项目。fabric项目解决了企业落地容器云平台的一些主要的痛点，通过经典网络模式可以很好的满足各个职能部门的诉求。但毕竟没有任何一种网络方案能满足所有的网络诉求，fabric也有其天生的缺点，例如经典网络模式下需要客户真实的IP网络，这些网络资源在容器化的环境下消耗速度很快，需要根据业务需要提前创建好网络资源，然而有些客户的IPV4资源会比较紧张。当然这一点随着VXLAN的支持和IPV6的普及，将会得到很大的改善。fabric核心是二层的解决方案，二层就必然面临扩展性的问题，我们目前的解决方案是通过分区的概念去映射真实的网络分区，然后通过扩展分区的方式扩展Kubernetes集群。

Q：IPAM的固定IP是怎么实现的？IP与Pod UID关联吗？

A：管理员录入网络信息后，Fabric会将所有IP地址存储到etcd中统一管理。目前固定IP是通过给deployment等workload对象增加Annotation实现的。IP不与Pod UID关联。

Q：这里面提到的三层网络和二层网络是指七层协议的三层二层吗？

A：是的，比如交换机工作在2层，路由器工作在三层。

Q：服务负载均衡怎么实现的呢？

A：外部流量导入集群的负载均衡是通过另外一个组件，ingress controller实现的，没有实现在CNI里面。Kubernetes svc的负载均衡是通过iptables实现的，Fabric项目也会往iptables里面加入一些规则，主要是跨节点SNAT。

Q：支持流量限流么？

A：支持Ingress/Egress限速，通过给容器加Annotation即可以实现容器的限速。

Q：有和Contiv做过对比吗？

A：选型阶段做过，比较早了，那时候貌似Contiv还不太成熟，所以没深入研究。

Q：这些网络方案有什么好的学习方式吗？

A：网络虽然很复杂，但万变不离其宗。容器网络这个词最近几年比较流行，是因为网络再容器环境下遇到了一些挑战，但网络本质的概念还是过去非常成熟的那一套。所以首先得学习基本的网络知识，然后去看下容器环境快速弹性等带来的痛点。

Q：TC怎么实现的？

A：这个实现的比较久了，早在过去重点支持Calico的时候就已经做了。有些细节模糊了，但基本是通过Linux tc实现的，因为本质是veth pair，所以限速可以在主机侧veth端实现。基本的限速命令可以查找tc机制就可以了，我们碰到限速不太准确，最后也通过调整参数解决了，误差控制在百分之几吧。

Q：与Kube-OVN做过对比吗？

A：Kube-OVN是友商开源的产品，我了解过。首先Kube-OVN和Fabric项目都是基于OVS进行研发的，都支持Overylay/underlay模式，都可以实现CNI协议。但其实差别还是比较大。OVN项目源于OpenStack，OpenStack里的网络模型是非常重的，概念、组件都比较多，OVN也在试图统一Kubernetes/OpenStack的网络模型，所以Kube-OVN里有一些能力其实已经不在CNI spec的范围内了，比如负载均衡，DNS等，其实在社区都有对应的实现。而Fabric会简单很多，是一个标准的CNI实现，网络模型也非常清晰，能够把容器直接融入现网环境，企业的网管一般都能掌控，对安全监管等已有体系兼容性比较好。

网络是非常复杂的，很难有一个统一的模型去兼顾所有的场景，个人认为这也是Kubernetes社区聪明的地方，把这些复杂的，不宜标准的东西抽象出来，交给第三方去做。也正是由于CNI协议的简单性和网络的复杂性，现在市场上CNI可以说百家争鸣，各有所长。个人认为这是一个非常好的现象。具体使用哪种CNI，还是要根据企业自身的情况作出决定。