デプロイメントのプランニング

Red Hat OpenShift Data Foundation を Red Hat OpenShift Container Platform 内にすべてデプロイすると、Operator ベースのデプロイメントおよび管理からのすべての利点が得られます。グラフィカルユーザーインターフェイス (GUI) で内部接続デバイス方式を使用すると、Local Storage Operator とローカルストレージデバイスを使用して、Red Hat OpenShift Data Foundation を内部モードでデプロイできます。

デプロイメントおよび管理の容易性は、OpenShift Data Foundation サービスを OpenShift Container Platform の内部で実行することに関する主な特長となっています。Red Hat OpenShift Data Foundation が完全に Red Hat OpenShift Container Platform 内で実行されている場合、以下の 2 つのデプロイメントモードを使用できます。

Simple (単純) デプロイメントは、以下のような場合に最も適しています。

Red Hat OpenShift Data Foundation をアプリケーションと共存させるには、ノードにローカルストレージデバイス、または EC2 の EBS ボリューム、VMware の vSphere 仮想ボリューム、SAN ボリュームなどのポータブルストレージデバイスを動的に接続する必要があります。

最適化アプローチは、以下の場合に最も適しています。

Red Hat OpenShift Data Foundation は、OpenShift Container Platform クラスター外で実行されている Red Hat Ceph Storage サービスをストレージクラスとして公開します。

以下の場合に外部アプローチが最も適しています。

Red Hat OpenShift Data Foundation は、ストレージクラスター内のディスクおよび Multicloud Object Gateway 操作のすべてに対して、クラスター全体の暗号化 (保存時の暗号化、encryption-at-rest) をサポートします。OpenShift Data Foundation は、キーのサイズが 512 ビットの Linux Unified Key System (LUKS) バージョン 2 ベースの暗号化と、各デバイスが異なる暗号化キーを持つ aes-xts-plain64 暗号を使用します。このキーは Kubernetes シークレットまたは外部 KMS を使用して保存されます。どちらのメソッドも同時に使用できず、メソッド間の移行はできません。

ブロックおよびファイルストレージの暗号化は、デフォルトで無効になっています。デプロイメント時にクラスターの暗号化を有効にできます。MultiCloud Object Gateway は、デフォルトで暗号化をサポートしています。詳細は、デプロイメントガイドを参照してください。

クラスター全体の暗号化は、鍵管理システム (KMS) を使用しない OpenShift Data Foundation 4.6 でサポートされます。OpenShift Data Foundation 4.7 以降では、HashiCorp Vault KMS の有無にかかわらずサポートされます。OpenShift Data Foundation 4.12 以降では、HashiCorp Vault KMS および Thales CipherTrust Manager KMS の有無にかかわらずサポートされます。

一般的なセキュリティープラクティスでは、定期的な暗号鍵のローテーションが求められます。Red Hat OpenShift Data Foundation は、Kubernetes シークレット (KMS 以外) に保存されている暗号鍵を毎週自動的にローテーションします。

HashiCorp Vault KMS を使用したクラスター全体の暗号化には、次の 2 つの認証方法があります。

デバイスの暗号化キーを保存するために外部の鍵管理システム (KMS) を使用して、ストレージクラスの暗号化で永続ボリューム (ブロックのみ) を暗号化できます。永続ボリュームの暗号化は RADOS Block Device (RBD) 永続ボリュームでのみ利用できます。永続ボリュームの暗号化を使用したストレージクラスの作成方法 を参照してください。

ストレージクラスの暗号化は、HashiCorp Vault KMS を使用する OpenShift Data Foundation 4.7 以降でサポートされます。ストレージクラスの暗号化は、HashiCorp Vault KMS と Thales CipherTrust Manager KMS の両方を使用する OpenShift Data Foundation 4.12 以降でサポートされます。

Red Hat OpenShift Data Foundation バージョン 4.12 では、デプロイメントの追加の鍵管理システム (KMS) プロバイダーとして Thales CipherTrust Manager が導入されています。Thales CipherTrust Manager は、一元化された鍵のライフサイクル管理を提供します。CipherTrust Manager は、鍵管理システム間の通信を可能にする Key Management Interoperability Protocol (KMIP) をサポートしています。

