第24章 Kubernetes NMState


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

Kubernetes NMState Operator をインストールしたら、Operator を使用してクラスターのノードのネットワーク状態とネットワーク設定を監視および更新できます。

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

24.1.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
    最後に成功した更新のタイムスタンプ。これは、ノードが到達可能であり、レポートの鮮度の評価に使用できる限り定期的に更新されます。

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

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

手順

  1. Networking NodeNetworkState に移動します。

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

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

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

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

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

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

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

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

24.1.3.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 ドロップダウンからインターフェイスのタイプを選択します。使用可能な値は、BridgeBonding、および 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-DNSAuto-routes、および Auto-gateway です。すべてのオプションがデフォルトで選択されています。

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

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

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

24.1.3.3. ポリシーの更新

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

手順

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

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

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

手順

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

24.1.3.4. ポリシーの削除

手順

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

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

24.1.4.1. ノード上でのインターフェイスの作成

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

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

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

手順

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

関連情報

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

NodeNetworkConfigurationPolicy マニフェストは、クラスターのノードについて要求されるネットワーク設定を記述します。ノードネットワークポリシーには、要求されたネットワーク設定と、クラスター全体でのポリシーの実行ステータスが含まれます。

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

手順

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

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

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

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

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

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

NodeNetworkConfigurationPolicy オブジェクトを編集し、インターフェイスの stateabsent に設定して、クラスターの 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
    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
    1
    ポリシーマニフェストのファイル名。

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

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

  • ポリシーを複数のノードに適用する必要がある場合は、ターゲットノードごとに NodeNetworkConfigurationPolicy マニフェストを作成します。Kubernetes NMState Operator は、NNCP を持つ各ノードにポリシーを不特定の順序で適用します。この方法でポリシーのスコープを設定すると、ポリシーの適用にかかる時間が短縮されますが、クラスターの設定にエラーがある場合はクラスター全体が停止するリスクがあります。この種のエラーを回避するには、最初に一部のノードに NNCP を適用し、正しく設定されていることを確認してから、残りのノードにポリシーを適用します。
  • 多数のノードにポリシーを適用する必要があるが、すべてのターゲットノードに対して 1 つの NNCP のみを作成する場合、Kubernetes NMState Operator は各ノードにポリシーを順番に適用します。クラスター設定の maxUnavailable パラメーターを使用して、ターゲットノードに対するポリシー適用の速度と範囲を設定できます。パラメーターのパーセンテージ値を低く設定すると、ポリシー適用を受信しているノードのごく一部に障害が影響する場合に、クラスター全体の障害が発生するリスクを軽減できます。
  • 関連するすべてのネットワーク設定を 1 つのポリシーで指定することを検討してください。
  • ノードが再起動すると、Kubernetes NMState Operator はノードにポリシーを適用する順序を制御できなくなります。Kubernetes NMState Operator は、相互依存するポリシーを順番に適用する場合があります。その結果、ネットワークオブジェクトがデグレード状態になることがあります。

24.1.5.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。

24.1.5.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 タグ。

24.1.5.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 ホストネットワークを設定して、パフォーマンスを最適化します。
  • ネットワークインターフェイスの 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
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 ネットワークインターフェイスが、追加インターフェイスとしてボンディングされたネットワークインターフェイスに追加されています。

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

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

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

24.1.5.7. 例: VRF インスタンスノードのネットワーク設定ポリシーを使用したネットワークインターフェイス

NodeNetworkConfigurationPolicy カスタムリソース (CR) を適用して、仮想ルーティングおよび転送 (VRF) インスタンスをネットワークインターフェイスに関連付けます。

重要

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

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

VRF インスタンスをネットワークインターフェイスに関連付けることにより、トラフィックの分離、独立したルーティングの決定、およびネットワークリソースの論理的な分離をサポートできます。

ベアメタル環境では、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 の名前。

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

重要

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

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

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

24.1.7. 例: IP 管理

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

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

24.1.7.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 アドレスに置き換えます。

24.1.7.2. IP アドレスなし

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

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

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

24.1.7.4. DNS

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

ヒント

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

ネットワークインターフェイスの DNS 設定を定義するには、最初にネットワークインターフェイスの YAML 設定ファイルで dns-resolver セクションを指定する必要があります。

重要

カスタマイズされた br-ex ブリッジを手動で設定しない限り、DNS リゾルバーを設定するときに、OVNKubernetes 管理の Open vSwitch ブリッジである br-ex ブリッジをインターフェイスとして使用することはできません。

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

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

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

  • ネットワークインターフェイスに静的 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
    # ...

24.1.7.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 アドレスと同じサブネットにある必要があります。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.