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
       pauseBeforeRepair: true

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

   dryRun: trueおよびpauseBeforeRepair: trueから開始します。pauseBeforeRepairをtrueに設定すると、OKEが中断アクションを開始する前に、選択した修復を検査できます。ドライラン中も一時停止が適用されます。pauseBeforeRepairが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ヘルス結果によって、ノードが別の修復に適格になる可能性があります。

メンテナンス・イベントの修復を構成する前に、適格なベア・メタルGPUワーカー・ノードを特定し、選択したノードのワークロードを中断できることを確認します。OKEが該当するコンピュート・アクションを実行する前に、メンテナンス・イベントの修復で、影響を受けるノードをコード化およびドレインできます。

メンテナンス・イベントの修復は、管理対象ノードおよび自己管理ノードを含む適格なベア・メタルGPUワーカー・ノードでサポートされます。クラスタは、拡張クラスタである必要があり、Kubernetesバージョン1.32以降が実行されている必要があります。メンテナンス・イベントの修復は、仮想ノードまたは非ベア・メタル・ワーカー・ノードには適用されません。

メンテナンス・イベントの修復では、GPUヘルス・モニタリングを使用して、GPUシェイプ上のノードローカルGPUまたはRDMAフォルトを識別します。OKEは、同じコンピュート・インスタンスのOCI Computeメンテナンス・イベントとローカル・フォルト・シグナルを関連付けます。一致するNodeRepairConfigリソースが1つだけ選択され、修復ポリシーで修復が許可されている場合、OKEは修復ワークフローを調整します。

メンテナンス・イベントの修復を構成する前に、GPUヘルス・モニタリング・アドオンでGPUホストをモニターするために必要な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です

また、OKEクラスタ・リソース・プリンシパルがGPUワーカー・ノード・インスタンスとそのメンテナンス・イベントを含むコンパートメント内のインスタンス・メンテナンス・イベントを使用できるようにするポリシーも作成します:

Allow any-user to use instance-maintenance-events in compartment id <worker-compartment-ocid> where request.principal.type = 'cluster'

特定のクラスタへのアクセスを制限するには、次のようなポリシーを使用します。

Allow any-user to use instance-maintenance-events in compartment id <worker-compartment-ocid> where all {request.principal.type = 'cluster', request.principal.id = '<cluster-ocid>'}

ここでは:

• <worker-compartment-ocid>は、GPUワーカー・ノード・インスタンスとそのメンテナンス・イベントを含むコンパートメントのOCIDです
• <cluster-ocid>は、クラスタのOCIDです。

メンテナンス・イベントの修復では、次のコンピュート・メンテナンス・イベント・アクションがサポートされます:

• STOP: OKEは、終了していないメンテナンス・イベントを調整します。メンテナンス・イベントの処理後、同じコンピュート・インスタンスおよびKubernetesノードがサービスに戻ることが予想されます。
• TERMINATE: OKEは、影響を受けるコンピュート・インスタンスの終了を調整します。管理対象ノード・プールの場合、置換は、管理対象ノード・プールの容量管理と使用可能なGPU容量によって異なります。自己管理ノードの場合、OKEは終了後にノードを自動的に置換しません。自己管理ノードに通常使用するノード管理プロセスを使用して、置換ノードをプロビジョニングおよび結合します(自己管理ノードの操作を参照)。

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

OKEがメンテナンス・イベントの修復リクエストを承認すると、次のアクションが調整されます。

1. 一度に1つの修復リクエストのみが処理されるようにします。
2. ローカルGPUまたはRDMAフォルト・シグナルを、同じインスタンスのコンピュート・メンテナンス・イベントに関連付けます。
3. 修復情報をNodeHealthReportに記録します。
4. ノードをコード化して、Kubernetesによって新しいポッドがスケジュールされないようにします。
5. ノードからワークロードを排出しようとします。
6. 該当するSTOPまたはTERMINATEメンテナンス・イベント・ワークフローを実行します。

メンテナンス・イベントの修復を構成するには:

1. クラスタが拡張クラスタであり、Kubernetesバージョン1.32以上が実行されていることを確認します。ノードが適格なベア・メタルGPUワーカー・ノード(管理対象ノードまたは自己管理ノード)であることを確認します。

   OKE管理ノード修復コントローラおよびNodeHealthReport CRDがクラスタにインストールされていることを確認し、GPUヘルス・モニタリング・アドオンがクラスタで使用可能であることを確認します。OKE管理リソースが欠落している場合は、Oracle Supportに連絡してください。OKE管理リソースは再作成しないでください。

