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

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

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

28.2.1. CLI を使用したノードのネットワーク状態の表示

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

手順

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

    $ oc get nns
    Copy to Clipboard

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

    $ oc get nns node01 -o yaml
    Copy to Clipboard

    出力例

    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

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

28.2.2. Web コンソールからのノードのネットワーク状態の表示

管理者は、OpenShift Container Platform Web コンソールを使用して、NodeNetworkState リソースとネットワークインターフェイスを観察し、ネットワークの詳細にアクセスできます。

手順

  1. Networking NodeNetworkState に移動します。

    NodeNetworkState ページでは、NodeNetworkState リソースと、ノード上に作成された対応するインターフェイスのリストを表示できます。Interface state、Interface type、および IP に基づく フィルター、または Name または Label の条件に基づく検索バーを使用して、表示される NodeNetworkState リソースを絞り込むことができます。

  2. NodeNetworkState リソースに関する詳細情報にアクセスするには、Name 列にリストされている NodeNetworkState リソース名をクリックします。
  3. NodeNetworkState リソースの Network Details セクションをデプロイメントして表示するには、> アイコンをクリックします。あるいは、Network interface 列の下の各インターフェイスタイプをクリックして、ネットワークの詳細を表示することもできます。

28.2.3. NodeNetworkConfigurationPolicy マニフェストを作成します。

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

ノードのネットワークポリシーをノードに適用すると、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 を削除します。

関連情報

28.2.4. Web コンソールからのポリシーの管理

NodeNetworkConfigurationPolicy マニフェストをクラスターに適用して、ノードからのインターフェイスの追加または削除など、ノードネットワーク設定を更新できます。Web コンソールからポリシーを管理するには、Networking メニューの NodeNetworkConfigurationPolicy ページで作成されたポリシーのリストにアクセスします。このページでは、ポリシーを作成、更新、監視、削除できます。

28.2.4.1. ポリシーステータスの監視

NodeNetworkConfigurationPolicy ページからポリシーのステータスを監視できます。このページには、クラスター内に作成されたすべてのポリシーが次の列を含む表形式で表示されます。

名前
作成されたポリシーの名前。
一致したノード
ポリシーが適用されるノードの数。これは、ノードセレクターに基づくノードのサブセット、またはクラスター上のすべてのノードのいずれかになります。
ノードのネットワーク状態
一致したノードの実行状態。制定状態をクリックすると、ステータスの詳細情報が表示されます。

目的のポリシーを見つけるには、Filter オプションを使用するか、検索オプションを使用して、制定状態に基づいてリストをフィルターできます。

28.2.4.2. ポリシーの作成

Web コンソールでフォームまたは YAML を使用してポリシーを作成できます。

手順

  1. Networking NodeNetworkConfigurationPolicy に移動します。

  2. NodeNetworkConfigurationPolicy ページで Create をクリックし、From Form オプションを選択します。

    既存のポリシーがない場合は、Create NodeNetworkConfigurationPolicy をクリックして、フォームを使用してポリシーを作成することもできます。

    注記

    YAML を使用してポリシーを作成するには、Create をクリックし、With YAML オプションを選択します。次の手順は、フォームを使用してポリシーを作成する場合にのみ適用されます。

  3. オプション: Apply this NodeNetworkConfigurationPolicy only to specific subsets of nodes using the node selector チェックボックスをオンにして、ポリシーを適用する必要があるノードを指定します。
  4. Policy name フィールドにポリシー名を入力します。
  5. オプション: Description フィールドにポリシーの説明を入力します。

  6. オプション: Policy Interface(s) セクションでは、編集可能なフィールドにプリセット値が設定されたブリッジインターフェイスがデフォルトで追加されます。次の手順を実行して値を編集します。

    1. Interface name フィールドにインターフェイスの名前を入力します。
    2. Network state ドロップダウンからネットワーク状態を選択します。デフォルトで選択されている値は Up です。

    3. Type ドロップダウンからインターフェイスのタイプを選択します。使用可能な値は、Bridge、Bonding、および Ethernet です。デフォルトで選択されている値は Bridge です。

      注記

      フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集できません。

    4. オプション: IP 設定セクションで、IPv4 チェックボックスをオンにしてインターフェイスに IPv4 アドレスを割り当て、IP アドレス割り当ての詳細を設定します。

      1. IP address をクリックしてインターフェイスを静的 IP アドレスで設定するか、DHCP をクリックして IP アドレスを自動割り当てします。

      2. IP address オプションを選択した場合は、IPV4 address フィールドに IPv4 アドレスを、Prefix length フィールドに接頭辞長を入力します。

        DHCP オプションを選択した場合は、無効にするオプションのチェックを外します。使用可能なオプションは、Auto-DNS、Auto-routes、および Auto-gateway です。すべてのオプションがデフォルトで選択されています。

    5. オプション: Port フィールドにポート番号を入力します。
    6. オプション: STP を有効にするには、Enable STP チェックボックスをオンにします。
    7. オプション: ポリシーにインターフェイスを追加するには、Add another interface to the policy をクリックします。
    8. オプション: ポリシーからインターフェイスを削除するには、インターフェイスの横にあるアイコン をクリックします。
    注記

    または、ページ上部の Edit YAML をクリックして、YAML を使用してフォームの編集を続けることもできます。

  7. Create をクリックしてポリシーの作成を完了します。

