GPUホストの修復

ユーザーが開始した修復を構成する前に、適格な管理対象GPUノード・プールおよび制御されたテスト・ノードを特定します。選択したノードのワークロードを中断できることを確認します。

ユーザーが開始した修復には、OCI IAMとKubernetes RBACの両方でアクセス制御が必要です。OCI IAMでは、OKEクラスタ・リソース・プリンシパルに、ホスト条件のコンピュートへのレポートに使用される定義済タグを適用する権限が必要です。Kubernetesでは、保護された修復リクエストを開始できるのは、信頼できるオペレータのみです。トラステッド・オペレータには、ターゲットのNodeリソースおよびClusterRoleBindingを介して委任されたOKE固有の認可を更新するための標準のKubernetes RBAC権限が必要です。

ユーザーが開始した修復をリクエストすると、OKEは次のアクションを調整します。

1. 一度に1つの修復リクエストのみが処理されるようにします。
2. ノードをコード化して、Kubernetesによって新しいポッドがスケジュールされないようにします。
3. ノードからワークロードを排出しようとします。
4. 条件をComputeにレポートし、影響を受けるインスタンスを終了します。
5. 管理対象ノード・プールの構成済容量をリストアします。

ユーザーが開始した修復を構成およびテストするには:

1. クラスタが拡張クラスタであり、Kubernetesバージョン1.32以上が実行されていることを確認します。ノードが適格な管理GPUワーカー・ノードであることを確認します。OKE管理ノード修復コントローラとNodeHealthReport CRD、oke-customer-node-repair-trigger ClusterRole、およびトリガー保護アドミッション・ポリシーとバインディングがクラスタにインストールされていることを確認します。OKE管理リソースが欠落している場合は、Oracle Supportに連絡してください。OKE管理リソースは再作成しないでください。

2. ライブ修復を使用する前に、サポート・リクエストを開き、テナンシのユーザー報告のハードウェア障害処理を有効にします。テナンシ、リージョン、クラスタOCIDおよびGPUノード・プールをリクエストに含めます。

3. ノード修復コントローラがホスト条件のコンピュートへのレポートに使用する定義済タグを作成または再利用します。

   ComputeInstanceHostActionsという名前のタグ・ネームスペースを作成または再利用します。そのネームスペースで、CustomerReportedHostStatusという名前のタグ・キー定義を作成または再利用します。同じテキストでフリーフォーム・タグを作成しないでください。詳細は、タグ・ネームスペースの作成およびタグ・キーの定義の作成を参照してください。

   元のインスタンスを終了する前に、ノード修復コントローラは、値unhealthyをインスタンス上のComputeInstanceHostActions.CustomerReportedHostStatus定義済タグに書き込みます。

4. OKEクラスタ・リソース・プリンシパルに、定義されたタグを適用するための狭いスコープの権限を付与するOCI IAMポリシーを作成します:

   Allow any-user to use tag-namespace in tenancy where all {request.principal.type = 'cluster', request.principal.id = '<cluster-ocid>', target.tag-namespace.name = 'ComputeInstanceHostActions'}

   IAMの変更には、伝播に時間がかかる場合があります。破壊的検証を実行する前に伝播を待機します。

5. 保護されたユーザーが開始した修復トリガーを信頼できるオペレータに委任します。

   信頼できるOCI IAMグループOCIDをOKE所有のoke-customer-node-repair-trigger ClusterRoleにバインドするClusterRoleBindingを作成します。オペレータには、ターゲットのNodeリソースを更新するための標準のKubernetes RBAC権限も必要です。

   次の内容を含むcir-trigger-operators.yamlという名前のファイルを作成します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: oke-node-repair-trigger-operators
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: oke-customer-node-repair-trigger
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: <trusted-oci-iam-group-ocid>

   <trusted-oci-iam-group-ocid>を、信頼できる演算子を含むOCI IAMグループのOCIDに置き換えます。

   次のように入力してバインディングを適用し、確認します。

   kubectl apply -f cir-trigger-operators.yaml

   kubectl get clusterrolebinding \
     oke-node-repair-trigger-operators \
     -o yaml

   このバインディングでは、Nodeリソースを更新するための一般権限は付与されません。既存のKubernetes認可モデルを使用して、信頼できるオペレータに必要な標準のKubernetes RBAC権限のみを付与します。

