24.5. 从 OpenShift SDN 网络插件迁移


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

警告

如果使用 OpenShift SDN 网络插件,则无法将集群升级到 OpenShift Container Platform 4.17。在升级到 OpenShift Container Platform 4.17 前,您必须迁移到 OVN-Kubernetes 插件。

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

警告

不要使用脚本或其他工具(如 Red Hat Ansible Automation Platform)自动从 OpenShift SDN 迁移到 OVN-Kubernetes。这可能导致 OpenShift Container Platform 集群中断或崩溃。

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

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

重要

在将 OpenShift Container Platform 集群迁移到使用 OVN-Kubernetes 网络插件前,将集群更新至最新的 z-stream 版本,以便所有最新的程序错误修复都应用到集群。

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

注意

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

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

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

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

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

裸机硬件

Amazon Web Services (AWS)

Google Cloud Platform (GCP)

IBM Cloud®

Microsoft Azure

Red Hat OpenStack Platform(RHOSP)

VMware vSphere

Nutanix

注意

每个列出的平台都支持在安装程序置备的基础架构和用户置备的基础架构上安装 OpenShift Container Platform 集群。

24.5.1.2. 离线迁移到 OVN-Kubernetes 网络插件的最佳实践

有关使用离线迁移方法迁移到 OVN-Kubernetes 网络插件时的最佳实践列表,请参阅 OpenShift SDN 到 OVN Kubernetes CNI 离线迁移的最佳实践

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

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

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

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

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

    • 命名空间隔离
    • 出口路由器 pod
  • 在迁移到 OVN-Kubernetes 之前,请确保不使用以下 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 定义中包含这些范围。

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

主网络接口

OpenShift SDN 插件允许 NodeNetworkConfigurationPolicy (NNCP)自定义资源(CR)的应用程序到节点上的主接口。OVN-Kubernetes 网络插件没有此功能。

如果您的 NNCP 应用到主接口,则必须在迁移到 OVN-Kubernetes 网络插件前删除 NNCP。删除 NNCP 不会从主接口中删除配置,但 Kubernetes-NMState 无法管理此配置。相反,configure-ovs.sh shell 脚本管理附加到这个接口的主接口和配置。

命名空间隔离

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

重要

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

出口 IP 地址

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

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

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

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

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

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

出口网络策略

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

表 24.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 上启用多播流量的区别:

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

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

网络策略

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

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

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

表 24.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 地址。

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

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

重要

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

先决条件

  • 您已在网络策略隔离模式下使用 OpenShift SDN CNI 网络插件配置集群。
  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您有最新的 etcd 数据库备份。
  • 您可以手动重新引导每个节点。
  • 您检查集群是否处于已知良好状态,且没有任何错误。
  • 您创建了一条安全组规则,允许所有云平台上所有节点的端口 6081 上用户数据报协议(UDP)数据包。
  • 将 webhook 的所有超时设置为 3 秒或删除 Webhook。