28.2.4.3. ポリシーの更新

28.2.4.3.1. フォームを使用してポリシーを更新する

手順

  1. Networking NodeNetworkConfigurationPolicy に移動します。
  2. NodeNetworkConfigurationPolicy ページで、編集するポリシーの横にあるアイコン kebab を選択し、Edit をクリックします。
  3. 更新するフィールドを編集します。
  4. Save をクリックします。
注記

フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集することはできません。

28.2.4.3.2. YAML を使用したポリシーの更新

手順

  1. Networking NodeNetworkConfigurationPolicy に移動します。
  2. NodeNetworkConfigurationPolicy ページで、編集するポリシーの Name 列の下にあるポリシー名をクリックします。
  3. YAML タブをクリックし、YAML を編集します。
  4. Save をクリックします。

28.2.4.4. ポリシーの削除

手順

  1. Networking NodeNetworkConfigurationPolicy に移動します。
  2. NodeNetworkConfigurationPolicy ページで、削除するポリシーの横にあるアイコン kebab を選択し、Delete をクリックします。
  3. ポップアップウィンドウで、削除を確認するポリシー名を入力し、Delete をクリックします。

28.2.5. CLI を使用したポリシーの管理

28.2.5.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
    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
    1
    ノードネットワーク設定ポリシーマニフェストのファイル名。

関連情報

28.2.5.2. ノード上でのノードネットワークポリシー更新の確認

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

手順

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

    $ oc get nncp
    Copy to Clipboard

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

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

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

    $ oc get nnce
    Copy to Clipboard

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

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

28.2.5.3. ノードからインターフェイスの削除

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
    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
    1
    ポリシーマニフェストのファイル名。

28.2.6. 異なるインターフェイスのポリシー設定の例

ポリシーをノードに適用する場合は、さまざまな 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 つのポリシーで指定することを検討してください。

28.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
1
ポリシーの名前。
2
オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。
3
この例では、hostname ノードセレクターを使用します。
4
インターフェイスの名前。
5
オプション: 人間が判読できるインターフェイスの説明。
6
インターフェイスのタイプ。この例では、ブリッジを作成します。
7
作成後のインターフェイスの要求された状態。
8
オプション: dhcp を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。
9
この例では ipv4 を有効にします。
10
この例では stp を無効にします。
11
ブリッジが接続されるノードの NIC。

28.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
1
ポリシーの名前。
2
オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。
3
この例では、hostname ノードセレクターを使用します。
4
インターフェイスの名前。ベアメタルにデプロイする場合、<interface_name>.<vlan_number> VLAN 形式のみがサポートされます。
5
オプション: 人間が判読できるインターフェイスの説明。
6
インターフェイスのタイプ。以下の例では VLAN を作成します。
7
作成後のインターフェイスの要求された状態。
8
VLAN が接続されているノードの NIC。
9
VLAN タグ。

28.2.6.3. 例: Virtual Function のノードネットワーク設定ポリシー (テクノロジープレビュー)

NodeNetworkConfigurationPolicy マニフェストを適用して、既存のクラスター内の Single Root I/O Virtualization (SR-IOV) ネットワーク Virtual Function (VF) のホストネットワーク設定を更新します。

重要

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

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

NodeNetworkConfigurationPolicy マニフェストを既存のクラスターに適用して、次のタスクを完了できます。

  • VF の QoS または MTU ホストネットワークを設定して、パフォーマンスを最適化します。
  • ネットワークインターフェイスの VF を追加、削除、または更新します。
  • VF ボンディング設定を管理します。
注記

SR-IOV Network Operator を通じて管理もされる物理機能で NMState を使用して SR-IOV VF のホストネットワーク設定を更新するには、関連する SriovNetworkNodePolicy リソースの externallyManaging パラメーターを true に設定する必要があります。詳細は、関連情報 セクションを参照してください。

