Gerenciar clusters do GKE otimizados para IA

Nesta página, mostramos como gerenciar clusters do Google Kubernetes Engine (GKE) otimizados para IA de máquinas A4X Max, A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPUs), incluindo os seguintes eventos comuns relevantes para clusters do GKE e cargas de trabalho de IA:

  • Manutenção do host
  • Upgrades de clusters
  • Relatórios de hosts com falha

Gerenciar a manutenção do host para cargas de trabalho de IA

Os nós do GKE são executados em instâncias do Compute Engine que periodicamente passam por eventos de host que podem interromper as cargas de trabalho de IA. Como os eventos de host ocorrem na infraestrutura Google Cloud subjacente, eles ignoram as janelas de manutenção e exclusões do GKE. Embora a maioria das instâncias de computação tenha a política de manutenção do host definida como migração em tempo real, o que minimiza a interrupção das cargas de trabalho, as GPUs e TPUs não são compatíveis com a migração em tempo real. Quando esses eventos de host afetam os nós do GKE que executam cargas de trabalho de IA, o GKE precisa encerrar o nó e os pods em execução nele. Se os pods forem implantados como parte de uma carga de trabalho maior, como um job ou uma implantação, o GKE tentará reiniciar os pods no nó afetado.

Para saber mais sobre como gerenciar a manutenção do host das instâncias de computação subjacentes, consulte Gerenciar a interrupção de nós do GKE para GPUs e TPUs.

Monitorar eventos de manutenção do host

Para clusters que executam o GKE versão 1.31.1-gke.2008000 ou posterior, é possível conferir o horário de início programado do evento de manutenção do host da seguinte maneira. O horário de início é representado por rótulos de nó do Kubernetes no nó correspondente do GKE para todas as GPUs e TPUs.

Para mais detalhes, consulte Monitorar notificações de manutenção.

Com esses rótulos de nó, é possível:

Iniciar manualmente um evento de manutenção de host

Depois que o Compute Engine emitir uma notificação sobre um evento de manutenção programada, será possível iniciar manualmente a manutenção em um horário que se alinhe à sua programação. Por exemplo, é possível realizar a manutenção durante períodos de atividade reduzida.

Se você não iniciar manualmente um evento de manutenção de host, o Compute Engine vai concluir automaticamente a manutenção programada regularmente.

Siga as instruções para iniciar manualmente um evento de manutenção de host. Além disso, continue lendo esta seção para saber o seguinte:

Usar informações de manutenção do host ao programar as cargas de trabalho

Use as informações de manutenção mostradas pelos rótulos de nó do GKE com a afinidade e antiafinidade de nó para minimizar as interrupções nas cargas de trabalho.

Confira nas seções a seguir exemplos de como usar essas informações.

Programar pods para nós que não têm eventos de manutenção programados para o futuro

É possível instruir o GKE a programar pods apenas para nós que não tenham eventos de manutenção programados para o futuro, como no snippet a seguir:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

Programar pods para nós que tenham manutenção programada após uma determinada data

É possível instruir o GKE a programar pods apenas para nós que tenham manutenção programada após uma determinada data, fornecendo o horário da época Unix:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

Gerenciar upgrades cluster do GKE para cargas de trabalho de IA

As cargas de trabalho de IA são sensíveis a interrupções.

Durante o ciclo de vida de um cluster do GKE, as cargas de trabalho de IA precisam estar preparadas para interrupções nas instâncias de computação subjacentes e no próprio cluster do GKE:

Recomendamos que você mantenha o cluster registrado em um canal de lançamento. Por padrão, os clusters do GKE são inscritos no canal de lançamento Regular. Para saber mais sobre os benefícios dos canais de lançamento, consulte a Comparação entre clusters registrados e não registrados em um canal de lançamento.

Com os canais de lançamento, você tem acesso a mais recursos, incluindo outros escopos de exclusão de manutenção. Recomendamos o escopo "sem upgrades secundários ou de nós" para cargas de trabalho de IA.

Informar hosts com falha pelo GKE

Nesta seção, descrevemos como, por meio do GKE, é possível informar um host com falha que tem instâncias de computação provisionadas usando o modelo de provisionamento vinculado à reserva. Se você quiser informar um host com falha para um nó que foi provisionado usando o modelo de provisionamento de início flexível (pré-lançamento), entre em contato com sua equipe de conta.

