Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

29.2. ノードのネットワーク状態と設定の監視と更新

NMState Operator のインストール方法の詳細は、Kubernetes NMState Operator を参照してください。

29.2.1. ノードのネットワーク状態の表示
リンクのコピー

ノードのネットワーク状態は、クラスター内のすべてのノードのネットワーク設定です。NodeNetworkState オブジェクトはクラスター内のすべてのノードにあります。このオブジェクトは定期的に更新され、ノードのネットワークの状態を取得します。

手順

  1. クラスターのすべての NodeNetworkState オブジェクトをリスト表示します。 

    $ oc get nns
    Copy to Clipboard Toggle word wrap

  2. NodeNetworkState オブジェクトを検査して、そのノードにネットワークを表示します。この例の出力は、明確にするために編集されています。 

    $ oc get nns node01 -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: nmstate.io/v1
kind: NodeNetworkState
metadata:
  name: node01
    1 
    
status:
  currentState:
    2 
    
    dns-resolver:
# ...
    interfaces:
# ...
    route-rules:
# ...
    routes:
# ...
  lastSuccessfulUpdateTime: "2020-01-31T12:14:00Z"
    3
    Copy to Clipboard Toggle word wrap

    1
    NodeNetworkState オブジェクトの名前はノードから取られています。
    2
    currentState には、DNS、インターフェイス、およびルートを含む、ノードの完全なネットワーク設定が含まれます。
    3
    最後に成功した更新のタイムスタンプ。これは、ノードが到達可能であり、レポートの鮮度の評価に使用できる限り定期的に更新されます。

29.2.2. NodeNetworkConfigurationPolicy マニフェストファイル
リンクのコピー

NodeNetworkConfigurationPolicy (NNCP) マニフェストファイルは、Kubernetes NMState Operator が OpenShift Container Platform クラスター内に存在するノードのネットワークを設定するために使用するポリシーを定義します。

重要

複数の NNCP CR をノードに適用する場合は、ポリシー名の英数字の並べ替えに基づいた論理的な順序で NNCP を作成する必要があります。Kubernetes NMState Operator は、新しく作成された NNCP CR を継続的にチェックし、Operator が CR をノードに即座に適用できるようにします。次の論理順序の問題の例を考えてみましょう。

  1. eth1.1000 などの VLAN ポートをリッスンするブリッジインターフェイスを定義するために、NNCP 1 を作成します。
  2. VLAN インターフェイスを定義するために NNCP 2 を作成し、このインターフェイスのポート (eth1.1000 など) を指定します。
  3. NNCP 2 をノードに適用する前に、NNCP 1 を適用します。

ポート eth1.1000 が 存在しないため、ノードでノード接続の問題が発生しています。その結果、クラスターは失敗します。

ノードのネットワークポリシーをノードに適用すると、Kubernetes NMState Operator によって、ノードのネットワークポリシーの詳細に従ってノードのネットワークが設定されます。

OpenShift CLI (oc) または OpenShift Container Platform Web コンソールを使用して NNCP を作成できます。インストール後のタスクとして、NNCP を作成したり、既存の NNCP を編集したりできます。

注記

NNCP を作成する前に、「各種インターフェイスのポリシー設定例」のドキュメントを一読してください。

NNCP を削除する必要がある場合は、oc delete nncp コマンドを使用して削除アクションを完了できます。ただし、このコマンドではブリッジインターフェイスなどのオブジェクトは削除されません。

ノードにインターフェイスを追加したノードネットワークポリシーを削除しても、そのノード上のポリシー設定は変更されません。同様に、インターフェイスを削除してもポリシーは削除されません。これは、Pod またはノードが再起動されるたびに、Kubernetes NMState Operator が、削除されたインターフェイスを再度追加するためです。

NNCP、ノードネットワークポリシー、およびインターフェイスを実際に削除するには、通常、次の操作が必要です。

  1. NNCP を編集し、ファイルからインターフェイスの詳細を削除します。ファイルから name、state、type パラメーターは削除しないでください。
  2. NNCP の interfaces.state セクションに state: absent を追加します。
  3. oc apply -f <nncp_file_name> を実行します。Kubernetes NMState Operator がクラスター内の各ノードにノードネットワークポリシーを適用すると、各ノードに存在するすべてのインターフェイスが absent とマークされます。
  4. oc delete nncp を実行して NNCP を削除します。

