实践案例 | 基于天翼云边缘计算场景，Kube-OVN社区最新拓展特性一览

作者：范日明，中国电信天翼云边缘计算高级研发工程师Kube-OVN Committer

随着社区贡献者和用户体量的不断增加，有越来越多新的需求和新的使用场景不断被挖掘出来，社区贡献者也为 Kube-OVN 实现了很多比较重和复杂的功能，其中电信天翼云边缘云团队功不可没。

在 All-in-K8s 后，电信天翼云团队正借助 Kube-OVN 搭建云原生网络架构。作为社区核心贡献者，Kube-OVN Committer，范日明详细分享了半年来，基于天翼云边缘计算场景，拓展的如访问控制、高可用虚拟IP、热迁移、智能网卡硬件卸载等，Kube-OVN 新的硬核特性。

一、访问控制:安全组

在访问控制方面，K8s 提供了 NetworkPolicy 的解决方案，最初天翼云边缘云也考虑过直接使用原生的 Network Policy 来做边缘云的访问控制，最终放弃，理由如下:1、边缘云产品定位是 IaaS，只不过在集成方案上采用了 K8s 云原生的方式，用户在 IaaS 上使用云主机依然延续公有云的使用习惯， 而不会理解 Network Policy 这个来自 K8s 的概念;2、Network Policy 的控制粒度和策略不够丰富，例如缺少 ICMP 类型匹配、防 ARP 欺骗、防 DHCP 欺骗、规则优先级等;3、在 IaaS 中，安全组功能已经深入人心，但无法在 Network Policy 基础上包装出同样的功能。于是我们决定拓展一套安全组功能。

最初我们在 Kubevirt 的基础上为虚机做了安全组，借鉴早期 OpenStack 安全组的实现方式，安全组规则使用 iptables 实现。这套方案使用也不错，支撑了很长一段时间，但依然存在局限，原因:1、只能为虚机提供安全组能力，容器实例没有;2、接入智能网卡硬件卸载后，网络包不经过内核，iptables 方案也就无法使用了。

后来，我们改成 OVS CT 流表的方式来做，并在 Kube-OVN 实现对应的 CRD 控制，参考 PR 链接  https://github.com/kubeovn/kube-ovn/pull/932，中文 wiki https://github.com/fanriming/kube-ovn/wiki/%E5%AE%89%E5%85%A8%E7%BB%84功能上可以做到和 OpenStack 一致，能同时支持容器和虚机，也支持智能网卡流表卸载。

二、高可用虚拟IP

说到高可用，在 K8s 世界里，应用可以基于 Service 代理后端多个实例、配合健康检查实现应用 HA，客户端与 ClusterIP 打交道。但这种云原生的方案并不能满足传统架构场景，典型的例子是 vCDN 虚机的大带宽场景，通常会采用 DR 模式的 LB 来提供服务；另外一种场景，是用户希望结合 keepalived 这样的高可用软件，自主管理基础组件的。这两种传统的架构都需要虚拟IP来配合。那客户需要用 VIP，给他分一个就可以了，又有什么需要拓展的呢？在公有云上，VIP 不是配上去就能用的。公有云出于安全考虑(如 ARP 欺骗、IP 地址篡改等)，只能使用平台分配的 IP 和 MAC 地址，VIP 需要由平台分配并绑定到网卡上才允许网络包通过。在 Kube-OVN 中也提供了这个 特性，当开启 port_security 特性时，容器只能使用 ipam 分配的地址，如果认为修改了网络包的 IP 地址则一律 drop 掉。在安全的基础上，我们增加了 VIP 的特性支持。https://github.com/kubeovn/kube-ovn/pull/1036 

使用方式非常简单，首先我们要在 subnet 资源中通过 excludeIps 字段预占 ip 地址，然后再把预占的 ip 地址通过 pod annotation 绑定到你希望分配的 pod 网卡上:

如果要回收或者 vip 也是可以的，因为 vip 的 annotation 支持动态更新。

三、热迁移