6. ドライラン・モードで、重複しないクラスタ・スコープのNodeRepairConfigカスタム・リソースを作成します。

   管理する恒久ノード・プール・ラベルを使用して、置換ノードに存在するノードを選択します。セレクタ・ラベルはユーザー定義です。置換ノードが保持するように、目的の管理対象ノード・プールにラベルを構成します。

   ノードは、1つのNodeRepairConfigリソースと完全に一致する必要があります。一致する構成または重複する構成がないリクエストは、修復の副作用なしで拒否されます。ユーザーが開始した修復およびGPUインスタンス・リカバリには、同じ構成または別個の構成を使用できます。別々の構成を使用する場合は、同じノードを複数の構成に含めないでください。そうしないと、修復要求は拒否されます。

   次の例では、ドライランモードで起動し、一度に1回の修復を許可し、異常ノードしきい値を10%に設定して、60分のドレイン猶予期間を使用し、強制猶予後の動作を無効にします。

   apiVersion: oci.oraclecloud.com/v1beta1
   kind: NodeRepairConfig
   metadata:
     name: gpu-node-repair
   spec:
     nodeSelector:
       matchLabels:
         example.com/gpu-repair: "enabled"
     policy:
       dryRun: true
       evictionGracePeriodMinutes: 60
       forceActionAfterGracePeriod: false
       maxUnhealthyNodeThreshold: "10%"
       maximumParallelNodeRepairs: 1

   policyセクションでは、dryRunおよびforceActionAfterGracePeriodはブール値です。evictionGracePeriodMinutesは負でない整数です。maximumParallelNodeRepairsは正の整数です。maxUnhealthyNodeThresholdは、正のノード数または引用符で囲まれた割合("10%"など)を受け入れます。

   dryRun: trueから開始します。構成の検証後、ライブ操作のためにdryRunのみをfalseに更新します。

7. 選択したノードに保護されたラベルoci.oraclecloud.com/customer-report-host-status=unhealthyを適用して、ドライラン修復をリクエストします。NodeHealthReportおよび関連するノード状態を調べます。ドライラン・リクエストは、完了したNodeHealthReportレコードを作成しますが、Compute定義済タグのコード化、ドレイン、適用、ノードの終了、再起動または置換は行いません。

8. 保護されたトリガー・ラベルをワンショット・ライブ・オーバーライドoci.oraclecloud.com/node-repair-dry-run=falseとともに適用して、ライブ修復をトリガーします。ライブ上書きはアクティブなトリガでのみ有効で、新しいトリガが作成された場合にのみサンプリングされます。

   ユーザーが開始した修復リクエストを再試行するには、oci.oraclecloud.com/customer-report-host-status=unhealthyラベルを削除して再適用します。同じラベル値を再適用しても、別のリクエストは開始されません。ラベルを削除しても、アクティブな修復は取り消されません。

   重要
   
   ユーザーが開始したライブ修復では、ワークロードをドレインし、元のコンピュート・インスタンスを終了できます。DrainingはKubernetes Eviction APIを使用し、ポッド・ディスラプションの予算を尊重します。DaemonSetポッドおよび静的ポッドはスキップされます。force-after-graceが有効な場合、ノード修復コントローラは残りのポッドを強制削除しませんが、後続のホスト・アクションはそれらを中断できます。

9. 修復アクションの進行状況、コンピュート定義タグ、元のインスタンスの終了、管理対象ノード・プール容量のリストア、および新しいUIDおよびインスタンスOCIDを使用した置換ノードの作成を確認します。終了したインスタンスのNodeHealthReportは、ワークフローの完了後も一時的に保持されます。

   Deferredの結果は、ワークフローが一時的にブロックされることを意味します。Failedの結果は、試行が停止したことを意味します。Supersededの結果は、優先度の高いOKEワークフローが引き継がれたことを意味します。Completedの結果は、OKEがリクエストされた終了ワークフローを終了したことを意味します。これは、物理的な修復が完了したことや、交換容量がReadyであることを意味しません。ワークフローが完了したら、管理対象ノード・プールに予想される容量があり、置換ノードが現在の正常なステータスをレポートしていることを確認します。