関連情報

29.2.3. CLI を使用したポリシーの管理
リンクのコピー

29.2.3.1. ノード上でのインターフェイスの作成
リンクのコピー

NodeNetworkConfigurationPolicy (NNCP) マニフェストをクラスターに適用して、クラスター内のノードにインターフェイスを作成します。マニフェストには、インターフェイスの要求された設定の詳細が含まれます。

デフォルトでは、マニフェストはクラスター内のすべてのノードに適用されます。インターフェイスを特定ノードに追加するには、ノードセレクターの spec: nodeSelector パラメーターおよび適切な <key>:<value> を追加します。

複数の nmstate 対応ノードを同時に設定できます。この設定は、並列のノードの 50% に適用されます。このストラテジーでは、ネットワーク接続に障害が発生した場合にクラスター全体が使用できなくなるのを回避します。クラスターの特定の部分にポリシー設定を並行して適用するには、NodeNetworkConfigurationPolicy マニフェスト設定ファイルで maxUnavailable パラメーターを使用します。

注記

ノードが 2 つある場合に、maxUnavailable パラメーターを 50% に設定した NNCP マニフェストをこれらのノードに適用すると、1 つのノードに NNCP 設定が反映されます。その後、maxUnavailable パラメーターを 50% に設定した追加の NNCP マニフェストファイルを導入すると、この NCCP は最初の NNCP とは別に適用されます。つまり、2 つの NNCP マニフェストによってノードに不適切な設定が適用されると、クラスターの半分を確実に機能させることができなくなります。

手順

  1. NodeNetworkConfigurationPolicy マニフェストを作成します。以下の例は、すべてのワーカーノードで Linux ブリッジを設定し、DNS リゾルバーを設定します。 

    apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br1-eth1-policy
    1 
    
spec:
  nodeSelector:
    2 
    
    node-role.kubernetes.io/worker: ""
    3 
    
  maxUnavailable: 3
    4 
    
  desiredState:
    interfaces:
      - name: br1
        description: Linux bridge with eth1 as a port
    5 
    
        type: linux-bridge
        state: up
        ipv4:
          dhcp: true
          enabled: true
          auto-dns: false
        bridge:
          options:
            stp:
              enabled: false
          port:
            - name: eth1
    dns-resolver:
    6 
    
      config:
        search:
        - example.com
        - example.org
        server:
        - 8.8.8.8
    Copy to Clipboard Toggle word wrap
    1
    ポリシーの名前。
    2
    オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。
    3
    この例では node-role.kubernetes.io/worker: "" ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。
    4
    オプション: ポリシー設定を同時に適用できる nmstate 対応ノードの最大数を指定します。このパラメーターは、"10%" などのパーセンテージ値 (文字列)、または 3 などの絶対値 (数値) のいずれかに設定できます。
    5
    オプション: インターフェイスの人間が判読できる説明。
    6
    オプション:DNS サーバーの検索およびサーバー設定を指定します。

  2. ノードのネットワークポリシーを作成します。 

    $ oc apply -f br1-eth1-policy.yaml
    1
    Copy to Clipboard Toggle word wrap
    1
    ノードネットワーク設定ポリシーマニフェストのファイル名。

関連情報

29.2.4. ノード上でのノードネットワークポリシー更新の確認
リンクのコピー

ノードネットワークポリシーを適用する際に、NodeNetworkConfigurationEnactment オブジェクトがクラスター内のすべてのノードに作成されます。ノードネットワーク設定の enactment (実行) は、そのノードでのポリシーの実行ステータスを表す読み取り専用オブジェクトです。ポリシーがノードに適用されない場合、そのノードの enactment (実行) にはトラブルシューティングのためのトレースバックが含まれます。

