14.2. 从 OpenShift SDN 集群网络供应商迁移

作为集群管理员，您可以从 OpenShift SDN CNI 集群网络供应商迁移到 OVN-Kubernetes Container Network Interface (CNI) 集群网络供应商。

要了解更多有关 OVN-Kubernetes 的信息，请参阅关于 OVN-Kubernetes 网络供应商。

14.2.1. 迁移到 OVN-Kubernetes 网络供应商

迁移到 OVN-Kubernetes Container Network Interface（CNI）默认网络供应商是一个手动过程，其中会包括一些停机时间使集群无法访问。虽然提供了一个回滚过程，但迁移通常被认为是一个单向过程。

注意

迁移至 OVN-Kubernetes 网络供应商仅在裸机硬件的安装程序置备的集群中支持。

不支持在裸机硬件的用户置备的集群上执行迁移。

14.2.1.1. 迁移到 OVN-Kubernetes 网络供应商时的注意事项

迁移过程中不会保留分配给节点的子网以及分配给各个 pod 的 IP 地址。

虽然 OVN-Kubernetes 网络供应商实现了 OpenShift SDN 网络供应商中的许多功能，但配置并不相同。

  • 如果您的集群使用以下 OpenShift SDN 功能，则必须在 OVN-Kubernetes 中手动配置相同的功能：

    • 命名空间隔离
    • 出口 IP 地址
    • 出口网络策略
    • 出口路由器 pod
    • 多播
  • 如果您的集群使用 100.64.0.0/16 IP 地址范围中的任何部分，则无法迁移到 OVN-Kubernetes，因为它在内部使用这个 IP 地址范围。

以下小节重点介绍了上述功能在 OVN-Kubernetes 和 OpenShift SDN 中的配置的不同。

命名空间隔离

OVN-Kubernetes 仅支持网络策略隔离模式。

重要

如果您的集群使用在多租户或子网隔离模式中配置的 OpenShift SDN，则无法迁移到 OVN-Kubernetes 网络供应商。

出口 IP 地址

下表中描述了在 OVN-Kubernetes 和 OpenShift SDN 配置出口 IP 地址的不同：

表 14.2. 出口 IP 地址配置的不同

OVN-KubernetesOpenShift SDN
  • 创建 EgressIPs 对象
  • 在一个 Node 对象上添加注解
  • 对 NetNamespace 对象进行补丁
  • 对 HostSubnet 对象进行补丁

有关在 OVN-Kubernetes 中使用出口 IP 地址的更多信息，请参阅"配置出口 IP 地址"。

出口网络策略

下表中描述在 OVN-Kubernetes 和 OpenShift SDN 间配置出口网络策略（也称为出口防火墙）的不同之处：

表 14.3. 出口网络策略配置的不同

OVN-KubernetesOpenShift SDN
  • 在命名空间中创建 EgressFirewall 对象
  • 在命名空间中创建一个 EgressNetworkPolicy 对象

有关在 OVN-Kubernetes 中使用出口防火墙的更多信息，请参阅"配置项目出口防火墙"。

出口路由器 pod

OVN-Kubernetes 不支持在 OpenShift Container Platform 4.6 中使用出口路由器 Pod。

多播

下表中描述了在 OVN-Kubernetes 和 OpenShift SDN 上启用多播流量的区别：

表 14.4. 多播配置的不同

OVN-KubernetesOpenShift SDN
  • 在 Namespace 对象上添加注解
  • 在 NetNamespace 对象中添加注解

有关在 OVN-Kubernetes 中使用多播的更多信息，请参阅"启用项目多播"。

网络策略

OVN-Kubernetes 在 networking.k8s.io/v1 API 组中完全支持 Kubernetes NetworkPolicy API。从 OpenShift SDN 进行迁移时，网络策略不需要更改。

14.2.1.2. 迁移过程如何工作

迁移过程按如下方式工作：

  1. 在 Cluster Network Operator（CNO）配置对象上设置一个临时注解。此注解会触发 CNO 来监视 defaultNetwork 字段的变化。
  2. 挂起 Machine Config Operator（MCO）以确保它不会中断迁移。
  3. 更新 defaultNetwork 字段。更新会导致 CNO 销毁 OpenShift SDN control plane pod 并部署 OVN-Kubernetes control plane pod。另外，它会更新 Multus 对象以反映新的集群网络供应商。
  4. 重新引导集群中的每个节点。由于集群中的现有 pod 不知道集群网络供应商的更改，因此重新引导每个节点可确保每个节点排空 pod。新的 pod 附加到 OVN-Kubernetes 提供的新集群网络中。
  5. 在集群重启中的所有节点后启用 MCO。MCO 向完成迁移所需的 systemd 配置推出更新。MCO 默认更新每个池的单个机器，因此迁移总时间随着集群的大小增加而增加。