ユーザーが修復を開始する場合、置換ワーカー・ノードの作成は、管理対象ノード・プール・リコンシリエーションおよび使用可能なGPU容量によって異なります。完了したワークフローでは、基礎となるGPUフォルトが修正されたことは確認されません。

GPUインスタンス・リカバリを構成する前に、適格な管理対象GPUノード・プールを特定し、そのワークロードを中断できることを確認します。GPUインスタンス・リカバリでは、インスタンスを再起動する前に、影響を受けるノードをコード化およびドレインできます。

GPUインスタンス・リカバリを構成する前に、GPUホストをモニターするためにGPU Health Monitoringアドオンに必要なIAMポリシーを作成します:

Allow dynamic-group <dg-name> to manage instance-family in compartment id <compartment-ocid>

Allow dynamic-group <dg-name> to read instance-agent-plugins in compartment id <compartment-ocid>

ここでは:

• <dg-name>は、GPUワーカー・ノードのコンピュート・インスタンスを含む動的グループの名前です。たとえば、ALL {instance.compartment.id = '<compartment-ocid>'}などのルールを使用します。ノード・プールにタグを適用することで、次のようなより限定的なルールを作成できます。

  ALL {
    instance.compartment.id = 'ocid1.compartment.oc1..examplecompartment',
    tag.Operations.Workload.value = 'gpu-monitoring',
    tag.Operations.Environment.value = 'prod'
  }

  詳細は、ノード・プールへのタグの適用を参照してください。

• <compartment-ocid>は、GPUワーカー・ノードを含むコンパートメントのOCIDです

GPUインスタンス・リカバリは、次のGPUシェイプを使用する適格な管理対象GPUワーカー・ノードでのみサポートされます:

• BM.GPU.A10.4
• BM.GPU.A100-v2.8
• BM.GPU.B200.8
• BM.GPU.B300.8
• BM.GPU.B300.HS.8
• BM.GPU.B4.8
• BM.GPU.GB200-v2.4
• BM.GPU.GB200-v3.4
• BM.GPU.GB200.4
• BM.GPU.GB300.4
• BM.GPU.H100.8
• BM.GPU.H100T.8
• BM.GPU.H200-NC.8
• BM.GPU.H200.8
• BM.GPU.L40S-NC.4
• BM.GPU.L40S.4
• BM.GPU.MI300X.8
• BM.GPU.MI355X-v1.8
• BM.GPU.MI355X.8

GPUシェイプの可用性はリージョンによって異なります。選択したGPUシェイプがクラスタが実行されているリージョンで使用可能であることを確認します。

Oracle Cloud Agentバージョン1.64.0以降は、Compute RDMA GPU Monitoringプラグインで必要であり、選択したノードにインストールする必要があります。

OKEは、適格なGPUヘルス・シグナルを受信すると、次のアクションを調整します。

1. 一度に1つのリカバリ・リクエストのみが処理されるようにします。
2. ノードをコード化して、Kubernetesによって新しいポッドがスケジュールされないようにします。
3. ノードからワークロードを排出しようとします。
4. 影響を受けるコンピュート・インスタンスを再起動します。

GPUインスタンス・リカバリを構成するには:

1. クラスタでKubernetesバージョン1.32以上が実行されていることを確認します。ノードが適格な管理GPUワーカー・ノードであることを確認します。OKE管理ノード修復コントローラおよびNodeHealthReport CRDがクラスタにインストールされていることを確認し、GPUヘルス・モニタリング・アドオンがクラスタで使用可能であることを確認します。

2. 次を入力して、GPUヘルス・モニタリング・アドオンに、クラスタで実行されているKubernetesバージョンのACTIVEオプションがあることを確認します:

   oci ce addon-option list \
     --kubernetes-version <version> \
     --addon-name GpuHealthMonitoring

   アドオンをインストールするときは、バージョンを固定するのではなく、最新の ACTIVEオプションをインストールしてください。インストールされるバージョンは、v1.1.0以降である必要があります。