次の YAML ファイルは、VF の QoS ポリシーを定義するマニフェストの例です。このファイルにはサンプル値が含まれていますが、これは独自の情報に置き換える必要があります。 

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
1
ポリシーの名前。
2
オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。
3
この例は、worker ロールを持つすべてのノードに適用されます。
4
物理機能 (PF) ネットワークインターフェイスの名前。
5
オプション: 人間が判読できるインターフェイスの説明。
6
インターフェイスのタイプ。
7
設定後のインターフェイスの要求された状態。
8
VF の総数。
9
ID 0 を持つ VF を識別します。
10
VF の最大伝送速度 (Mbps) を設定します。このサンプル値は、200 Mbps のレートを設定します。

次の YAML ファイルは、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: ens1f0v1
4 

        type: ethernet
        state: up
      - name: ens1f0v1.477
5 

        type: vlan
        state: up
        vlan:
          base-iface: ens1f0v1
6 

          id: 477
      - name: bond0
7 

        description: Add vf
8 

        type: bond
9 

        state: up
10 

        link-aggregation:
          mode: active-backup
11 

          options:
            primary: ens1f1v0.477
12 

          port:
13 

            - ens1f1v0.477
            - ens1f0v0.477
            - ens1f0v1.477
14
Copy to Clipboard
1
ポリシーの名前。
2
オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。
3
この例は、worker ロールを持つすべてのノードに適用されます。
4
VF ネットワークインターフェイスの名前。
5
VLAN ネットワークインターフェイスの名前。
6
VLAN インターフェイスがアタッチされている VF ネットワークインターフェイス。
7
ボンディングネットワークインターフェイスの名前。
8
オプション: 人間が判読できるインターフェイスの説明。
9
インターフェイスのタイプ。
10
設定後のインターフェイスの要求された状態。
11
ボンディングのボンディングポリシー。
12
割り当てられたプライマリーボンディングポート。
13
ボンディングされたネットワークインターフェイスのポート。
14
この例では、この VLAN ネットワークインターフェイスが、追加インターフェイスとしてボンディングされたネットワークインターフェイスに追加されています。

28.2.6.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
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 に設定されます。

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

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

28.2.6.6. 例: 同じノードネットワーク設定ポリシーでの複数のインターフェイス

同じノードネットワーク設定ポリシーで複数のインターフェイスを作成できます。これらのインターフェイスは相互に参照でき、単一のポリシーマニフェストを使用してネットワーク設定をビルドし、デプロイできます。

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

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

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
1
ポリシーの名前。
2
この例では、vrf:true のラベルが割り当てられたべてのノードにポリシーを適用します。
3
インターフェイスの名前。
4
インターフェイスのタイプ。この例では VRF インスタンスを作成します。
5
VRF が接続されるノードインターフェイス。
6
VRF のルートテーブル ID の名前。

28.2.7. ブリッジに接続された NIC の静的 IP の取得

重要

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

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

28.2.7.1. 例: ブリッジに接続された NIC から静的 IP アドレスを継承する Linux ブリッジインターフェイスノードネットワーク設定ポリシー

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

28.2.8. 例: IP 管理

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

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

28.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
1
この値を、インターフェイスの静的 IP アドレスに置き換えます。

28.2.8.2. IP アドレスなし

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

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

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

28.2.8.3. 動的ホストの設定

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

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

以下のスニペットは、動的 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

28.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:
        search:
        - example.com
        - example.org
        server:
        - 2001:db8:f::1
        - 192.0.2.251
# ...
    Copy to Clipboard

    重要

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

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

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

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

次の例は、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

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

    重要

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

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

    # ...
dns-resolver:
  config:
    search:
    - example.com
    - example.org
    server:
    - 2001:db8:1::d1
    - 2001:db8:1::d2
    - 192.0.2.1
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

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

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

    # ...
dns-resolver:
  config:
    search:
    - example.com
    - example.org
    server: []
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

28.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
1
イーサネットインターフェイスの静的 IP アドレス。
2
ノードトラフィックのネクストホップアドレス。これは、イーサネットインターフェイスに設定される IP アドレスと同じサブネットにある必要があります。
重要

静的ルートを設定する際に、カスタマイズされた br-ex ブリッジを手動で設定していない限り、OVN-Kubernetes br-ex ブリッジをネクストホップインターフェイスとして使用することはできません。

詳細は、インストーラーでプロビジョニングされるクラスターのベアメタルへのデプロイ、または ユーザーがプロビジョニングしたクラスターをベアメタルにインストール ドキュメントの「カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成」を参照してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat