主な機能

ワーカーノードごとの静的VNI

IBM Cloud VPC でベアメタルベースの Red Hat OpenShift on IBM Cloud クラスタまたは新しいワーカープールを作成すると、2 つの VNI が自動的に作成され、各ベアメタルワーカーノードに静的にアタッチされます。 1つのVNIが通常のワーカートラフィック（ポッドネットワーク、オーバーレイUDN、マスター通信）を処理する。 2番目のVNIは、あなたが管理するダイナミックVNIアタッチメントのキャリアとして機能する。

ダイナミックVNIアタッチメント

クラスタ作成後にオンデマンドでVNIを作成および管理できます。 ダイナミックVNIは特定のワーカーにアタッチすることも、ライブマイグレーション中に VM、同じゾーン内のワーカー間でフローティングするように設定することもできる。

ライブ移行サポート

ベアメタルワーカーノードに接続されたVNIにより、 OpenShift 仮想化ベースのVMのライブマイグレーションは、ネットワーク接続を維持することができます。 VNIは、同一ゾーン内のベアメタルワーカーインスタンス間のワークロードを暗黙的にフローティングし、追従する。

VNIに関する重要な制限と考慮事項については、「 制限と考慮事項 」を参照のこと。

アカウント間アタッチメント

Red Hat OpenShift on IBM Cloud では、ワーカーノードはアカウントプロビジョニングされないため、VNI のライフサイクル管理はスタンドアロン VPC ベアメタルインスタンスとは若干異なります。 VNI はワークロードにアタッチされているため、 Red Hat OpenShift on IBM Cloud クラスタ管理者はアカウント VNI のアタッチメントに対する可視性が異なります。 VNI管理の違いについては、このドキュメントで取り上げている。

スタンドアロンVPCベアメタルインスタンス上のVNIの詳細については、 仮想ネットワークインターフェースについてを 参照してください。

プライマリUDNの作成

プライマリユーザー定義ネットワークをポッドまたは 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

次に、それを使用するネームスペースを作成します。 名前空間は、プライマリUDNを使用するために、作成時に特定のラベル（ k8s.ovn.org/primary-user-defined-network ）が含まれていなければならない。

次に例を示します。

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 アドオンによって管理されています。 Virtualization Service を使用している場合は、この手順をスキップしてください。

1. Red Hat OpenShift on IBM Cloud コンソールの OperatorHub から、または 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. カスタム・リソースのステータスを確認し、該当するすべてのクラスタ・ノードがブリッジ・マッピング要求を照合するまで待ちます。

localnetユーザー定義ネットワークの作成

選択したVLANを使用して、VNIからのトラフィックを利用可能にするUDNまたは ClusterUserDefinedNetwork （CUDN）を作成します。

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. 適切なサブネットとIPアドレス構成で VPC内にVNIを作成 します。

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.

なぜ通常のポッドをローカルネットのUDNにアタッチできないのですか？

ローカルネットUDNは、OVN側でIPアドレス管理（IPAM）が無効になっているため、OVNからポッドへの静的IPアドレスの割り当ては行われない。 この構成は、DHCPを使用するか、ゲスト・オペレーティング・システム内で静的IPを設定する VM ワークロード用に設計されている。 これらのオプションは、ポッドワークロードでは利用できない。

なぜワーカープール間でライブマイグレーションが保留されているのか？

異なるワーカープールには、世代も能力も異なるCPUを搭載した異なるワーカーフレーバーがあるかもしれない。 CPUの全機能セットが VM ワークロードに透過的に見える場合、 VM、CPUの全機能をサポートしていない別のワーカーにライブマイグレーションすることはできません。 Worker のフレーバー間の互換性を高めるために、ゲスト OS の目に見える CPU 機能を最初に制限することができます。

ダイナミック・アタッチドVNIが機能しないのはなぜですか？

以下の項目を確認してください。

• CUDNのVLAN IDがVNIアタッチメントのVLAN IDと一致していることを確認する。 VPCのDHCPは、VLANが不一致の場合でも、それ以上のトラフィックが発生せずに動作する可能性があります。
• フローティングが有効になっていない場合は、VNI がアタッチされているワーカー上でワークロードがスケジュールされていることを確認してください。
• 専用 OVS ブリッジとマッピングがワーカーに存在することを確認する。 NodeNetworkConfigurationPolicy リソースのステータスをチェックする。