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 默认更新每个池的单个机器,因此迁移总时间随着集群的大小增加而增加。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.