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 ファイルは、イーサネットインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: eth1-policy 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
    - name: eth1 
4

      description: Configuring eth1 on node01 
5

      type: ethernet 
6

      state: up 
7

      ipv4:
        dhcp: true 
8

        enabled: true 
9
Copy to Clipboard Toggle word wrap
1
ポリシーの名前。
2
オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。
3
この例では、hostname ノードセレクターを使用します。
4
インターフェイスの名前。
5
オプション: 人間が判読できるインターフェイスの説明。
6
インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
7
作成後のインターフェイスの要求された状態。
8
オプション: dhcp を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。
9
この例では ipv4 を有効にします。

1.7.2. 例: Linux ブリッジインターフェイスノードネットワーク設定ポリシー

NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してクラスター内のノード上に Linux ブリッジインターフェイスを作成します。

以下の YAML ファイルは、Linux ブリッジインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br1-eth1-policy 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
      - name: br1 
4

        description: Linux bridge with eth1 as a port 
5

        type: linux-bridge 
6

        state: up 
7

        ipv4:
          dhcp: true 
8

          enabled: true 
9

        bridge:
          options:
            stp:
              enabled: false 
10

          port:
            - name: eth1 
11
Copy to Clipboard Toggle word wrap
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 インターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: vlan-eth1-policy 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
    - name: eth1.102 
4

      description: VLAN using eth1 
5

      type: vlan 
6

      state: up 
7

      vlan:
        base-iface: eth1 
8

        id: 102 
9
Copy to Clipboard Toggle word wrap
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 ファイルは、ボンドインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: bond0-eth1-eth2-policy 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
    - name: bond0 
4

      description: Bond with ports eth1 and eth2 
5

      type: bond 
6

      state: up 
7

      ipv4:
        dhcp: true 
8

        enabled: true 
9

      link-aggregation:
        mode: active-backup 
10

        options:
          miimon: '140' 
11

        port: 
12

        - eth1
        - eth2
      mtu: 1450 
13
Copy to Clipboard Toggle word wrap
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 を作成します。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: bond-vlan 
1

spec:
  nodeSelector: 
2

    kubernetes.io/hostname: <node01> 
3

  desiredState:
    interfaces:
    - name: bond10 
4

      description: Bonding eth2 and eth3 
5

      type: bond 
6

      state: up 
7

      link-aggregation:
        mode: balance-xor 
8

        options:
          miimon: '140' 
9

        port: 
10

        - eth2
        - eth3
    - name: bond10.103 
11

      description: vlan using bond10 
12

      type: vlan 
13

      state: up 
14

      vlan:
         base-iface: bond10 
15

         id: 103 
16

      ipv4:
        dhcp: true 
17

        enabled: true 
18
Copy to Clipboard Toggle word wrap
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 には、独自の情報に置き換える必要があるサンプル値が含まれています。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: qos 
1

spec:
  nodeSelector: 
2

    node-role.kubernetes.io/worker: "" 
3

  desiredState:
    interfaces:
      - name: ens1f0 
4

        description: Change QOS on VF0 
5

        type: ethernet 
6

        state: up 
7

        ethernet:
         sr-iov:
           total-vfs: 3 
8

           vfs:
           - id: 0 
9

             max-tx-rate: 200 
10
Copy to Clipboard Toggle word wrap
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 を直接管理するように設定されています。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: addvf 
1

spec:
  nodeSelector: 
2

    node-role.kubernetes.io/worker: "" 
3

  maxUnavailable: 3
  desiredState:
    interfaces:
      - name: ens1f1 
4

        type: ethernet
        state: up
        ethernet:
            sr-iov:
              total-vfs: 1 
5

              vfs:
                - id: 0
                  trust: true 
6

                  vlan-id: 477 
7

      - name: bond0 
8

        description: Attach VFs to bond 
9

        type: bond 
10

        state: up 
11

        link-aggregation:
          mode: active-backup 
12

          options:
            primary: ens1f0v0 
13

          port: 
14

            - ens1f0v0
            - ens1f1v0 
15
Copy to Clipboard Toggle word wrap
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 ネットワークインターフェイスが、ボンディングされたネットワークインターフェイスへの追加インターフェイスとして追加されます。

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 インスタンスをネットワークインターフェイスに関連付ける例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: vrfpolicy 
1

spec:
  nodeSelector:
    vrf: "true" 
2

  maxUnavailable: 3
  desiredState:
    interfaces:
      - name: ens4vrf 
3

        type: vrf 
4

        state: up
        vrf:
          port:
            - ens4 
5

          route-table-id: 2 
6
Copy to Clipboard Toggle word wrap
1
ポリシーの名前。
2
この例では、vrf:true のラベルが割り当てられたべてのノードにポリシーを適用します。
3
インターフェイスの名前。
4
インターフェイスのタイプ。この例では VRF インスタンスを作成します。
5
VRF が接続されるノードインターフェイス。
6
VRF のルートテーブル ID の名前。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat