Reparando Hosts de GPU

Antes de configurar o reparo iniciado pelo usuário, identifique um pool de nós de GPU gerenciado elegível e um nó de teste controlado. Certifique-se de que as cargas de trabalho no nó selecionado possam ser interrompidas.

O reparo iniciado pelo usuário requer controle de acesso no OCI IAM e no Kubernetes RBAC. No OCI IAM, o controlador de recursos do cluster do OKE requer permissão para aplicar a tag definida usada para reportar a condição do host ao serviço Compute. No Kubernetes, apenas um operador confiável deve ser capaz de iniciar a solicitação de reparo protegida. O operador confiável requer permissões RBAC padrão do Kubernetes para atualizar o recurso Node de destino e a autorização específica do OKE delegada por meio de um ClusterRoleBinding.

Quando você solicita o reparo iniciado pelo usuário, o OKE coordena as seguintes ações:

1. Garante que apenas uma solicitação de reparo seja processada por vez.
2. Conecta o nó para que o Kubernetes não programe novos pods nele.
3. Tentativas de drenar cargas de trabalho do nó.
4. Reporta a condição ao serviço Compute e encerra a instância afetada.
5. Restaura a capacidade configurada do pool de nós gerenciados.

Para configurar e testar o reparo iniciado pelo usuário:

1. Verifique se o cluster é um cluster aprimorado e está executando o Kubernetes versão 1.32 ou posterior. Verifique se o nó é um nó de trabalho de GPU gerenciado elegível. Verifique se o Controlador de Reparo de Nó gerenciado pelo OKE e os CRDs NodeHealthReport, o oke-customer-node-repair-trigger ClusterRole e a política e associação de admissão de proteção de trigger estão instalados no cluster. Se algum recurso gerenciado pelo OKE estiver ausente, entre em contato com o Suporte Técnico da Oracle. Não recrie recursos gerenciados pelo OKE.

2. Antes de usar o reparo ao vivo, abra uma solicitação de Suporte para permitir o tratamento de falhas de hardware relatadas pelo usuário para sua tenancy. Inclua a tenancy, a região, o OCID do cluster e o pool de nós da GPU na solicitação.

3. Crie ou reutilize a tag definida que o Controlador de Reparo de Nós usa para reportar a condição do host ao serviço Compute.

   Crie ou reutilize um namespace de tag chamado ComputeInstanceHostActions. Nesse namespace, crie ou reutilize uma definição de chave de tag chamada CustomerReportedHostStatus. Não crie uma tag de formato livre com o mesmo texto. Para obter mais informações, consulte Criando um Namespace de Tag e Criando uma Definição de Chave de Tag.

   Antes de encerrar a instância original, o Controlador de Reparo de Nós grava o valor unhealthy na tag definida ComputeInstanceHostActions.CustomerReportedHostStatus na instância.

4. Crie uma política do OCI IAM que conceda ao controlador de recursos do cluster do OKE a permissão com escopo restrito para aplicar a tag definida:

   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'}

   As alterações do IAM podem levar tempo para serem propagadas. Aguarde a propagação antes de executar a validação destrutiva.

5. Delega o acionador de reparo iniciado pelo usuário protegido a operadores confiáveis.

   Crie um ClusterRoleBinding que vincule um OCID de grupo confiável do OCI IAM ao oke-customer-node-repair-trigger ClusterRole de propriedade do OKE. Os operadores também exigem permissões padrão do Kubernetes RBAC para atualizar o recurso Node de destino.

   Crie um arquivo chamado cir-trigger-operators.yaml com o seguinte conteúdo:

   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>

   Substitua <trusted-oci-iam-group-ocid> pelo OCID do grupo do OCI IAM que contém os operadores confiáveis.

   Aplique e verifique a vinculação digitando:

   kubectl apply -f cir-trigger-operators.yaml

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

   Este binding não concede permissão geral para atualizar recursos do Node. Use seu modelo de autorização existente do Kubernetes para conceder apenas as permissões padrão do Kubernetes RBAC exigidas pelos operadores confiáveis.

6. Crie um recurso personalizado NodeRepairConfig não sobreposto no escopo do cluster no modo dry-run.

   Selecione nós usando um label de pool de nós durável que você gerencia e que esteja presente nos nós de substituição. O rótulo do seletor é definido pelo usuário. Configure o label no pool de nós gerenciados pretendido para que os nós de substituição o mantenham.

   Um nó deve corresponder exatamente a um recurso NodeRepairConfig. Solicitações sem configuração correspondente ou configurações sobrepostas são rejeitadas sem efeitos colaterais de reparo. Você pode usar as mesmas configurações ou configurações separadas para reparo iniciado pelo usuário e recuperação de instância de GPU. Se você usar configurações separadas, não inclua os mesmos nós em várias configurações; caso contrário, a solicitação de reparo será rejeitada.

   O exemplo a seguir começa no modo dryrun, permite um reparo de cada vez, define o limite de nó não saudável como 10%, usa um período de tolerância de drenagem de 60 minutos e desativa o comportamento de força após gravidade:

   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

   Na seção policy, dryRun e forceActionAfterGracePeriod são valores Boolianos. evictionGracePeriodMinutes é um inteiro não negativo. maximumParallelNodeRepairs é um inteiro positivo. maxUnhealthyNodeThreshold aceita uma contagem de nós positiva ou uma porcentagem entre aspas, como "10%".

   Comece com dryRun: true. Após validar a configuração, atualize apenas dryRun para false para operação ativa.

7. Solicite um reparo a seco aplicando a etiqueta protegida oci.oraclecloud.com/customer-report-host-status=unhealthy ao nó selecionado. Inspecione o NodeHealthReport e o estado do nó relacionado. Uma solicitação de dryrun cria um registro NodeHealthReport concluído, mas não cancela, drena, aplica a tag definida do serviço Compute, encerra, reinicializa ou substitui o nó.

8. Acione um reparo ao vivo aplicando o rótulo de trigger protegido junto com a substituição ao vivo de um tiro oci.oraclecloud.com/node-repair-dry-run=false. A substituição ativa é válida apenas com um acionador ativo e é amostrada somente quando um novo acionador é criado.

   Para repetir uma solicitação de reparo iniciada pelo usuário, remova e reaplique o label oci.oraclecloud.com/customer-report-host-status=unhealthy. A reaplicação do mesmo valor de rótulo não inicia outra solicitação. A remoção do rótulo não cancela um reparo ativo.

   Importante
   
   Um reparo ao vivo iniciado pelo usuário pode drenar cargas de trabalho e encerrar a instância do serviço Compute original. O Draining usa a API do Kubernetes Eviction e honra os orçamentos de interrupção de pods. Os pods DaemonSet e os pods estáticos são ignorados. Se force-after-grace estiver ativado, o Controlador de Reparo de Nós não forçará a exclusão dos pods restantes, mas a ação de host subsequente ainda poderá interrompê-los.

9. Verifique o andamento da ação de reparo, a tag definida do serviço Compute, o encerramento da instância original, a restauração da capacidade do pool de nós gerenciados e a criação de um nó substituto com um novo UID e OCID da instância. O NodeHealthReport para instâncias encerradas é retido temporariamente após a conclusão do workflow.

   Um resultado Deferred significa que o workflow está temporariamente bloqueado. Um resultado Failed significa que a tentativa foi interrompida. Um resultado Superseded significa que um workflow do OKE de maior prioridade assumiu. Um resultado Completed significa que o OKE concluiu o workflow de desligamento solicitado. Isso não significa que o reparo físico esteja completo ou que a capacidade de substituição seja Ready. Depois que o workflow for concluído, verifique se o pool de nós gerenciados tem a capacidade esperada e se o nó de substituição reporta o status de integridade atual.

Para o reparo iniciado pelo usuário, a criação de um nó de trabalho substituto depende da reconciliação de pool de nós gerenciados e da capacidade de GPU disponível. Um fluxo de trabalho concluído não confirma se a falha de GPU subjacente foi corrigida.

Antes de configurar a recuperação de instância de GPU, identifique um pool de nós de GPU gerenciado elegível e confirme se suas cargas de trabalho podem ser interrompidas. A recuperação da instância de GPU pode conectar e drenar um nó afetado antes de reinicializar sua instância.

Antes de configurar a recuperação da instância de GPU, crie as políticas do IAM exigidas pelo complemento GPU Health Monitoring para monitorar hosts de GPU:

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>

em que:

• <dg-name> é o nome do grupo dinâmico que inclui as instâncias do serviço Compute para os nós de trabalho de GPU. Por exemplo, usando uma regra como ALL {instance.compartment.id = '<compartment-ocid>'}. Ao aplicar tags a pools de nós, você pode criar regras mais restritivas, como:

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

  Para obter mais informações, consulte Aplicando Tags a Pools de Nós.

• <compartment-ocid> é o OCID do compartimento que contém os nós de trabalho da GPU.

A recuperação da instância de GPU só é suportada em nós de trabalho de GPU gerenciados elegíveis usando as seguintes formas de 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

A disponibilidade da forma da GPU varia de acordo com a região. Confirme se a forma de GPU selecionada está disponível na região em que o cluster é executado.

O Oracle Cloud Agent versão 1.64.0 ou posterior é exigido pelo plug-in de Monitoramento de GPU RDMA de Computação e deve ser instalado nos nós selecionados.

Quando o OKE recebe um sinal de integridade de GPU elegível, ele coordena as seguintes ações:

1. Garante que apenas uma solicitação de recuperação seja processada por vez.
2. Conecta o nó para que o Kubernetes não programe novos pods nele.
3. Tentativas de drenar cargas de trabalho do nó.
4. Reinicializa a instância de Computação afetada.

