搜索

26.5. 从 OpenShift SDN 网络插件迁移

download PDF

作为集群管理员,您可以使用 离线 迁移方法或有限的实时迁移方法从 OpenShift SDN 网络插件迁移到 OVN-Kubernetes 网络插件。

要了解更多有关 OVN-Kubernetes 的信息,请参阅关于 OVN-Kubernetes 网络插件

26.5.1. 离线迁移到 OVN-Kubernetes 网络插件概述

离线迁移方法是一个手动过程,其中包括一些停机时间,在此期间集群无法访问。此方法主要用于自我管理的 OpenShift Container Platform 部署。

虽然提供了一个回滚过程,但离线迁移通常被认为是一个单向过程。

注意

从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。

以下小节提供了有关离线迁移方法的更多信息。

26.5.1.1. 使用离线迁移方法时支持的平台

下表提供了有关离线迁移类型的支持的平台信息。

表 26.4. 离线迁移方法支持的平台
平台离线迁移

裸机硬件 (IPI 和 UPI)

Amazon Web Services (AWS) (IPI 和 UPI)

Google Cloud Platform (GCP) (IPI 和 UPI)

IBM Cloud® (IPI and UPI)

Microsoft Azure (IPI 和 UPI)

Red Hat OpenStack Platform (RHOSP) (IPI 和 UPI)

VMware vSphere (IPI 和 UPI)

AliCloud (IPI 和 UPI)

Nutanix (IPI 和 UPI)

26.5.1.2. 离线迁移到 OVN-Kubernetes 网络插件的注意事项

如果您在 OpenShift Container Platform 集群中有超过 150 个节点,请创建一个支持问题单,供您迁移到 OVN-Kubernetes 网络插件。

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

虽然 OVN-Kubernetes 网络插件实现 OpenShift SDN 网络插件中存在的许多功能,但配置并不相同。

  • 如果您的集群使用以下 OpenShift SDN 网络插件功能,您必须在 OVN-Kubernetes 网络插件中手动配置相同的功能:

    • 命名空间隔离
    • 出口路由器 pod
  • OVN-Kubernetes 是 OpenShift Container Platform 4.14 及之后的版本中的默认网络供应商,在内部使用以下 IP 地址范围:100.64.0.0/16, 169.254.169.0/29, 100.88.0.0/16, fd98::/64, fd69::/125, 和 fd97::/64。如果您的集群使用 OVN-Kubernetes,请不要在集群或基础架构中的任何其他 CIDR 定义中包含这些 IP 地址范围。

以下小节重点介绍了上述功能在 OVN-Kubernetes 和 OpenShift SDN 网络插件中的配置差异。

命名空间隔离

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

重要

对于使用在多租户或子网隔离模式下配置的 OpenShift SDN 的集群,您仍然可以迁移到 OVN-Kubernetes 网络插件。请注意,在迁移操作后,多租户隔离模式会被丢弃,因此您必须手动配置网络策略,以便为 Pod 和服务达到相同的项目级别的隔离。

出口 IP 地址

OpenShift SDN 支持两种不同的 Egress IP 模式:

  • 自动分配方法中,给节点分配一个出口 IP 地址范围。
  • 手动分配方法中,给节点分配包含一个或多个出口 IP 地址的列表。

迁移过程支持迁移使用自动分配模式的 Egress IP 配置。

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

表 26.5. 出口 IP 地址配置的不同
OVN-KubernetesOpenShift SDN
  • 创建 EgressIPs 对象
  • 在一个 Node 对象上添加注解
  • NetNamespace 对象进行补丁
  • HostSubnet 对象进行补丁

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

出口网络策略

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

表 26.6. 出口网络策略配置的不同
OVN-KubernetesOpenShift SDN
  • 在命名空间中创建 EgressFirewall 对象
  • 在命名空间中创建一个 EgressNetworkPolicy 对象
注意

由于 EgressFirewall 对象的名称只能设置为 default,在迁移后,所有迁移的 EgressNetworkPolicy 对象都会命名为 default,而无论在 OpenShift SDN 下的名称是什么。

