Kubernetes中文社区
本文根据博云在dockerone社区微信群分享内容整理
过去几年博云在企业中落地容器云平台遇到了很多痛点，其中一个比较典型的痛点来自网络方面，今天很高兴跟大家聊聊这个话题并介绍下我们基于OVS自研的CNI插件——内部称之为fabric项目。
不同于开发测试场景，生产场景上线一套平台或系统要求会严格很多。安全、监控、流程、现有系统集成、业务暴露等等的建设要求都要匹配上，否则不可能上线。在这个过程中，特别是在传统的金融类企业对监管要求严格的情况下，容器云平台落地时会碰到很多问题，这其中，最典型的一个需求就是容器云平台的网络建设，必须同时满足业务方，运维人员，安全人员，网络人员的诉求。
现在容器云平台大部分都是基于Kubernetes构建，市面上的CNI插件也非常多，各个企业现网的需求也有很大的不同，所以几乎不可能出现一种网络模型适配所有客户场景的情况。现在主流的比较成熟稳定的CNI比如calico在扩展性、稳定性等方面表现优秀，但在传统金融类企业落地时非常困难，经常需要对不同的需求做出妥协。
我们和多家客户进行了深入沟通，虽然需求有所差异，但总结下来主要的诉求包括：
- 在主流的二层组网的数据中心中，受限于硬件能力或管理复杂度，大部分客户不希望引入BGP等三层路由概念。
- 企业业务系统往往会在容器云平台内外同时同时部署，希望平台内外网络能够直接打通。
- IP地址是业务的身份识别，希望能够具备固定IP的能力，而且是可管理、可审计的IP地址。
- 管理网络和数据网络分离。
- 具备网络隔离能力，硬件隔离的强安全性和软件隔离的灵活性都需要。
- 网络模型应该尽量简单，易于掌控，易于调试。
- 高性能，低抖动的网络吞吐能力。
- 其他的高级特性，如双向限速、DPDK、overlay等。
我们对市面上主流的CNI插件进行了广泛的调研后，发现主流的CNI对以上“国产化”的需求的支持并不理想，主要的不满足点包括：
- 网络模型差异（三层VS二层，当然L2的方案也很多，OVS有流表等等高级功能，非常适合当今云化的环境），要适配现网环境、安全策略等。
- 云原生理念。主流的CNI较好的满足了云原生的概念，但客户的实际需求中其实是有些“anti-cloudnative”的，如何在cloudnative和anti-cloudnative之间做到平衡其实普遍缺少实践经验。
- 简单稳定可靠。这其实是非常重要的要考虑的点，厂商、企业都要有相应的人员能够掌控网络模型，毕竟网络作为云平台的底层，出现问题后影响太大。
我们针对网络建设的核心需求及社区现状综合分析之后，决定启动beyondFabric项目，目前该项目已经作为博云容器云平台重点支持的两个网络模型（calico/beyondFabric）之一，支撑了多家企业的生产系统的稳定运行。
fabric经典模式示意图
从fabric的概念图中可以一目了然的看清楚云平台的网络拓扑，每个计算节点上安装一个OVS，并且作为一个单纯的虚拟交换机使用，容器通过veth pair连接到OVS的端口上从而自然的获得物理环境下的网络身份；在网络的层面上，容器、虚拟机、物理机是完全对等的。不论是网络管理人员还是业务人员都可以简单清晰的了解到网络的拓扑情况。而且在这种简化的部署模型中（同时也是使用度最广的模型）不包括控制器等复杂逻辑，提供了简单、高效、稳定的网络环境。
fabric的组件图
- fabric是基于OVS的CNI插件，其具体职能为为POD组建网络并设置IP地址。
- fabric-ctl负责网络及IP地址管理，通过RESTFUL API提供网络/IP的管理能力，如创建网络， 编辑网络，查找IP等。fabric-ctl本身是无状态的，所有状态信息存储到etcd中。
- fabric-admin的主要使用人员为平台管理员或BOC运维人员，方便使用人员查看和管理网络及IPAM等。fabric-admin的命令行格式参考Kubectl。
在经典组网模式下，将ovs作为一个基本的虚拟交换机使用即可，非常简单。如果使用networkpolicy等隔离策略，需要在每个节点上引入一个分布式控制器。
增加网络
查看网络
查看IP地址使用
固定IP地址
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已经有多个的落地案例，在可管理性、稳定性、性能等多个方面运行良好。
网络是非常复杂的，很难有一个统一的模型去兼顾所有的场景，个人认为这也是Kubernetes社区聪明的地方，把这些复杂的，不宜标准的东西抽象出来，交给第三方去做。也正是由于CNI协议的简单性和网络的复杂性，现在市场上CNI可以说百家争鸣，各有所长。个人认为这是一个非常好的现象。具体使用哪种CNI，还是要根据企业自身的情况作出决定。
