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

2022-03-03 10:40:18 浏览数 (1)

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

  • ovn在Geneve隧道中，除了携带VNI外，同时还携带了ingress port和egress port。
  • vxlan的vni字段只用来表示tunnel id
  • 在table0处提取后跳转到table6在consider_port_binding中，将本NODE所属接口的mac地址，生成规则后填充到table6中
  • table6根据目的mac来设置NXM_NX_REG15（若多播设置为0x8000），再跳转到table33
  • 后续在使用egress pipeline时，确保不匹配inport
  • nbctl lsp-set-addresses设置时，确保同一VPC下的mac地址不冲突

对Kube-OVN社区版本能力的展望

  • 多集群互联
  • 更加贴近传统vpc网络 or 云原生网络；service能力提升。
  • vpc能力的完善？(路由，eni)。
  • nfv能力的完善？(lb，nat，vpn)
  • 观测/定位手段更加丰富。
  • 是否考虑单独实现数据面，不依赖ovn?

官网：

https://www.kube-ovn.io

GitHub:

https://github.com/kubeovn/kube-ovn

Slack：

https://kube-ovn-slackin.herokuapp.com

Kube-OVN提供面向企业场景的容器网络解决方案。

填写表单，了解跨云网络管理、IaaS（包括OpenStack、VM等）与K8s统一网络技术栈、容器托管新一代数据中心SDN、微服务架构下高性能网络、5G及边缘集群落地等应用场景。

tcp/ip node.js 容器 https 私有网络

0 人点赞