Se você observar erros de memória de GPU ou Xid em um nó e quiser verificar se medidas de recuperação manual, como acionar uma reinicialização do SO convidado (kubectl label nodes <NODE_NAME> cloud.google.com/perform-reboot=true), podem resolver o problema antes de informar o host como defeituoso, consulte Analisar mensagens Xid.

Um host é uma única máquina de servidor físico no data center que executa uma instância de computação que hospeda o nó do GKE. É possível informar hosts com falha aplicando um rótulo de nó fault-behavior ao nó do GKE afetado. Depois que você aplicar o rótulo a um nó específico do GKE, o GKE vai seguir estas etapas:

  1. Remove as cargas de trabalho do nó sem interrupções.
  2. Impede que novos pods sejam programados no nó.
  3. Chama a API na instância de computação para marcar o host como defeituoso.
  4. Aguarda que a instância de computação seja reativada em uma máquina host íntegra. Para reservas que usam o modo operacional de reserva de toda a capacidade, o Compute Engine traz de volta a instância de computação no mesmo nó depois que a operação de reparo é concluída.
  5. Remove o taint e o rótulo fault-behavior do nó.

Depois disso, o nó estará pronto para veicular cargas de trabalho novamente.

Requisitos

Para informar um host com falha, o nó do GKE precisa atender aos seguintes requisitos:

  • É necessário executar a versão de patch do GKE 1.32.3-gke.1057001 ou posterior.
  • É necessário executar um dos seguintes tipos de máquina de GPU: A4X Max, A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPUs).
  • É preciso executar os nós do GKE em uma instância de computação vinculada à reserva.
  • O nó do GKE precisa estar no estado RUNNING. Se você tentar informar um host com falha depois de excluir a instância de computação, uma mensagem de erro será retornada, e a máquina host não será marcada como com falha.
  • O número de chamadas para essa API por reserva e por mês pode ser limitado com base em uma avaliação da integridade dos seus blocos. As limitações de taxa não se aplicam se a reserva usar o modo operacional de reserva de capacidade total.

Reportar um host com falha

Para reportar um host com falha:

  1. Use as ferramentas de observabilidade do GKE, suas próprias ferramentas de monitoramento ou registros para identificar os nós do GKE que estão com problemas de desempenho. Salve o NODE_NAME.

  2. Informe que o nó está com defeito usando o comando a seguir. Você pode informar um motivo e, com versões posteriores, uma descrição:

      kubectl patch node NODE_NAME --type merge -p '{
    "metadata": {
      "labels": {
        "cloud.google.com/fault-behavior": "FAULT_REASON"
      },
      "annotations": {
        "cloud.google.com/fault-description": "FAULT_DESCRIPTION"
      }
    }
  }'

    Modifique o comando da seguinte maneira:

    • Substitua NODE_NAME pelo nome do nó com falha.
    • Substitua FAULT_REASON pelo motivo de falha apropriado usando um ou mais dos seguintes valores:
      • PERFORMANCE: use esse valor se as GPUs em uma instância de computação estiverem com desempenho mais lento do que outras GPUs no cluster e você não encontrar erros de XID nos registros, e nenhum dos outros padrões de falha comuns, como corrupção de dados silenciosa, for detectado.
      • SDC: use esse valor para corrupção de dados silenciosa, se você notar corrupção de dados, mas nenhuma falha do sistema. Essa corrupção de dados pode ser causada por defeitos de CPU, bugs de software, como use-after-free ou memory stomping, problemas de kernel ou outros defeitos. Na maioria das vezes, esse termo é usado para se referir a defeitos induzidos por hardware.
      • XID: use esse valor se você identificou um erro de GPU irrecuperável com um XID para uma instância de computação.
      • unspecified: use esse valor se você não tiver certeza de qual comportamento está causando o problema com a instância de computação. Esse é o valor padrão. No entanto, recomendamos especificar um dos outros valores, se aplicável.
    • Ajuste o bloco annotations com base na versão do plano de controle do cluster do GKE:
      • 1.35.6-gke.1017000 ou posterior, ou 1.36.0-gke.3251000 ou posterior: mantenha o bloco de anotações e substitua FAULT_DESCRIPTION por uma descrição de texto da falha observada. Isso pode incluir o código do erro XID, os sintomas ou os carimbos de data/hora. Essa descrição é encaminhada ao Compute Engine para ajudar no diagnóstico de reparo e é removida automaticamente do nó após a conclusão da operação. Por exemplo: GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z.
      • Versões anteriores: remova todo o bloco annotations do comando. O campo fault-description não é encaminhado para o Compute Engine nessas versões e não é removido automaticamente do nó. Em vez disso, entre em contato com a equipe de conta ou com o Cloud Customer Care para fornecer detalhes sobre a falha.