手順

  1. ポリシーがクラスターに適用されていることを確認するには、ポリシーとそのステータスをリスト表示します。 

    $ oc get nncp
    Copy to Clipboard Toggle word wrap

  2. オプション: ポリシーの設定に想定されている以上の時間がかかる場合は、特定のポリシーの要求される状態とステータスの状態を検査できます。 

    $ oc get nncp <policy> -o yaml
    Copy to Clipboard Toggle word wrap

  3. オプション: ポリシーのすべてのノード上での設定に想定されている以上の時間がかかる場合は、クラスターの enactment (実行) のステータスをリスト表示できます。 

    $ oc get nnce
    Copy to Clipboard Toggle word wrap

  4. オプション: 特定の enactment (実行) の設定 (失敗した設定のエラーレポートを含む) を表示するには、以下を実行します。 

    $ oc get nnce <node>.<policy> -o yaml
    Copy to Clipboard Toggle word wrap

29.2.5. ノードからインターフェイスの削除
リンクのコピー

NodeNetworkConfigurationPolicy オブジェクトを編集し、インターフェイスの state を absent に設定して、クラスターの 1 つ以上のノードからインターフェイスを削除できます。

ノードからインターフェイスを削除しても、ノードのネットワーク設定は以前の状態に自動的に復元されません。以前の状態に復元する場合、そのノードのネットワーク設定をポリシーで定義する必要があります。

ブリッジまたはボンディングインターフェイスを削除すると、そのブリッジまたはボンディングインターフェイスに以前に接続されたか、それらの下位にあるノード NIC は down の状態になり、到達できなくなります。接続が失われないようにするには、同じポリシーでノード NIC を設定し、ステータスを up にし、DHCP または静的 IP アドレスのいずれかになるようにします。

注記

インターフェイスを追加したポリシーを削除しても、ノード上のポリシーの設定は変更されません。NodeNetworkConfigurationPolicy はクラスターのオブジェクトですが、このオブジェクトは要求される設定のみを表します。同様に、インターフェイスを削除してもポリシーは削除されません。

手順

  1. インターフェイスの作成に使用する NodeNetworkConfigurationPolicy マニフェストを更新します。以下の例は Linux ブリッジを削除し、接続が失われないように DHCP で eth1 NIC を設定します。 

    apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: <br1-eth1-policy>
    1 
    
spec:
  nodeSelector:
    2 
    
    node-role.kubernetes.io/worker: ""
    3 
    
  desiredState:
    interfaces:
    - name: br1
      type: linux-bridge
      state: absent
    4 
    
    - name: eth1
    5 
    
      type: ethernet
    6 
    
      state: up
    7 
    
      ipv4:
        dhcp: true
    8 
    
        enabled: true
    9
    Copy to Clipboard Toggle word wrap
    1
    ポリシーの名前。
    2
    オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。
    3
    この例では node-role.kubernetes.io/worker: "" ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。
    4
    状態を absent に変更すると、インターフェイスが削除されます。
    5
    ブリッジインターフェイスから接続が解除されるインターフェイスの名前。
    6
    インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
    7
    インターフェイスの要求された状態。
    8
    オプション: dhcp を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。
    9
    この例では ipv4 を有効にします。

  2. ノード上でポリシーを更新し、インターフェイスを削除します。 

    $ oc apply -f <br1-eth1-policy.yaml>
    1
    Copy to Clipboard Toggle word wrap
    1
    ポリシーマニフェストのファイル名。

29.2.6. 異なるインターフェイスのポリシー設定の例
リンクのコピー