流程

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

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
  2. 运行以下命令,验证 OVN_SDN_MIGRATION_TIMEOUT 环境变量是否已设置,并等于 0s

    #!/bin/bash
    
    if [ -n "$OVN_SDN_MIGRATION_TIMEOUT" ] && [ "$OVN_SDN_MIGRATION_TIMEOUT" = "0s" ]; then
        unset OVN_SDN_MIGRATION_TIMEOUT
    fi
    
    #loops the timeout command of the script to repeatedly check the cluster Operators until all are available.
    
    co_timeout=${OVN_SDN_MIGRATION_TIMEOUT:-1200s}
    timeout "$co_timeout" bash <<EOT
    until
      oc wait co --all --for='condition=AVAILABLE=True' --timeout=10s && \
      oc wait co --all --for='condition=PROGRESSING=False' --timeout=10s && \
      oc wait co --all --for='condition=DEGRADED=False' --timeout=10s;
    do
      sleep 10
      echo "Some ClusterOperators Degraded=False,Progressing=True,or Available=False";
    done
    EOT
  3. 运行以下命令,从 Cluster Network Operator (CNO) 配置对象中删除配置:

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
    --patch '{"spec":{"migration":null}}'
  4. 通过完成以下步骤,删除 NodeNetworkConfigurationPolicy (NNCP)自定义资源(CR)定义 OpenShift SDN 网络插件的主网络接口:

    1. 输入以下命令检查现有 NNCP CR 是否将主接口绑定到集群:

      $ oc get nncp

      输出示例

      NAME          STATUS      REASON
      bondmaster0   Available   SuccessfullyConfigured

      Network Manager 将绑定的主接口的连接配置文件存储在 /etc/NetworkManager/system-connections 系统路径中。

    2. 从集群中删除 NNCP:

      $ oc delete nncp <nncp_manifest_filename>
  5. 要为迁移准备所有节点,请运行以下命令在 CNO 配置对象上设置 migration 字段:

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

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

    1. 运行以下命令检查重启是否已完成:

      $ oc get mcp
    2. 运行以下命令,检查所有集群 Operator 是否可用:

      $ oc get co
    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

  6. 可选: 您可以自定义 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
        }}}}'

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

    $ oc get mcp

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

    注意

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

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

    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. 解决上一命令输出中显示的日志中的任何错误。
  9. 要启动迁移,请使用以下命令配置 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 网络供应商在内部使用此块。

      重要

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

  10. 在继续执行后续步骤前,验证 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

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

    重要

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

    在重新引导节点前,集群 Operator 无法正常工作。

    • 使用 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
  12. 确认迁移成功完成:

    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 的日志以了解更多信息。

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

    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

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

有限的实时迁移方法是在不中断服务的情况下将 OpenShift SDN 网络插件及其网络配置、连接和相关资源迁移到 OVN-Kubernetes 网络插件的过程。它可用于 OpenShift Container Platform。

重要

在将 OpenShift Container Platform 集群迁移到使用 OVN-Kubernetes 网络插件前,将集群更新至最新的 z-stream 版本,以便所有最新的程序错误修复都应用到集群。

它不适用于托管 control plane 部署类型。这个迁移方法对于需要持续服务可用性的部署类型非常重要,并具有以下优点:

  • 持续服务可用性
  • 最小化停机时间
  • 自动节点重新引导
  • 从 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。如需更多信息,请参阅 OpenShift SDN CNI 删除

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

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

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

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

裸机硬件

Amazon Web Services (AWS)

Google Cloud Platform (GCP)

IBM Cloud®

Microsoft Azure

Red Hat OpenStack Platform(RHOSP)

VMware vSphere

Nutanix

注意

每个列出的平台都支持在安装程序置备的基础架构和用户置备的基础架构上安装 OpenShift Container Platform 集群。

24.5.2.2. 有限实时迁移到 OVN-Kubernetes 网络插件的最佳实践

有关迁移到使用有限实时迁移方法的 OVN-Kubernetes 网络插件时的最佳实践列表,请参阅 Limited Live Migration from OpenShift SDN to OVN-Kubernetes