Depois que você informa um host com falha para um nó, o tempo de reinicialização do nó varia de acordo com o modo operacional de reserva especificado na reserva que o nó usa. Para verificar o modo operacional de uma reserva, confira o campo reservationOperationalMode na reserva. A tabela a seguir resume o processo de host com falha para os dois modos operacionais de reserva disponíveis: modo de capacidade total e modo gerenciado.
Modo de capacidade total (ALL_CAPACITY) Modo gerenciado (HIGHLY_AVAILABLE_CAPACITY)
Tipos de máquina compatíveis A4X Max e A4X A4, A3 Ultra, A3 Mega e A3 High (8 GPUs)
Limitação de taxa da API de relatório de host com falha Não há limites de taxa. As chamadas de API podem ter limitação de taxa.
Processo de relatório de host com falha

Quando você informa um host com falha para um nó que é executado no modo de capacidade total, ocorre o seguinte:

  1. Remover pods: depois que o rótulo é aplicado ao nó com falha, o GKE aplica um taint ao nó para bloquear a programação de novos pods. O GKE também começa a remover normalmente os pods em execução no nó. O GKE respeita os orçamentos de interrupção de pods (PDBs, na sigla em inglês) e o campo spec.terminationGracePeriodSeconds dos manifestos de pod. Para mais informações, consulte Configurar o GKE para encerrar as cargas de trabalho normalmente.
  2. Informar e reparar o host com falha: o GKE chama a API Compute Engine para informar e reparar o host com falha. Essa sequência de operações geralmente leva de 10 a 12 minutos para informar o host com falha e de 3 a 14 dias, ou até mais, para reparar o host.

  3. Reiniciar o nó: após a conclusão da operação de reparo do host, uma das seguintes ações ocorre:

    • Se o nó estiver no estado REPAIRING e os recursos estiverem disponíveis quando o reparo for concluído, o Compute Engine reiniciará automaticamente o nó no host reparado.
    • Caso contrário, se o nó estiver no estado TERMINATED ou se os recursos não estiverem disponíveis quando o reparo for concluído, o estado do nó permanecerá ou mudará para TERMINATED. É preciso reiniciar manualmente o nó quando você quiser que ele seja executado. No entanto, se os recursos não estiverem disponíveis quando você reiniciar o nó, por exemplo, se outras instâncias de computação já estiverem usando o host reparado, a reinicialização poderá falhar.

Quando você informa um host com falha para um nó que é executado no modo gerenciado, ocorre o seguinte:

  1. Remover pods: depois que o rótulo é aplicado ao nó com falha, o GKE aplica um taint ao nó para bloquear a programação de novos pods. O GKE também começa a remover normalmente os pods em execução no nó. O GKE respeita os orçamentos de interrupção de pods (PDBs, na sigla em inglês) e o campo spec.terminationGracePeriodSeconds dos manifestos de pod. Para mais informações, consulte Configurar o GKE para encerrar as cargas de trabalho normalmente.

  2. Informar e começar a reparar o host com falha: o GKE chama a API Compute Engine para informar e reparar o host com falha. Essa sequência de operações geralmente leva de 10 a 12 minutos para informar o host com falha.

    O comportamento do nó quando a operação de reparo do host começa varia de acordo com a série de máquinas:

    • A4 e A3 Ultra: o GKE tenta migrar em tempo real o nó para um host diferente. Se você não tiver capacidade reservada suficiente ou se a capacidade não estiver disponível na zona do nó, o nó será interrompido.
    • A3 Mega e A3 High: o GKE interrompe o nó e o reinicia em um host íntegro.

    O reparo do host com falha original pode levar de 3 a 14 dias ou até mais, às vezes.

  3. Migrar ou reiniciar o nó: depois que a operação de reparo do host é iniciada, o Compute Engine tenta reservar um host íntegro para substituir o host com falha na capacidade reservada. Se o Compute Engine encontrar um host de substituição, vai acontecer o seguinte:

    • A4 e A3 Ultra: se o nó foi migrado em tempo real na etapa anterior, ele continua em execução no host de substituição. Se o nó tiver sido interrompido, ele será reiniciado no host de substituição.
    • A3 Mega e A3 High: o nó é reiniciado no host de substituição.

    Se o Compute Engine não encontrar um host de substituição imediatamente, o nó será reiniciado da seguinte maneira:

    • Se o nó estiver no estado REPAIRING e os recursos estiverem disponíveis antes ou quando o reparo for concluído, o Compute Engine vai reiniciar automaticamente o nó em um host íntegro.
    • Caso contrário, se o nó estiver no estado TERMINATED ou se os recursos não estiverem disponíveis antes ou quando o reparo for concluído, o estado do nó permanecerá ou mudará para TERMINATED. É preciso reiniciar manualmente o nó quando você quiser que ele seja executado.

    Ao contrário do modo de capacidade total, não é necessário esperar que o host original com falha seja reparado antes que a carga de trabalho possa ser retomada.

