27.2. ノードのネットワーク状態と設定の監視と更新
NMState Operator のインストール方法の詳細は、Kubernetes NMState Operator を参照してください。
27.2.1. ノードのネットワーク状態の表示 リンクのコピーリンクがクリップボードにコピーされました!
ノードのネットワーク状態は、クラスター内のすべてのノードのネットワーク設定です。NodeNetworkState
オブジェクトはクラスター内のすべてのノードにあります。このオブジェクトは定期的に更新され、ノードのネットワークの状態を取得します。
手順
クラスターのすべての
NodeNetworkState
オブジェクトを一覧表示します。oc get nns
$ oc get nns
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeNetworkState
オブジェクトを検査して、そのノードにネットワークを表示します。この例の出力は、明確にするために編集されています。oc get nns node01 -o yaml
$ oc get nns node01 -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.2. 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、ノードネットワークポリシー、およびインターフェイスを実際に削除するには、通常、次の操作が必要です。
-
NNCP を編集し、ファイルからインターフェイスの詳細を削除します。ファイルから
name
、state
、type
パラメーターは削除しないでください。 -
NNCP の
interfaces.state
セクションにstate: absent
を追加します。 -
oc apply -f <nncp_file_name>
を実行します。Kubernetes NMState Operator がクラスター内の各ノードにノードネットワークポリシーを適用すると、各ノードに存在するすべてのインターフェイスが absent とマークされます。 -
oc delete nncp
を実行して NNCP を削除します。
関連情報
27.2.3. CLI を使用したポリシーの管理 リンクのコピーリンクがクリップボードにコピーされました!
27.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 マニフェストによってノードに不適切な設定が適用されると、クラスターの半分を確実に機能させることができなくなります。
手順
NodeNetworkConfigurationPolicy
マニフェストを作成します。以下の例は、すべてのワーカーノードで Linux ブリッジを設定し、DNS リゾルバーを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では
node-role.kubernetes.io/worker: ""
ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 4
- オプション: ポリシー設定を同時に適用できる nmstate 対応ノードの最大数を指定します。このパラメーターは、
10%
などのパーセンテージ値 (文字列)、または3
などの絶対値 (数値) のいずれかに設定できます。 - 5
- オプション: インターフェイスの人間が判読できる説明。
- 6
- オプション:DNS サーバーの検索およびサーバー設定を指定します。
ノードのネットワークポリシーを作成します。
oc apply -f br1-eth1-policy.yaml
$ oc apply -f br1-eth1-policy.yaml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ノードネットワーク設定ポリシーマニフェストのファイル名。
関連情報
27.2.4. ノード上でのノードネットワークポリシー更新の確認 リンクのコピーリンクがクリップボードにコピーされました!
ノードネットワークポリシーを適用する際に、NodeNetworkConfigurationEnactment
オブジェクトがクラスター内のすべてのノードについて作成されます。ノードネットワーク設定の enactment (実行) は、そのノードでのポリシーの実行ステータスを表す読み取り専用オブジェクトです。ポリシーがノードに適用されない場合、そのノードの enactment (実行) にはトラブルシューティングのためのトレースバックが含まれます。
手順
ポリシーがクラスターに適用されていることを確認するには、ポリシーとそのステータスをリスト表示します。
oc get nncp
$ oc get nncp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ポリシーの設定に想定されている以上の時間がかかる場合は、特定のポリシーの要求される状態とステータスの状態を検査できます。
oc get nncp <policy> -o yaml
$ oc get nncp <policy> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ポリシーのすべてのノード上での設定に想定されている以上の時間がかかる場合は、クラスターの enactment (実行) のステータスをリスト表示できます。
oc get nnce
$ oc get nnce
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 特定の enactment (実行) の設定 (失敗した設定のエラーレポートを含む) を表示するには、以下を実行します。
oc get nnce <node>.<policy> -o yaml
$ oc get nnce <node>.<policy> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.5. ノードからインターフェイスの削除 リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
オブジェクトを編集し、インターフェイスの state
を absent
に設定して、クラスターの 1 つ以上のノードからインターフェイスを削除できます。
ノードからインターフェイスを削除しても、ノードのネットワーク設定は以前の状態に自動的に復元されません。以前の状態に復元する場合、そのノードのネットワーク設定をポリシーで定義する必要があります。
ブリッジまたはボンディングインターフェイスを削除すると、そのブリッジまたはボンディングインターフェイスに以前に接続されたか、それらの下位にあるノード NIC は down
の状態になり、到達できなくなります。接続が失われないようにするには、同じポリシーでノード NIC を設定し、ステータスを up
にし、DHCP または静的 IP アドレスのいずれかになるようにします。
インターフェイスを追加したポリシーを削除しても、ノード上のポリシーの設定は変更されません。NodeNetworkConfigurationPolicy
はクラスターのオブジェクトですが、このオブジェクトは要求される設定のみを表します。同様に、インターフェイスを削除してもポリシーは削除されません。
手順
インターフェイスの作成に使用する
NodeNetworkConfigurationPolicy
マニフェストを更新します。以下の例は Linux ブリッジを削除し、接続が失われないように DHCP でeth1
NIC を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では
node-role.kubernetes.io/worker: ""
ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 4
- 状態を
absent
に変更すると、インターフェイスが削除されます。 - 5
- ブリッジインターフェイスから接続が解除されるインターフェイスの名前。
- 6
- インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
- 7
- インターフェイスの要求された状態。
- 8
- オプション:
dhcp
を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4
を有効にします。
ノード上でポリシーを更新し、インターフェイスを削除します。
oc apply -f <br1-eth1-policy.yaml>
$ oc apply -f <br1-eth1-policy.yaml>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーマニフェストのファイル名。
27.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 つのポリシーで指定することを検討してください。
27.2.6.1. 例: Linux ブリッジインターフェイスノードネットワーク設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してクラスター内のノード上に Linux ブリッジインターフェイスを作成します。
以下の YAML ファイルは、Linux ブリッジインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostname
ノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、ブリッジを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcp
を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4
を有効にします。 - 10
- この例では
stp
を無効にします。 - 11
- ブリッジが接続されるノードの NIC。
27.2.6.2. 例: VLAN インターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してクラスター内のノード上に VLAN インターフェイスを作成します。
1 つの NodeNetworkConfigurationPolicy
マニフェストで、ノードの VLAN インターフェイスに関連するすべての設定を定義します。たとえば、同じ NodeNetworkConfigurationPolicy
マニフェストで、ノードの VLAN インターフェイスと VLAN インターフェイスの関連ルートを定義します。
ノードが再起動すると、Kubernetes NMState Operator はポリシーを適用する順序を制御できません。したがって、関連するネットワーク設定に別々のポリシーを使用すると、Kubernetes NMState Operator がこれらのポリシーを順番に適用するため、ネットワークオブジェクトがデグレード状態になる可能性があります。
以下の YAML ファイルは、VLAN インターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostname
ノードセレクターを使用します。 - 4
- インターフェイスの名前。ベアメタルにデプロイする場合、
<interface_name>.<vlan_number>
VLAN 形式のみがサポートされます。 - 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。以下の例では VLAN を作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- VLAN が接続されているノードの NIC。
- 9
- VLAN タグ。
27.2.6.3. 例: ボンドインターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してノード上にボンドインターフェイスを作成します。
OpenShift Container Platform は以下の bond モードのみをサポートします。
-
mode=1 active-backup
-
mode=2 balance-xor
-
mode=4 802.3ad
その他のボンディングモードはサポートされていません。
以下の YAML ファイルは、ボンドインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 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
に設定されます。
27.2.6.4. 例: イーサネットインターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してクラスター内のノードにイーサネットインターフェイスを作成します。
以下の YAML ファイルは、イーサネットインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostname
ノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcp
を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4
を有効にします。
27.2.6.5. 例: 同じノードネットワーク設定ポリシーでの複数のインターフェイス リンクのコピーリンクがクリップボードにコピーされました!
同じノードネットワーク設定ポリシーで複数のインターフェイスを作成できます。これらのインターフェイスは相互に参照でき、単一のポリシーマニフェストを使用してネットワーク設定をビルドし、デプロイできます。
以下の YAML ファイルの例では、2 つの NIC 間に bond10
という名前のボンドと、ボンドに接続する bond10.103
という名前の VLAN を作成します。
- 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 を有効にします。
27.2.7. ブリッジに接続された NIC の静的 IP の取得 リンクのコピーリンクがクリップボードにコピーされました!
NIC の静的 IP のキャプチャーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
27.2.7.1. 例: ブリッジに接続された NIC から静的 IP アドレスを継承する Linux ブリッジインターフェイスノードネットワーク設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のノードに Linux ブリッジインターフェイスを作成し、単一の NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用して NIC の静的 IP 設定をブリッジに転送します。
以下の YAML ファイルは、Linux ブリッジインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelector
パラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。この例ではnode-role.kubernetes.io/worker: ""
ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 3
- ブリッジを接続するノード NIC への参照。
- 4
- インターフェイスのタイプ。この例では、ブリッジを作成します。
- 5
- ブリッジインターフェイスの IP アドレス。この値は、
spec.capture.eth1-nic
エントリーにより参照される NIC の IP アドレスと一致します。 - 6
- ブリッジが接続されるノードの NIC。
27.2.8. 例: IP 管理 リンクのコピーリンクがクリップボードにコピーされました!
以下の設定スニペットの例は、さまざまな IP 管理方法を示しています。
これらの例では、ethernet
インターフェイスタイプを使用して、ポリシー設定に関連するコンテキストを表示しつつ、サンプルを単純化します。これらの IP 管理のサンプルは、他のインターフェイスタイプでも使用できます。
27.2.8.1. 静的 リンクのコピーリンクがクリップボードにコピーされました!
以下のスニペットは、イーサネットインターフェイスで IP アドレスを静的に設定します。
- 1
- この値を、インターフェイスの静的 IP アドレスに置き換えます。
27.2.8.2. IP アドレスなし リンクのコピーリンクがクリップボードにコピーされました!
以下のスニペットでは、インターフェイスに IP アドレスがないことを確認できます。
インターフェイスを無効にするために ipv4.enabled
パラメーターと ipv6.enabled
パラメーターの両方を false
に設定する場合は、必ず state
パラメーターを up
に設定してください。この設定で state: down を設定すると、自動 DHCP 割り当てによりインターフェイスは DHCP IP アドレスを受け取ります。
27.2.8.3. 動的ホストの設定 リンクのコピーリンクがクリップボードにコピーされました!
以下のスニペットは、動的 IP アドレス、ゲートウェイアドレス、および DNS を使用するイーサネットインターフェイスを設定します。
以下のスニペットは、動的 IP アドレスを使用しますが、動的ゲートウェイアドレスまたは DNS を使用しないイーサネットインターフェイスを設定します。
27.2.8.4. DNS リンクのコピーリンクがクリップボードにコピーされました!
DNS 設定の定義は、/etc/resolv.conf
ファイルの変更に類似しています。以下のスニペットは、ホストに DNS 設定を定義します。
- 1
- Kubernetes NMState がカスタム DNS 設定を保存するためには、インターフェイスを
auto-dns: false
で設定するか、インターフェイスで静的 IP 設定を使用する必要があります。
DNS リゾルバーの設定時に、インターフェイスとして OVNKubernetes が管理する Open vSwitch ブリッジである br-ex
を使用することはできません。
27.2.8.5. 静的ルーティング リンクのコピーリンクがクリップボードにコピーされました!
以下のスニペットは、インターフェイス eth1
に静的ルートおよび静的 IP を設定します。
静的ルートを設定する際に、カスタマイズされた br-ex
ブリッジを手動で設定していない限り、OVN-Kubernetes br-ex
ブリッジをネクストホップインターフェイスとして使用することはできません。