如果您随后回滚到 OpenShift SDN,则所有 EgressNetworkPolicy 对象都会命名为 default,因为之前的名称已丢失。

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

出口路由器 pod

OVN-Kubernetes 支持重定向模式的出口路由器 pod。OVN-Kubernetes 不支持 HTTP 代理模式或 DNS 代理模式的出口路由器 pod。

使用 Cluster Network Operator 部署出口路由器时,您无法指定节点选择器来控制用于托管出口路由器 pod 的节点。

多播

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

表 26.7. 多播配置的不同
OVN-KubernetesOpenShift SDN
  • Namespace 对象上添加注解
  • NetNamespace 对象中添加注解

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

网络策略

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

26.5.1.3. 离线迁移过程如何工作

下表对迁移过程进行了概述,它分为操作中的用户发起的步骤,以及在响应过程中迁移过程要执行的操作。

表 26.8. 从 OpenShift SDN 离线迁移到 OVN-Kubernetes
用户发起的步骤迁移操作

将名为 clusterNetwork.operator.openshift.io 自定义资源(CR)的 migration 字段设置为 OVNKubernetes。在设置值之前,请确保 migration 项为 null

Cluster Network Operator (CNO)
相应地更新名为 clusterNetwork.config.openshift.io CR 的状态。
Machine Config Operator(MCO)
将更新发布到 OVN-Kubernetes 所需的 systemd 配置 ; MCO 默认更新每个池的单一机器,从而导致迁移总时间随着集群大小而增加。

更新 Network.config.openshift.io CR 的 networkType 字段。

CNO

执行以下操作:

  • 销毁 OpenShift SDN control plane pod。
  • 部署 OVN-Kubernetes control plane pod。
  • 更新 Multus 守护进程集和配置映射对象,以反映新的网络插件。

重新引导集群中的每个节点。

Cluster
当节点重启时,集群会为 OVN-Kubernetes 集群网络上的 pod 分配 IP 地址。

26.5.1.4. 使用离线迁移方法迁移到 OVN-Kubernetes 网络插件

作为集群管理员,您可以将集群的网络插件更改为 OVN-Kubernetes。在迁移过程中,您必须重新引导集群中的每个节点。

重要

在进行迁移时,集群不可用,工作负载可能会中断。仅在服务中断可以接受时才执行迁移。

先决条件

  • 在网络策略隔离模式中使用 OpenShift SDN CNI 网络插件配置集群。
  • 安装 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 角色的用户访问集群。
  • etcd 数据库的最新备份可用。
  • 可根据每个节点手动触发重新引导。
  • 集群处于已知良好状态,没有任何错误。
  • 在迁移到 OVN-Kubernetes 之前,必须有一条安全组规则,以允许所有云平台上所有节点的 UDP 数据包在端口 6081 上。

