Meetup活动回顾！Kube-OVN 1.8新版本特性预览及功能规划

Kube-OVN社区 2021-09-02 14:48:19

8 月 26 日，Kube-OVN 社区第二期线上 Meetup 成功举办。本次活动由项目发起人刘梦馨主讲，他分享了当前Kube-OVN 项目及社区的发展情况，同时带来了Kube-OVN 1.8版本的特性预览及未来功能规划，吸引了众多用户一起交流讨论。

Kube-OVN 项目及社区成果

Kube-OVN 项目的代码通过 Apache2.0 的方式进行开源，社区提供的所有功能，包括代码、文档、故障报告和运维手册，都在 Github 上开源。

Kube-OVN 在发展过程中得到了很多企业和个人用户的支持，用户分别来自于天翼云、金山、华为、锐捷、浪潮、字节跳动、Intel 等公司。在社区用户的支持下， Kube-OVN 项目到目前为止已经收到大约 1780 个 commit，在这两年多进行了 31 次发版，有 43 位贡献者为项目贡献了代码、文档，在 Dockerhub 上的镜像数据，主镜像有约160 万次的拉取。

Kube-OVN1.8 新特性

Kube-OVN 1.8 新版本的功能从『Underlay 网络强化』、『网络延迟优化』、『Kubernetes和 OpenStack 互联互通』、『VPC 能力进一步完善』这些调整方向来介绍。

『Underlay 网络强化』

随着 Underlay 的用户越来越多，需求也会变得越来越复杂。在1.7发版之后，社区交流群里提出了非常多关于 Underlay 的问题，比如：

宿主机只有单网卡可不可以？
多个网卡对应多个 Vlan可不可以？
网卡配错了只能删了重搭吗？
网卡名不一致可不可以？
容器内多个网卡在不同的 Vlan可不可以？
部分 Vlan只在部分主机的部分网卡存在可不可以？
组播能不能支持？
Overlay 和 Underlay 混部行不行？

三个月以来，1.7版本在社区的反馈中一步步迭代，上述所有问题已经全部得到解决，并且经过了很多次 poc 和社区用户的打磨，在生产环境中得到了验证。可以说 Underlay 的网络能力比上个版本强化了很多。

更新功能：

ProviderNetwork 定义主机、网卡、底层网络三者映射关系
动态按需调整网络映射
Vlan 和 ProviderNetwork 关联
无 Vlan 关联 Subnet自动为 Overlay网络

『网络延迟优化』

"你们用了OVS 性能会不会有影响呀" ，"你们和Calico的性能相比怎么样"，"为什么我这边性能压不上去呢？""看了其他人的性能测评你们的性能好像很差呀" ......这些来自用户的灵魂拷问在1.8 版本统统都有解答。并且在这个周期内对小包的延迟做了深入的性能分析和性能优化。

优化方向：

选取特定物理环境做基准测试
开发自动化性能测试工具进行频繁测试优化
生成火焰图进行瓶颈分析
fastpath 内核模块，OVS 编译优化，OVN LB 流表裁剪

经过优化之后，在当前的测试环境下，TCP和 UDP 的延迟相对于宿主机的延迟能控制在 5% 左右，UDP 的带宽有比较大的提升，比之前提升了大概两倍多，接近到百分之90%的主机带宽水平。关于Calico 性能的横评，我们测试了五组数据：在 Kube-OVN overlay 对标 Calico 的 overlay ，Kube-OVN underly 对标 Calico 的不封装的模式下，我们都会比 Calico要好一些。具体的性能优化的方案可以在 Github 上看到。之后有机会也可以专门分享一期我们究竟是如何把性能优化上去的。

『Kubernetes和 OpenStack 互联互通』

OVN-IC 方式实现OpenStack 内VPC 和Kubernetes 内VPC 对等连接
Kubernetes 和 OpenStack 共享底层 OVN 基础设施
Kubernetes 内导入 OpenStack VPC，直接在 Kubernetes 内创建 OpenStack VPC 网络下 Pod

在之前 1.7 版本周期用的是异构的模式打通网络，让 OpenStack 和 K8s 里面的工作负载可以相互进行访问。而这次1.8 版本我们想更进一步，最终实现在 OpenStack 或者是 K8s 里面的一个 VPC 下，可以直接创建 Pod 和 VM 。这个功能正在和 Intel 团队一块来推进，并且在一些客户的场景已经有了初步验证。

『VPC 能力进一步完善』

VPC 内Service 支持
Security Group 支持
VPC 内支持 L4 SLB

在1.8版本后用户自定义的 VPC 会有 service 支持、 Security 的 Group 支持。4层负载均衡这条路基本上调通了，外部 LB 也可以在 VPC里面来做。当前的VPC内的功能包括子网、路由触网的网关EIP、Floating IP，NAT dataway，然后再加上安全组，功能已经比较完整了。在下个周期 VPC 会做更多的完善，希望今年年底的时候，整个VPC多租户网络能够比较完整的呈现。开源社区里面如果能把多租户的这些功能引入到 K8s 里面来的话，可能对 K8s 之后在数据中心的落地都会有比较大的一个帮助。