2. 選択したGPUワーカー・ノードのGPUヘルス・モニタリング・アドオンをインストールして構成します。

   メンテナンス・イベントの修復では、OKEがローカルGPUまたはRDMAフォルト・シグナルをコンピュート・メンテナンス・イベントに関連付けることができるように、選択したGPUワーカー・ノードでGPUヘルス・モニタリングを有効にする必要があります。

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

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

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

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

   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条件で拒否されます。

   選択したノードでGPUヘルス・モニタリング構成を確認します。コントローラは、oci.oraclecloud.com/GpuHealthMonitoringConfiguredノード条件を公開します。GPUフォルト・モニターは、oci.oraclecloud.com/GpuHealthMonitoringUnavailableノード条件を公開します。

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

   管理する耐久性のあるラベルを使用して、目的のGPUワーカー・ノードに存在するノードを選択します。管理対象ノード・プールの場合は、ノード・プールのラベルを構成して、置換ノードが保持されるようにします。自己管理ノードの場合、ラベルが目的のノードに一貫して適用されていることを確認します。

   ノードは、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
       pauseBeforeRepair: true

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

   dryRun: trueおよびpauseBeforeRepair: trueから開始します。pauseBeforeRepairをtrueに設定すると、OKEが中断アクションを開始する前に、選択した修復を検査できます。ドライラン中も一時停止が適用されます。pauseBeforeRepairがtrueに設定されている場合、一時停止したシミュレーションを完了する前に続行する必要があります。

4. 予行演習の動作を確認します。

   予行演習モードでは、OKEは、選択したノード、一致する修復ポリシー、相関メンテナンス・イベントおよび提案されたメンテナンス・イベント・アクションを評価します。ドライランモードは、ノードの接続、ドレイン、停止、終了、または交換を行わないでください。

   相関メンテナンス・イベントおよびワークフロー結果についてNodeHealthReportを検査します。メンテナンス・イベントのOCIDは、status.signals.maintenanceEvent[].maintenanceEventIdに示されています。相関アクションは、status.signals.maintenanceEvent[].actionに示されています。コンピュート・イベントのライフサイクル状態は、status.signals.maintenanceEvent[].maintenanceLifecycleStateに表示されます。

   選択した修復試行を確認するには、status.repair.selectedSignalIds、status.repair.repairAction、status.repair.dryRun、status.repair.terminalStateおよびstatus.lastRepairAttemptを確認します。ドライラン・シミュレーションが成功すると、CompletedがdryRun: trueで記録されます。ドライラン完了では、実際のドレインまたはコンピュート・アクションが成功することは証明されません。

5. 一致するNodeRepairConfigリソースを更新して、制御されたライブ修復を有効にします。

   ライブ操作の場合は、dryRunをtrueからfalseに変更するなど、目的のポリシー・フィールドのみを更新します。dryRunを変更しても、すでに許可されている修復試行はリプレイされません。NodeRepairConfigリソースを変更しても、既存のメンテナンス・イベント・シグナルを再評価したり、すでに許可されている修復試行を変更したりすることはありません。更新されたポリシーは、次の個別のメンテナンス・イベント・シグナルに適用されます。

   NodeHealthReportリソースを編集したり、内部Node条件を切り替えて再試行を強制しないでください。

   重要
   
   ライブ・メンテナンス・イベントの修復により、ワークロードをドレインし、影響を受けるコンピュート・インスタンスを停止または終了できます。DrainingはKubernetes Eviction APIを使用し、ポッド・ディスラプションの予算を尊重します。DaemonSetポッドおよび静的ポッドはスキップされます。force-after-graceが有効な場合、ノード修復コントローラは残りのポッドを強制削除しませんが、後続の計算アクションによってそれらが中断される可能性があります。

6. コンピュート・アクションの前に修復が一時停止する場合は、NodeHealthReportおよびノードの条件を調べます。一時停止された修復は、oci.oraclecloud.com/NodeAutoRepairPaused=Trueノード条件によって示されます。

   一時停止した修復を続行するには、次のように入力します。

   kubectl label node <node-name> oci.oraclecloud.com/node-repair-paused-response=continue --overwrite

   一時停止した修復を取り消すには、次のように入力します。

   kubectl label node <node-name> oci.oraclecloud.com/node-repair-paused-response=cancel --overwrite

   ノード修復コントローラは、応答ラベルを消費し、一時停止状態をクリアします。一時停止した修復を続行すると、OKEは修復ポリシーおよび中断制限を再度チェックしてから続行します。

   一時停止した修復を取り消すと、OKE修復の試行のみが停止されます。基礎となるコンピュート・メンテナンス・イベントの取消、再スケジュールまたは削除は行いません。OKEでは、修復試行のCancelledが記録され、一時停止条件とレスポンス・ラベルがクリアされます。OKEはコンピュート・メンテナンス・イベントの追跡を続行し、MaintenanceEventDetected条件が存在する場合があります。OKE修復試行を取り消しても、コンピュートが独自のスケジュールでメンテナンスを処理できないわけではありません。