流程

  1. 要备份集群网络的配置,请输入以下命令:

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
  2. 要为迁移准备所有节点,请输入以下命令在 Cluster Network Operator 配置对象上设置 migration 字段:

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
    注意

    此步骤不会立即部署 OVN-Kubernetes。相反,指定 migration 字段会触发 Machine Config Operator(MCO)将新机器配置应用到集群中的所有节点,以准备 OVN-Kubernetes 部署。

  3. 可选:您可以禁用将几个 OpenShift SDN 功能自动迁移到 OVN-Kubernetes 等效功能:

    • 出口 IP
    • 出口防火墙
    • 多播

    要为之前记录的 OpenShift SDN 功能禁用配置自动迁移,请指定以下键:

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{
        "spec": {
          "migration": {
            "networkType": "OVNKubernetes",
            "features": {
              "egressIP": <bool>,
              "egressFirewall": <bool>,
              "multicast": <bool>
            }
          }
        }
      }'

    其中:

    bool:指定是否启用功能的迁移。默认值是 true

  4. 可选: 您可以自定义 OVN-Kubernetes 的以下设置,以满足您的网络基础架构要求:

    • 最大传输单元 (MTU)。在为这个可选步骤自定义 MTU 前请考虑以下几点:

      • 如果您使用默认 MTU,并且要在迁移期间保留默认 MTU,则可以忽略这一步。
      • 如果您使用自定义 MTU,并且要在迁移过程中保留自定义 MTU,则必须在此步骤中声明自定义 MTU 值。
      • 如果要在迁移过程中更改 MTU 值,此步骤将无法正常工作。相反,您必须首先按照"选择集群 MTU"的说明进行操作。然后,您可以通过执行此步骤并声明自定义 MTU 值来保留自定义 MTU 值。

        注意

        OpenShift-SDN 和 OVN-Kubernetes 具有不同的覆盖(overlay)开销。MTU 值应遵循在 "MTU 值选择" 页面中找到的准则来选择。

    • Geneve(Generic Network Virtualization Encapsulation)覆盖网络端口
    • OVN-Kubernetes IPv4 内部子网
    • OVN-Kubernetes IPv6 内部子网

    要自定义之前记录的设置之一,请输入以下命令。如果您不需要更改默认值,请从补丁中省略该键。

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>,
              "v4InternalSubnet":"<ipv4_subnet>",
              "v6InternalSubnet":"<ipv6_subnet>"
        }}}}'

    其中:

    mtu
    Geneve 覆盖网络的 MTU。这个值通常是自动配置的;但是,如果集群中的节点没有都使用相同的 MTU,那么您必须将此值明确设置为比最小节点 MTU 的值小 100
    port
    Geneve 覆盖网络的 UDP 端口。如果没有指定值,则默认为 6081。端口不能与 OpenShift SDN 使用的 VXLAN 端口相同。VXLAN 端口的默认值为 4789
    ipv4_subnet
    OVN-Kubernetes 内部使用的 IPv4 地址范围。您必须确保 IP 地址范围没有与 OpenShift Container Platform 安装使用的任何其他子网重叠。IP 地址范围必须大于可添加到集群的最大节点数。默认值为 100.64.0.0/16
    ipv6_subnet
    OVN-Kubernetes 内部使用的 IPv6 地址范围。您必须确保 IP 地址范围没有与 OpenShift Container Platform 安装使用的任何其他子网重叠。IP 地址范围必须大于可添加到集群的最大节点数。默认值为 fd98::/48

    更新 mtu 字段的 patch 命令示例

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'

  5. 当 MCO 更新每个机器配置池中的机器时,它会逐一重启每个节点。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态:

    $ oc get mcp

    成功更新的节点具有以下状态: UPDATED=trueUPDATING=falseDEGRADED=false

    注意

    默认情况下,MCO 会一次在一个池中更新一个机器,从而导致迁移总时间随着集群大小的增加而增加。

  6. 确认主机上新机器配置的状态:

    1. 要列出机器配置状态和应用的机器配置名称,请输入以下命令:

      $ oc describe node | egrep "hostname|machineconfig"

      输出示例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      验证以下语句是否正确:

      • machineconfiguration.openshift.io/state 字段的值为 Done
      • machineconfiguration.openshift.io/currentConfig 字段的值等于 machineconfiguration.openshift.io/desiredConfig 字段的值。
    2. 要确认机器配置正确,请输入以下命令:

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      这里的 <config_name>machineconfiguration.openshift.io/currentConfig 字段中机器配置的名称。

      机器配置必须包括以下对 systemd 配置的更新:

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
    3. 如果节点一直处于 NotReady 状态,检查机器配置守护进程 pod 日志并解决所有错误。

      1. 运行以下命令列出 pod:

        $ oc get pod -n openshift-machine-config-operator

        输出示例

        NAME                                         READY   STATUS    RESTARTS   AGE
        machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
        machine-config-daemon-5cf4b                  2/2     Running   0          43h
        machine-config-daemon-7wzcd                  2/2     Running   0          43h
        machine-config-daemon-fc946                  2/2     Running   0          43h
        machine-config-daemon-g2v28                  2/2     Running   0          43h
        machine-config-daemon-gcl4f                  2/2     Running   0          43h
        machine-config-daemon-l5tnv                  2/2     Running   0          43h
        machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
        machine-config-server-bsc8h                  1/1     Running   0          43h
        machine-config-server-hklrm                  1/1     Running   0          43h
        machine-config-server-k9rtx                  1/1     Running   0          43h

        配置守护进程 pod 的名称使用以下格式: machine-config-daemon-<seq><seq> 值是一个随机的五个字符的字母数字序列。

      2. 使用以下命令,输出在上一个输出中显示的第一个机器配置守护进程 pod 的 pod 日志:

        $ oc logs <pod> -n openshift-machine-config-operator

        其中 pod 是机器配置守护进程 pod 的名称。

      3. 解决上一命令输出中显示的日志中的任何错误。
  7. 要启动迁移,请使用以下命令配置 OVN-Kubernetes 网络插件:

    • 要指定网络供应商而不更改集群网络 IP 地址块,请输入以下命令:

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
    • 要指定不同的集群网络 IP 地址块,请输入以下命令:

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": <prefix>
              }
            ],
            "networkType": "OVNKubernetes"
          }
        }'

      其中 cidr 是 CIDR 块,prefix 是集群中每个节点的 CIDR 块的分片。您不能使用任何与 10064.0.0/16 CIDR 块重叠的 CIDR 块,因为 OVN-Kubernetes 网络供应商在内部使用此块。

      重要

      您无法在迁移过程中更改服务网络地址块。

  8. 在继续执行后续步骤前,验证 Multus 守护进程集的 rollout 是否已完成:

    $ oc -n openshift-multus rollout status daemonset/multus

    Multus pod 的名称采用 multus-<xxxxx> 的形式,其中 <xxxxx>是由字母组成的随机序列。pod 可能需要一些时间才能重启。

    输出示例

    Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
    ...
    Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
    daemon set "multus" successfully rolled out

  9. 要完成更改网络插件,请重新引导集群中的每个节点。您可以使用以下方法之一重新引导集群中的节点:

    重要

    以下脚本同时重新引导集群中的所有节点。这可能导致集群不稳定。另一种选择是一次手动重新引导节点。逐一重新引导节点会导致在具有多个节点的群集中出现大量停机时间。

    • 使用 oc rsh 命令,您可以使用类似如下的 bash 脚本:

      #!/bin/bash
      readarray -t POD_NODES <<< "$(oc get pod -n openshift-machine-config-operator -o wide| grep daemon|awk '{print $1" "$7}')"
      
      for i in "${POD_NODES[@]}"
      do
        read -r POD NODE <<< "$i"
        until oc rsh -n openshift-machine-config-operator "$POD" chroot /rootfs shutdown -r +1
          do
            echo "cannot reboot node $NODE, retry" && sleep 3
          done
      done
    • 通过 ssh 命令,您可以使用类似如下的 bash 脚本:该脚本假设您已将 sudo 配置为不提示输入密码。

      #!/bin/bash
      
      for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
      do
         echo "reboot node $ip"
         ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
      done
  10. 确认迁移成功完成:

    1. 要确认网络插件是 OVN-Kubernetes,请输入以下命令。status.networkType 的值必须是 OVNKubernetes

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
    2. 要确认集群节点处于 Ready 状态,请输入以下命令:

      $ oc get nodes
    3. 要确认您的 pod 不在错误状态,请输入以下命令:

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'

      如果节点上的 pod 处于错误状态,请重新引导该节点。

    4. 要确认所有集群 Operator 没有处于异常状态,请输入以下命令:

      $ oc get co

      每个集群 Operator 的状态必须是: AVAILABLE="True"PROGRESSING="False"DEGRADED="False"。如果 Cluster Operator 不可用或降级,请检查集群 Operator 的日志以了解更多信息。

  11. 只有在迁移成功且集群处于良好状态时完成以下步骤:

    1. 要从 CNO 配置对象中删除迁移配置,请输入以下命令:

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
    2. 要删除 OpenShift SDN 网络供应商的自定义配置,请输入以下命令:

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
    3. 要删除 OpenShift SDN 网络供应商命名空间,请输入以下命令:

      $ oc delete namespace openshift-sdn