ポリシーをノードに適用する場合は、さまざまな NodeNetworkConfigurationPolicy (NNCP) マニフェスト設定例を読む前に、クラスターが最適なパフォーマンス状態で実行されるように次の要素を考慮してください。

  • 複数の NNCP CR をノードに適用する場合は、ポリシー名の英数字の並べ替えに基づいた論理的な順序で NNCP を作成する必要があります。Kubernetes NMState Operator は、新しく作成された NNCP CR を継続的にチェックし、Operator が CR をノードに即座に適用できるようにします。
  • 多数のノードにポリシーを適用する必要があるが、すべてのノードに対して 1 つの NNCP のみを作成する場合、Kubernetes NMState Operator は各ノードにポリシーを順番に適用します。クラスターの設定ファイルの maxUnavailable パラメーターを使用して、ターゲットノードに対するポリシー適用の速度と範囲を設定できます。パラメーターのパーセンテージ値を低く設定すると、ポリシー適用を受信しているノードのごく一部に障害が影響する場合に、クラスター全体の障害が発生するリスクを軽減できます。
  • 2 つの NNCP マニフェストで maxUnavailable パラメーターを 50% に設定すると、ポリシー設定がクラスター内のノードの 100% に適用されます。
  • ノードが再起動すると、Kubernetes NMState Operator はノードにポリシーを適用する順序を制御できなくなります。Kubernetes NMState Operator は、相互依存するポリシーを順番に適用する場合があります。その結果、ネットワークオブジェクトがデグレード状態になることがあります。
  • 関連するすべてのネットワーク設定を 1 つのポリシーで指定することを検討してください。

29.2.6.1. 例: 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。

29.2.6.2. 例: 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 タグ。

29.2.6.3. 例: ボンドインターフェイスノードネットワークの設定ポリシー
リンクのコピー

NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してノード上にボンドインターフェイスを作成します。

注記

OpenShift Container Platform は以下の bond モードのみをサポートします。

  • active-backup
  • balance-xor
  • 802.3ad

その他のボンディングモードはサポートされていません。

balance-xor および 802.3ad のボンディングモードでは、EtherChannel または同様のポートグループを確立するためのスイッチ設定が必要です。また、これらの 2 つのモードには、インターフェイスを介して渡されるトラフィックの送信元と宛先に応じて、追加の負荷分散設定も必要です。active-backup ボンディングモードには、スイッチ設定は必要ありません。その他のボンディングモードはサポートされていません。

以下の 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 に設定されます。

29.2.6.4. 例: イーサネットインターフェイスノードネットワークの設定ポリシー
リンクのコピー

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 を有効にします。

29.2.6.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 を有効にします。

29.2.7. ブリッジに接続された NIC の静的 IP の取得
リンクのコピー

重要

NIC の静的 IP のキャプチャーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

クラスター内のノードに Linux ブリッジインターフェイスを作成し、単一の NodeNetworkConfigurationPolicy マニフェストをクラスターに適用して NIC の静的 IP 設定をブリッジに転送します。

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

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

spec:
  nodeSelector:
2 

    node-role.kubernetes.io/worker: ""
  capture:
    eth1-nic: interfaces.name=="eth1"
3 

    eth1-routes: routes.running.next-hop-interface=="eth1"
    br1-routes: capture.eth1-routes | routes.running.next-hop-interface := "br1"
  desiredState:
    interfaces:
      - name: br1
        description: Linux bridge with eth1 as a port
        type: linux-bridge
4 

        state: up
        ipv4: "{{ capture.eth1-nic.interfaces.0.ipv4 }}"
5 

        bridge:
          options:
            stp:
              enabled: false
          port:
            - name: eth1
6 

     routes:
        config: "{{ capture.br1-routes.routes.running }}"
Copy to Clipboard Toggle word wrap
1
ポリシーの名前。
2
オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。この例では node-role.kubernetes.io/worker: "" ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。
3
ブリッジを接続するノード NIC への参照。
4
インターフェイスのタイプ。この例では、ブリッジを作成します。
5
ブリッジインターフェイスの IP アドレス。この値は、spec.capture.eth1-nic エントリーにより参照される NIC の IP アドレスと一致します。
6
ブリッジが接続されるノードの NIC。

29.2.8. 例: IP 管理
リンクのコピー

次の設定スニペットの例は、さまざまな IP 管理方法を示しています。

これらの例では、ethernet インターフェイスタイプを使用して、ポリシー設定に関連するコンテキストを表示しつつ、サンプルを単純化します。これらの IP 管理のサンプルは、他のインターフェイスタイプでも使用できます。

29.2.8.1. 静的
リンクのコピー

以下のスニペットは、イーサネットインターフェイスで IP アドレスを静的に設定します。 

# ...
    interfaces:
    - name: eth1
      description: static IP on eth1
      type: ethernet
      state: up
      ipv4:
        dhcp: false
        address:
        - ip: 192.168.122.250