3. 次のように入力して、OKE管理GPUヘルス・モニタリング・アドオンをインストールします:

   oci ce cluster install-addon \
     --addon-name GpuHealthMonitoring \
     --cluster-id $CLUSTER_ID \
     --region $REGION

   このコマンドは、クラスタで使用可能な最新バージョンのアドオンをインストールします。

   サポートされているアドオン構成キーは、nodeSelectors、tolerationsおよびrollingUpdateです。rollingUpdate値は、プレーン・テキストのJSON形式を使用して、maxSurgeおよびmaxUnavailableによるローリング更新動作を制御します。

4. GpuHealthMonitoringConfigリソースを作成して、選択したGPUワーカー・ノードのGPUヘルス・モニタリングを有効にします。構成には、spec.enabledおよび空でないノード・セレクタが必要です。

   apiVersion: oci.oraclecloud.com/v1beta1
   kind: GpuHealthMonitoringConfig
   metadata:
     name: gpu-health-monitoring
   spec:
     enabled: true
     nodeSelector:
       matchLabels:
         nvidia.com/gpu.present: "true"

   構成をgpu-health-monitoring.yamlとして保存し、次のように入力して適用します。

   kubectl apply -f gpu-health-monitoring.yaml

   spec.enabledフィールドは、選択したノードのモニタリングを有効または無効にします。spec.nodeSelectorフィールドでは、Compute RDMA GPU MonitoringプラグインおよびGPU Fault Monitorが実行されるGPUノードが選択されます。

   セレクタが同じノードに一致する有効なGpuHealthMonitoringConfigリソースを複数作成しないでください。重複ポリシーは、statusがFalseに設定され、reasonがMultipleMatchingPoliciesに設定されているReady条件で拒否されます。

5. 選択したノードでGPUヘルス・モニタリング構成を確認します。

   コントローラは、oci.oraclecloud.com/GpuHealthMonitoringConfiguredノード条件を公開します。値Trueは、Compute RDMA GPU Monitoringプラグインが有効として構成されていることを示します。値Falseは、無効として構成されていることを示します。値Unknownは、構成済の状態を現在信頼できないことを示します。

   GPUフォルト・モニターは、oci.oraclecloud.com/GpuHealthMonitoringUnavailableノード条件を公開します。値Trueは、1つ以上の必要なGPUヘルス結果ファイルが使用できないことを示します。考えられる原因としては、古いOracle Cloud Agentバージョン、サポートされていないシェイプ、無効または異常なプラグイン、構成の誤りなどがあります。値Falseは、必要な結果ファイルが存在することを示します。

6. ドライラン・モードで、重複しないクラスタ・スコープのNodeRepairConfigカスタム・リソースを作成します。

   管理する恒久ノード・プール・ラベルを使用してノードを選択します。セレクタ・ラベルはユーザー定義です。

   ノードは、1つのNodeRepairConfigリソースと完全に一致する必要があります。一致する構成または重複する構成がないリクエストは、修復の副作用なしで拒否されます。ユーザーが開始した修復およびGPUインスタンス・リカバリには、同じ構成または別個の構成を使用できます。別々の構成を使用する場合は、同じノードを複数の構成に含めないでください。そうしないと、修復要求は拒否されます。

   次の例では、ドライランモードで起動し、一度に1回の修復を許可し、異常ノードしきい値を10%に設定して、60分のドレイン猶予期間を使用し、強制猶予後の動作を無効にします。

   apiVersion: oci.oraclecloud.com/v1beta1
   kind: NodeRepairConfig
   metadata:
     name: gpu-node-repair
   spec:
     nodeSelector:
       matchLabels:
         example.com/gpu-repair: "enabled"
     policy:
       dryRun: true
       evictionGracePeriodMinutes: 60
       forceActionAfterGracePeriod: false
       maxUnhealthyNodeThreshold: "10%"
       maximumParallelNodeRepairs: 1

   policyセクションでは、dryRunおよびforceActionAfterGracePeriodはブール値です。evictionGracePeriodMinutesは負でない整数です。maximumParallelNodeRepairsは正の整数です。maxUnhealthyNodeThresholdは、正のノード数または引用符で囲まれた割合("10%"など)を受け入れます。

   dryRun: trueから開始します。構成の検証後、ライブ操作のためにdryRunのみをfalseに更新します。

   GPUインスタンスのリカバリは、ヘルス・シグナル駆動型であることに注意してください。ユーザーが開始した修復ラベルoci.oraclecloud.com/customer-report-host-status=unhealthyをGPUインスタンス・リカバリに適用しないでください。

7. そのノードに対して適格なGPUヘルス・シグナルがレポートされていることを確認します。

   ノードは、次の条件がすべて満たされている場合にのみ、自動リブートの対象となります。

   • ノード条件oci.oraclecloud.com/GpuHealthMonitoringFaultDetectedはTrueです。
   • NodeHealthReportには、status.signals.clusterHealthCheck[]の下のエントリが含まれます。
   • シグナルには、空でないidがあります。
   • シグナルにはaction=REBOOTがあります。この値には大/小文字区別はありません。
   • シグナルにnull以外のfirstObservedAt値があります。
   • シグナルにはnull以外のlastObservedAt値があり、そのシグナルがアクティブであることを示します。
   • 信号は少なくとも10分間アクティブのままです。
   • ノード修復コントローラの再試行およびクールダウン・ルールにより、別の試行が許可されます。リブートのクールダウンは60分です。
   • 実際の再起動の場合、有効なドライラン値はfalseです。
   • 後続の入場および中断ガードレールが通過します。

   action=CUSTOMER_ACTION_REQUIREDを指定したシグナルは、自動リブートをトリガーしません。これらのシグナルのいずれかが表示される場合は、NodeHealthReportおよびノードの条件を確認し、報告されたGPUの健全性の問題を調査し、解決の助けが必要な場合はサポートに連絡してください。

8. NodeRepairConfigリソースでライブ修復を有効にします。

   GPUインスタンス・リカバリは、適格なシグナルが少なくとも10分間アクティブのままであり、リピート再起動クールダウンが60分後にのみ開始されます。ドレイン動作は、一致するNodeRepairConfigリソースで指定された修復ポリシーに従います。DrainingはKubernetes Eviction APIを使用し、ポッド・ディスラプションの予算を尊重します。GPUインスタンス・リカバリの完了に必要な時間は、ワークロードの中断設定、ノード・ドレイン動作およびコンピュート・インスタンスの状態によって異なる場合があります。

9. GPUインスタンスのリカバリが正常に完了したことを確認します。

   NodeHealthReportにRebootアクションがライブ・モードで表示され、終了ステータスがCompletedであることを確認します。コンピュート・インスタンスがRunning状態であり、KubernetesノードがReadyであり、現在のGPUヘルス結果によってフォルトがレポートされなくなったことを確認します。

10. ワークフローの完了後にGPUヘルス結果を確認します。

    リブート後にGPUの健全性結果が引き続き同じ障害を報告する場合、または障害を再度報告する場合、その障害は解決されていません。完了したリカバリ・ワークフローは、基礎となるGPUフォルトが修正されたことを意味しません。GPUインスタンス・リカバリでは、クールダウン・ルールを使用して即時再起動ループを防止します。GPUヘルス結果が障害の報告を停止した後、新しい障害を報告する後のGPUヘルス結果によって、ノードが別の修復に適格になる可能性があります。

Kubernetesリソースと標準のKubernetesモニタリング・ツールを使用して、NodeHealthReport、Nodeの状態、影響を受けるワークロードを検査し、ワークフローを修復します。

GPUホスト修復ワークフローを監視するには:

1. 修復前、修復中および修復後に、NodeHealthReportおよび影響を受けるワーカー・ノードを調べます。

   修復リクエスト、修復の進行状況、アクション、ドライラン・モードまたはライブ・モードおよびワークフロー結果について、NodeHealthReportを確認します。ノード・ラベルおよび条件について、影響を受けるKubernetes Nodeリソースを確認します。Kubernetesイベントで最近のノードを確認し、アクティビティを修復します。GPUインスタンス・リカバリの場合は、影響を受けるKubernetes NodeリソースのGpuHealthMonitoringConfigured、GpuHealthMonitoringUnavailableおよびGpuHealthMonitoringFaultDetected条件を確認します。

   コントローラ所有のリソースを読み取り専用として扱います。生成されたアクションやコントローラ所有のリソースを作成または編集しないでください。

