NVIDIAネットワーク事業者

{"limits": {"cpu": "500m", "memory": "128Mi"}, "requests": {"cpu": "5m", "memory": "64Mi"}}

{"beta.kubernetes.io/os": "linux", "network.nvidia.com/operator.mofed.wait": "false"}

NVIDIA Network Operatorポッドのスケジュールを制御します。

• オペレータを安定したインフラストラクチャーノードまたはコントロールプレーンノードで保持します。
• オペレータがビジー・ワーカー・ノード上のワークロードと競合しないようにします。
• クラスタに多数のノードがあり、ノード状態が頻繁に変更される場合に、ネットワーク制御ループを予測可能にするのに役立ちます。

この引数が正しく構成されていない場合は、次のようにします。

• オペレータは、オーバーロードされたワーカー・ノードで実行できます。
• セレクタが制限しすぎるか正しくない場合、演算子ポッドは Pending 状態のままになることがあります。
• オペレータが不安定な場合、ネットワーク関連のリコンシリエーションが遅くなるか、一貫性がなくなる可能性があります。

• 専用インフラストラクチャ・ノードでオペレータをスケジュールします。
• シンプルで信頼性の高いセレクタを使用します。
• ワークロードが頻繁に変更される場合は、オペレータをワーカー・プールから遠ざけます。

NVIDIAネットワーク・オペレータ・ポッドおよび関連するDaemonSetの許容範囲を制御します。

• オペレータとそのDaemonSetを、テイントされたインフラストラクチャ・ノードで実行できるようにします。
• コントロールプレーンまたは専用ネットワークノードでの配置の障害を防止します。
• GPUまたはネットワーク・ノードが汚れている場合の分離をサポートします。

この引数が正しく構成されていない場合は、次のようにします。

• オペレータまたはそのDaemonSetは、テイントされたノードで Pending 状態のままになる場合があります。
• SR-IOV、ドライバ、またはCNIコンポーネントが必要なノードで実行されない場合があります。
• 一部のノードは、必要なネットワーク機能を受信しない場合があります。

• 許容範囲をノード・プールで使用されるtaintに一致させます。
• オペレータ管理のDaemonSet間で一貫した許容範囲を使用します。
• ノード・テイント・ポリシーの変更後に構成を再テストします。

NVIDIAネットワーク・オペレータ・ポッドのノード・アフィニティ・ルールを制御します。

• ノードの適切なクラスで演算子を保持します。
• オペレータがワーカー・ノード・チャーンの影響を受ける可能性を減らします。
• オペレータは、安定したネットワーク・インフラストラクチャの近くで実行できます。

この引数が正しく構成されていない場合は、次のようにします。

• オペレータが不適切なノードでスケジュールされている可能性があります。
• ルールが制限しすぎると、演算子は Pending 状態のままになります。
• ルールが広すぎると、配置によって意図した回復力が得られない場合があります。

• アフィニティ・ルールを使用して、安定したノードを優先します。
• マルチゾーン制約またはマルチプール制約が必要でないかぎり、ルールは単純にしてください。
• 必要に応じて、アフィニティ・ルールを許容範囲と組み合せます。

NVIDIA Network OperatorコンテナのCPUおよびメモリーリクエストと制限を定義します。

オペレータは、クラスタ全体のネットワーキング・リソースを調整します。ノードの数が増えるにつれて、より多くのオブジェクト、ノード状態の変更およびリコンシリエーション操作を処理する必要があります。

また、オペレータはノード機能検出ラベルを使用して、ネットワーク・コンポーネントが必要なノードを判別します。

リソースのサイズが小さい場合:

• 和解は遅いかもしれません。
• ネットワーキング・ソフトウェアのロールアウトが遅延する場合があります。
• オペレータは、頻繁なノード変更または構成の更新中に不安定になることがあります。

• 頻繁なノード変更または多数のネットワーキング・カスタム・リソースがあるクラスタのCPUおよびメモリー・リソースを増やします。
• オペレータのCPU使用率、メモリー使用量およびリコンシリエーション・レイテンシを監視します。
• この引数は、コントロールプレーンのサイズ設定として扱います。

CNIバイナリがデプロイされるノードのディレクトリを制御します。

CNIバイナリは、コンテナ・ランタイムで使用されるディレクトリにデプロイする必要があります。パスが正しくないと、多数のノードが同時に影響を受ける可能性があります。

この引数が正しく構成されていない場合は、次のようにします。

• ポッドが作成される場合がありますが、ネットワーキングが使用できなくなる可能性があります。
• CNIバイナリが間違ったホストパスにデプロイされている可能性があります。
• ネットワークが機能していなくても、クラスタが構成されているように見えることがあります。

• 値は、ノード・ランタイムのデフォルトと位置合せしたままにします。
• この値は、コンテナ・ランタイムで別のCNIバイナリ・ディレクトリを使用している場合にのみ変更してください。
• 広く適用する前に、単一ノード・プールのパスを検証します。

CNI構成ファイルがデプロイされるホスト・ディレクトリを制御します。

CNI構成ファイルは、kubeletまたはコンテナ・ランタイムによって読み取られたディレクトリに配置する必要があります。正しくないディレクトリは、構成を使用するすべてのノードに影響する可能性があります。

この引数が正しく構成されていない場合は、次のようにします。

• CNI構成ファイルは、kubeletまたはコンテナ・ランタイムが読み取らないディレクトリにデプロイされる場合があります。
• セカンダリネットワーキングが機能しない場合でも、ノードが構成されていると表示されることがあります。
• パスの不一致にもかかわらずオペレータが正常であるように見えるため、トラブルシューティングが困難な場合があります。

• 値をノード・ランタイムで使用されるCNI構成ディレクトリと連携させます。
• この引数は、クラスタ・ポリシー設定ではなくホスト実行時設定として扱います。
• 広い範囲で適用する前に、単一のGPUまたはネットワーク・ノードでファイル配置を検証します。

NVIDIAネットワーク・オペレータがアドミッション・コントローラをデプロイするかどうかを制御します。

アドミッション・コントローラは、無効な構成がクラスタに入らないようにするのに役立ちます。これは、多くのユーザーまたは自動化システムがネットワーキング・カスタム・リソースを作成する場合に重要になります。

アドミッションコントローラが無効になっている場合:

• 無効なSR-IOV、ネットワークポリシー、またはNIC構成が受け入れられる可能性があります。
• 問題が検出される前に、無効な設定が多数のノードに適用される可能性があります。
• 大規模なクラスタでは、運用リスクが増加します。

• 本番環境でアドミッション・コントローラを有効にします。
• Webフックで生成された証明書が使用されている場合は、証明書マネージャが健全であることを確認します。

SR-IOVネットワークオペレータを配備するかどうかを制御します。

SR-IOVネットワークオペレータは、一部のRDMAおよびGPUDirect RDMA構成を含む、仮想機能ベースの高性能ネットワーキングに必要なSR-IOVコンポーネントを提供します。

必要なときにSR-IOVネットワークオペレータが無効になっている場合:

• SR-IOV機能は配備されません。
• ノードは、ワークロードに必要なネットワーキング・リソースを提供しない場合があります。
• GPUおよびRDMAネットワーク・パスは未完了のままになる場合があります。

• クラスタでSR-IOVが必要な場合にのみ、SR-IOVネットワークオペレータを有効にします。
• 仮想機能ベースのネットワークを使用しないクラスタでは、無効にしたままにします。
• 有効にすると、基本ネットワーキング・コンポーネントとして扱います。

SR-IOVネットワークオペレータによって作成されたリソースに使用される接頭辞を設定します。