虚机热迁移在 IaaS 中是基本功能，Kubevirt 也支持，但受限于常规 CNI 的架构，对网络的适配还做不到和 OpenStack 一致的体验。我们对于热迁移在网络层面的期望是，虚机网络配置不变(固定 mac 和 ip)，网络通信不中断。

• Kubevirt 官方文档描述了热迁移对网络的要求:Live migration is not allowed with a pod network binding of bridge interface type. 

• Live migration requires ports 49152, 49153 to be available in the virt-launcher pod. If these ports are explicitly specified in masquarade interface, live migration will not function. 

仔细分析下这两个限制条件的原因是什么？因为 kubevirt 虚机在热迁移时使用 pod 的默认网络来做数据同步，为了避免和虚机业务网络冲突而给设的限制。那如果我们把管理网络和业务网络区分开，就可以不受这个限制，所以采取的方案是保留 pod 默认网卡用于热迁移， 虚机业务网口统一以 multus-cni 附加网卡方式添加。

另外我们还需要解决地址冲突、默认路由配置、网络不中断的一些问题，现在这些都能通过 Kube-OVN 得到支持。 https://github.com/kubeovn/kube-ovn/pull/1001 

具体配置参考示例如下:

这个 yaml 需要注意的的几个点:1、业务网卡使用 multus 方式配置，保留 pod 默认网络用于热迁移数据传输;2、如果需要为 vm 分配固定 ip，可以使用..ovn.kubernetes.io/allow_live_migration 注解避免 ip 冲突错误;

3、如果使用 kubevirt dhcp 配置 vm 网络，需要解决默认路由的问题，我们可以通过 “..ovn.kubernetes.io/default_route” 注解选择默认路由网卡。

四、智能网卡硬件卸载

相比中心云，边缘云的主要优势是网络，对网络性能也有更高的要求。

以往对于这种有极致网络性能要求的业务，通常会使用 vf/pf 网卡直通的方案，这样能够满足网络性能的需求，但却没有 SDN 的能力，同时监控和计费等也变得更复杂了。我们想寻求一种既能满足极致性能、又具有 SDN 能力的方案，于是决定集成智能网卡来解决。

Kube-OVN 在很早的版本就已经支持 Mellanox CX5 网卡的 offload，性能上能达到千万级别的 PPS，非常理想。但在做方案集成的时候，发现并不是一蹴而就，我们遇到的主要问题和解决思路有以下几点:1、需要在 ovs 2.14 以下的版本才能正常硬件卸载，Kube-OVN 在 v1.6 以后的版本已经升级到 2.15，所以需要对底层 ovn 和 ovs 的版本重新适配，我们的方案中采用了 ovn 20.06 + ovs 2.14 的组合适配;2、并不是所有的流表都能卸载，如 Kube-OVN 中默认开启了 lb 特性来做容器网络访问 service 的路径，lb 特性在底层使用了 dp_hash 流表，而 CX5 并不支持 dp_hash 的卸载，为了解决这个问题，我们给 lb 特性加了个开关 enalbe-lb=false;3、NetworkPolicy 和安全组功能使用了 ct 有状态的流表，需要使用较新的版本内核和驱动才能实现卸载，我们的测试环境是 linux 5.12 内核(当时 lts 版本还未发布) + MLNX_OFED_LINUX-5.4-1.0.3.0 驱动;4、虚机使用 vf 区别于容器，需要增加 vf vfio-pci 驱动的适配，我们为虚机对应的 Network Attachment Definition 增加了 vf_driver: vfio-pci 字段，Kube-OVN CNI 会对 vfio-pci 驱动的 vf 做对应预处理，而 Kubevirt 只需按照常规配置 sr-iov 方式接入。

经过这些适配，基本上能够把智能网卡 + Kube-OVN + Kubevirt 这一套集成起来了，也已经能满足常规的 SDN 和高性能场景。

以上是电信天翼云边缘计算团队，去年相对重要的几个工作。2022 年，团队也计划在 Kube-OVN 的基础上发展出更丰富、更优质的网络能力，期待未来再次和大家分享！