1 

          prefix-length: 24
        enabled: true
# ...
Copy to Clipboard Toggle word wrap
1
この値を、インターフェイスの静的 IP アドレスに置き換えます。

29.2.8.2. IP アドレスなし
リンクのコピー

以下のスニペットでは、インターフェイスに IP アドレスがないことを確認できます。 

# ...
    interfaces:
    - name: eth1
      description: No IP on eth1
      type: ethernet
      state: up
      ipv4:
        enabled: false
# ...
Copy to Clipboard Toggle word wrap
重要

インターフェイスを無効にするために ipv4.enabled パラメーターと ipv6.enabled パラメーターの両方を false に設定する場合は、必ず state パラメーターを up に設定してください。この設定で state: down を設定すると、自動 DHCP 割り当てによりインターフェイスは DHCP IP アドレスを受け取ります。

29.2.8.3. 動的ホストの設定
リンクのコピー

以下のスニペットは、動的 IP アドレス、ゲートウェイアドレス、および DNS を使用するイーサネットインターフェイスを設定します。 

# ...
    interfaces:
    - name: eth1
      description: DHCP on eth1
      type: ethernet
      state: up
      ipv4:
        dhcp: true
        enabled: true
# ...
Copy to Clipboard Toggle word wrap

以下のスニペットは、動的 IP アドレスを使用しますが、動的ゲートウェイアドレスまたは DNS を使用しないイーサネットインターフェイスを設定します。 

# ...
    interfaces:
    - name: eth1
      description: DHCP without gateway or DNS on eth1
      type: ethernet
      state: up
      ipv4:
        dhcp: true
        auto-gateway: false
        auto-dns: false
        enabled: true
# ...
Copy to Clipboard Toggle word wrap

29.2.8.4. DNS
リンクのコピー

デフォルトでは、nmstate API は DNS 値をネットワークインターフェイスに保存するのではなく、グローバルに保存します。特定の状況では、DNS 値を保存するようにネットワークインターフェイスを設定する必要があります。

ヒント

DNS 設定の設定は、/etc/resolv.conf ファイルの変更に相当します。

ネットワークインターフェイスの DNS 設定を定義するには、最初にネットワークインターフェイスの YAML 設定ファイルで dns-resolver セクションを指定する必要があります。NNCP 設定をネットワークインターフェイスに適用するには、oc apply -f <nncp_file_name> コマンドを実行する必要があります。

次の例は、DNS 値をグローバルに保存するデフォルトの状況を示しています。

  • ネットワークインターフェイスなしで静的 DNS を設定します。ホストノード上の /etc/resolv.conf ファイルを更新する場合、NodeNetworkConfigurationPolicy (NNCP) マニフェストでインターフェイス (IPv4 または IPv6) を指定する必要はありません。

    DNS 値をグローバルに保存するネットワークインターフェイスの DNS 設定の例

    apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
 name: worker-0-dns-testing
spec:
  nodeSelector:
    kubernetes.io/hostname: <target_node>
  desiredState:
    dns-resolver:
      config:
        server:
        - 2001:db8:f::1
        - 192.0.2.251
        search:
        - example.com
        - example.org
# ...
    Copy to Clipboard Toggle word wrap

    重要

    次の例に示すように、NNCP ファイルの dns-resolver.config セクションで DNS オプションを指定できます。 

    # ...
desiredState:
    dns-resolver:
      config:
        options:
         - timeout:2
         - attempts:3
# ...
    Copy to Clipboard Toggle word wrap

    ネットワークインターフェイスから DNS オプションを削除する場合は、NNCP に次の設定を適用してから oc apply -f <nncp_file_name> コマンドを実行します。 

    # ...
    dns-resolver:
      config: {}
    interfaces: []
# ...
    Copy to Clipboard Toggle word wrap

次の例は、DNS 値を格納するためにネットワークインターフェイスを設定する必要がある状況を示しています。

  • 静的 DNS ネームサーバーを動的 DNS ネームサーバーよりも優先する場合は、ネットワークインターフェイス YAML 設定ファイルで、Dynamic Host Configuration Protocol (DHCP) または IPv6 自動設定 (autoconf) メカニズムのいずれかを実行するインターフェイスを定義します。

    DHCPv4 ネットワークプロトコルから取得した DNS ネームサーバーに 192.0.2.1 を追加する設定の例

    # ...
