28.2. ノードのネットワーク状態と設定の監視と更新
28.2.1. CLI を使用したノードのネットワーク状態の表示
ノードのネットワーク状態は、クラスター内のすべてのノードのネットワーク設定です。NodeNetworkState
オブジェクトはクラスター内のすべてのノードにあります。このオブジェクトは定期的に更新され、ノードのネットワークの状態を取得します。
手順
クラスターのすべての
NodeNetworkState
オブジェクトをリスト表示します。$ oc get nns
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
28.2.2. Web コンソールからのノードのネットワーク状態の表示
管理者は、OpenShift Container Platform Web コンソールを使用して、NodeNetworkState
リソースとネットワークインターフェイスを観察し、ネットワークの詳細にアクセスできます。
手順
Networking
NodeNetworkState に移動します。 NodeNetworkState ページでは、
NodeNetworkState
リソースと、ノード上に作成された対応するインターフェイスのリストを表示できます。Interface state、Interface type、および IP に基づく フィルター、または Name または Label の条件に基づく検索バーを使用して、表示されるNodeNetworkState
リソースを絞り込むことができます。-
NodeNetworkState
リソースに関する詳細情報にアクセスするには、Name 列にリストされているNodeNetworkState
リソース名をクリックします。 -
NodeNetworkState
リソースの Network Details セクションをデプロイメントして表示するには、> アイコンをクリックします。あるいは、Network interface 列の下の各インターフェイスタイプをクリックして、ネットワークの詳細を表示することもできます。
28.2.3. Web コンソールからのポリシーの管理
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用して、ノードからのインターフェイスの追加または削除など、ノードネットワーク設定を更新できます。Web コンソールからポリシーを管理するには、Networking メニューの NodeNetworkConfigurationPolicy ページで作成されたポリシーのリストにアクセスします。このページでは、ポリシーを作成、更新、監視、削除できます。
28.2.3.1. ポリシーステータスの監視
NodeNetworkConfigurationPolicy ページからポリシーのステータスを監視できます。このページには、クラスター内に作成されたすべてのポリシーが次の列を含む表形式で表示されます。
- 名前
- 作成されたポリシーの名前。
- 一致したノード
- ポリシーが適用されるノードの数。これは、ノードセレクターに基づくノードのサブセット、またはクラスター上のすべてのノードのいずれかになります。
- ノードのネットワーク状態
- 一致したノードの実行状態。制定状態をクリックすると、ステータスの詳細情報が表示されます。
目的のポリシーを見つけるには、Filter オプションを使用するか、検索オプションを使用して、制定状態に基づいてリストをフィルターできます。
28.2.3.2. ポリシーの作成
Web コンソールでフォームまたは YAML を使用してポリシーを作成できます。
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 NodeNetworkConfigurationPolicy ページで Create をクリックし、From Form オプションを選択します。
既存のポリシーがない場合は、Create NodeNetworkConfigurationPolicy をクリックして、フォームを使用してポリシーを作成することもできます。
注記YAML を使用してポリシーを作成するには、Create をクリックし、With YAML オプションを選択します。次の手順は、フォームを使用してポリシーを作成する場合にのみ適用されます。
- オプション: Apply this NodeNetworkConfigurationPolicy only to specific subsets of nodes using the node selector チェックボックスをオンにして、ポリシーを適用する必要があるノードを指定します。
- Policy name フィールドにポリシー名を入力します。
- オプション: Description フィールドにポリシーの説明を入力します。
オプション: Policy Interface(s) セクションでは、編集可能なフィールドにプリセット値が設定されたブリッジインターフェイスがデフォルトで追加されます。次の手順を実行して値を編集します。
- Interface name フィールドにインターフェイスの名前を入力します。
- Network state ドロップダウンからネットワーク状態を選択します。デフォルトで選択されている値は Up です。
Type ドロップダウンからインターフェイスのタイプを選択します。使用可能な値は、Bridge、Bonding、および Ethernet です。デフォルトで選択されている値は Bridge です。
注記フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集できません。
オプション: IP 設定セクションで、IPv4 チェックボックスをオンにしてインターフェイスに IPv4 アドレスを割り当て、IP アドレス割り当ての詳細を設定します。
- IP address をクリックしてインターフェイスを静的 IP アドレスで設定するか、DHCP をクリックして IP アドレスを自動割り当てします。
IP address オプションを選択した場合は、IPV4 address フィールドに IPv4 アドレスを、Prefix length フィールドに接頭辞長を入力します。
DHCP オプションを選択した場合は、無効にするオプションのチェックを外します。使用可能なオプションは、Auto-DNS、Auto-routes、および Auto-gateway です。すべてのオプションがデフォルトで選択されています。
- オプション: Port フィールドにポート番号を入力します。
- オプション: STP を有効にするには、Enable STP チェックボックスをオンにします。
- オプション: ポリシーにインターフェイスを追加するには、Add another interface to the policy をクリックします。
- オプション: ポリシーからインターフェイスを削除するには、インターフェイスの横にあるアイコン をクリックします。
注記または、ページ上部の Edit YAML をクリックして、YAML を使用してフォームの編集を続けることもできます。
- Create をクリックしてポリシーの作成を完了します。
28.2.3.3. ポリシーの更新
28.2.3.3.1. フォームを使用してポリシーを更新する
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 - NodeNetworkConfigurationPolicy ページで、編集するポリシーの横にあるアイコン を選択し、Edit をクリックします。
- 更新するフィールドを編集します。
- Save をクリックします。
フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集することはできません。
28.2.3.3.2. YAML を使用したポリシーの更新
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 - NodeNetworkConfigurationPolicy ページで、編集するポリシーの Name 列の下にあるポリシー名をクリックします。
- YAML タブをクリックし、YAML を編集します。
- Save をクリックします。
28.2.3.4. ポリシーの削除
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 - NodeNetworkConfigurationPolicy ページで、削除するポリシーの横にあるアイコン を選択し、Delete をクリックします。
- ポップアップウィンドウで、削除を確認するポリシー名を入力し、Delete をクリックします。
28.2.4. CLI を使用したポリシーの管理
28.2.4.1. ノード上でのインターフェイスの作成
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用してクラスター内のノード上にインターフェイスを作成します。マニフェストには、インターフェイスの要求された設定の詳細が含まれます。
デフォルトでは、マニフェストはクラスター内のすべてのノードに適用されます。インターフェイスを特定ノードに追加するには、ノードセレクターの spec: nodeSelector
パラメーターおよび適切な <key>:<value>
を追加します。
複数の nmstate 対応ノードを同時に設定できます。この設定は、並列のノードの 50% に適用されます。このストラテジーでは、ネットワーク接続に障害が発生した場合にクラスター全体が使用できなくなるのを回避します。クラスターの特定の部分に、ポリシーの並行設定を適用するには、maxUnavailable
フィールドを使用します。
手順
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 サーバーの検索およびサーバー設定を指定します。
ノードのネットワークポリシーを作成します。
$ oc apply -f br1-eth1-policy.yaml 1
- 1
- ノードネットワーク設定ポリシーマニフェストのファイル名。
関連情報
28.2.4.2. ノード上でのノードネットワークポリシー更新の確認
NodeNetworkConfigurationPolicy
マニフェストは、クラスターのノードについて要求されるネットワーク設定を記述します。ノードネットワークポリシーには、要求されたネットワーク設定と、クラスター全体でのポリシーの実行ステータスが含まれます。
ノードネットワークポリシーを適用する際に、NodeNetworkConfigurationEnactment
オブジェクトがクラスター内のすべてのノードについて作成されます。ノードネットワーク設定の enactment (実行) は、そのノードでのポリシーの実行ステータスを表す読み取り専用オブジェクトです。ポリシーがノードに適用されない場合、そのノードの enactment (実行) にはトラブルシューティングのためのトレースバックが含まれます。
手順
ポリシーがクラスターに適用されていることを確認するには、ポリシーとそのステータスをリスト表示します。
$ oc get nncp
オプション: ポリシーの設定に想定されている以上の時間がかかる場合は、特定のポリシーの要求される状態とステータスの状態を検査できます。
$ oc get nncp <policy> -o yaml
オプション: ポリシーのすべてのノード上での設定に想定されている以上の時間がかかる場合は、クラスターの enactment (実行) のステータスをリスト表示できます。
$ oc get nnce
オプション: 特定の enactment (実行) の設定 (失敗した設定のエラーレポートを含む) を表示するには、以下を実行します。
$ oc get nnce <node>.<policy> -o yaml
28.2.4.3. ノードからインターフェイスの削除
NodeNetworkConfigurationPolicy
オブジェクトを編集し、インターフェイスの state
を absent
に設定して、クラスターの 1 つ以上のノードからインターフェイスを削除できます。
ノードからインターフェイスを削除しても、ノードのネットワーク設定は以前の状態に自動的に復元されません。以前の状態に復元する場合、そのノードのネットワーク設定をポリシーで定義する必要があります。
ブリッジまたはボンディングインターフェイスを削除すると、そのブリッジまたはボンディングインターフェイスに以前に接続されたか、それらの下位にあるノード NIC は down
の状態になり、到達できなくなります。接続が失われないようにするには、同じポリシーでノード NIC を設定し、ステータスを up
にし、DHCP または静的 IP アドレスのいずれかになるようにします。
インターフェイスを追加したポリシーを削除しても、ノード上のポリシーの設定は変更されません。NodeNetworkConfigurationPolicy
はクラスターのオブジェクトですが、これは要求される設定のみを表します。
同様に、インターフェイスを削除してもポリシーは削除されません。
手順
インターフェイスの作成に使用する
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
を有効にします。
ノード上でポリシーを更新し、インターフェイスを削除します。
$ oc apply -f <br1-eth1-policy.yaml> 1
- 1
- ポリシーマニフェストのファイル名。
28.2.5. 異なるインターフェイスのポリシー設定の例
ポリシーを適用する際には、クラスターが最適なパフォーマンス状態で実行されるように、さまざまな NodeNetworkConfigurationPolicy
(NNCP) マニフェスト設定の例を読む前に、次の要素を考慮してください。
-
ポリシーを複数のノードに適用する必要がある場合は、ターゲットノードごとに
NodeNetworkConfigurationPolicy
マニフェストを作成します。Kubernetes NMState Operator は、NNCP を持つ各ノードにポリシーを不特定の順序で適用します。この方法でポリシーのスコープを設定すると、ポリシーの適用にかかる時間が短縮されますが、クラスターの設定にエラーがある場合はクラスター全体が停止するリスクがあります。この種のエラーを回避するには、最初に一部のノードに NNCP を適用し、正しく設定されていることを確認してから、残りのノードにポリシーを適用します。 -
多数のノードにポリシーを適用する必要があるが、すべてのターゲットノードに対して 1 つの NNCP のみを作成する場合、Kubernetes NMState Operator は各ノードにポリシーを順番に適用します。クラスター設定の
maxUnavailable
パラメーターを使用して、ターゲットノードに対するポリシー適用の速度と範囲を設定できます。パラメーターのパーセンテージ値を低く設定すると、ポリシー適用を受信しているノードのごく一部に障害が影響する場合に、クラスター全体の障害が発生するリスクを軽減できます。 - 関連するすべてのネットワーク設定を 1 つのポリシーで指定することを検討してください。
- ノードが再起動すると、Kubernetes NMState Operator はノードにポリシーを適用する順序を制御できなくなります。Kubernetes NMState Operator は、相互依存するポリシーを順番に適用する場合があります。その結果、ネットワークオブジェクトがデグレード状態になることがあります。
28.2.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。
28.2.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 タグ。
28.2.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 または 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
- 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.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
に設定されます。
28.2.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
を有効にします。
28.2.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 を有効にします。
28.2.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
28.2.6. ブリッジに接続された NIC の静的 IP の取得
NIC の静的 IP のキャプチャーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
28.2.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。
28.2.7. 例: IP 管理
次の設定スニペットの例は、さまざまな IP 管理方法を示しています。
これらの例では、ethernet
インターフェイスタイプを使用して、ポリシー設定に関連するコンテキストを表示しつつ、サンプルを単純化します。これらの IP 管理のサンプルは、他のインターフェイスタイプでも使用できます。
28.2.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 アドレスに置き換えます。
28.2.7.2. IP アドレスなし
以下のスニペットでは、インターフェイスに IP アドレスがないことを確認できます。
# ... interfaces: - name: eth1 description: No IP on eth1 type: ethernet state: up ipv4: enabled: false # ...
28.2.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 # ...
28.2.7.4. DNS
デフォルトでは、nmstate
API は DNS 値をネットワークインターフェイスに保存するのではなく、グローバルに保存します。特定の状況では、DNS 値を保存するようにネットワークインターフェイスを設定する必要があります。ネットワークインターフェイスの DNS 設定を定義するには、最初にネットワークインターフェイスの YAML 設定ファイルで dns-resolver
セクションを指定する必要があります。
DNS 設定の設定は、/etc/resolv.conf
ファイルの変更に相当します。
DNS リゾルバーの設定時に、OVNKubernetes 管理の Open vSwitch ブリッジである 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 # ...
28.2.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 # ...