容器网络方案调研：都是网络插件，Kube-OVN 凭啥脱颖而出？

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

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

受访者概况

运行容器的环境：

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

当前网络方案使用现状

正在使用的网络方案：

是否使用 IPv6：

是否使用 NetworkPolicy：

是否需要网络多租户方案（VPC）：

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

对于 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 未来功能的需求度：

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

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

Kube-OVN 网络研讨会 Q&A

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

Q2、是不是基于 OpenStack 的 OVN 方案做的修改和定制？

A2：OVN 基于 OVS 的控制平面，是比较通用的网络组件。Kube-OVN 是通过将 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, 只要协议能写出来就支持。