主要功能

每个工作节点的静态 VNI

在 IBM Cloud VPC 中创建基于裸机的 Red Hat OpenShift on IBM Cloud 群集或新工作池时，会自动创建两个 VNI 并静态连接到每个裸机工作节点。 一个 VNI 负责处理常规工作者流量（pod 网络、叠加 UDN 和主站通信）。 第二个 VNI 充当您管理的动态 VNI 附件的载体。

动态 VNI 附件

创建群集后，您可以按需创建和管理 VNI。 在实时迁移过程中，动态 VNI 可以连接到特定的工作人员，也可以配置为在同一区域的工作人员之间浮动，跟随 VM 工作负载。

实时迁移支持

通过连接到裸机工作节点的 VNI，基于 OpenShift Virtualization 的虚拟机的实时迁移可以保留网络连接。 VNI 在同一区域内的裸机工作实例之间隐式浮动并跟踪工作负载。

有关虚拟网络标识的重要限制和注意事项，请参阅 限制和注意事项。

跨账户附件

在 Red Hat OpenShift on IBM Cloud 中，工作节点不在账户中配置，这意味着 VNI 的生命周期管理与独立的 VPC 裸机实例略有不同。 Red Hat OpenShift on IBM Cloud 群集管理员对 VNI 附件的可见性不同，因为它们附加到工作负载上，而工作负载在账户内是不可见的。 本文档介绍了 VNI 管理的不同之处。

有关独立 VPC 裸机实例上 VNI 的更多信息，请参阅 关于虚拟网络接口。

创建主 UDN

要将主用户定义网络用于 pod 或 VM 工作负载，首先要创建 UDN 本身。

可跨命名空间使用的集群用户定义网络示例：

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: primary
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: green
  network:
    layer2:
      ipam:
        lifecycle: Persistent
      role: Primary
      subnets:
        - 10.0.0.0/24
    topology: Layer2

然后，创建将使用它的命名空间。 命名空间在创建时必须包含一个特定标签（称为 k8s.ovn.org/primary-user-defined-network ），以便使用主 UDN。

示例：

kind: Namespace
apiVersion: v1
metadata:
  name: green
  labels:
    k8s.ovn.org/primary-user-defined-network: ''

一旦 (C)UDN 和命名空间就位，在该命名空间中创建的任何工作负载都将使用默认路由访问 UDN。

创建辅助 UDN

辅助 UDN 配置与主 UDN 类似，但角色设置为 Secondary。 有关详细信息，请参阅 Red Hat OpenShift 多网络文档。

安装 NMState 操作符

OpenShift 虚拟化服务集群 已预装 NMState 操作员，并由 openshift-virtualization 插件进行管理。 如果您使用的是虚拟化服务，请跳过此步骤。

1. 从 OperatorHub Red Hat OpenShift on IBM Cloud 控制台或使用 CLI 部署 NMState Operator。

2. 使用默认配置创建 NMState 实例。

   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   spec:
     probeConfiguration:
       dns:
         host: root-servers.net
   

创建 OVS 网桥

OpenShift 虚拟化服务 集群已预先配置了所需的NNCP资源。 您只需为采用手动安装 OpenShift 虚拟化功能的标准 OpenShift 集群手动创建这些资源。

1. 通过部署以下 NMState 自定义资源，创建连接到 eth1 的专用 OVS 网桥。

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "br-eth1"
   spec:
     desiredState:
       interfaces:
       - name: "br-eth1"
         description: A dedicated OVS bridge with a NIC as a port
         type: ovs-bridge
         state: up
         bridge:
           allow-extra-patch-ports: true
           options:
             stp: false
           port:
           - name: "eth1"
   

2. 检查自定义资源状态，并等待所有适用的群集节点核对桥接创建请求。

3. 创建以下 NMState 自定义资源，将新 OVS 桥接器修补为默认桥接器。 将 vpc-vlans 替换为所需的网络名称。

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "vpc-vlans"
   spec:
     desiredState:
       ovn:
         bridge-mappings:
         - localnet: "vpc-vlans"
           bridge: "br-eth1"
           state: present
   

4. 检查自定义资源状态，并等待所有适用的群集节点核对桥接映射请求。

创建本地网用户定义网络

创建 UDN 或 ClusterUserDefinedNetwork (CUDN)，通过使用选定的 VLAN 提供来自 VNI 的流量。

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan250"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "default"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 250

替换以下值：

• vlan250:您的 CUDN 名称
• default:要使用 CUDN 的命名空间
• vpc-vlans:您在网桥映射中定义的物理网络名称
• 250:您所需的 VLAN ID（范围：1-500）

至此，特定 VLAN 的网络管道连接结束。 您可以使用不同的 VLAN ID 定义多个 CUDN，同时重复使用网桥映射。

完成 localnet UDN 设置后，可使用 IBM Cloud 控制台或 IBM Cloud CLI ks vni 命令将 VNI 附加到群集。 请参阅以下章节中的示例。

准备工作

1. 在 VPC 中创建 VNI，并配置适当的子网和 IP 地址。

2. 确保您拥有管理群集和 VNI 所需的权限。

示例

ibmcloud ks vni attach baremetal --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123 --vlan 251

示例输出

OK
Successfully attached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba to worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.
Worker Node ID                                         VNI ID                                      VLAN ID
kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   251

示例输出

ibmcloud ks vni ls --cluster-id c9pqfcmw0tq431jdnrrg

OK
VNI ID                                      Worker Node                                            IP Address   MAC Address         VLAN   Floating   Auto-delete
0716-d97d3626-acb2-476b-8b12-bcafa1dec5bb   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000456   10.240.1.5   02:00:02:00:73:A5   250    -          false
0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   10.240.1.4   02:00:01:00:73:A5   251    -          false

示例

ibmcloud ks vni detach --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123

Detach VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123? This action cannot be undone. [y/N]> y
OK
Successfully detached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.

为什么不能将普通 pod 附加到本地网 UDN？

本地网 UDN 在 OVN 端禁用了 IP 地址管理 (IPAM)，这意味着不会从 OVN 向 pod 分配静态 IP 地址。 该配置专为 VM 工作负载设计，这些负载使用 DHCP 或在客户操作系统内设置静态 IP。 这些选项不适用于 pod 工作负载。

为什么跨工人池的实时迁移尚未完成？

不同的工人池可能有不同的工人类型，CPU 也有不同的世代和性能。 如果 VM 工作负载可以透明地看到全部 CPU 功能集，则无法将 VM 迁移到另一个不支持全部 CPU 功能的工作负载上。 您可以在开始时限制客户操作系统的可见 CPU 功能，以获得更高的跨 Worker 版本兼容性。

为什么动态连接的虚拟网络标识符不起作用？

检查以下各项：

• 验证 CUDN 中的 VLAN ID 是否与 VNI 附件中的 VLAN ID 一致。 如果 VLAN 不匹配，VPC DHCP 仍可正常工作，不会产生更多流量。
• 如果未启用浮动，请确保工作负载调度在连接 VNI 的工作站上。
• 验证专用 OVS 网桥和映射是否存在于工作者身上。 检查 NodeNetworkConfigurationPolicy 资源状态。