1.7. 異なるインターフェイスのポリシー設定の例
ポリシーをノードに適用する場合は、さまざまな NodeNetworkConfigurationPolicy
(NNCP) マニフェスト設定例を読む前に、クラスターが最適なパフォーマンス状態で実行されるように次の要素を考慮してください。
-
ポリシーを複数のノードに適用する必要がある場合は、ターゲットノードごとに
NodeNetworkConfigurationPolicy
マニフェストを作成します。Kubernetes NMState Operator は、定義済みの NNCP を持つ各ノードにポリシーを不特定の順序で適用します。この方法でポリシーのスコープを設定すると、ポリシーの適用にかかる時間が短縮されますが、クラスターの設定にエラーがある場合はクラスター全体が停止するリスクがあります。この種のエラーを回避するには、最初に一部のノードに NNCP を適用し、これらのノードに対して NNCP が正しく設定されていることを確認してから、残りのノードにポリシーを適用します。 -
多数のノードにポリシーを適用する必要があるが、すべてのノードに対して 1 つの NNCP のみを作成する場合、Kubernetes NMState Operator は各ノードにポリシーを順番に適用します。クラスターの設定ファイルの
maxUnavailable
パラメーターを使用して、ターゲットノードに対するポリシー適用の速度と範囲を設定できます。パラメーターのパーセンテージ値を低く設定すると、ポリシー適用を受信しているノードのごく一部に障害が影響する場合に、クラスター全体の障害が発生するリスクを軽減できます。 -
2 つの NNCP マニフェストで
maxUnavailable
パラメーターを50%
に設定すると、ポリシー設定がクラスター内のノードの 100% に適用されます。 - ノードが再起動すると、Kubernetes NMState Operator はノードにポリシーを適用する順序を制御できなくなります。Kubernetes NMState Operator は、相互依存するポリシーを順番に適用する場合があります。その結果、ネットワークオブジェクトがデグレード状態になることがあります。
- 関連するすべてのネットワーク設定を 1 つのポリシーで指定することを検討してください。
1.7.1. 例: イーサネットインターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してクラスター内のノードにイーサネットインターフェイスを作成します。
以下の YAML ファイルは、イーサネットインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostname
ノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcp
を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4
を有効にします。
1.7.2. 例: Linux ブリッジインターフェイスノードネットワーク設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してクラスター内のノード上に Linux ブリッジインターフェイスを作成します。
以下の YAML ファイルは、Linux ブリッジインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostname
ノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、ブリッジを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcp
を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4
を有効にします。 - 10
- この例では
stp
を無効にします。 - 11
- ブリッジが接続されるノードの NIC。
1.7.3. 例: VLAN インターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してクラスター内のノード上に VLAN インターフェイスを作成します。
1 つの NodeNetworkConfigurationPolicy
マニフェストで、ノードの VLAN インターフェイスに関連するすべての設定を定義します。たとえば、同じ NodeNetworkConfigurationPolicy
マニフェストで、ノードの VLAN インターフェイスと VLAN インターフェイスの関連ルートを定義します。
ノードが再起動すると、Kubernetes NMState Operator はポリシーを適用する順序を制御できません。したがって、関連するネットワーク設定に別々のポリシーを使用すると、Kubernetes NMState Operator がこれらのポリシーを順番に適用するため、ネットワークオブジェクトがデグレード状態になる可能性があります。
以下の YAML ファイルは、VLAN インターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostname
ノードセレクターを使用します。 - 4
- インターフェイスの名前。ベアメタルにデプロイする場合、
<interface_name>.<vlan_number>
VLAN 形式のみがサポートされます。 - 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。以下の例では VLAN を作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- VLAN が接続されているノードの NIC。
- 9
- VLAN タグ。
1.7.4. 例: ボンドインターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してノード上にボンドインターフェイスを作成します。
OpenShift Container Platform は以下の bond モードのみをサポートします。
-
mode=1 active-backup
-
mode=2 balance-xor
-
mode=4 802.3ad
その他のボンディングモードはサポートされていません。
以下の YAML ファイルは、ボンドインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostname
ノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、ボンドを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcp
を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4
を有効にします。 - 10
- ボンドのドライバーモード。この例では、アクティブなバックアップモードを使用します。
- 11
- オプション: この例では、miimon を使用して 140ms ごとにボンドリンクを検査します。
- 12
- ボンド内の下位ノードの NIC。
- 13
- オプション: ボンドの Maximum Transmission Unit (MTU)指定がない場合、この値はデフォルトで
1500
に設定されます。
1.7.5. 例: 同じノードネットワーク設定ポリシーでの複数のインターフェイス リンクのコピーリンクがクリップボードにコピーされました!
同じノードネットワーク設定ポリシーで複数のインターフェイスを作成できます。これらのインターフェイスは相互に参照でき、単一のポリシーマニフェストを使用してネットワーク設定をビルドし、デプロイできます。
以下の YAML ファイルの例では、2 つの NIC 間に bond10
という名前のボンドと、ボンドに接続する bond10.103
という名前の VLAN を作成します。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostname
ノードセレクターを使用します。 - 4 11
- インターフェイスの名前。
- 5 12
- オプション: 人間が判読できるインターフェイスの説明。
- 6 13
- インターフェイスのタイプ。
- 7 14
- 作成後のインターフェイスの要求された状態。
- 8
- ボンドのドライバーモード。
- 9
- オプション: この例では、miimon を使用して 140ms ごとにボンドリンクを検査します。
- 10
- ボンド内の下位ノードの NIC。
- 15
- VLAN が接続されているノードの NIC。
- 16
- VLAN タグ。
- 17
- オプション: dhcp を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。
- 18
- この例では ipv4 を有効にします。
1.7.6. 例: 仮想機能のノードネットワーク設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストを適用して、既存のクラスター内の Single Root I/O Virtualization (SR-IOV) ネットワーク Virtual Function (VF) のホストネットワーク設定を更新します。
NodeNetworkConfigurationPolicy
マニフェストを既存のクラスターに適用して、次のタスクを完了できます。
- VF の QoS ホストネットワークを設定して、パフォーマンスを最適化します。
- ネットワークインターフェイスの VF を追加、削除、または更新します。
- VF ボンディング設定を管理します。
SR-IOV Network Operator によっても管理されている Physical Function 上で、NMState を使用して SR-IOV VF のホストネットワーク設定を更新するには、関連する SriovNetworkNodePolicy
リソースの externallyManaged
パラメーターを true
に設定する必要があります。詳細は、関連情報 セクションを参照してください。
次の YAML ファイルは、VF の QoS ポリシーを定義するマニフェストの例です。この YAML には、独自の情報に置き換える必要があるサンプル値が含まれています。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例は、
worker
ロールを持つすべてのノードに適用されます。 - 4
- 物理機能 (PF) ネットワークインターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。
- 7
- 設定後のインターフェイスの要求された状態。
- 8
- VF の総数。
- 9
- ID
0
を持つ VF を識別します。 - 10
- VF の最大伝送速度 (Mbps) を設定します。このサンプル値は、200 Mbps のレートを設定します。
以下の YAML ファイルは、ネットワークインターフェイスに VF を追加するマニフェストの例です。
この設定例では、ens1f1v0
VF が ens1f1
物理インターフェイス上に作成され、この VF はボンディングされたネットワークインターフェイス bond0
に追加されます。ボンディングは、冗長性に active-backup
モードを使用します。この例では、VF は、ハードウェアオフロードを使用して物理インターフェイス上の VLAN を直接管理するように設定されています。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例は、
worker
ロールを持つすべてのノードに適用されます。 - 4
- VF ネットワークインターフェイスの名前。
- 5
- 作成する VF の数。
- 6
- アクティブな VF とバックアップ VF の間のフェイルオーバーボンディングを許可する設定。
- 7
- VLAN の ID。この例では、ハードウェアオフロードを使用して、VF 上で直接 VLAN を定義します。
- 8
- ボンディングネットワークインターフェイスの名前。
- 9
- オプション: 人間が判読できるインターフェイスの説明。
- 10
- インターフェイスのタイプ。
- 11
- 設定後のインターフェイスの要求された状態。
- 12
- ボンディングのボンディングポリシー。
- 13
- 割り当てられたプライマリーボンディングポート。
- 14
- ボンディングされたネットワークインターフェイスのポート。
- 15
- この例では、VLAN ネットワークインターフェイスが、ボンディングされたネットワークインターフェイスへの追加インターフェイスとして追加されます。
1.7.7. 例: VRF インスタンスノードのネットワーク設定ポリシーを使用したネットワークインターフェイス リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
カスタムリソース (CR) を適用して、Virtual Routing and Forwarding (VRF) インスタンスをネットワークインターフェイスに関連付けます。
VRF インスタンスとネットワークインターフェイスの関連付けは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、お客様が、今後リリースされる製品の機能に早期にアクセスして、開発プロセス中に機能のテストやフィードバックを行えるようにするものです。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
VRF インスタンスをネットワークインターフェイスに関連付けることにより、トラフィックの分離、独立したルーティングの決定、およびネットワークリソースの論理的な分離をサポートできます。
仮想ルート転送 (VRF) を設定する場合、VRF 値を 1000
未満のテーブル ID に変更する必要があります。1000
より大きい値は OpenShift Container Platform 用に予約されているためです。
ベアメタル環境では、MetalLB を使用して、VRF インスタンスに属するインターフェイスを通じてロードバランサーサービスを通知できます。詳細は、関連情報 セクションを参照してください。
次の YAML ファイルは、VRF インスタンスをネットワークインターフェイスに関連付ける例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。