Para configurar a recuperação de instância de GPU:

1. Verifique se o cluster está executando o Kubernetes versão 1.32 ou posterior. Verifique se o nó é um nó de trabalho de GPU gerenciado elegível. Verifique se o Controlador de Reparo de Nós gerenciado pelo OKE e os CRDs NodeHealthReport estão instalados no cluster e verifique se o complemento de Monitoramento de Integridade da GPU está disponível para o cluster.

2. Verifique se o complemento de Monitoramento de Integridade da GPU tem uma opção ACTIVE para a versão do Kubernetes em execução no cluster digitando:

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

   Ao instalar a extensão, instale a opção ACTIVE mais recente em vez de fixar uma versão. A versão instalada deve ser v1.1.0 ou posterior.

3. Instale o complemento GPU Health Monitoring gerenciado pelo OKE digitando:

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

   O comando instala a versão mais recente disponível do complemento para o cluster.

   As chaves de configuração de extensões suportadas são nodeSelectors, tolerations e rollingUpdate. O valor rollingUpdate controla o comportamento de atualização incremental por maxSurge e maxUnavailable, usando o formato JSON em texto sem formatação.

4. Crie um recurso GpuHealthMonitoringConfig para ativar o monitoramento da integridade da GPU para os nós de trabalho da GPU selecionados. A configuração requer spec.enabled e um seletor de nó não vazio.

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

   Salve a configuração como gpu-health-monitoring.yaml e aplique-a digitando:

   kubectl apply -f gpu-health-monitoring.yaml

   O campo spec.enabled ativa ou desativa o monitoramento dos nós selecionados. O campo spec.nodeSelector seleciona os nós de GPU nos quais o plug-in de Monitoramento de GPU RDMA de Computação e o Monitor de Falha de GPU são executados.

   Evite criar vários recursos GpuHealthMonitoringConfig ativados cujos seletores correspondam ao mesmo nó. As políticas de sobreposição são rejeitadas com uma condição Ready que tem status definido como False e reason definido como MultipleMatchingPolicies.

5. Verifique a configuração do monitoramento de integridade da GPU nos nós selecionados.

   O controlador publica a condição do Nó oci.oraclecloud.com/GpuHealthMonitoringConfigured. Um valor True indica que o plug-in de Monitoramento de GPU de RDMA de Computação foi configurado como ativado. Um valor False indica que ele foi configurado como desativado. Um valor Unknown indica que o estado configurado não pode ser confiável no momento.

   O Monitor de Falha de GPU publica a condição do Nó oci.oraclecloud.com/GpuHealthMonitoringUnavailable. Um valor True indica que um ou mais arquivos de resultado de integridade de GPU obrigatórios estão indisponíveis. As possíveis causas incluem uma versão desatualizada do Oracle Cloud Agent, uma forma não suportada, um plug-in desativado ou não íntegro ou uma configuração incorreta. Um valor False indica que os arquivos de resultados necessários estão presentes.

6. Crie um recurso personalizado NodeRepairConfig não sobreposto no escopo do cluster no modo dry-run.

   Selecione nós usando um label de pool de nós durável que você gerencia. O rótulo do seletor é definido pelo usuário.

   Um nó deve corresponder exatamente a um recurso NodeRepairConfig. Solicitações sem configuração correspondente ou configurações sobrepostas são rejeitadas sem efeitos colaterais de reparo. Você pode usar as mesmas configurações ou configurações separadas para reparo iniciado pelo usuário e recuperação de instância de GPU. Se você usar configurações separadas, não inclua os mesmos nós em várias configurações; caso contrário, a solicitação de reparo será rejeitada.

   O exemplo a seguir começa no modo dryrun, permite um reparo de cada vez, define o limite de nó não saudável como 10%, usa um período de tolerância de drenagem de 60 minutos e desativa o comportamento de força após gravidade:

   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

   Na seção policy, dryRun, forceActionAfterGracePeriod e pauseBeforeRepair são valores Boolianos. evictionGracePeriodMinutes é um inteiro não negativo. maximumParallelNodeRepairs é um inteiro positivo. maxUnhealthyNodeThreshold aceita uma contagem de nós positiva ou uma porcentagem entre aspas, como "10%".

   Comece com dryRun: true e pauseBeforeRepair: true. A definição de pauseBeforeRepair como true permite inspecionar o reparo selecionado antes que o OKE inicie ações de interrupção. A pausa também se aplica durante a seca. Quando pauseBeforeRepair for definido como true, você deverá continuar a simulação pausada para que ela possa ser concluída.

   Após validar a configuração, atualize apenas dryRun para false para operação ativa.

   Observe que a recuperação de instância de GPU é orientada por sinal de integridade. Não aplique o label de reparo iniciado pelo usuário oci.oraclecloud.com/customer-report-host-status=unhealthy para recuperação da instância de GPU.

