主要特性

每個工作節點的靜態 VNI

在 IBM Cloud VPC 中建立基於裸機的 Red Hat OpenShift on IBM Cloud 群集或新 Worker pool 時，會自動建立兩個 VNI，並靜態連接至每個裸機 Worker 節點。 一個 VNI 可處理一般 Worker 流量（pod 網路、overlay UDN 及主站通訊）。 第二個 VNI 充當您管理的動態 VNI 附件的載具。

動態 VNI 附件

您可以在群集建立後，依需求建立和管理 VNI。 動態 VNI 可以附加到特定工作人員，或設定為在同一區域的工作人員之間浮動，在即時移轉過程中跟隨 VM 工作負載。

即時遷移支援

透過連接至裸金屬工作節點的 VNI，OpenShift 虛擬化虛擬機器的即時遷移可以保留網路連線。 VNI 隱含浮動並跟隨同一區域內裸金屬工作站實體之間的工作負載。

有關 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) 以供 Primary UDN 使用。

範例：

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

一旦 (C)UDN 和命名空間就位，在此命名空間中建立的任何工作負載都會使用預設路由存取 UDN。

建立第二 UDN

Secondary UDN 設定與 Primary 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 Virtualization 的標準 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 橋接到預設的 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. 檢查自訂資源狀態，並等待所有適用的群集節點對齊橋接映射請求。

建立 localnet 使用者定義網路

建立 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 附加到 localnet UDN？

Localnet UDN 在 OVN 端已停用 IP 位址管理 (IPAM)，這表示不會從 OVN 為 Pod 指派靜態 IP 位址。 此設定專為使用 DHCP 或在客座作業系統內設定靜態 IP 的 VM 工作負載而設計。 這些選項無法用於 Pod 工作負載。

為什麼跨工人池的即時移轉尚未完成？

不同的 Worker 池可能有不同的 Worker 風格，使用不同世代和能力的 CPU。 如果完整的 CPU 功能集對 VM 工作負載是透明可見的，您就無法將 VM Live 遷移到其他不支援所有 CPU 功能的 Worker。 您可以在一開始就限制客座作業系統可見的 CPU 功能，以獲得更多跨 Worker flavors 的相容性。

為什麼動態附加的 VNI 無法運作？

請檢查下列項目：

• 驗證 CUDN 中的 VLAN ID 是否與 VNI 附件中的 VLAN ID 相符。 如果 VLAN 不匹配，VPC DHCP 可能仍能運作，而不會產生更多流量。
• 如果未啟用浮動，請確定工作負載排程在附加 VNI 的工作站上。
• 驗證專用 OVS 橋接和映射是否存在於工作者身上。 檢查 NodeNetworkConfigurationPolicy 資源狀態。