当CNI遇上Kata-KataNative的CNI扩展

Posted 2021-06-28 rayylee

Kata Native 的 CNI 扩展

背景

CNI 是 kubernetes 上为容器配置网络的通用接口。kubernetes 社区有很多 CNI 网络插件的实现。kube-ovn 就是一个把基于 OVN 的网络虚拟化集成到 kubernetes 中的 CNI 实现。

通常情况下，kubernetes CNI 提供给容器运行时的网络都是一个本地的 network namespace，里面包含一个 veth 设备。虽然这个 veth 设备可以直接为传统的 runc 容器提供网络连接能力，却不能被基于虚拟化技术的容器运行时（如 Kata Containers）直接使用。为了兼容 CNI 的实现，Kata Containers 会在容器的 network namespace 中创建一个 tap 设备，并使用 TC mirroring 规则来连通 veth 和 tap 设备，如下图所示。

这样的网络架构保证了 Kata Containers 对广泛的 CNI 实现的兼容性，却也带来了明显的开销。每个网络包需要多次协议栈转跳才能抵达应用。幸好，这个网络数据链路是可以优化的。

CNI 优化方案

我们观察到，在上面的网络架构中，Kata 其实只需要一个 tap 设备而并不在意这个 tap 设备是如何创建并连接到外部网络的。基于这点，我们可以把这个 tap 设备作为 pod 网络配置的入口点，让 CNI 负责在宿主机上创建并配置 tap 设备，从而让去掉宿主机上的 network namespace 和 veth 网卡对成为可能。如下图所示。

这样的网络架构中，Kata Containers 并不在意 tap 设备是如何创建的，所以 CNI 可以选择舍弃或者保留宿主机上的 network namespace，但 veth 网卡对不再是必须的，同时CNI 的网络实现细节仍然对 Kata Containers 透明。

换成流程图大概就是

我们对这个新的网络架构有两个期待：

• 去掉 veth 网卡对以及 veth 和 tap 设备之间的网络包跳转，降低 Kata 容器的网络延迟
• 扩展 CNI 接口让 CNI 能够配置实现更高性能的网络设备连通，比如 VFIO 和 vhost-user 设备

通过现场对方案的交流，我们在 Kata 社区和 kube-ovn 社区分别创建了 issue 来跟踪这一改进。有兴趣的同学可以到 issue 中查看最新进展。

• https://github.com/kubeovn/kube-ovn/issues/837
• https://github.com/kata-containers/kata-containers/issues/1922

参考:
开源黑客松：当 CNI 遇上 Kata