7. Verifique se um sinal de integridade de GPU elegível foi reportado para o nó.

   Um nó só será elegível para reinicialização automatizada quando todas as seguintes condições forem atendidas:

   • A condição do Nó oci.oraclecloud.com/GpuHealthMonitoringFaultDetected é True.
   • O NodeHealthReport contém uma entrada em status.signals.clusterHealthCheck[].
   • O sinal tem um id não vazio.
   • O sinal tem action=REBOOT. O valor não diferencia maiúsculas e minúsculas.
   • O sinal tem um valor firstObservedAt não nulo.
   • O sinal tem um valor lastObservedAt não nulo, indicando que o sinal está ativo.
   • O sinal permaneceu ativo por pelo menos 10 minutos.
   • As regras de repetição e de cooldown do Controlador de Reparo de Nó permitem outra tentativa. A recarga de reinicialização repetida é de 60 minutos.
   • O valor efetivo de dryrun é false para uma reinicialização real.
   • Os limites de admissão e interrupção subsequentes passam.

   Sinais com action=CUSTOMER_ACTION_REQUIRED não acionam uma reinicialização automatizada. Se você vir um desses sinais, revise as condições do nó e do NodeHealthReport, investigue o problema de integridade da GPU relatado e entre em contato com o Suporte se precisar de ajuda para resolvê-lo.

8. Ative o reparo ao vivo no recurso NodeRepairConfig.

   A recuperação da instância de GPU começa somente depois que o sinal elegível permanecer ativo por pelo menos 10 minutos e a recarga de reinicialização repetida for de 60 minutos. O comportamento de drenagem segue a política de reparo especificada no recurso NodeRepairConfig correspondente. O Draining usa a API do Kubernetes Eviction e honra os orçamentos de interrupção de pods. O tempo necessário para concluir a recuperação da instância de GPU pode variar, dependendo das definições de interrupção da carga de trabalho, do comportamento de drenagem do nó e do estado da instância do serviço Compute.

9. Verifique se a recuperação da instância de GPU foi concluída com sucesso.

   Confirme se o NodeHealthReport mostra uma ação Reboot no modo ativo e tem um status de terminal Completed. Confirme se a instância do serviço Compute está no estado Running, se o nó do Kubernetes é Ready e se o resultado de integridade da GPU atual não reporta mais a falha.

10. Revise o resultado de integridade da GPU após a conclusão do fluxo de trabalho.

    Se o resultado de integridade da GPU ainda relatar a mesma falha após a reinicialização ou relatar a falha novamente, a falha não foi resolvida. Um fluxo de trabalho de recuperação concluído não significa que a falha de GPU subjacente foi corrigida. A recuperação da instância de GPU usa regras de cooldown para evitar loops de reinicialização imediatos. Depois que o resultado de integridade da GPU parar de reportar a falha, um resultado de integridade da GPU posterior que reportar uma nova falha poderá tornar o nó elegível para outro reparo.

Antes de configurar o reparo do evento de manutenção, identifique os nós de trabalho de GPU bare metal elegíveis e confirme se as cargas de trabalho nos nós selecionados podem ser interrompidas. O reparo do evento de manutenção pode se conectar e drenar um nó afetado antes que o OKE execute a ação de Computação aplicável.

O reparo do evento de manutenção é suportado para nós de trabalho de GPU bare metal elegíveis, incluindo nós gerenciados e nós autogerenciados. O cluster deve ser um cluster aprimorado e estar executando o Kubernetes versão 1.32 ou posterior. O reparo do evento de manutenção não se aplica a nós virtuais ou a nós de trabalho não bare metal.

O reparo de eventos de manutenção usa o Monitoramento de Integridade da GPU para identificar falhas de GPU ou RDMA locais em formas de GPU. O OKE correlaciona o sinal de falha local com um evento de manutenção do OCI Compute para a mesma instância do Compute. Se o nó for selecionado por exatamente um recurso NodeRepairConfig correspondente e a política de reparo permitir reparo, o OKE coordenará o workflow de reparo.

Antes de configurar o reparo do evento de manutenção, crie as políticas do IAM exigidas pelo complemento GPU Health Monitoring para monitorar hosts de GPU:

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>

em que:

• <dg-name> é o nome do grupo dinâmico que inclui as instâncias do serviço Compute para os nós de trabalho de GPU. Por exemplo, usando uma regra como ALL {instance.compartment.id = '<compartment-ocid>'}. Ao aplicar tags a pools de nós, você pode criar regras mais restritivas, como:

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

  Para obter mais informações, consulte Aplicando Tags a Pools de Nós.

• <compartment-ocid> é o OCID do compartimento que contém os nós de trabalho da GPU.

Crie também uma política que permita ao controlador de recursos do cluster do OKE usar eventos de manutenção de instância no compartimento que contém as instâncias do nó de trabalho da GPU e seus eventos de manutenção:

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

Para restringir o acesso a um cluster específico, use uma política como:

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>'}

em que:

• <worker-compartment-ocid> é o OCID do compartimento que contém as instâncias do nó de trabalho da GPU e seus eventos de manutenção.
• <cluster-ocid> é o OCID do cluster.

O reparo do evento de manutenção suporta as seguintes ações de evento de manutenção do serviço Compute:

• STOP: O OKE coordena um evento de manutenção que não está sendo encerrado. A mesma instância do serviço Compute e o mesmo nó do Kubernetes devem retornar ao serviço após o processamento do evento de manutenção.
• TERMINATE: O OKE coordena o encerramento da instância do serviço Compute afetada. Para pools de nós gerenciados, a substituição depende do gerenciamento de capacidade de pool de nós gerenciados e da capacidade de GPU disponível. Para nós autogerenciados, o OKE não substitui automaticamente o nó após o encerramento. Provisione e participe de um nó substituto usando o processo de gerenciamento de nós que você normalmente usa para nós autogerenciados (consulte Como Trabalhar com Nós Autogerenciados).

O Oracle Cloud Agent versão 1.64.0 ou posterior é exigido pelo plug-in de Monitoramento de GPU RDMA de Computação e deve ser instalado nos nós selecionados.

Quando o OKE admite uma solicitação de reparo de evento de manutenção, ele coordena as seguintes ações:

1. Garante que apenas uma solicitação de reparo seja processada por vez.
2. Correlaciona o sinal de falha local da GPU ou RDMA com um evento de manutenção do serviço Compute para a mesma instância.
3. Registra informações de reparo em um NodeHealthReport.
4. Conecta o nó para que o Kubernetes não programe novos pods nele.
5. Tentativas de drenar cargas de trabalho do nó.
6. Executa o workflow de evento de manutenção STOP ou TERMINATE aplicável.

Para configurar o reparo do evento de manutenção:

1. Verifique se o cluster é um cluster aprimorado e está executando o Kubernetes versão 1.32 ou posterior. Verifique se o nó é um nó de trabalho de GPU bare metal elegível, um nó gerenciado ou um nó autogerenciado.

   Verifique se o Controlador de Reparo de Nós gerenciado pelo OKE e os CRDs NodeHealthReport estão instalados no cluster e verifique se o complemento de Monitoramento de Integridade da GPU está disponível para o cluster. Se algum recurso gerenciado pelo OKE estiver ausente, entre em contato com o Suporte Técnico da Oracle. Não recrie recursos gerenciados pelo OKE.

2. Instale e configure o complemento de Monitoramento de Integridade de GPU para os nós de trabalho de GPU selecionados.

   O reparo do evento de manutenção requer que o Monitoramento de Integridade da GPU seja ativado nos nós de trabalho da GPU selecionados para que o OKE possa correlacionar um sinal de falha local da GPU ou RDMA com um evento de manutenção do serviço Compute.

   Verifique se o complemento de Monitoramento de Integridade da GPU tem uma opção ACTIVE para a versão do Kubernetes em execução no cluster digitando:

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

   Instale o complemento GPU Health Monitoring gerenciado pelo OKE digitando:

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

   Crie um recurso GpuHealthMonitoringConfig para ativar o monitoramento da integridade da GPU para os nós de trabalho da GPU selecionados. A configuração requer spec.enabled e um seletor de nó não vazio.

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

   Salve a configuração como gpu-health-monitoring.yaml e aplique-a digitando:

   kubectl apply -f gpu-health-monitoring.yaml

   O campo spec.enabled ativa ou desativa o monitoramento dos nós selecionados. O campo spec.nodeSelector seleciona os nós de GPU nos quais o plug-in de Monitoramento de GPU RDMA de Computação e o Monitor de Falha de GPU são executados.

   Evite criar vários recursos GpuHealthMonitoringConfig ativados cujos seletores correspondam ao mesmo nó. As políticas de sobreposição são rejeitadas com uma condição Ready que tem status definido como False e reason definido como MultipleMatchingPolicies.

   Verifique a configuração do monitoramento de integridade da GPU nos nós selecionados. O controlador publica a condição do Nó oci.oraclecloud.com/GpuHealthMonitoringConfigured. O Monitor de Falha de GPU publica a condição do Nó oci.oraclecloud.com/GpuHealthMonitoringUnavailable.