24.5.2.3. 有限实时迁移到 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。迁移后,集群管理员可以启用双栈。
  • OpenShift SDN 插件允许 NodeNetworkConfigurationPolicy (NNCP)自定义资源(CR)的应用程序到节点上的主接口。OVN-Kubernetes 网络插件没有此功能。
  • 集群 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 地址范围。如需更多信息,请参阅"选择 OVN-Kubernetes 地址范围"。
  • 在大多数情况下,有限的实时迁移独立于 Multus CNI 插件创建的 pod 的二级接口。但是,如果这些二级接口在主机的默认网络接口控制器 (NIC) 上设置,例如,使用 MACVLAN、IPVLAN、SR-IOV 或桥接接口作为控制节点,则 OVN-Kubernetes 可能会遇到故障。在继续有限的实时迁移前,用户应删除此配置。
  • 当主机中存在多个 NIC 时,且默认路由不在具有 Kubernetes NodeIP 的接口上,则必须使用离线迁移。
  • 在启动有限实时迁移前,必须删除 openshift-sdn 命名空间中的所有 DaemonSet 对象(不受 Cluster Network Operator (CNO) 管理。这些非受管守护进程集可能会导致迁移状态在未正确处理时保持不完整。
  • 如果您运行 Operator 或您已配置了 pod 中断预算,您可能会在升级过程中遇到中断。如果在 PodDisruptionBudget 中将 minAvailable 设置为 1,则节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点,则所有 pod 只能有一个节点上运行,PodDisruptionBudget 字段可能会阻止节点排空。

24.5.2.4. 有限的实时迁移过程是如何工作的

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

表 24.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 中的状态条件,以指示迁移完成。如果您的迁移被阻止,请参阅"检查有限的实时迁移指标"以了解有关对问题进行故障排除的信息。

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

使用有限的实时迁移方法迁移到 OVN-Kubernetes 网络插件是一个步骤,要求用户检查出口 IP 资源、出口防火墙资源和多播启用的命名空间的行为。管理员还必须查看其部署中的任何网络策略,并删除出口路由器资源,然后才能启动有限的实时迁移过程。以下流程应该连续使用。

24.5.2.5.1. 在启动有限实时迁移前检查集群资源

在使用有限的实时迁移功能迁移到 OVN-Kubernetes 之前,您应该在 OpenShift SDN 部署中检查出口 IP 资源、出口防火墙资源和多播启用的命名空间。您还应检查部署中的任何网络策略。如果您在迁移前发现集群有这些资源,您应该在迁移后检查其行为,以确保它们按预期工作。

以下流程演示了如何检查出口 IP 资源、出口防火墙资源、多播支持的命名空间、网络策略和 NNCP。检查这些资源后不需要任何操作。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 作为 OpenShift Container Platform 集群管理员,检查出口防火墙资源。您可以使用 oc CLI 或 OpenShift Container Platform Web 控制台进行此操作。

    1. 使用 oc CLI 工具检查出口防火墙资源:

      1. 要检查出口防火墙资源,请输入以下命令:

        $ oc get egressnetworkpolicies.network.openshift.io -A

        输出示例

        NAMESPACE    NAME                      AGE
        <namespace>  <example_egressfirewall>  5d

      2. 您可以使用 -o yaml 标志检查出口防火墙资源的预期行为。例如:

        $ oc get egressnetworkpolicy <example_egressfirewall> -n <namespace> -o yaml

        输出示例

        apiVersion: network.openshift.io/v1
        kind: EgressNetworkPolicy
        metadata:
          name: <example_egress_policy>
          namespace: <namespace>
        spec:
          egress:
          - type: Allow
            to:
              cidrSelector: 0.0.0.0/0
          - type: Deny
            to:
              cidrSelector: 10.0.0.0/8

    2. 使用 OpenShift Container Platform Web 控制台检查出口防火墙资源:

      1. 在 OpenShift Container Platform web 控制台中点 Observe Metrics
      2. Expression 框中,键入 sdn_controller_num_egress_firewalls,然后点 Run queries。如果您有出口防火墙资源,则会在 Expression 框中返回。
  2. 检查集群是否有出口 IP 资源。您可以使用 oc CLI 或 OpenShift Container Platform Web 控制台进行此操作。

    1. 使用 oc CLI 工具检查出口 IP:

      1. 要列出带有出口 IP 资源的命名空间,请输入以下命令

        $ oc get netnamespace -A | awk '$3 != ""'

        输出示例

        NAME        NETID      EGRESS IPS
        namespace1  14173093   ["10.0.158.173"]
        namespace2  14173020   ["10.0.158.173"]

    2. 使用 OpenShift Container Platform Web 控制台检查出口 IP:

      1. 在 OpenShift Container Platform web 控制台中点 Observe Metrics
      2. Expression 框中,键入 sdn_controller_num_egress_ips,然后点 Run queries。如果您有出口防火墙资源,则会在 Expression 框中返回。
  3. 检查集群是否有启用多播的命名空间。您可以使用 oc CLI 或 OpenShift Container Platform Web 控制台进行此操作。

    1. 使用 oc CLI 工具检查启用多播的命名空间:

      1. 要找到启用多播的命名空间,请输入以下命令:

        $ oc get netnamespace -o json | jq -r '.items[] | select(.metadata.annotations."netnamespace.network.openshift.io/multicast-enabled" == "true") | .metadata.name'

        输出示例

        namespace1
        namespace3

    2. 使用 OpenShift Container Platform Web 控制台检查多播启用的命名空间:

      1. 在 OpenShift Container Platform web 控制台中点 Observe Metrics
      2. Expression 框中,键入 sdn_controller_num_multicast_enabled_namespaces,然后点 Run queries。如果您启用了多播的命名空间,则会在 Expression 框中返回它们。
  4. 检查集群是否有网络策略。您可以使用 oc CLI 完成此操作。

    1. 要使用 oc CLI 工具检查网络策略,请输入以下命令:

      $ oc get networkpolicy -n <namespace>

      输出示例

      NAME              POD-SELECTOR   AGE
      allow-multicast   app=my-app     11m

24.5.2.5.2. 在启动有限实时迁移前删除出口路由器 pod

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

The cluster configuration is invalid (network type limited 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.

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 要找到集群中的出口路由 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"
    }

  2. 另外,您还可以查询 OpenShift Container Platform Web 控制台上的指标。

    1. 在 OpenShift Container Platform web 控制台中点 Observe Metrics
    2. Expression 框中,输入 network_attachment_definition_instances{networks="egress-router"}。然后,点 Add
  3. 要删除出口路由器 pod,请输入以下命令:

    $ oc delete pod <egress_pod_name> -n <egress_router_project>
24.5.2.5.3. 删除 NodeNetworkConfigurationPolicy (NNCP) 自定义资源 (CR)

OpenShift SDN 插件允许 NodeNetworkConfigurationPolicy (NNCP) 自定义资源 (CR) 的应用程序到节点上的主接口。OVN-Kubernetes 网络插件没有此功能。

如果您的 NNCP 应用到主接口,则必须在迁移到 OVN-Kubernetes 网络插件前删除 NNCP。删除 NNCP 不会从主接口中删除配置,但 Kubernetes-NMState 无法管理此配置。相反,configure-ovs.sh shell 脚本管理主接口及其附加的配置。

先决条件

  • 您创建了 NNCP CR,并将其应用到网络的主接口。

流程

  1. 运行以下命令,从 Cluster Network Operator (CNO) 配置对象中删除配置:

    $ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'
  2. 通过完成以下步骤,删除 NodeNetworkConfigurationPolicy (NNCP)自定义资源(CR)定义 OpenShift SDN 网络插件的主网络接口:

    1. 输入以下命令检查现有 NNCP CR 是否将主接口绑定到集群:

      $ oc get nncp

      输出示例

      NAME          STATUS      REASON
      bondmaster0   Available   SuccessfullyConfigured

      Network Manager 将绑定的主接口的连接配置文件存储在 /etc/NetworkManager/system-connections 系统路径中。

    2. 从集群中删除 NNCP:

      $ oc delete nncp <nncp_manifest_filename>
24.5.2.5.4. 启动有限的实时迁移过程

在检查了出口 IP 资源、出口防火墙资源和多播启用命名空间的行为后,并删除了任何出口路由器资源,您可以启动有限的实时迁移过程。

先决条件

  • 在网络策略隔离模式下,使用 OpenShift SDN CNI 网络插件配置集群。
  • 已安装 OpenShift CLI(oc)。
  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您已创建了 etcd 数据库的最新备份。
  • 集群处于已知良好状态,且没有任何错误。
  • 在迁移到 OVN-Kubernetes 之前,必须有一条安全组规则,以允许所有云平台上所有节点的 UDP 数据包在端口 6081 上。
  • 如果 OpenShift-SDN 之前使用 100.64.0.0/16100.88.0.0/16 地址范围,则代表已修补它们。此流程的第一步是检查这些地址范围是否在使用。如果在使用它们,请参阅"使用 OVN-Kubernetes 地址范围"。
  • 您已检查出口 IP 资源、出口防火墙资源和多播启用的命名空间。
  • 在开始有限的实时迁移前,您已删除了任何出口路由器 pod。如需有关出口路由器 pod 的更多信息,请参阅"以重定向模式部署出口路由器 pod"。
  • 您已参阅本文档的"正在考虑的有限实时迁移"部分。

流程

  1. 要修补集群级别的网络配置,并启动从 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 会重启集群中的节点两次。在集群升级过程中,迁移大约需要进行两次。

    重要

    oc patch 命令检查 OpenShift SDN 使用的重叠 CIDR。如果检测到重叠的 CIDR,您必须在有限的实时迁移进程启动前对它们进行补丁。如需更多信息,请参阅"使用 OVN-Kubernetes 地址范围"。

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

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

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

24.5.2.5.5. 修补 OVN-Kubernetes 地址范围

OVN-Kubernetes 保留以下 IP 地址范围:

  • 100.64.0.0/16.默认情况下,此 IP 地址范围用于 OVN-Kubernetes 的 internalJoinSubnet 参数。
  • 100.88.0.0/16.默认情况下,此 IP 地址范围用于 OVN-Kubernetes 的 internalTransSwitchSubnet 参数。

如果 OpenShift SDN 使用这些 IP 地址,或者任何可能会与此集群通信的外部网络,则您必须在启动有限的实时迁移前使用不同的 IP 地址范围。

如果迁移最初被阻止,则可以使用以下步骤来修补 OpenShift SDN 使用的 CIDR 范围。

注意

这是一个可选的流程,只有在使用 oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}' 命令来"初始有限的实时迁移过程"时迁移被阻止的情况下使用。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。