Monitorar o progresso da operação

É possível monitorar o progresso da operação do GKE usando o rótulo de nó cloud.google.com/report-and-replace-status no nó do GKE, que tem um dos seguintes valores:

  • PodsEvicted: o GKE terminou de remover os pods do nó afetado.
  • OperationRUNNING: a operação para informar o host com falha está em execução.
  • OperationDONE: o host subjacente foi relatado como defeituoso, e o nó do GKE está pronto para ser movido para um novo host.
  • OperationFAILED: a API na instância de computação falhou devido a limites de cota ou outros problemas de infraestrutura. Para entender o erro, consulte Resolver problemas de API de relatório de host com falha. Para saber como recuperar, consulte Gerenciar falhas de relatório e substituição.
  • Error: a chamada de API falhou porque a solicitação não atendeu a um dos requisitos descritos na seção anterior.

Também é possível visualizar o rótulo do nó node.gke.io/report-and-replace-operation para conferir o ID da operação do Compute Engine e monitorar o status da operação.

Para conferir esses dois rótulos de nó, use o seguinte comando:

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,node.gke.io/report-and-replace-operation

Se ocorrer um erro de API, o GKE vai definir o rótulo de nó cloud.google.com/report-and-replace-status como Error. Se ocorrer uma falha na operação, o GKE definirá o rótulo como OperationFAILED. Nos dois casos, o GKE remove o rótulo de nó cloud.google.com/fault-behavior. Além disso, no GKE versão 1.35.6-gke.1256000 ou posterior, ou 1.36.0-gke.4060000 ou posterior, o GKE aplica um taint cloud.google.com/report-and-replace-failed:NoSchedule ao nó. Esse taint impede que novos pods sejam programados no nó, o que garante que as cargas de trabalho não sejam colocadas em um nó com um host potencialmente defeituoso. Para saber mais, consulte Tratar falhas de relatório e substituição.

Para saber como acompanhar o status detalhado de uma operação de relatório de host com falha, consulte Analisar operações de relatório de host com falha.

Processar falhas de denúncia e substituição

Quando uma operação de relatório e substituição falha, o GKE aplica o taint cloud.google.com/report-and-replace-failed:NoSchedule ao nó afetado. Esse taint mantém o nó isolado para que nenhuma nova carga de trabalho seja programada nele enquanto o host subjacente ainda estiver com falha.

Verificar se há taint de falha

Para verificar se um nó tem o taint de falha de relatório e substituição, execute o seguinte comando:

  kubectl describe node NODE_NAME | grep "report-and-replace-failed"

Recuperar-se de uma falha de relatório e substituição

Para se recuperar de uma falha de relatório e substituição, faça o seguinte:

  • Tente a operação novamente reaplicando o rótulo cloud.google.com/fault-behavior ao nó. Se a nova tentativa for bem-sucedida, o GKE removerá automaticamente o taint cloud.google.com/report-and-replace-failed:NoSchedule:

      kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON

  • Remova o taint manualmente se você determinar que o nó está íntegro ou se quiser que ele volte ao serviço:

      kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-

A seguir