3. Crie um recurso personalizado NodeRepairConfig não sobreposto no escopo do cluster no modo dry-run.

   Selecione nós usando um rótulo durável que você gerencia e que esteja presente nos nós de trabalho de GPU pretendidos. Para pools de nós gerenciados, configure o label no pool de nós para que os nós de substituição o retenham. Para nós autogerenciados, certifique-se de que o rótulo seja aplicado consistentemente aos nós pretendidos.

   Um nó deve corresponder exatamente a um recurso NodeRepairConfig. Solicitações sem configuração correspondente ou configurações sobrepostas são rejeitadas sem efeitos colaterais de reparo. Não crie configurações de sobreposição para reparo iniciado pelo usuário, recuperação de instância de GPU e reparo de evento de manutenção.

   O exemplo a seguir começa no modo dryrun, permite um reparo de cada vez, define o limite de nó não saudável como 10%, usa um período de tolerância de drenagem de 60 minutos e desativa o comportamento de força após gravidade:

   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

   Na seção policy, dryRun, forceActionAfterGracePeriod e pauseBeforeRepair são valores Boolianos. evictionGracePeriodMinutes é um inteiro não negativo. maximumParallelNodeRepairs é um inteiro positivo. maxUnhealthyNodeThreshold aceita uma contagem de nós positiva ou uma porcentagem entre aspas, como "10%".

   Comece com dryRun: true e pauseBeforeRepair: true. A definição de pauseBeforeRepair como true permite inspecionar o reparo selecionado antes que o OKE inicie ações de interrupção. A pausa também se aplica durante a seca. Quando pauseBeforeRepair for definido como true, você deverá continuar a simulação pausada para que ela possa ser concluída.

4. Verificar o comportamento de dryrun.

   No modo dryrun, o OKE avalia o nó selecionado, a política de reparo correspondente, o evento de manutenção correlacionado e a ação de evento de manutenção proposta. O modo dryrun não deve isolar, drenar, parar, encerrar ou substituir o nó.

   Inspecione o NodeHealthReport para obter o evento de manutenção correlacionado e o resultado do workflow. O OCID do evento de manutenção é mostrado em status.signals.maintenanceEvent[].maintenanceEventId. A ação correlacionada é mostrada no status.signals.maintenanceEvent[].action. O estado do ciclo de vida do evento do serviço Compute é mostrado em status.signals.maintenanceEvent[].maintenanceLifecycleState.

   Para verificar a tentativa de reparo selecionada, revise status.repair.selectedSignalIds, status.repair.repairAction, status.repair.dryRun, status.repair.terminalState e status.lastRepairAttempt. Uma simulação de dryrun bem-sucedida registra Completed com dryRun: true. A conclusão de dryrun não prova que uma ação real de drenagem ou computação será bem-sucedida.

5. Ative o reparo em tempo real controlado atualizando o recurso NodeRepairConfig correspondente.

   Para a operação ativa, atualize somente os campos de política pretendidos, como alterar dryRun de true para false. A alteração de dryRun não repete uma tentativa de reparo já admitida. A alteração do recurso NodeRepairConfig não reavalia um sinal de evento de manutenção existente ou altera uma tentativa de reparo já admitida. A política atualizada se aplica ao próximo sinal de evento de manutenção distinto.

   Não edite recursos NodeHealthReport nem alterne condições Node internas para forçar uma nova tentativa.

   Importante
   
   Um reparo de evento de manutenção ao vivo pode drenar cargas de trabalho e interromper ou encerrar a instância do serviço Compute afetada. O Draining usa a API do Kubernetes Eviction e honra os orçamentos de interrupção de pods. Os pods DaemonSet e os pods estáticos são ignorados. Se a ação force-after-grace estiver ativada, o Controlador de Reparo de Nó não forçará a exclusão dos pods restantes, mas a ação de Computação subsequente ainda poderá interrompê-los.

6. Se o reparo for pausado antes da ação de Computação, inspecione as condições NodeHealthReport e do nó. Um reparo pausado é indicado pela condição do nó oci.oraclecloud.com/NodeAutoRepairPaused=True.

   Para continuar o reparo pausado, insira:

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

   Para cancelar o reparo pausado, insira:

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

   O Controlador de Reparo de Nó consome o label de resposta e limpa a condição de pausa. Quando você continuar um reparo pausado, o OKE verificará a política de reparo e os limites de interrupção novamente antes de continuar.

   O cancelamento de um reparo pausado interrompe apenas a tentativa de reparo do OKE. Ele não cancela, reprograma nem remove o evento de manutenção subjacente do serviço Compute. O OKE registra Cancelled para a tentativa de reparo e limpa a condição de pausa e o label de resposta. O OKE continua rastreando o evento de manutenção do serviço Compute e a condição MaintenanceEventDetected pode permanecer presente. O cancelamento da tentativa de reparo do OKE não impede que o Compute processe a manutenção de acordo com sua própria programação.

7. Para um reparo de evento de manutenção STOP, verifique se o workflow de evento de manutenção é concluído e se o mesmo nó retorna ao serviço.

   Em um reparo STOP sem encerramento bem-sucedido, o nome Node do Kubernetes, o UID Node do Kubernetes e o OCID da instância do serviço Compute permanecem os mesmos.

   Confirme se o NodeHealthReport registra o repairAction: STOP e não é um dry-run. Confirme se o status.lastRepairAttempt registra result: Completed e um timestamp completedAt. Confirme se o Node original é Ready e agendável, com identidades inalteradas.