流程

  1. 如果已使用 100.64.0.0/16 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"}}}}}'
  2. 如果已使用 100.88.0.0/16 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"}}}}}'

在修补 100.64.0.0/16100.88.0.0/16 IP 地址范围后,您可以启动有限的实时迁移。

24.5.2.5.6. 启动有限实时迁移后检查集群资源

以下流程演示了如何在使用 OVN-Kubernetes 时检查出口 IP 资源、出口防火墙资源、多播启用的命名空间和网络策略。如果您在 OpenShift SDN 上有这些资源,您应该在迁移后检查它们,以确保它们正常工作。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 您已使用有限的实时迁移成功从 OpenShift SDN 迁移到 OVN-Kubernetes。

流程

  1. 作为 OpenShift Container Platform 集群管理员,检查出口防火墙资源。您可以使用 oc CLI 或 OpenShift Container Platform Web 控制台进行此操作。

    1. 使用 oc CLI 工具检查出口防火墙资源:

      1. 要检查出口防火墙资源,请输入以下命令:

        $ oc get egressfirewalls.k8s.ovn.org -A

        输出示例

        NAMESPACE    NAME                      AGE
        <namespace>  <example_egressfirewall>   5d

      2. 您可以使用 -o yaml 标志检查出口防火墙资源的预期行为。例如:

        $ oc get egressfirewall <example_egressfirewall> -n <namespace> -o yaml

        输出示例

        apiVersion: k8s.ovn.org/v1
        kind: EgressFirewall
        metadata:
          name: <example_egress_policy>
          namespace: <namespace>
        spec:
          egress:
          - type: Allow
            to:
              cidrSelector: 192.168.0.0/16
          - type: Deny
            to:
              cidrSelector: 0.0.0.0/0

        确保此资源的行为是预期的,因为它可能会在迁移后有所变化。有关出口防火墙的更多信息,请参阅"配置项目的出口防火墙"。

    2. 使用 OpenShift Container Platform Web 控制台检查出口防火墙资源:

      1. 在 OpenShift Container Platform web 控制台中点 Observe Metrics
      2. Expression 框中,键入 ovnkube_controller_num_egress_firewall_rules,然后点 Run queries。如果您有出口防火墙资源,则会在 Expression 框中返回。
  2. 检查集群是否有出口 IP 资源。您可以使用 oc CLI 或 OpenShift Container Platform Web 控制台进行此操作。

    1. 使用 oc CLI 工具检查出口 IP:

      1. 要列出带有出口 IP 资源的命名空间,请输入以下命令:

        $ oc get egressip

        输出示例

        NAME                EGRESSIPS    ASSIGNED NODE                              ASSIGNED EGRESSIPS
        egress-sample       192.0.2.10   ip-10-0-42-79.us-east-2.compute.internal   192.0.2.10
        egressip-sample-2   192.0.2.14   ip-10-0-42-79.us-east-2.compute.internal   192.0.2.14

      2. 要提供有关出口 IP 的详细信息,请输入以下命令:

        $ oc get egressip <egressip_name> -o yaml

        输出示例

        apiVersion: k8s.ovn.org/v1
        kind: EgressIP
        metadata:
          annotations:
            kubectl.kubernetes.io/last-applied-configuration: |
              {"apiVersion":"k8s.ovn.org/v1","kind":"EgressIP","metadata":{"annotations":{},"name":"egressip-sample"},"spec":{"egressIPs":["192.0.2.12","192.0.2.13"],"namespaceSelector":{"matchLabels":{"name":"my-namespace"}}}}
          creationTimestamp: "2024-06-27T15:48:36Z"
          generation: 7
          name: egressip-sample
          resourceVersion: "125511578"
          uid: b65833c8-781f-4cc9-bc96-d970259a7631
        spec:
          egressIPs:
          - 192.0.2.12
          - 192.0.2.13
          namespaceSelector:
            matchLabels:
              name: my-namespace

        对所有出口 IP 重复此操作。确保每个资源的行为都是预期的,因为它可能会在迁移后有所变化。有关 EgressIPs 的更多信息,请参阅"配置 EgressIP 地址"。

    2. 使用 OpenShift Container Platform Web 控制台检查出口 IP:

      1. 在 OpenShift Container Platform web 控制台中点 Observe Metrics
      2. Expression 框中,键入 ovnkube_clustermanager_num_egress_ips,然后点 Run queries。如果您有出口防火墙资源,则会在 Expression 框中返回。
  3. 检查集群是否有启用多播的命名空间。您只能使用 oc CLI 完成此操作。

    1. 要找到启用多播的命名空间,请输入以下命令:

      $ oc get namespace -o json | jq -r '.items[] | select(.metadata.annotations."k8s.ovn.org/multicast-enabled" == "true") | .metadata.name'

      输出示例

      namespace1
      namespace3

    2. 要描述每个启用多播的命名空间,请输入以下命令:

      $ oc describe namespace <namespace>

      输出示例

      Name:         my-namespace
      Labels:       kubernetes.io/metadata.name=my-namespace
                    pod-security.kubernetes.io/audit=restricted
                    pod-security.kubernetes.io/audit-version=v1.24
                    pod-security.kubernetes.io/warn=restricted
                    pod-security.kubernetes.io/warn-version=v1.24
      Annotations:  k8s.ovn.org/multicast-enabled: true
                    openshift.io/sa.scc.mcs: s0:c25,c0
                    openshift.io/sa.scc.supplemental-groups: 1000600000/10000
                    openshift.io/sa.scc.uid-range: 1000600000/10000
      Status:       Active

      确保正确配置多播功能,并在每个命名空间中按预期工作。如需更多信息,请参阅"为项目启用多播"。

  4. 检查集群的网络策略。您只能使用 oc CLI 完成此操作。

    1. 要获取命名空间中网络策略的信息,请输入以下命令:

      $ oc get networkpolicy -n <namespace>

      输出示例

      NAME              POD-SELECTOR   AGE
      allow-multicast   app=my-app     11m

    2. 要提供有关网络策略的详细信息,请输入以下命令:

      $ oc describe networkpolicy allow-multicast -n <namespace>

      输出示例

      Name:         allow-multicast
      Namespace:    my-namespace
      Created on:   2024-07-24 14:55:03 -0400 EDT
      Labels:       <none>
      Annotations:  <none>
      Spec:
        PodSelector:     app=my-app
        Allowing ingress traffic:
          To Port: <any> (traffic allowed to all ports)
          From:
            IPBlock:
              CIDR: 224.0.0.0/4
              Except:
        Allowing egress traffic:
          To Port: <any> (traffic allowed to all ports)
          To:
            IPBlock:
              CIDR: 224.0.0.0/4
              Except:
        Policy Types: Ingress, Egress

      确保网络策略的行为如预期。对网络策略的优化因 SDN 和 OVN-K 而异,因此用户可能需要调整其策略以便为不同的 CNI 实现最佳性能。如需更多信息,请参阅"关于网络策略"。

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

可用于监控有限实时迁移的进度。可以在 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 表达式填充的标签值。使用这些信息来监控进度或对迁移进行故障排除。

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

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

表 24.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

24.5.3. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.