CipherTrust Manager は、デプロイメント時に有効になります。

OpenShift Data Foundation バージョン 4.14 以降、Red Hat Ceph Storage のメッセンジャーバージョン 2 プロトコルを使用して、転送中のデータを暗号化できるようになりました。これにより、インフラストラクチャーに重要なセキュリティー要件が提供されます。

転送中の暗号化は、クラスターの作成中、デプロイ時に有効にできます。クラスターの作成中に転送中のデータ暗号化を有効にする手順については、ご使用の環境の デプロイメントガイド を参照してください。

msgr2 プロトコルは、次の 2 つの接続モードをサポートしています。

crc

secure

デフォルトのモードは crc です。

現時点で特定のシステムが 1 つまたは複数のコアを消費するかどうかに関する決定は、同時マルチスレッド (SMT) のレベルによって異なります。IBM Power は、以下の表にあるように、各コアの同時マルチスレッドレベルの 1、2、4、または 8 を提供します。これは vCPU の数に対応します。

SMT が設定されたシステムでは、サブスクリプションに必要なコア数の計算は SMT レベルによって異なります。したがって、2 コアのサブスクリプションは、上記の表に示すように SMT レベル 1 の 2 vCPU に対応し、SMT レベル 2 の 4 vCPU に、SMT レベル 4 では 8 vCPU に、SMT レベル 8 では 16 vCPU に対応します。大規模な仮想マシン (VM) には 16 vCPU が含まれる場合があります。この場合、SMT レベル 8 では SMT レベルで vCPU の # を除算した計算により 2 コアサブスクリプションが必要になります (SMT-8 の場合: 16 vCPU/8 = 2)。サブスクリプションは 2 コア単位で提供されるため、これらの 2 コアまたは 16 vCPU に対応するには 1 つの 2 コアサブスクリプションが必要になります。

IBM Power には、共有プロセッサープールの概念があります。共用プロセッサープール内のプロセッサーは、クラスター内のノード間で共有できます。Red Hat OpenShift Data Foundation に必要な集約コンピュート容量はコアのペアの倍数である必要があります。

Red Hat OpenShift Data Foundation 内部クラスターのみをサポートします。

内部クラスターは、ストレージデバイス要件 の両方を満たし、aws-ebs プロビジョナー経由で EBS ストレージを提供するストレージクラスを備えている必要があります。

OpenShift Data Foundation は、Amazon Web Services (AWS) によって導入された gp2-csi および gp3-csi ドライバーをサポートします。これらのドライバーは、より優れたストレージ拡張機能と割引された月額料金 (gp3-csi) を提供します。ストレージクラスを選択するときに、新しいドライバーを選択できるようになりました。高いスループットが必要な場合は、OpenShift Data Foundation をデプロイするときに gp3-csi を使用することを推奨します。

高い 1 秒あたりの入出力操作 (IOPS) が必要な場合、推奨される EC2 インスタンスタイプは D2 または D3 です。

内部クラスターをサポートし、外部クラスターの使用をサポートします。

内部クラスターは、ストレージデバイスの要件 を満たし、Local Storage Operator 経由でローカル SSD (NVMe/SATA/SAS、SAN) を提供するストレージクラスを備えている必要があります。

内部クラスターをサポートし、外部クラスターの使用をサポートします。

推奨されるバージョン:

詳細は、VMware vSphere インフラストラクチャーの要件 を参照してください。

さらに、内部クラスターは、ストレージデバイス要件 を満たし、次のいずれかを提供するストレージクラスを備えている必要があります。

Red Hat OpenShift Data Foundation 内部クラスターのみをサポートします。

内部クラスターは、ストレージデバイス要件 を満たし、azure-disk プロビジョナー経由で Azure ディスクを提供するストレージクラスを備えている必要があります。

Red Hat OpenShift Data Foundation 内部クラスターのみをサポートします。

内部クラスターは、ストレージデバイス要件 の両方を満たし、gce-pd プロビジョナー経由で GCE Persistent Disk を提供するストレージクラスを備えている必要があります。