26.5.2. 有限实时迁移到 OVN-Kubernetes 网络插件概述

有限的实时迁移方法是在不中断服务的情况下将 OpenShift SDN 网络插件及其网络配置、连接和相关资源迁移到 OVN-Kubernetes 网络插件的过程。它可用于 OpenShift Container Platform、Red Hat OpenShift Dedicated、Red Hat OpenShift Service on AWS 和 Azure Red Hat OpenShift 部署类型。它不适用于 HyperShift 部署类型。这个迁移方法对于需要持续服务可用性的部署类型非常重要,并具有以下优点:

  • 持续服务可用性
  • 最小化停机时间
  • 自动节点重新引导
  • 从 OpenShift SDN 网络插件无缝过渡到 OVN-Kubernetes 网络插件

虽然提供了一个回滚过程,但有限的实时迁移通常被认为是一个单向过程。

注意

从 OpenShift Container Platform 4.14 开始,OpenShift SDN CNI 已被弃用。自 OpenShift Container Platform 4.15 起,网络插件不是新安装的选项。在以后的发行版本中,计划删除 OpenShift SDN 网络插件,并不再被支持。红帽将在删除前对这个功能提供程序错误修正和支持,但不会再改进这个功能。作为 OpenShift SDN CNI 的替代选择,您可以使用 OVN Kubernetes CNI。