8. Para um reparo de evento de manutenção TERMINATE, verifique se o reparo ao vivo corresponde ao evento de manutenção pretendido e à instância do serviço Compute, se a instância original foi encerrada e se o Kubernetes Node original foi removido.

   Para pools de nós gerenciados, confirme se a capacidade de substituição se torna disponível quando a capacidade de GPU, os limites de serviço e as cotas de compartimento permitem substituição. Para nós autogerenciados, provisione e una um nó substituto usando o processo de gerenciamento de nós que você normalmente usa para nós autogerenciados (consulte Como Trabalhar com Nós Autogerenciados).

   Um resultado Completed indica que o OKE concluiu o workflow de desligamento. Ele não confirma que o reparo do host físico foi concluído, que a capacidade de substituição está pronta ou que as cargas de trabalho foram recuperadas.

Um workflow de reparo de evento de manutenção concluído não confirma se a falha subjacente da GPU ou RDMA foi corrigida, se o reparo do host físico foi concluído, se a capacidade de substituição está pronta ou se as cargas de trabalho foram recuperadas. Após a conclusão do fluxo de trabalho, verifique os sinais de integridade atuais do nó, a prontidão do nó, a capacidade esperada e a integridade do aplicativo.

Use recursos do Kubernetes e ferramentas de monitoramento padrão do Kubernetes para inspecionar o NodeHealthReport, as condições do Nó, as cargas de trabalho afetadas e o workflow de reparo.

Para monitorar um workflow de reparo de host de GPU:

1. Inspecione o NodeHealthReport e o nó de trabalho afetado antes, durante e após o reparo.

   Revise o NodeHealthReport para a solicitação de reparo, o andamento do reparo, a ação, o modo de execução a seco ou ao vivo e o resultado do workflow. Revise o recurso Node do Kubernetes afetado para labels e condições de nó. Revisar Eventos do Kubernetes para verificar a atividade recente de nó e reparo. Para recuperar a instância de GPU, verifique as condições GpuHealthMonitoringConfigured, GpuHealthMonitoringUnavailable e GpuHealthMonitoringFaultDetected no recurso Node do Kubernetes afetado. Para o reparo do evento de manutenção, verifique o sinal de integridade da GPU ou RDMA, o evento de manutenção correlacionado do Compute e o status de reparo do evento de manutenção registrado no NodeHealthReport.

   Trate os recursos de propriedade do controlador como somente leitura. Não crie nem edite ações geradas ou recursos de propriedade do controlador.

2. Revise o status de reparo e o estado do nó suportados.

   Use o NodeHealthReport para revisar a política de reparo, o valor efetivo de dryrun, o resultado da admissão, o resultado do terminal e a última tentativa de reparo. Use o recurso Node do Kubernetes afetado para revisar as condições do nó. Quando aplicável, verifique o estado do ciclo de vida da instância do serviço Compute, a tag definida para o serviço Compute usada para reparo iniciado pelo usuário, os detalhes do evento de manutenção para reparo do evento de manutenção e se a capacidade de substituição está pronta.

   Não se baseie em leasings internos, IDs de solicitação, caminhos de arquivos, intervalos de sondagem ou fases intermediárias de fluxo de trabalho como indicadores de status.

3. Para o reparo iniciado pelo usuário, investigue as solicitações rejeitadas, o reparo diferido, o reparo com falha e o reparo substituído.

   Uma solicitação pode ser rejeitada quando nenhum recurso NodeRepairConfig corresponder ao nó ou quando mais de uma configuração for aplicada.

   Use o resultado NodeHealthReport para decidir o que investigar:

   • Se o NodeHealthReport mostrar o AdmissionRejected, verifique o recurso NodeRepairConfig, a autorização do trigger e a configuração do label.
   • Se NodeHealthReport mostrar Deferred, aguarde a condição de bloqueio ser removida ou ajuste a capacidade se a capacidade de substituição estiver indisponível.
   • Se o NodeHealthReport mostrar Failed, inspecione o NodeHealthReport, os Eventos do Kubernetes, os orçamentos de interrupção de pod, a política do IAM, a tag definida pelo serviço Compute e o estado da instância do serviço Compute.
   • Se o NodeHealthReport mostrar Superseded, siga o workflow do OKE que assumiu o reparo.
   • Se o NodeHealthReport mostrar o Completed, verifique se a instância original foi encerrada e se a capacidade de substituição está pronta.

