容器网络方案调研:都是网络插件,Kube-OVN凭啥脱颖而出?

近日,灵雀云通过网络研讨会直播发布了基于 OVN 的 Kubernetes开源网络项目Kube-OVN的 1.0 GA版本,同时Kube-OVN技术社区初步成型,获得了大批开发者和用户的关注。

为更加直观的了解社区对于容器网络的使用现状和需求,在此次线上研讨会中,我们发布了【关于网络组件Kube-OVN的使用调查】。2周内,共收集了158份有效调研问卷,本文将分享问卷中的相关数据,同时附Kube-OVN 1.0 网络研讨会的部分问答实录,望对持续关注容器网络解决方案的伙伴们一些有价值的参考。

受访者概况

运行容器的环境:

本次调研的158位调研对象中,60%来自互联网行业,金融、工业、制造、教育等传统行业占30.5%。受访人员中47.4%是开发岗位,运维28.9%,架构师21.1%。

被调研企业中,容器化已经达到100%。容器运行在私有云的占比最多,达到60.5%,在公有云上运行的占比为36.8%。(备注:此选项为多选)

当前网络方案使用现状

正在使用的网络方案:

 

网络架构本身就是K8s中较为复杂、让很多用户头疼的方面之一。K8s网络模型本身对某些特定的网络功能有一定要求,但在实现方面也具有一定的灵活性。因此,业界已存在不少网络方案。此题为多选,如图所示,calico和flannel作为目前最流行的CNI插件分别收获了55.3%和47.4%的用户,与此同时,也有28.9%的用户已经采用了Kube-OVN来满足特定的环境和需求的补充。

是否使用IPv6:

 

是否使用NetworkPolicy:

是否需要网络多租户方案(VPC):

是否需要和物理网络打通:


以上是用户对是否使用 IPv6、NetworkPolicy、是否需要网络多租户方案(VPC)、是否需要和物理网络打通的使用现状的数据反馈,供参考。

对于Kube-OVN功能的需求

 

Kube-OVN已有功能需求度:

调研中可以看出,子网功能是用户关注Kube-OVN的最高需求。

子网是Kube-OVN中最重要的概念,通过子网相关的 CRD, 用户可以方便的实现子网和 namespace 的绑定。Kube-OVN支持子网cidr,gateway,exclude_ips 以及 switch_name 的设置。同时支持基于子网的IP隔离,用户可以轻松实施基本的网络隔离策略。在后台实现上,Kube-OVN会监听 namespace 和 subnet 的变化,并根据变化在 ovn 中创建并设置虚拟交换机,将其和集群路由器关联,设置对应的 acl和 lb。

Kube-OVN未来功能的需求度:

 

 

Kube-OVN未来的规划围绕着三个关键词:功能,运维性,性能。

功能方面会继续完善企业级网络的能力,例如多网卡的支持,多租户网络以及 IPv4/IPv6双栈。

运维性方面讲继续增加更多网络诊断以及可视化工具,方便后期的网络的运维管理。性能方面一方面和 Intel 合作 DPDK 相关的开发,增加数据平面的能力,另一方面对控制平面持续优化,增强大规模集群网络管控的能力。

Kube-OVN网络研讨会 Q&A

Q1、开源版本与商业版本有多大区别?
A1:商业版本代码上是没有区别的。我们有发布商业版本的计划,将提供完整的技术支持和售后服务,如果客户有通用型的需求会优先进行开发,并提供一些定制的开发,同时针对客户的机器和网络做一些针对性的调优。

Q2、是不是基于OpenStack的OVN方案做的修改和定制?
A2:OVN基于OVS的控制平面,是比较通用的网络组件。[Kube-OVN](http://www.alauda.cn/open/detail/id/377.html)是通过将OpenStack领域成熟的网络功能平移到K8s。

Q3、 IPAM的功能什么时候做好?IPAM用固定IP功能和之前的使用方式一样吗?
A3:1.1的版本会把IPAM做好,IPAM只是第一步,后续多网卡的支持会根据IPAM一起做出来。IPAM用固定IP功能和之前大部分是一样的,有些小区别就是子网的定义会发生一些变化,就是需要指定哪个子网用固定IP。

Q4、固定IP是什么场景?
A4:固定IP适合一些传统业务的场景,有些公司是没有固定IP是无法容器化的。有些传统的业务他的服务发现就是根据IP来的,所以IP如果一直变的话改动就太大了。

Q5、 IP直接路由的场景是什么?
A5:这个场景很传统,相当于把容器当做虚拟机来看待,这样容器的IP是全网可达的,这样的话与底层的网络是打通的。

Q6、网关节点可以单独部署吗?
A6:可以单独部署也可以和整个集群在一起,只要是K8s的机器就可以做为网关的节点。

Q7、DPDK的集成什么时候可以完成?
A7:目前在和Intel爱尔兰的团队合作开发,但是什么时候完成要看爱尔兰的团队的进度了。大家如果感兴趣可以看一下PR,已经列出了很多问题。地址:https://github.com/alauda/kube-ovn/issues/104

Q8、分布式网关路由不是OVN2.12的内置功能么?
A8:Kube-OVN里的分布式网关和OVN里的分布式网关不太一样,Kube-OVN主要是从容器网络的角度来讲的,就是容器都可以通过当前主机的网卡访问外网。

Q9、Kube-OVN的多网卡和Intel的muticni, 华为的多网卡方案有什么区别?
A9:我们主要做多网卡的IPAM,是集群级别的IP分配的工具。会配合其他多网卡的插件共同使用。

Q10、多租户支持到什么程度?
A10:多租户是我们一直想做的一个事情,OVN的多租户的能力比较强,我们想平移到K8s上。我们碰到的一个问题主要是,K8s有自己多租户的设计,但是这个项目还没把方针确定出来。K8s有个多租户的SIG,但是具体的方案还没确定,所以如果上游的方案没定下来我们直接做可能影响效率。现在能做到的就是分配子网,保障网络的隔离。

Q11、 Trace的能力会把中间的虚拟交换、网关之类的元素提出来么?还是只会看到源和目的这样?
A11:我们最终期望的是把中间的逻辑链路和物理链路都画出来,如果网络不通那么哪里出问题很容易就看出来,我们先做的是源和目的的端到端的监测,快速提供监测能力。

Q12、和Intel多网卡集成有案例吗? 比如Kube-OVN和falanel的共存?
A12:我们最近会开始做这个事情出一个完整的多网卡方案,目前社区有用户进行过集成,Intel 也在电信领域做了一些案例。

Q13、 Kube-OVN和OVN-Kubernetes 这个项目有哪些区别?
A13:区别很大,具体我写在这个链接里面了:https://github.com/alauda/kube-ovn/issues/104

我们最开始是想在OVN-Kubernetes上进行一个改造的,但是后来发现网络模型与我们差别较大。OVN-Kubernetes IP分配是一个主机一个网段,就相当于IP与主机是绑死的。而我们是有多租户的想法,想做到Namespace与子网绑定,基本上从底层的网络拓扑就完全不一样了。另外OVN-Kubernetes有不太稳定等其他原因。

Q14、Kube-OVN有些流表功能依赖于内核模块,对主机内核版本有没有要求?
A14:有一定要求,如果是用CentOS 7推荐用CentOS 官方支持的最新内核,如果ubutu 建议18.04以上版本。

Q15、 Kube-OVN能支持Pod级别的安全规则吗?
A15:我们现在支持K8s 的network policy, 只要协议能写出来就支持。

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录