容器网络方案调研：都是网络插件，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, 只要协议能写出来就支持。