内部 Red Hat OpenShift Data Foundation クラスターをサポートし、外部クラスターを使用します。

内部クラスターは、ストレージデバイス要件 を満たし、Cinder プロビジョナー経由で標準ディスクを提供するストレージクラスを備えている必要があります。

内部 Red Hat OpenShift Data Foundation クラスターをサポートし、外部クラスターを使用します。

内部クラスターは、ストレージデバイスの要件 を満たし、Local Storage Operator 経由でローカル SSD (NVMe/SATA/SAS、SAN) を提供するストレージクラスを備えている必要があります。

内部 Red Hat OpenShift Data Foundation クラスターをサポートします。また、Red Hat Ceph Storage が x86 上で実行される外部モードもサポートします。

内部クラスターは、ストレージデバイスの要件 を満たし、Local Storage Operator 経由でローカル SSD (NVMe/SATA/SAS、SAN) を提供するストレージクラスを備えている必要があります。

内部クラスターをサポートし、外部クラスターの使用をサポートします。

内部クラスターは、ストレージデバイスの要件 を満たし、Local Storage Operator 経由でローカル SSD (NVMe/SATA/SAS、SAN) を提供するストレージクラスを備えている必要があります。

Red Hat OpenShift Data Foundation サポートおよび相互運用性チェッカー のラボにアクセスして外部モードの Red Hat OpenShift Data Foundation および Red Hat Ceph Storage (RHCS) のサポートと相互運用性を確認する。

RHCS クラスターのインストール方法は、インストールガイド を参照してください。

IBM FlashSystem を他のプロバイダーのプラグ可能な外部ストレージとして使用するには、最初に OpenShift Data Foundation をデプロイする必要があります。これは、IBM FlashSystem ストレージクラスをバッキングストレージとして使用します。

サポートされている最新の FlashSystem ストレージシステムとバージョンは、IBM ODF FlashSystem ドライバーのドキュメント を参照してください。

OpenShift Data Foundation をデプロイする方法は、Creating an OpenShift Data Foundation Cluster for external IBM FlashSystem storage を参照してください。

Red Hat OpenShift Data Foundation のサービスは、ベースサービスの初期セットで構成されており、追加のデバイスセットで拡張できます。

これらの Red Hat OpenShift Data Foundation サービス Pod はすべて、OpenShift Container Platform ノード上の kubernetes によってスケジュールされます。クラスターを (障害ドメインごとに 1 ノード) 3 の倍数に拡張する方法は、Pod の配置ルールを簡単に満たす方法です。

OpenShift Data Foundation クラスターは、標準のデプロイメントリソース要件を満たしていない場合に、最小の設定でデプロイされます。

デバイスセットを追加する場合は、最小デプロイメントを標準デプロイメントに変換することが推奨されます。

Red Hat OpenShift Data Foundation は、3 ノードの OpenShift のコンパクトなベアメタルクラスターにインストールできます。ここでは、すべてのワークロードが 3 つの強力なマスターノードで実行されます。ワーカーノードまたはストレージノードは含まれません。

コンパクトのベアメタルクラスターで OpenShift Container Platform を設定するには、3 ノードクラスターの設定 および エッジデプロインメントの 3 ノードアーキテクチャーの提供を参照してください。

Multicloud Object Gateway (MCG) コンポーネントのみを使用してデプロイされた OpenShift Data Foundation クラスターは、デプロイメントに柔軟性を提供し、リソース消費を削減するのに役立ちます。

Network File System (NFS) を使用してエクスポートを作成すると、OpenShift クラスターから外部からアクセスできます。この機能を使用する場合、NFS サービスは 3 つの CPU と 8Gi の RAM を消費します。NFS はオプションであり、デフォルトでは無効になっています。

NFS ボリュームには、次の 2 つの方法でアクセスできます。

NFS 機能の詳細は、NFS を使用したエクスポートの作成 を参照してください。

OpenShift Data Foundation は、クラスターのパフォーマンスを向上させる 3 つのパフォーマンスプロファイルを提供します。利用可能なリソースと、デプロイ時またはデプロイ後に必要なパフォーマンスレベルに基づいて、これらのプロファイルの 1 つを選択できます。

