第23章 Kubernetes NMState
23.1. ノードのネットワーク状態と設定の監視と更新
Kubernetes NMState Operator をインストールしたら、Operator を使用してクラスターのノードのネットワーク状態とネットワーク設定を監視および更新できます。
NMState Operator のインストール方法の詳細は、Kubernetes NMState Operator を参照してください。
23.1.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
23.1.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 列の下の各インターフェイスタイプをクリックして、ネットワークの詳細を表示することもできます。
23.1.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 (ノードネットワークポリシー) と作成済みインターフェイスを削除するには、通常、次のアクションが必要になります。
-
NNCP を編集し、ファイルからインターフェイスの詳細を削除します。ファイルから
name
、state
、type
パラメーターは削除しないでください。 -
NNCP の
interface.state
セクションにstate: absent
を追加します。 -
oc apply -f <nncp_file_name>
を実行します。Kubernetes NMState Operator がクラスター内の各ノードにノードネットワークポリシーを適用すると、各ノードで以前に作成されたインターフェイスには absent のマークが付けられます。 -
NNCP を削除するには、
oc delete nncp
を実行します。
関連情報
23.1.4. ノード上に IP over InfiniBand インターフェイスを作成する
OpenShift Container Platform Web コンソールでは、InfiniBand (IPoIB) モードをサポートする NVIDIA Network Operator などの Red Hat 認定サードパーティー Operator をインストールできます。サードパーティー Operator は、通常、OpenShift Container Platform クラスター内のリソースを管理するために他のベンダーのインフラストラクチャーと組み合わせて使用します。クラスター内のノードに IPoIB インターフェイスを作成するには、NodeNetworkConfigurationPolicy
(NNCP) マニフェストファイルで InfiniBand (IPoIB) インターフェイスを定義する必要があります。
OpenShift Container Platform のドキュメントでは、NodeNetworkConfigurationPolicy
(NNCP) マニフェストファイルで IPoIB インターフェイス設定を定義する方法についてのみ説明しています。設定手順の大部分については、NVIDIA およびその他のサードパーティーベンダーのドキュメントを参照してください。Red Hat のサポートは、NNCP 設定以外には適用されません。
NVIDIA Operator の詳細は、Getting Started with Red Hat OpenShift (NVIDIA Docs Hub) を参照してください。
前提条件
- IPoIB インターフェイスをサポートする Red Hat 認定サードパーティー Operator をインストールした。
手順
NodeNetworkConfigurationPolicy
(NNCP) マニフェストファイルを作成または編集し、ファイル内で IPoIB インターフェイスを指定します。apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: worker-0-ipoib spec: # ... interfaces: - description: "" infiniband: mode: datagram 1 pkey: "0xffff" 2 ipv4: address: - ip: 100.125.3.4 prefix-length: 16 dhcp: false enabled: true ipv6: enabled: false name: ibp27s0 state: up type: infiniband 3 # ...
- 1
datagram
は IPoIB インターフェイスのデフォルトモードであり、このモードではパフォーマンスとレイテンシーが最適化されます。connected
モードはサポートされているモードですが、周辺ネットワークデバイスとのノードの接続性を高めるために最大転送単位 (MTU) 値を調整する必要がある場合にのみ、このモードを使用することを検討してください。- 2
- 文字列または整数値をサポートします。このパラメーターは、NVIDIA などのサードパーティーベンダーとの認証および暗号化通信を目的としたインターフェイスの保護キー (P-key) を定義します。
None
および0xffff
の値は、InfiniBand システムの基本インターフェイスの保護キーを示します。 - 3
- インターフェイスのタイプを `infiniband` に設定します。
次のコマンドを実行して、クラスター内の各ノードに NNCP 設定を適用します。Kubernetes NMState Operator は、各ノードに IPoIB インターフェイスを作成できます。
$ oc apply -f <nncp_file_name> 1
- 1
<nncp_file_name>
は、NNCP ファイルの名前に置き換えます。
23.1.5. Web コンソールからのポリシーの管理
NodeNetworkConfigurationPolicy
マニフェストをクラスターに適用して、ノードからのインターフェイスの追加または削除など、ノードネットワーク設定を更新できます。Web コンソールからポリシーを管理するには、Networking メニューの NodeNetworkConfigurationPolicy ページで作成されたポリシーのリストにアクセスします。このページでは、ポリシーを作成、更新、監視、削除できます。
23.1.5.1. ポリシーステータスの監視
NodeNetworkConfigurationPolicy ページからポリシーのステータスを監視できます。このページには、クラスター内に作成されたすべてのポリシーが次の列を含む表形式で表示されます。
- 名前
- 作成されたポリシーの名前。
- 一致したノード
- ポリシーが適用されるノードの数。これは、ノードセレクターに基づくノードのサブセット、またはクラスター上のすべてのノードのいずれかになります。
- ノードのネットワーク状態
- 一致したノードの実行状態。制定状態をクリックすると、ステータスの詳細情報が表示されます。
目的のポリシーを見つけるには、Filter オプションを使用するか、検索オプションを使用して、制定状態に基づいてリストをフィルターできます。
23.1.5.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 をクリックしてポリシーの作成を完了します。
23.1.6. ポリシーの更新
23.1.6.1. フォームを使用してポリシーを更新する
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 -
NodeNetworkConfigurationPolicy ページで、編集するポリシーの横にある
アイコンをクリックし、Edit をクリックします。
- 更新するフィールドを編集します。
- Save をクリックします。
フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集することはできません。
23.1.6.2. YAML を使用したポリシーの更新
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 - NodeNetworkConfigurationPolicy ページで、編集するポリシーの Name 列の下にあるポリシー名をクリックします。
- YAML タブをクリックし、YAML を編集します。
- Save をクリックします。
23.1.6.3. ポリシーの削除
手順
-
Networking
NodeNetworkConfigurationPolicy に移動します。 -
NodeNetworkConfigurationPolicy ページで、削除するポリシーの横にあるアイコン
を選択し、Delete をクリックします。
- ポップアップウィンドウで、削除を確認するポリシー名を入力し、Delete をクリックします。
23.1.7. CLI を使用したポリシーの管理
23.1.7.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
- ノードネットワーク設定ポリシーマニフェストのファイル名。
関連情報
23.1.7.2. ノード上でのノードネットワークポリシー更新の確認
ノードネットワークポリシーを適用する際に、NodeNetworkConfigurationEnactment
オブジェクトがクラスター内のすべてのノードについて作成されます。ノードネットワーク設定の enactment (実行) は、そのノードでのポリシーの実行ステータスを表す読み取り専用オブジェクトです。ポリシーがノードに適用されない場合、そのノードの enactment (実行) にはトラブルシューティングのためのトレースバックが含まれます。
手順
ポリシーがクラスターに適用されていることを確認するには、ポリシーとそのステータスをリスト表示します。
$ oc get nncp
オプション: ポリシーの設定に想定されている以上の時間がかかる場合は、特定のポリシーの要求される状態とステータスの状態を検査できます。
$ oc get nncp <policy> -o yaml
オプション: ポリシーのすべてのノード上での設定に想定されている以上の時間がかかる場合は、クラスターの enactment (実行) のステータスをリスト表示できます。
$ oc get nnce
オプション: 特定の enactment (実行) の設定 (失敗した設定のエラーレポートを含む) を表示するには、以下を実行します。
$ oc get nnce <node>.<policy> -o yaml
23.1.7.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
- ポリシーマニフェストのファイル名。
23.1.8. 異なるインターフェイスのポリシー設定の例
ポリシーをノードに適用する場合は、さまざまな NodeNetworkConfigurationPolicy
(NNCP) マニフェスト設定例を読む前に、クラスターが最適なパフォーマンス状態で実行されるように次の要素を考慮してください。
-
ポリシーを複数のノードに適用する必要がある場合は、ターゲットノードごとに
NodeNetworkConfigurationPolicy
マニフェストを作成します。Kubernetes NMState Operator は、定義済みの NNCP を持つ各ノードにポリシーを不特定の順序で適用します。この方法でポリシーのスコープを設定すると、ポリシーの適用にかかる時間が短縮されますが、クラスターの設定にエラーがある場合はクラスター全体が停止するリスクがあります。この種のエラーを回避するには、最初に一部のノードに NNCP を適用し、これらのノードに対して NNCP が正しく設定されていることを確認してから、残りのノードにポリシーを適用します。 -
多数のノードにポリシーを適用する必要があるが、すべてのノードに対して 1 つの NNCP のみを作成する場合、Kubernetes NMState Operator は各ノードにポリシーを順番に適用します。クラスターの設定ファイルの
maxUnavailable
パラメーターを使用して、ターゲットノードに対するポリシー適用の速度と範囲を設定できます。パラメーターのパーセンテージ値を低く設定すると、ポリシー適用を受信しているノードのごく一部に障害が影響する場合に、クラスター全体の障害が発生するリスクを軽減できます。 - 関連するすべてのネットワーク設定を 1 つのポリシーで指定することを検討してください。
- ノードが再起動すると、Kubernetes NMState Operator はノードにポリシーを適用する順序を制御できなくなります。Kubernetes NMState Operator は、相互依存するポリシーを順番に適用する場合があります。その結果、ネットワークオブジェクトがデグレード状態になることがあります。
23.1.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。
23.1.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 タグ。
23.1.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 ホストネットワークを設定して、パフォーマンスを最適化します。
- ネットワークインターフェイスの 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 ネットワークインターフェイスが、追加インターフェイスとしてボンディングされたネットワークインターフェイスに追加されています。
関連情報
23.1.8.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
に設定されます。
23.1.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
を有効にします。
23.1.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 を有効にします。
23.1.8.7. 例: VRF インスタンスノードのネットワーク設定ポリシーを使用したネットワークインターフェイス
NodeNetworkConfigurationPolicy
カスタムリソース (CR) を適用して、Virtual Routing and Forwarding (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
23.1.9. ブリッジに接続された NIC の静的 IP の取得
NIC の静的 IP のキャプチャーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
23.1.9.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。
23.1.10. 例: IP 管理
次の設定スニペットの例は、さまざまな IP 管理方法を示しています。
これらの例では、ethernet
インターフェイスタイプを使用して、ポリシー設定に関連するコンテキストを表示しつつ、サンプルを単純化します。これらの IP 管理のサンプルは、他のインターフェイスタイプでも使用できます。
23.1.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 アドレスに置き換えます。
23.1.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 アドレスを受け取ります。
23.1.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 # ...
23.1.10.4. DNS
デフォルトでは、nmstate
API は DNS 値をネットワークインターフェイスに保存するのではなく、グローバルに保存します。特定の状況では、DNS 値を保存するようにネットワークインターフェイスを設定する必要があります。
DNS 設定の設定は、/etc/resolv.conf
ファイルの変更に相当します。
ネットワークインターフェイスの DNS 設定を定義するには、最初にネットワークインターフェイスの YAML 設定ファイルで dns-resolver
セクションを指定する必要があります。NNCP 設定をネットワークインターフェイスに適用するには、oc apply -f <nncp_file_name>
コマンドを実行する必要があります。
カスタマイズされた 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 # ...
重要次の例に示すように、NNCP ファイルの
dns-resolver.config
セクションで DNS オプションを指定できます。# ... desiredState: dns-resolver: config: search: 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: 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 # ...
23.1.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 # ...
静的ルートを設定する際に、カスタマイズされた br-ex
ブリッジを手動で設定していない限り、OVN-Kubernetes br-ex
ブリッジをネクストホップインターフェイスとして使用することはできません。
詳細は、インストーラーでプロビジョニングされるクラスターのベアメタルへのデプロイ、または ユーザーがプロビジョニングしたクラスターをベアメタルにインストール ドキュメントの「カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成」を参照してください。