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

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版本在多个客户的生产环境中稳定运行,完美的支持了物理环境以及vmwareopenstack等虚拟化环境。随着BeyondContainer 2.3版本的发布,BeyondFabric迎来了2.0版本。2.0版本里,网络功能更加丰富、同时在可扩展性、可用性等方面有了很大增强。

 

 

 

BeyondFabric 2.0功能增强

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

 

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

 

 

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

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