『其他功能增强』

本次版本升级还有其他小功能的增强，比如Pod 粒度流量镜像、Tunnel IP 动态调整、多网卡自定义路由等。

Kube-OVN 未来功能展望

Kube-OVN 未来功能主要从三个方向进行规划：性能进一步增强、VPC能力下层、KubeVirt 虚拟化能力增强。

性能进一步增强主要通过优化数据平面和控制平面实现，希望把 Kube-OVN 的性能做得更好，减少用户的担心

在VPC的层面上，根据两种不同的场景支持Cluster CRD 和 Namespaced CRD，再加上南北向的QoS，接着实现VPC对等连接，然后考虑引进L4 LoadBalancer和L7 LoadBalancer（因为7层的功能比较丰富）

KubeVirt 虚拟化能力增强主要是希望做一套完整的方案来使 KubeVirt 固定 IP 热迁移，还包括网络直通，避免多次复制性能消耗，以及智能网卡直通、DPDK 网卡直通等一些规划的介绍。

希望越来越多的用户能参与到项目的规划过程中。

QA 汇总

1、Kube-OVN 网络插件性能怎么样？

在刚才的分享中已经基本回答了，后续我们计划做一个完整的、面向几个主流容器网络方案的横评，把测评工具、测试方案和数据全部开放出来，请大家拭目以待。

2、Kube-OVN 后续考虑支持关于 VPC 之间软路由互联么？或者分享下当前的实现方案？

我不太清楚软路由具体是什么样的方式，互联的话我们目前在做的是跨集群互联。就是有两个 K8s 集群，都跑在 Kube-OVN，但是他们可能是部署在不同的环境里，那么基于我们的一些集群互联的方式，可以把两个集群的网络拉平，然后只要每个集群内各有一个节点，这个节点之间相互是可以跟对端进行互通的，就可以打造两个集群之间的隧道，实现两个集群之间的直接互通。

3、目前对 network policy 能完全支持吗？

我们现在能做到对容器网络的 network policy 完全支持，但是因为用户有一部分容器可能会跑在主机网络上，因为主机网络的流量不过 OVS，所以对主机网络那部分目前还没有很好的支持方法。

4、OVS 本身的 lb 应该还不支持健康监测吧？有没有针对四层 lb 的健康监测的设计？

我们目前在做的是 K8s 层面的健康检查，直接把 endpoint里面的后端信息直接加到 4 层 LB 上面。

5、OVN 层面独立部署，从而多集群共享 vpc 这个有支持计划吗？

我们在跟 OpenStack 互联的方案里面目前是这么做的。你可以当成这个 OVN 是独立部署的，然后 Kube-OVN 和 OpenStack 是共用的 OVN ，VPC 共享也是通过这个方式来做的。但是多个 K8s 共享一个vpc，目前还没有这方面的计划。

6、后续会考虑实现基于 K8s 中的 ip 和 node 的信息进行流表重建的工具么？因为OpenStack neutron 这边的 ovn 是有这样的工具的，即使把 ovn 数据库以及组件清空，也是可以基于一条命令重建流表的。

我们现在把所有的网络信息往OVN 同步，同时往 K8s 的 annotation 上同步一份。所以就算把 Kube-OVN 都删掉，我们还有恢复信息的能力。这个数据是都有的，这方面的工具还没有研发，完整的验证还没有进行，这应该是下个周期内要做的工作。

7、面向多个云厂商，如何让上面的 K8s 集群网络互通？

这个问题有几种做法，最好的做法其实是跟多个公有云之间买互通的线，让他们帮你把网络打通，这种理论上性能和可靠性都是最好的。如果公有云不愿意做这个事情的话，拿 Kube-OVN 也可以实现，你需要在每个公有云上各选几个节点，这个节点相当于是做互联的网关。这几个节点之间，不管是通过公网 IP 的方式也好，或者是在这几个机器之间打隧道的方式也好，跨集群互联的功能就可以跑起来了。

8、对通过 service 访问的流量能实现 networkpolicy 策略吗？

通过 service 访问的流量，如果是对Cluster IP做限制，我们现在应该也是支持的，因为我们这边做完 nat 之后，你看到的目标其实是原目标的 IP，所以你即使通过 service 送到了那边，但是你 Ingress 的时候，由于我看到的是你的原IP，我还是会按照对应的策略进行一个限制。如果更严格一点的话，你其实是应该把 Service IP 这样的一些东西也写到一个 network policy 里面，这样可以做一个比较完整的限制。

9、metalLB 结合 ovs virtual ip 也可以做负载均衡，这个方案感觉怎么样？

metalLB 本身是一个还算比较清晰、比较直接的方式，我们也试过这个方案，觉得挺好的。

本届Meetup圆满结束，感谢大家对 Kube-OVN 的支持。欢迎更多朋友加入社区，我们共同把这个项目打造得更好。

点击即可观看活动视频。

在 Kube-OVN 微信公众号后台回复“0826”，即可获取演讲PPT。

...全文