联系电话:4006-252-832

灵雀云技术博客

汇聚容器/Kubernetes、DevOps、微服务等云原生领域前沿资讯、技术干货、用户实践等。
活动回顾Kube-OVN 社区线上 Meetup,what's the next
2021-09-02

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 的支持。欢迎更多朋友加入社区,我们共同把这个项目打造得更好。


活动回看

复制活动链接:https://qdrl.qq.com/yNkgduq1至浏览器打开,即可观看活动视频。

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


上一篇:千人围观,Kube-OVN社区周年庆

下一篇:数字化装备制造新标杆!灵雀云携手腾讯云打造三一集团技术中台



联系电话:4006-252-832
© 2021 All Rights Reserved. 灵雀云 版权所有 备案号:京ICP备15011102号-2

返回顶部