7. STOPメンテナンス・イベントの修復の場合は、メンテナンス・イベント・ワークフローが完了し、同じノードがサービスに戻ることを確認します。

   終了しないSTOP修復が成功した場合、KubernetesのNode名、KubernetesのNode UIDおよびコンピュート・インスタンスのOCIDは同じままです。

   NodeHealthReportがrepairAction: STOPを記録し、ドライランではないことを確認します。status.lastRepairAttemptがresult: CompletedおよびcompletedAtタイムスタンプを記録していることを確認します。元のNodeがReadyでスケジュール可能であり、アイデンティティが変更されていないことを確認します。

8. TERMINATEメンテナンス・イベントの修復の場合、ライブ修復が目的のメンテナンス・イベントおよびコンピュート・インスタンスと一致し、元のインスタンスが終了し、元のKubernetes Nodeが削除されていることを確認します。

   管理対象ノード・プールの場合、GPU容量、サービス制限およびコンパートメント割当てで置換が許可されると、置換容量が使用可能になることを確認します。自己管理ノードの場合は、通常自己管理ノードに使用するノード管理プロセスを使用して、置換ノードをプロビジョニングおよび結合します(自己管理ノードの操作を参照)。

   Completedの結果は、OKEが終了ワークフローを完了したことを示します。物理ホストの修復が完了したこと、交換容量の準備ができたこと、またはワークロードが回復したことは確認されません。

完了したメンテナンス・イベント修復ワークフローでは、基礎となるGPUまたはRDMAの障害が修正されたこと、物理ホストの修復が完了したこと、交換容量の準備ができたこと、またはワークロードが回復したことを確認できません。ワークフローが完了したら、ノードの現在のヘルス・シグナル、ノードの準備状況、予想される容量およびアプリケーションのヘルスを確認します。

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

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

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

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

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

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. メンテナンス・イベントの修復については、GPUヘルス・モニタリング構成、ローカルGPUまたはRDMAフォルト・シグナル、相関するコンピュート・メンテナンス・イベント、NodeRepairConfigリソースの一致、一時停止した修復、不完全なドレイン、およびSTOPまたはTERMINATEワークフローの結果を調査します。

   メンテナンス・イベントの修復については、oci.oraclecloud.com/MaintenanceEventDetectedおよびoci.oraclecloud.com/NodeAutoRepairPausedノードの条件を確認してください。NodeHealthReportで、メンテナンス・イベントのOCID、アクション、フォルト・コード、メンテナンス・ライフサイクルの状態、修復ID、選択したシグナルID、修復アクション、ドライラン値、入学状態、拒否の詳細、終了状態および最後の修復試行を確認します。

   ノード条件、メンテナンス・イベント情報およびNodeHealthReport結果を使用して、調査対象を決定します。

   • ローカルGPUまたはRDMAフォルトでメンテナンス・イベントの修復が開始されない場合は、GPUヘルス・モニタリング、Oracle Cloud Agent、GPUワーカー・ノード・シェイプ、およびNodeHealthReportに記録されたヘルス・シグナルを確認します。同じインスタンスに対して一致するコンピュート・メンテナンス・イベントが存在することを確認します。
   • メンテナンス・イベントの修復が認められない場合は、1つのNodeRepairConfigのみがノードを選択し、修復ポリシーおよび中断制限によって修復が許可されていることを確認します。NodeHealthReport入学結果を検査します。
   • 修復が一時停止されている場合は、NodeHealthReportおよびノードの条件を調べてから、サポートされているレスポンス・メカニズムを使用して修復を続行するか取り消します。
   • STOP修復が完了したが、ノードがスケジュール可能でない場合は、ノードの準備状況、コードオン状態、コンピュート・メンテナンス・イベントのライフサイクル状態、現在のヘルス・シグナルおよびKubernetesイベントを確認します。
   • TERMINATE修復が完了したが、予想される容量が使用できない場合は、GPUシェイプ容量、サービス制限、コンパートメント割当ておよびノード・プールの状態を確認します。自己管理ノードの場合は、通常自己管理ノードに使用するノード管理プロセスを使用して、置換ノードをプロビジョニングおよび結合します(自己管理ノードの操作を参照)。

   関連するOKE修復結果には、Completed、Failed、Cancelled、SupersededおよびAdmissionRejectedが含まれます。Deferred状態は、終端の結果ではなく、一時的なブロックを表します。コンピュート・メンテナンスのライフサイクル値は、OKE修復結果とは異なります。

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

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

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