4. Para recuperação de instância de GPU, investigue a configuração de monitoramento de integridade de GPU, resultados de integridade indisponíveis, sinais de reinicialização, sinais que exigem ação, drenos incompletos, reinicializações concluídas com uma falha contínua e sinais contínuos que não acionam reinicializações repetidas.

   Use as condições do nó, os sinais de integridade da GPU e o resultado NodeHealthReport para decidir o que investigar:

   • Se a condição do nó GpuHealthMonitoringConfigured for False ou Unknown, verifique a configuração do Oracle Cloud Agent e a configuração do complemento GpuHealthMonitoring.
   • Se a condição do nó GpuHealthMonitoringUnavailable for True, verifique se a forma da GPU é suportada, se o Oracle Cloud Agent versão 1.64.0 ou posterior está instalado, se o plug-in de Monitoramento de GPU RDMA de Computação está ativado e se o complemento de Monitoramento de Integridade de GPU está instalado e configurado.
   • Se um sinal de integridade de GPU ativo tiver action=REBOOT, monitore o NodeHealthReport para o workflow de recuperação da instância de GPU.
   • Se um sinal de integridade de GPU tiver action=CUSTOMER_ACTION_REQUIRED, investigue o problema de integridade de GPU relatado. Esse sinal não aciona uma reinicialização automatizada.
   • Se o NodeHealthReport mostrar um dreno incompleto ou um reparo com falha, inspecione os Eventos do Kubernetes, orçamentos de interrupção de pod, estado da carga de trabalho e condições do nó.
   • Se a reinicialização for concluída, mas o resultado da integridade da GPU ainda relatar a falha, investigue a falha em andamento.
   • Se o mesmo sinal continuar após a reinicialização, a recuperação da instância de GPU não reinicializará imediatamente o nó novamente. As regras de recarga impedem loops de reinicialização imediatos.

5. Para reparo de eventos de manutenção, investigue a configuração do Monitoramento de Integridade da GPU, sinais de falha de GPU ou RDMA locais, eventos de manutenção correlacionados do serviço Compute, recursos correspondentes de NodeRepairConfig, reparos pausados, drenos incompletos e o resultado do workflow STOP ou TERMINATE.

   Para reparo de evento de manutenção, revise as condições do nó oci.oraclecloud.com/MaintenanceEventDetected e oci.oraclecloud.com/NodeAutoRepairPaused. No NodeHealthReport, revise o OCID do evento de manutenção, a ação, os códigos de falha, o estado do ciclo de vida de manutenção, o ID do reparo, os IDs de sinal selecionados, a ação de reparo, o valor de dryrun, o estado de admissão, os detalhes da rejeição, o estado do terminal e a última tentativa de reparo.

   Use as condições do nó, as informações do evento de manutenção e o resultado NodeHealthReport para decidir o que investigar:

   • Se uma falha de GPU ou RDMA local não iniciar o reparo do evento de manutenção, verifique o Monitoramento de Integridade da GPU, o Oracle Cloud Agent, a forma do nó de trabalho da GPU e os sinais de integridade registrados no NodeHealthReport. Confirme se existe um evento de manutenção correspondente do serviço Compute para a mesma instância.
   • Se o reparo do evento de manutenção não for admitido, confirme se exatamente um NodeRepairConfig seleciona o nó e se a política de reparo e os limites de interrupção permitem o reparo. Inspecione o resultado da admissão NodeHealthReport.
   • Se o reparo estiver pausado, inspecione as condições do nó e do NodeHealthReport e use o mecanismo de resposta suportado para continuar ou cancelar o reparo.
   • Se um reparo de STOP for concluído, mas o nó não for programável, verifique a prontidão do nó, o estado do cordon, o estado do ciclo de vida do evento de manutenção do serviço Compute, os sinais de integridade atuais e os Eventos do Kubernetes.
   • Se um reparo de TERMINATE for concluído, mas a capacidade esperada não estiver disponível, verifique a capacidade da forma da GPU, os limites de serviço, as cotas de compartimento e o estado do pool de nós. Para nós autogerenciados, provisione e una um nó substituto usando o processo de gerenciamento de nós que você normalmente usa para nós autogerenciados (consulte Como Trabalhar com Nós Autogerenciados).

   Os resultados de reparo relevantes do OKE incluem Completed, Failed, Cancelled, Superseded e AdmissionRejected. Um estado Deferred representa um bloqueio temporário, não um resultado terminal. Os valores do ciclo de vida de manutenção de computação são separados dos resultados do reparo do OKE.

6. Antes de abrir uma solicitação de serviço, colete as informações necessárias para investigar o fluxo de trabalho de reparo.

   Inclua o OCID da tenancy, o OCID do cluster, a região, a versão do Kubernetes, a versão do complemento GPU Health Monitoring, a versão do Oracle Cloud Agent, o nome do nó de trabalho afetado, o OCID da instância do serviço Compute, os recursos relevantes NodeHealthReport e NodeRepairConfig, os labels e as condições do nó, os Eventos do Kubernetes, o orçamento de interrupção de pod e o estado da carga de trabalho, os timestamps e os resultados de integridade da GPU atual. Para reparo de evento de manutenção, inclua também o OCID do evento de manutenção do serviço Compute, a ação do evento de manutenção, os códigos de falha, o estado do ciclo de vida do evento de manutenção e quaisquer detalhes de evento de manutenção disponíveis do serviço Compute.

   Não modifique CRDs de propriedade do OKE, recursos do controlador, objetos de internação, ações geradas ou recursos de coordenação.