以下小节提供了有关有限实时迁移方法的更多信息。

26.5.2.1. 使用有限实时迁移方法时支持的平台

下表提供了有关有限实时迁移类型的支持的平台信息。

表 26.9. 有限实时迁移方法支持的平台
平台有限实时迁移

裸机硬件 (IPI 和 UPI)

Amazon Web Services (AWS) (IPI 和 UPI)

Google Cloud Platform (GCP) (IPI 和 UPI)

IBM Cloud® (IPI and UPI)

Microsoft Azure (IPI 和 UPI)

Red Hat OpenStack Platform (RHOSP) (IPI 和 UPI)

VMware vSphere (IPI 和 UPI)

AliCloud (IPI 和 UPI)

Nutanix (IPI 和 UPI)

26.5.2.2. 有限实时迁移到 OVN-Kubernetes 网络插件的注意事项

在使用有限实时迁移方法到 OVN-Kubernetes 网络插件之前,集群管理员应考虑以下信息:

  • 启用 OpenShift SDN 多租户模式的集群不支持有限的实时迁移步骤。
  • 出口路由器 pod 会阻止有限的实时迁移过程。在开始有限的实时迁移过程前,必须删除它们。
  • 在有限的实时迁移过程中,会临时禁用多播、多播、出口 IP 地址和出口防火墙。在有限实时迁移过程完成后,可以从 OpenShift SDN 迁移到 OVN-Kubernetes。
  • 迁移旨在成为单向过程。但是,对于希望回滚到 OpenShift-SDN 的用户,从 OpenShift-SDN 迁移到 OVN-Kubernetes 必须已成功。用户可以按照以下步骤从 OVN-Kubernetes 网络插件迁移到 OpenShift SDN 网络插件。
  • HyperShift 集群中不支持有限的实时迁移。
  • OpenShift SDN 不支持 IPsec。迁移后,集群管理员可以启用 IPsec。
  • OpenShift SDN 不支持 IPv6。迁移后,集群管理员可以启用双栈。
  • 集群 MTU 是 pod 接口的 MTU 值。它始终小于硬件 MTU,以考虑集群网络覆盖开销。OVN-Kubernetes 的开销为 100 字节,OpenShift SDN 是 50 字节。

    在有限的实时迁移过程中,OVN-Kubernetes 和 OpenShift SDN 并行运行。OVN-Kubernetes 管理某些节点的集群网络,而 OpenShift SDN 管理其他用户的集群网络。为确保跨 CNI 流量保持正常工作,Cluster Network Operator 会更新可路由的 MTU,以确保两个 CNI 共享相同的覆盖 MTU。因此,在迁移完成后,集群 MTU 小于 50 字节。

  • 安装后无法更改 OVN-Kubernetes 的一些参数。只有启动有限的实时迁移前才能设置以下参数:

    • InternalTransitSwitchSubnet
    • internalJoinSubnet
  • OVN-Kubernetes 会保留 100.64.0.0/16100.88.0.0/16 IP 地址范围。如果 OpenShift SDN 被配置为使用这些 IP 地址范围之一,您必须在启动有限的实时迁移前将它们进行补丁为使用不同的 IP 地址范围。

    • 100.64.0.0/16.默认情况下,此 IP 地址范围用于 OVN-Kubernetes 的 internalJoinSubnet 参数。如果这个 IP 地址范围已经在使用中,输入以下命令将其更新至不同的范围,例如 100.63.0.0/16

      $ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalJoinSubnet": "100.63.0.0/16"}}}}}'
    • 100.88.0.0/16.默认情况下,此 IP 地址范围用于 OVN-Kubernetes 的 internalTransSwitchSubnet 参数。如果这个 IP 地址范围已经在使用中,输入以下命令将其更新至不同的范围,例如 100.99.0.0/16

      $ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalTransitSwitchSubnet": "100.99.0.0/16"}}}}}'
  • 在大多数情况下,有限的实时迁移独立于 Multus CNI 插件创建的 pod 的二级接口。但是,如果这些二级接口在主机的默认网络接口控制器 (NIC) 上设置,例如,使用 MACVLAN、IPVLAN、SR-IOV 或桥接接口作为控制节点,则 OVN-Kubernetes 可能会遇到故障。在继续有限的实时迁移前,用户应删除此配置。
  • 当主机中存在多个 NIC 时,且默认路由不在具有 Kubernetes NodeIP 的接口上,则必须使用离线迁移。
  • 在启动有限实时迁移前,必须删除 openshift-sdn 命名空间中的所有 DaemonSet 对象(不受 Cluster Network Operator (CNO) 管理。这些非受管守护进程集可能会导致迁移状态在未正确处理时保持不完整。

26.5.2.3. 实时迁移过程如何工作

下表总结了实时迁移过程,具体是流程中用户发起的步骤与迁移脚本在响应中执行的操作之间的部分。

表 26.10. 从 OpenShiftSDN 实时迁移到 OVNKubernetes
用户发起的步骤迁移操作

通过将 networkTypeOpenShiftSDN 改为 OVNKubernetes 来修补集群级别的网络配置。

Cluster Network Operator (CNO)
  • network.operator 自定义资源 (CR) 中设置迁移相关字段,并等待可路由 MTU 应用到所有节点。
  • network.operator CR 进行补丁,将 OVN-Kubernetes 的迁移模式设置为 Live,并以迁移模式部署 OpenShift SDN 网络插件。
  • 部署启用了混合覆盖的 OVN-Kubernetes,确保不会发生任何操作条件。
  • 等待 OVN-Kubernetes 部署并更新 network.config CR 状态中的条件。
  • 触发 Machine Config Operator (MCO),将新机器配置应用到每个机器配置池,其中包括节点封锁、排空和重启。
  • OVN-Kubernetes 将节点添加到适当的区中,并使用 OVN-Kubernetes 作为默认 CNI 插件重新创建 pod。
  • 从 network.operator CR 中删除与迁移相关的字段,并执行清理操作,如删除 OpenShift SDN 资源,并使用必要的配置以正常模式重新部署 OVN-Kubernetes。
  • 等待 OVN-Kubernetes 重新部署并更新 network.config CR 中的状态条件,以指示迁移完成。如果您的迁移被阻止,请参阅"检查有限的实时迁移指标"以了解有关对问题进行故障排除的信息。

26.5.2.4. 使用有限的实时迁移方法迁移到 OVN-Kubernetes 网络插件

以下流程检查出口路由器资源,并使用有限的实时迁移方法从 OpenShift SDN 网络插件迁移到 OVN-Kubernetes 网络插件。

先决条件

  • 在网络策略隔离模式下,使用 OpenShift SDN CNI 网络插件配置集群。
  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您已创建了 etcd 数据库的最新备份。
  • 集群处于已知良好状态,且没有任何错误。
  • 在迁移到 OVN-Kubernetes 之前,必须有一条安全组规则,以允许所有云平台上所有节点的 UDP 数据包在端口 6081 上。
  • 在开始有限的实时迁移前,集群管理员必须删除所有出口路由器 pod。如需有关出口路由器 pod 的更多信息,请参阅"以重定向模式部署出口路由器 pod"。
  • 您已参阅本文档的"正在考虑的有限实时迁移"部分。

流程

  1. 在启动有限的实时迁移前,您必须检查任何出口路由器 pod。如果在执行有限的实时迁移时集群中有一个出口路由器 pod,Network Operator 会阻断迁移并返回以下错误:

    The cluster configuration is invalid (network type live migration is not supported for pods with `pod.network.openshift.io/assign-macvlan` annotation. Please remove all egress router pods). Use `oc edit network.config.openshift.io cluster` to fix.
    • 输入以下命令查找集群中的出口路由器 pod:

      $ oc get pods --all-namespaces -o json | jq '.items[] | select(.metadata.annotations."pod.network.openshift.io/assign-macvlan" == "true") | {name: .metadata.name, namespace: .metadata.namespace}'

      输出示例

      {
        "name": "egress-multi",
        "namespace": "egress-router-project"
      }

    • 另外,您还可以查询 OpenShift Container Platform Web 控制台的指标,或使用 oc CLI 检查出口路由器 pod。如需更多信息,请参阅"检查有限的实时迁移指标"。
  2. 输入以下命令删除出口路由器 pod:

    $ oc delete pod <egress_pod_name> -n <egress_router_project>
  3. 输入以下命令来修补集群级别的网络配置,并启动从 OpenShift SDN 到 OVN-Kubernetes 的迁移:

    $ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}'

    运行这些命令后,迁移过程开始。在此过程中,Machine Config Operator 会重启集群中的节点两次。在集群升级时,迁移大约需要两倍。

  4. 可选:您可以输入以下命令来确保迁移过程已完成,并检查 network.config 的状态:

    $ oc get network.config.openshift.io cluster -o jsonpath='{.status.networkType}'
    $ oc get network.config cluster -o=jsonpath='{.status.conditions}' | jq .

    您可以检查有限的实时迁移指标,以进行故障排除。如需更多信息,请参阅"检查有限的实时迁移指标"。

  5. 只有在迁移成功且集群处于良好状态时完成以下步骤:

    1. 要从 network.config 自定义资源中删除迁移配置,请输入以下命令:

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
    2. 要删除 OpenShift SDN 网络供应商的自定义配置,请输入以下命令:

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
    3. 要删除 OpenShift SDN 网络供应商命名空间,请输入以下命令:

      $ oc delete namespace openshift-sdn

26.5.2.5. 检查有限的实时迁移指标

可用于监控有限实时迁移的进度。可以在 OpenShift Container Platform Web 控制台中或使用 oc CLI 查看指标。

先决条件

  • 您已启动了一个有限实时迁移到 OVN-Kubernetes。

流程

  1. 在 OpenShift Container Platform Web 控制台中查看有限的实时迁移指标:

    1. Observe Metrics
    2. Expression 框中,键入 openshift_network 并点 openshift_network_operator_live_migration_procedure 选项。
  2. 使用 oc CLI 查看指标:

    1. 输入以下命令为 openshift-monitoring 命名空间中的 prometheus-k8s 服务帐户生成令牌:

      $ oc create token prometheus-k8s -n openshift-monitoring

      输出示例

      eyJhbGciOiJSUzI1NiIsImtpZCI6IlZiSUtwclcwbEJ2VW9We...

    2. 输入以下命令请求有关 openshift_network_operator_live_migration_condition 指标的信息:

      $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: <eyJhbGciOiJSUzI1NiIsImtpZCI6IlZiSUtwclcwbEJ2VW9We...>" "https://<openshift_API_endpoint>" --data-urlencode "query=openshift_network_operator_live_migration_condition" | jq`

      输出示例

       "status": "success",
        "data": {
          "resultType": "vector",
          "result": [
            {
              "metric": {
                "__name__": "openshift_network_operator_live_migration_condition",
                "container": "network-operator",
                "endpoint": "metrics",
                "instance": "10.0.83.62:9104",
                "job": "metrics",
                "namespace": "openshift-network-operator",
                "pod": "network-operator-6c87754bc6-c8qld",
                "prometheus": "openshift-monitoring/k8s",
                "service": "metrics",
                "type": "NetworkTypeMigrationInProgress"
              },
              "value": [
                1717653579.587,
                "1"
              ]
            },
      ...

"Information about limited live migration metrics" 中的表显示可用的指标,以及 openshift_network_operator_live_migration_procedure 表达式填充的标签值。使用这些信息来监控进度或对迁移进行故障排除。

26.5.2.5.1. 关于有限实时迁移指标的信息

下表显示了可用的指标以及从 openshift_network_operator_live_migration_procedure 表达式填充的标签值。使用这些信息来监控进度或对迁移进行故障排除。

表 26.11. 有限的实时迁移指标
指标标签值
openshift_network_operator_live_migration_blocked:
Prometheus 量表向量指标。包含恒定的 1 值的指标,带有 CNI 有限实时迁移的原因可能没有启动。当 CNI 有限实时迁移通过注解 Network 自定义资源时,此指标可用。
除非有限实时迁移被阻止,否则不会发布此指标。
标签值列表包括以下内容
  • UnsupportedCNI: 无法迁移到不支持的目标 CNI。从 OpenShift SDN 迁移时,有效的 CNI 是 OVNKubernetes
  • UnsupportedHyperShiftCluster :在 HCP 集群中不支持有限实时迁移。
  • UnsupportedSDNNetworkIsolationMode: OpenShift SDN 配置了一个不支持的网络隔离模式 Multitenant。在执行有限的实时迁移前,迁移到受支持的网络隔离模式。
  • UnsupportedMACVLANInterface :删除出口路由器或包含 pod 注解 pod.network.openshift.io/assign-macvlan 的任何 pod。使用以下命令查找 offending pod 的命名空间或 pod 名称:

    oc get pods -Ao=jsonpath='{range .items[?(@.metadata.annotations.pod\.network\.openshift\.io/assign-macvlan=="")]}{@.metadata.namespace}{"\t"}{@.metadata.name}{"\n"}'
openshift_network_operator_live_migration_condition:
代表 CNI 限制实时迁移的每个条件类型的状态的指标。为 network.config 定义了一组状态条件类型,以支持 CNI 有限实时迁移的可观察性。
1 表示条件状态为 true0 代表 false-1 代表未知。当 CNI 有限实时迁移通过注解 Network 自定义资源时,此指标可用。
只有通过向 Network CR 集群添加相关注解来触发有限实时迁移时,此指标才可用,否则不会被发布。如果 Network CR 集群中没有以下条件类型,则会清除指标及其标签。
标签值列表包括以下内容
  • NetworkTypeMigrationInProgress
  • NetworkTypeMigrationTargetCNIAvailable
  • NetworkTypeMigrationTargetCNIInUse
  • NetworkTypeMigrationOriginalCNIPurged
  • NetworkTypeMigrationMTUReady

26.5.3. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.