Red Hat OpenShift Data Foundation では、動的ストレージデバイスサイズの要求サイズとして 0.5 TiB、2 TiB または 4 TiB の容量を選択できます。ノードごとに実行できる動的ストレージデバイスの数は、ノードのサイズ、基盤となるプロビジョナーの制限、および リソース要件 によって決まります。

ローカルストレージのデプロイメントの場合、16 TiB 以下のディスクサイズを使用でき、すべてのディスクが同じサイズおよび種類である必要があります。ノードごとに実行できるローカルストレージデバイスの数は、ノードのサイズと リソース要件 によって決まります。クラスターを (障害ドメインごとに 1 ノード) 3 の倍数に拡張する方法は、Pod の配置ルール を簡単に満たす方法です。

使用する前に、利用可能なストレージ容量を必ず確保するようにしてください。利用可能なストレージ容量が完全に使い切られる場合はリカバリーが難しく、単に容量を追加したり、コンテンツを削除したり、移行したりするよりも多くの介入が必要になります。

容量アラートは、クラスターストレージ容量が合計容量の 75% (ほぼ一杯) および 85% (一杯) になると発行されます。容量に関する警告に常に迅速に対応し、ストレージを定期的に確認して、ストレージ領域が不足しないようにします。75% (ほぼフル) に達したら、スペースを解放するか、クラスターを拡張します。85% (フル) アラートに達すると、ストレージ領域が完全に不足していて、標準コマンドを使用して領域を解放できないことが示唆されます。この時点で、Red Hat カスタマーサポート にお問い合わせください。

次の表は、動的ストレージデバイスを使用した Red Hat OpenShift Data Foundation のノード設定の例を示しています。

Ceph-CSI が Multus 対応の CephCluster と通信するには、Kubernetes ホストに設定が必要です。

以下の前提条件を満たすには、Multus ネットワークの設定方法と Rook による使用方法の理解が必要です。このセクションは、発生する可能性のある疑問を明確にするのに役立ちます。

次の 2 つの基本要件を満たす必要があります。

これら 2 つの要件は、さらに次のように細分化できます。

ノード設定と Pod 設定は相互に関連しており、密接に結び付いています。両方を同時に計画する必要があります。どちらも OpenShift Data Foundation で Multus パブリックネットワークをサポートするのに不可欠です。

“パブリックネットワークインターフェイス” は両方で同じである必要があります。一般的に、接続テクノロジー (Macvlan) も両方で同じである必要があります。NetworkAttachmentDefinition 内の IP 範囲は、ノード上のルートとしてエンコードする必要があります。ミラーでは、ノードの IP 範囲は NetworkAttachmentDefinition 内のルートとしてエンコードする必要があります。

一部のインストールでは、Pod とノードの両方に同じパブリックネットワーク IP アドレス範囲を使用しない場合があります。Pod とノードに異なる範囲がある場合は、各範囲が他の範囲にルーティングされ、単一の連続したネットワークとして機能するように、追加の手順を実行する必要があります。これらの要件には慎重な計画が必要です。これらの要件を理解して実装するには、Multus の例 を参照してください。

OpenShift Container Platform では、ホストの要件を満たすようにホストを設定する適切な方法として、NMState Operator の NodeNetworkConfigurationPolicies を使用することを推奨しています。必要に応じて他の方法も使用できます。

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: multus-public-test
 namespace: openshift-storage
 labels:
   app: multus-public-test
spec:
 selector:
   matchLabels:
     app: multus-public-test
 template:
   metadata:
     labels:
       app: multus-public-test
     annotations:
       k8s.v1.cni.cncf.io/networks: openshift-storage/public-net #
   spec:
     containers:
       - name: test
         image: quay.io/ceph/ceph:v18 # image known to have ‘ping’ installed
         command:
           - sleep
           - infinity
         resources: {}

$ oc -n openshift-storage describe pod -l app=multus-public-test | grep -o -E 'Add .* from .*'
Add eth0 [10.128.2.86/23] from ovn-kubernetes
Add net1 [192.168.20.22/24] from default/public-net
Add eth0 [10.129.2.173/23] from ovn-kubernetes
Add net1 [192.168.20.29/24] from default/public-net
Add eth0 [10.131.0.108/23] from ovn-kubernetes
Add net1 [192.168.20.23/24] from default/public-net

