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

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

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

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

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

手順

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

    $ oc get nns

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

    $ oc get nns node01 -o yaml

    出力例

    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

    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 クラスター内に存在するノードのネットワークを設定するために使用するポリシーを定義します。

重要

複数の NNCP CR をノードに適用する場合は、ポリシー名の英数字のソートに基づいて、論理順序で NNCP を作成する必要があります。Kubernetes NMState Operator は、Operator が CR をノードに即時に適用することができるように、新しく作成された NNCP 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 を削除します。

28.2.5. Web コンソールからのポリシーの管理
リンクのコピー

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

28.2.5.1. ポリシーステータスの監視
リンクのコピー

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

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

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

28.2.5.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.5.3. ポリシーの更新
リンクのコピー

28.2.5.3.1. フォームを使用してポリシーを更新する
リンクのコピー

手順

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

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

28.2.5.3.2. YAML を使用したポリシーの更新
リンクのコピー

手順

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

28.2.5.4. ポリシーの削除
リンクのコピー

手順

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

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

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

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

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

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

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

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

28.2.8.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 によっても管理されている Physical Function 上で、NMState を使用して SR-IOV VF のホストネットワーク設定を更新するには、関連する SriovNetworkNodePolicy リソースの externallyManaged パラメーターを 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
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
1
ポリシーの名前。
2
オプション: nodeSelector パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。
3
この例は、worker ロールを持つすべてのノードに適用されます。
4
VF ネットワークインターフェイスの名前。
5
VLAN ネットワークインターフェイスの名前。
6
VLAN インターフェイスがアタッチされている VF ネットワークインターフェイス。
7
ボンディングネットワークインターフェイスの名前。
8
オプション: 人間が判読できるインターフェイスの説明。
9
インターフェイスのタイプ。
10
設定後のインターフェイスの要求された状態。
11
ボンディングのボンディングポリシー。
12
割り当てられたプライマリーボンディングポート。
13
ボンディングされたネットワークインターフェイスのポート。
14
この例では、この VLAN ネットワークインターフェイスが、追加インターフェイスとしてボンディングされたネットワークインターフェイスに追加されています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28.2.10.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
# ...

    重要

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

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

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

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

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

  • 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
# ...

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

    重要

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

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

    example.com および example.org の静的 DNS 検索ドメインと静的 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
# ...

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

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

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る