实践案例 | 基于 Kube-OVN 的虚拟网络技术探索

灵雀云

发布于 2022-03-03 10:40:18

1.9K0

发布于 2022-03-03 10:40:18

Kube-OVN开源以来，积累了各行业的用户实践，在KubeCON China 2021，来自字节跳动系统工程和技术团队（STE）的高级工程师费翔，带来了他和团队基于Kube-OVN做的场景落地和技术实现的分享。分享中梳理了字节团队技术选型过程，也同时也详细指出了基于社区版本之上，字节团队在实际应用场景下的技术拓展思路、成果，以及对社区未来功能的展望。

作者：费翔｜字节跳动高级研发工程师

Kube-OVN社区Contributor

基于虚拟机与容器混跑场景需求的网络技术选型过程

去年，我们团队针对搭建K8s集群，在虚拟机和容器上混合运行这个需求进行了CNI工具的选型，经过一些列调研工作，我们把目标锁定Kube-OVN，有以下几点考虑：

首先，Kube-OVN是中心化的IPAM，地址管理更加灵活。市面上传统的Cilium和Calico这些工具，都是一个node节点上面分配一个网段，这样相当于Pod IP是和node的节点强相关，无法达到灵活迁移的要求。
第二、Kube-OVN具有更贴近传统IaaS的虚拟网络模型（VPC/Subnet）。Kube-OVN具备一些subnet和LB的一些概念，比较符合我们需求。现在，Kube-OVN还扩充了vpc场景，这样的话它其实和IaaS的网络更加相似了。
第三、Kube-OVN的控制面是基于OVN的，可以实现更灵活的网络编排调度。
第四、Kube-OVN的数据面是基于OVS，在虚拟机的场景下，方案也比较成熟，性能潜力也比较大，有各种offload或者dpdk的加速手段。

基于以上考虑，我们决定选用Kube-OVN。

基于Kube-OVN实现的初版网络方案

Pod网络流量模型

我们第一版网络流量模型是完全基于Kube-OVN社区的一些技术来实现的：

Pod直接互访走的是geneve隧道，这个是标准的一个Pod互通的流量模型。
基于Kube-OVN的分布式网关子网，Pod访问集群外的流量都导出本Node上OVN0接口。
虚拟机Pod直接使用Underlay地址，三角流量路径，网关ECMP高可用。

注：虚机访问集群外的流量，从本Node的ovn0接口forward到eth0接口发出。入向走geneve隧道到node

容器Pod访问集群外流量，在宿主机做SNAT，从本node发出。

IPv6双栈（已经并入社区）

Service的网络流量模型

我们同时还有一个service的网络流量模型，实现如下：

Service使用IPvs实现
需要对外发布的Service分配external IP，getway发布external service bgp网段。

初版网络方案存在的问题及改进方案

但是这一版方案我们上线之后发现了一些问题，主要问题是有下面几个，

第一、源路由数目过多，每个Pod需要一个单独的路由，集群规模大之后性能受影响。

第二、虚拟机场景下流量路径过长，性能达不到预期。

第三、Geneve隧道业界使用案例较少，兼容性存在风险（offload）。

基于以上三个问题，我们分别做了一些改进的方案。

改进方案一：虚拟机使用ovs-dpdk

使用ovs-dpdk 代替ovs-kernel.
cniserver创建vhostclient类型的socket，mount到pod内，qemu使用该socket创建虚机。
pod内没有eth0网卡设备，在containerd上可以work，不太符合规范，最好是多网卡。

改进方案二：源路由优化(待上线)

创建public logical switch(172.168.0.1/30)，绑定localnet logical port，用来和local 网络打通，实际上是通过一个patch设备和br-ex网络连通。
ovn下发低优默认路由，dst 0.0.0.0/0 nexthop 172.168.0.2。不再下发POD源地址路由。
mac-binding table设置172.168.0.2 00:10:10:10:10:10条目。
开发br-ex控制器，流表修改mac并从br-ex或者eth发出。
Join switch不在承担连接overlay的unerlay的作用，只用作POD访问NODE的流量。

改进方案三：geneve替换为vxlan