$ oc debug node/NODE
Starting pod/NODE-debug ...
To use host binaries, run `chroot /host`
Pod IP: ****
If you don't see a command prompt, try pressing enter.


sh-5.1# chroot /host


sh-5.1# ping 192.168.20.22
PING 192.168.20.22 (192.168.20.22) 56(84) bytes of data.
64 bytes from 192.168.20.22: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 192.168.20.22: icmp_seq=2 ttl=64 time=0.056 ms
^C
--- 192.168.20.22 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1046ms
rtt min/avg/max/mdev = 0.056/0.074/0.093/0.018 ms


sh-5.1# ping 192.168.20.29
PING 192.168.20.29 (192.168.20.29) 56(84) bytes of data.
64 bytes from 192.168.20.29: icmp_seq=1 ttl=64 time=0.403 ms
64 bytes from 192.168.20.29: icmp_seq=2 ttl=64 time=0.181 ms
^C
--- 192.168.20.29 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1007ms
rtt min/avg/max/mdev = 0.181/0.292/0.403/0.111 ms


sh-5.1# ping 192.168.20.23
PING 192.168.20.23 (192.168.20.23) 56(84) bytes of data.
64 bytes from 192.168.20.23: icmp_seq=1 ttl=64 time=0.329 ms
64 bytes from 192.168.20.23: icmp_seq=2 ttl=64 time=0.227 ms
^C
--- 192.168.20.23 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1047ms
rtt min/avg/max/mdev = 0.227/0.278/0.329/0.051 ms

このクラスターに関連するネットワークプランは次のとおりです。

ノードのネットワークポリシーは、Multus パブリックネットワーク上の Pod にルーティングするように設定する必要があります。

Pod は Macvlan 経由で接続され、Macvlan ではホストと Pod が相互にルーティングできないため、ホストも Macvlan 経由で接続する必要があります。一般的に、ホストは Pod と同じテクノロジーを使用して Multus パブリックネットワークに接続する必要があります。Pod 接続は、ネットワークアタッチメント定義で設定されます。

ホストの IP 範囲は、範囲全体のサブセットであるため、ホストは IP 割り当てだけでは Pod にルーティングできません。ホストが 192.168.0.0/16 の範囲全体にルーティングできるようにするには、ホストにルートを追加する必要があります。

NodeNetworkConfigurationPolicy の desiredState 仕様は次のようになります。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
 name: ceph-public-net-shim-compute-0
 namespace: openshift-storage
spec:
 nodeSelector:
   node-role.kubernetes.io/worker: ""
   kubernetes.io/hostname: compute-0
 desiredState:
   interfaces:
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan
       state: up
       mac-vlan:
         base-iface: eth0
         mode: bridge
         promiscuous: true
       ipv4:
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.1 # STATIC IP FOR compute-0
             prefix-length: 22
   routes:
     config:
       - destination: 192.168.0.0/16
         next-hop-interface: odf-pub-shim
---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
 name: ceph-public-net-shim-compute-1
 namespace: openshift-storage
spec:
 nodeSelector:
   node-role.kubernetes.io/worker: ""
   kubernetes.io/hostname: compute-1
 desiredState:
   interfaces:
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan
       state: up
       mac-vlan:
         base-iface: eth0
         mode: bridge
         promiscuous: true
       ipv4:
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.1 # STATIC IP FOR compute-1
             prefix-length: 22
   routes:
     config:
       - destination: 192.168.0.0/16
         next-hop-interface: odf-pub-shim
---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
 name: ceph-public-net-shim-compute-2 # [1]
 namespace: openshift-storage
spec:
 nodeSelector:
   node-role.kubernetes.io/worker: ""
   kubernetes.io/hostname: compute-2 # [2]
 desiredState:
   Interfaces: [3]
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan # [4]
       state: up
       mac-vlan:
         base-iface: eth0 # [5]
         mode: bridge
         promiscuous: true
       ipv4: # [6]
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.2 # STATIC IP FOR compute-2 # [7]
             prefix-length: 22
   routes: # [8]
     config:
       - destination: 192.168.0.0/16 # [9]
         next-hop-interface: odf-pub-shim