dns-resolver:
  config:
    server:
    - 192.0.2.1
interfaces:
  - name: eth1
    type: ethernet
    state: up
    ipv4:
      enabled: true
      dhcp: true
      auto-dns: true
# ...
    Copy to Clipboard Toggle word wrap

  • nmstate API を使用して DNS 値をグローバルに保存するデフォルトの方法を採用するのではなく、DNS 値を保存するようにネットワークインターフェイスを設定する必要がある場合は、ネットワークインターフェイス YAML ファイルで静的 DNS 値と静的 IP アドレスを設定できます。

    重要

    ネットワークインターフェイスレベルで DNS 値を保存すると、インターフェイスを Open vSwitch (OVS) ブリッジ、Linux ブリッジ、ボンディングなどのネットワークコンポーネントに接続した後に、名前解決の問題が発生する可能性があります。

    インターフェイスレベルで DNS 値を保存する設定の例

    # ...
dns-resolver:
  config:
    server:
    - 2001:db8:1::d1
    - 2001:db8:1::d2
    - 192.0.2.1
    search:
    - example.com
    - example.org
interfaces:
  - name: eth1
    type: ethernet
    state: up
    ipv4:
      address:
      - ip: 192.0.2.251
        prefix-length: 24
      dhcp: false
      enabled: true
    ipv6:
      address:
      - ip: 2001:db8:1::1
        prefix-length: 64
      dhcp: false
      enabled: true
      autoconf: false
# ...
    Copy to Clipboard Toggle word wrap

  • ネットワークインターフェイスに静的 DNS 検索ドメインおよび静的 DNS ネームサーバーを設定する場合は、ネットワークインターフェイスの YAML 設定ファイルで Dynamic Host Configuration Protocol (DHCP)または IPv6 Autoconfiguration (autoconf)メカニズムのいずれかを実行する静的インターフェイスを定義します。

    重要

    次の dns-resolver 設定をネットワークインターフェイス YAML ファイルに指定すると、再起動時に競合状態が発生し、NodeNetworkConfigurationPolicy (NNCP)がクラスターで実行される Pod に適用できなくなる可能性があります。

    • ネットワークインターフェイスの静的 DNS 検索ドメインと動的 DNS ネームサーバーの設定
    • search パラメーターのドメイン接尾辞を指定し、server パラメーターの IP アドレスを設定しません。

    静的 DNS ネームサーバーと共に example.com および example.org 静的 DNS 検索ドメインを設定する設定例

    # ...
dns-resolver:
  config:
    server:
    - 2001:db8:f::1
    - 192.0.2.251
    search:
    - example.com
    - example.org
interfaces:
  - name: eth1
    type: ethernet
    state: up
    ipv4:
      enabled: true
      dhcp: true
      auto-dns: true
    ipv6:
      enabled: true
      dhcp: true
      autoconf: true
      auto-dns: true
# ...
    Copy to Clipboard Toggle word wrap

29.2.8.5. 静的ルーティング
リンクのコピー

以下のスニペットは、インターフェイス eth1 に静的ルートおよび静的 IP を設定します。 

dns-resolver:
  config:
# ...
interfaces:
  - name: eth1
    description: Static routing on eth1
    type: ethernet
    state: up
    ipv4:
      dhcp: false
      enabled: true
      address:
      - ip: 192.0.2.251
1 

        prefix-length: 24
routes:
  config:
  - destination: 198.51.100.0/24
    metric: 150
    next-hop-address: 192.0.2.1
2 

    next-hop-interface: eth1
    table-id: 254
# ...
Copy to Clipboard Toggle word wrap
1
イーサネットインターフェイスの静的 IP アドレス。
2
ノードトラフィックのネクストホップアドレス。これは、イーサネットインターフェイスに設定される IP アドレスと同じサブネットにある必要があります。
重要

静的ルートを設定する際に、OVN-Kubernetes br-ex ブリッジをネクストホップインターフェイスとして使用することはできません。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat