Kata 在 Kubernetes 中的网络模型

介绍

基于 containerd，kata2 进行介绍（kata3 这部分实现一样^_）；现有环境是 kube-ovn 的，基于 kube-ovn 的实现进行串联。

Kata 为了兼容各种 CNI ，那么就不能对 CNI 提出要求，需要去适应 CNI。

cni 的角色

CNI 常规做法

Kuberntes 通过 containerd 为 pod 创建 netNS，并通过调用 CNI 二进制在 netNS 里为 pod 创建网络环境。通常情况下，CNI 在 netNS 创建的网卡名称为 eth0，根据 multus 的策略，多网卡时对应着 net1，net2 等。

KubeOVN 的实现

Kube-OVN 提供集中式 IPAM，IPAM 工作完成后将分配的资源存入 annotation。
然后在 containerd 调 cni 去为 pod 创建网络环境。

那么 KubeOVN 基于 ovs 为 pod 创建几种类型的网卡。

Veth-Pair

一端在 ovs br-int 桥上，一端在 pod 的 netNS 中，cni 在 netNS 里配置 eth0 的 ip,mac,route 等信息。

$ ip netns exec  cni-d060bedf-279d-382a-b3a8-82107d3ff868 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
23: eth0@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default 
  link/ether 00:00:00:71:23:11 brd ff:ff:ff:ff:ff:ff link-netnsid 0
  inet 172.10.0.201/16 brd 172.10.255.255 scope global eth0
     valid_lft forever preferred_lft forever
  inet6 fd00:10:16::c9/64 scope global 
     valid_lft forever preferred_lft forever
  inet6 fe80::200:ff:fe71:2311/64 scope link 
     valid_lft forever preferred_lft forever
     
$ ip netns exec cni-d060bedf-279d-382a-b3a8-82107d3ff868 ethtool -i eth0
driver: veth
version: 1.0
firmware-version: 
expansion-rom-version: 
bus-info: 
...

Internal

在 ovs 桥上创建 internal port，由于 containerd 要求 netNS 里有 eth0 网卡的存在，且 ovs 上 internal port 不能重名；所以需要创建 dummy eth0。

# ip netns exec cni-844e1dbe-0e5f-8b71-2406-f80c2c4a34da ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default 
    link/ether be:fb:34:4d:7f:7c brd ff:ff:ff:ff:ff:ff
    inet 172.10.0.45/16 brd 172.10.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd00:10:16::2d/64 scope global 
       valid_lft forever preferred_lft forever
81: cc1f5ac06321_c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 00:00:00:31:71:af brd ff:ff:ff:ff:ff:ff
    inet 172.10.0.45/16 brd 172.10.255.255 scope global cc1f5ac06321_c
       valid_lft forever preferred_lft forever
    inet6 fd00:10:16::2d/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::200:ff:fe31:71af/64 scope link 
       valid_lft forever preferred_lft forever
       

# ip netns exec cni-844e1dbe-0e5f-8b71-2406-f80c2c4a34da ethtool -i eth0
driver: dummy
version: 1.0
firmware-version: 
expansion-rom-version: 
bus-info: 
...
# ip netns exec cni-844e1dbe-0e5f-8b71-2406-f80c2c4a34da ethtool -i cc1f5ac06321_c
driver: openvswitch
version: 4.18.0-348.23.1.el8_5.x86_64
firmware-version: 
expansion-rom-version: 
bus-info: 
...

Kata 使用 netNS

简略介绍网络使用

Kata 是先通过不同 hypervisor 启动 VM，然后在 VM 中启动容器，那么就需要将 CNI 在 netNS 实现的网络功能全部复制到 VM 中。

像常见 CNI 的做法，都是为 pod 在 netNS 里创建 eth0 网卡提供网络服务。
即无论提供的是普通的 veth 还是物理设备（sriov），那么都需要 CNI 为 KATA 将网卡放到 namespace 里且命名为 eth0 等。

相对于 pod ，启动 VM，hypervisor 支持的网卡类型就十分有限了。通常我们使用 tap，包括 tuntap，macvtap；其他也支持 vfio-pci，和 vhost-user。

Kata 的实现

鉴于无法使用 veth-pair 作为 VM 的网卡 和 为了实现 VM 中的网络配置，Kata 做了如下实现。
首先介绍在 Kata 项目中实现的两层网络抽象。

网络抽象

kata 提供了两个 网络 抽象。
network interworking model 和 endpoint model

endpoint model

该网络抽象是定义一个为 Kata 提供网卡的设备。如 kubernetes cni 通常提供 veth-pair，ovs-dpdk 可以提供 vhost-user，ovs-offload 可以提供 vf 设备。通过该定义，提取 netNS 网络信息（网络信息包括网卡的 ip，mac，mtu，route等），通常该网络信息由 cni 来进行配置。

runtime 进程依次在 netNS 里遍历网络设备，过滤掉 lo 后进行处理。然后识别出网卡的类型，然后进行 Attach。

有七种类型，识别到类型后，生成对应的类型抽象接口，然后为接口实现对应的 Attach 功能。即为 KATA 准备网卡或网络设备：

• physical
  物理设备，第一个判断，如 sriov 网卡等，通过查询给到网卡的 BusInfo 信息来判断。Attach 的实现，将该网卡绑 vfio-pci 驱动，将该网卡当设备添加。
• macvlan
• mactap
• tuntap
• veth
  kubernetes 普通模式，需要 cni 在 netNS 创建 veth 一端，另一端在 ovs bridge 或 linux bridge上。Attach 的实现，通过下一个 network interworking model 抽象来决定如何在启动 qemu 时使用网卡。
• ipvlan
• vhost-user
  使用 vhost 当网卡，目前 kata 只粗略实现，无实际使用意义，硬编码一个地址，然后去查看是否有 socket 来进行判断；我们基于 kube-ovn ovs-dpdk 开发了自己的 vhost-user 模式，由于给到 hypervisor 的是一个 socket 文件，cni 无法传递网络信息给 hypervisor，我们就修改 CNI 在 netNS 里创建 dummy 网卡，该网卡只为了储存 CNI 分配的网络资源，然后 kata 启动时获取；所以，vhost-user 或 tap 直通 都是从 netNS 里 dummy 网卡获取 CNI 分配的资源。

像 cni 为 calico ipip 模式下，就无法为 kata 提供网络，因为 calico ipip 模式在 netNS 下创建 tunl0 网卡，是个 tunl driver 的网卡，无法识别，所以 kata 无法启动。

veth endpoint 此类 endpoint （包括 macvlan，macvtap，tap，ipvlan 等）都会创建 NetworkInterfacePair （defines a pair between VM and virtual network interfaces.）

type NetworkInterfacePair struct {
	TapInterface
	VirtIface NetworkInterface
	NetInterworkingModel
}

NetInterworkingModel 就是下一个抽象的选择
VirtIface 为 veth pair 在 netNS 里的网卡
TapInterface 为需要在 netNS 里创建的 tap 设备，供 qemu 等 hypervisor 启动时使用。

network interworking model

该 model 的选择是 kata 配置项，是 qemu 等 hypervisor 使用的网卡设备类型。
有三种类型:

• tcfilter

Uses tc filter rules to redirect traffic from the network interface provided by plugin to a tap interface connected to the VM.

本质是使用 tap 设备 （qemu 进程）
-netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 -device driver=virtio-net-pci,netdev=network-0,mac=00:00:00:b6:b7:37,disable-modern=true,mq=on,vectors=4

tcfilter 大致过程如下：
从上文的 TapInterface 在 netNS 创建 tap 设备(tapx_kata)，然后在 两个网卡之间设置 tcfilter。

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: tap0_kata: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN group default qlen 1000
    link/ether 96:36:cd:da:e3:07 brd ff:ff:ff:ff:ff:ff
49: eth0@if50: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:00:b6:b7:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.10.0.16/16 brd 172.10.255.255 scope global eth0
       valid_lft forever preferred_lft forever

• macvtap

Used when the Container network interface can be bridged using macvtap

本质是使用 macvtap 设备 （qemu 进程）
-netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 -device driver=virtio-net-pci,netdev=network-0,mac=00:00:00:5e:99:3e,disable-modern=true,mq=on,vectors=4
macvtap 大致过程如下：
从上文的 TapInterface 在 netNS eth0 上创建 macvtap 设备(tapx_kata)，将 veth 设备的 mac 配置到新的 macvtap 上.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
43: eth0@if44: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 72:5d:00:a2:b8:47 brd ff:ff:ff:ff:ff:ff link-netnsid 0
52314: tap0_kata@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1500
    link/ether 00:00:00:5e:99:3e brd ff:ff:ff:ff:ff:ff

• none

Used when customize network. Only creates a tap device. No veth pair.

do nothing.

可以看到 qemu 使用 tap 启动

补充

physical

-netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 -device driver=virtio-net-pci,netdev=network-0,mac=00:00:00:34:e7:67,disable-modern=false,mq=on,vectors=4 -device vfio-pci,host=af:00.4,bus=rp0

vhost-user

-chardev socket,id=char-c8d20b1ce6cf9432,path=/var/run/openvswitch/vhost_sockets/e5b31efb-b8d4-4344-8b38-5aa8b80de679/vhostuser-sockets/eth0,server=on -netdev type=vhost-user,id=net-c8d20b1ce6cf9432,chardev=char-c8d20b1ce6cf9432,queues=2,vhostforce