接頭辞によって、Kubernetesおよびワークロードが使用する拡張リソース名が決まります。接頭辞を変更するには、すべてのワークロードマニフェストで新しいリソース名を使用する必要があります。

この引数が正しく構成されていない場合は、次のようにします。

• ワークロードで、正しくない拡張リソース名がリクエストされる場合があります。
• スケジューラがリクエストされたリソースと一致しないため、ポッドは Pending 状態のままになる可能性があります。
• 古いリソース・ネーミング規則と新しいリソース・ネーミング規則が矛盾して使用される場合があります。

• 別のネーミング・ポリシーが必要でないかぎり、デフォルト値を保持します。
• 実行中のクラスタで接頭辞を頻繁に変更しないでください。
• ワークロード・マニフェストで同じ接頭辞が使用されていることを確認します。

SR-IOVネットワークオペレータのアドミッションコントローラを制御します。

アドミッションコントローラは、ノードに到達する前に無効なSR-IOV構成を検出し、ノードグループとポリシーの数が増えるにつれて、仮想機能とNIC設定の一貫性を維持するのに役立ちます。

アドミッション・コントローラが無効になっている場合:

• 無効なSR-IOV構成が適用される可能性があります。
• 誤った構成が多数のノードに分散する可能性があります。
• 構成エラーからの回復はより困難な場合があります。

• 本番環境でアドミッション・コントローラを有効にします。
• 証明書マネージャおよびWebフック証明書の処理が健全であることを確認します。
• アドミッション・コントローラを無効にするのは、アドミッションWebフックを回避する特定の理由がある場合のみです。

SR-IOV構成デーモンが構成するノードを選択します。

セレクタは、SR-IOV構成を受信するノードを決定します。大規模なクラスタでは、誤ったセレクタが数百または数千のノードに影響する可能性があります。

この引数が正しく構成されていない場合は、次のようにします。

• SR-IOV構成が間違ったノードに適用されている可能性があります。
• 目的のノードが構成を受け取らない可能性があります。
• ネットワーキング機能は、ノード・プール間で一貫性がなくなる可能性があります。

• セレクタは、ノード機能検出によって生成されたノード・ラベルと密接に連携します。
• 広く適用する前に、小さいノード・グループでセレクタをテストします。

仮想機能の作成をオペレータまたはカスタム・ロジックのどちらで自動的に管理するかを決定します。

自動化された一貫性のある仮想機能作成プロセスにより、ノード間の構成の違いが軽減されます。カスタム作成ロジックにより、柔軟性が向上しますが、一貫性のないノード構成の可能性が高まります。

この引数が正しく構成されていない場合は、次のようにします。

• 仮想機能が予期されたノードに作成されない可能性があります。
• ノード・プールの動作は異なる場合があります。
• ネットワーク構成は時間の経過とともに変化する可能性があります。

• カスタム・ロジックが必要でないかぎり、オペレータ管理の仮想機能の作成を使用します。
• 同じ操作ドメイン内で作成モードを混在させないようにします。
• 幅広く適用する前に、単一ノード・プールで仮想機能の作成を検証します。

オペレータがノード機能検出依存性チェックをスキップするかどうかを決定します。

チェックをスキップすると、ノード機能検出が個別に管理されている場合に冗長な依存関係の検証が回避されます。ただし、クラスタ管理者は、必要なノード・ラベルが使用可能であり、正しいままであることを確認する必要があります。

この引数が正しく構成されていない場合は、次のようにします。

• オペレータは、ノード機能検出がインストールされていないか正常な場合でも、ノード機能検出に依存することがあります。
• 必要なラベルがない可能性があります。
• SR-IOVおよび関連コンポーネントのノードターゲット指定が正しくないと、多くのノードに影響する可能性があります。

• ノード機能の検出がすでにデプロイおよび検証されている場合のみ、依存性チェックをスキップします。
• NVIDIA Network Operatorを有効にする前に、目的のノードに必要なラベルが存在することを確認します。