2. サポートされている修復ステータスおよびノード状態を確認します。

   NodeHealthReportを使用して、修復ポリシー、有効なドライラン値、入学結果、最終結果および最後の修復試行を確認します。影響を受けるKubernetes Nodeリソースを使用して、ノード条件を確認します。該当する場合は、コンピュート・インスタンスのライフサイクル状態、ユーザーが開始した修復に使用されるコンピュート定義タグ、および交換容量の準備ができているかどうかを確認します。

   ステータス・インジケータとして、内部リース、リクエストID、ファイル・パス、ポーリング間隔または中間ワークフロー・フェーズに依存しないでください。

3. ユーザーが開始した修復の場合は、拒否されたリクエスト、遅延修復、失敗した修復、および破棄された修復を調査します。

   リクエストは、ノードに一致するNodeRepairConfigリソースがない場合、または複数の構成が適用される場合に拒否できます。

   NodeHealthReportの結果を使用して、調査対象を決定します。

   • NodeHealthReportにAdmissionRejectedが表示されている場合は、NodeRepairConfigリソース、トリガー認可およびラベル構成を確認します。
   • NodeHealthReportにDeferredが表示されている場合は、ブロッキング状態がクリアされるまで待機するか、交換容量が使用できない場合は容量を調整します。
   • NodeHealthReportにFailedが表示されている場合は、NodeHealthReport、Kubernetesイベント、ポッド中断予算、IAMポリシー、コンピュート定義タグおよびコンピュート・インスタンスの状態を検査します。
   • NodeHealthReportにSupersededが表示されている場合は、修復を引き継いだOKEワークフローに従います。
   • NodeHealthReportにCompletedと表示されている場合は、元のインスタンスが終了し、交換容量の準備ができていることを確認します。

4. GPUインスタンス・リカバリの場合、GPUヘルス・モニタリング構成、使用できないヘルス結果、再起動シグナル、アクションが必要なシグナル、未完了のドレイン、進行中の障害による再起動の完了、および繰返し再起動をトリガーしない継続シグナルを調査します。

   ノード条件、GPUヘルス・シグナルおよびNodeHealthReport結果を使用して、調査対象を決定します。

   • GpuHealthMonitoringConfiguredノード条件がFalseまたはUnknownの場合は、Oracle Cloud Agent構成およびGpuHealthMonitoringアドオン構成を確認します。
   • GpuHealthMonitoringUnavailableノード条件がTrueの場合は、GPUシェイプがサポートされていること、Oracle Cloud Agentバージョン1.64.0以降がインストールされていること、Compute RDMA GPU Monitoringプラグインが有効になっていること、およびGPU Health Monitoringアドオンがインストールおよび構成されていることを確認します。
   • アクティブなGPUヘルス・シグナルにaction=REBOOTがある場合は、GPUインスタンス・リカバリ・ワークフローのNodeHealthReportを監視します。
   • GPUヘルス・シグナルにaction=CUSTOMER_ACTION_REQUIREDがある場合は、報告されたGPUヘルスの問題を調査します。このシグナルは自動リブートをトリガーしません。
   • NodeHealthReportに未完了のドレインまたは失敗した修復が表示された場合は、Kubernetesイベント、ポッド中断の予算、ワークロードの状態およびノード条件を調べます。
   • リブートが完了したが、GPUの健全性結果が引き続き障害を報告する場合は、進行中の障害を調査します。
   • リブート後に同じシグナルが継続した場合、GPUインスタンス・リカバリはノードをすぐに再起動しません。クールダウン・ルールは、即時再起動ループを防止します。

5. サービス・リクエストを開く前に、修復ワークフローを調査するために必要な情報を収集します。

   テナンシOCID、クラスタOCID、リージョン、Kubernetesバージョン、GPUヘルス・モニタリング・アドオン・バージョン、Oracle Cloud Agentバージョン、影響を受けるワーカー・ノード名、コンピュート・インスタンスOCID、関連するNodeHealthReportおよびNodeRepairConfigリソース、ノードのラベルと条件、Kubernetesイベント、ポッド中断の予算とワークロードの状態、タイムスタンプ、および現在のGPUヘルス結果を含めます。

   OKE所有のCRD、コントローラ・リソース、アドミッション・オブジェクト、生成されたアクションまたは調整リソースを変更しないでください。