パブリックネットワークの NetworkAttachmentDefinition は、次のようになります。ここでは、range 要求を簡素化するために、Whereabouts の exclude オプションを使用しています。Whereabouts の routes[].dst オプションにより、Pod が Multus パブリックネットワーク経由でホストにルーティングされるようになります。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
 name: public-net
 namespace: openshift-storage
spec:
 config: '{
     "cniVersion": "0.3.1",
     "type": "macvlan", # [1]
     "master": "eth0", # [2]
     "mode": "bridge",
     "ipam": {
       "type": "whereabouts", # [3]
       "range": "192.168.0.0/16", # [4]
       "exclude": [
          "192.168.252.0/22" # [5]
       ],
       "routes": [              # [6]
         {"dst": "192.168.252.0/22"} # [7]
       ]
     }
   }'

アップグレード時にホルダー Pod のメンテナンスの影響が繰り返し発生するため (ホルダー Pod は Multus が有効な場合に存在します)、ホルダー Pod は ODF v4.16 リリースで非推奨となり、ODF v4.17 リリースで削除される予定です。この非推奨化に伴い、ホルダー Pod を削除する前に、追加のネットワーク設定アクションを完了する必要があります。ODF v4.15 の Multus が有効になっているクラスターを、標準のアップグレード手順に従って v4.16 にアップグレードします。ODF クラスター (Multus が有効) を v4.16 に正常にアップグレードした後、管理者は記事 Disabling Multus holder pods に記載されている手順を完了して、ホルダー Pod を無効化および削除する必要があります。この無効化手順は時間がかかることに注意してください。ただし、v4.16 にアップグレードした直後にすべての手順を完了する必要はありません。ODF を v4.17 にアップグレードする前に、このプロセスを完了することが重要です。

デフォルトで、Red Hat OpenShift Data Foundation は Red Hat OpenShift Software Defined Network (SDN) を使用するように設定されています。デフォルトの SDN には、以下のトラフィックタイプがあります。

OpenShift Data Foundation を OpenShift のデフォルトネットワークから分離する方法は 3 つあります。

以下が必要な場合は、OpenShift Data Foundation に Multus を使用します。

遅延の改善 - ODF を使用した Multus は常に遅延を改善します。ホストインターフェイスをホストネットワークに近い速度で使用し、OpenShift のソフトウェア定義の Pod ネットワークをバイパスします。各インターフェイスのインターフェイスレベルごとの Linux チューニングを実行することもできます。

帯域幅の向上 - OpenShift Data Foundation クライアントデータトラフィックと内部データトラフィックの専用インターフェイス。これらの専用インターフェイスは、完全な帯域幅を予約します。

セキュリティーの向上 - Multus は、ストレージネットワークトラフィックをアプリケーションネットワークトラフィックから分離して、セキュリティーを強化します。ネットワークがインターフェイスを共有している場合、帯域幅またはパフォーマンスが分離されない場合がありますが、QoS またはトラフィックシェーピングを使用して、共有インターフェイス上の帯域幅に優先順位を付けることができます。

Multus を使用するには、OpenShift Data Foundation クラスターをデプロイする前にネットワーク接続定義 (NAD) を作成する必要があります。これは後でクラスターに接続されます。詳細は、ネットワークアタッチメント定義の作成 を参照してください。

追加のネットワークを Pod に割り当てるには、インターフェイスの割り当て方法を定義する設定を作成する必要があります。それぞれのインターフェイスは、NetworkAttachmentDefinition カスタムリソース (CR) を使用して指定します。これらの各 CR 内のコンテナーネットワークインターフェイス (CNI) 設定は、対象のインターフェイスの作成方法を定義します。

OpenShift Data Foundation は、次の機能を含む macvlan ドライバーをサポートしています。

OpenShift Data Foundation は、次の 2 つのタイプの IP アドレス管理をサポートします。

ベアメタルで Multus ベースの設定に必要な手順については、Multus ネットワークの作成 を参照してください。