为什么我们要自主开发一个稳定可靠的容器网络
在过去的几年里，随着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 对网络进行全方面监控，并对接主流的流量分析平台。