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

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

 

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

 

 

 

02全分布式,消除中央控制器,提升扩展性和可用性

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

 

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

 

 

 

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

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

 

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

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyzxxy.html