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

   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.

   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.
   • Passam guardrails de admissão e interrupção subsequentes.

   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.

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.

   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 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. 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, recursos relevantes de NodeHealthReport e NodeRepairConfig, labels e condições de nó, Eventos do Kubernetes, orçamento de interrupção de pod e estado da carga de trabalho, timestamps e resultados de integridade da GPU atual.

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