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
• Denúncia de host 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 sofrem eventos de host que podem prejudicar as cargas de trabalho de IA. Como os eventos de host ocorrem na infraestruturaGoogle Cloud , eles ignoram as janelas e exclusões de manutenção 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 seus 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 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ós 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 fazer o seguinte:

• Iniciar manualmente um evento de manutenção de host
• Usar informações de eventos de manutenção do host ao programar suas cargas de trabalho

Iniciar manualmente um evento de manutenção de host

Depois que o Compute Engine emite uma notificação sobre um evento de manutenção programada, é possível iniciar manualmente a manutenção em um horário que esteja alinhado à sua programação. Por exemplo, você pode 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:

• Configure o GKE para encerrar as cargas de trabalho normalmente
• Processo de encerramento sem dificuldades
• Monitorar o progresso de uma finalização suave ativa

Use informações de manutenção do host ao programar suas cargas de trabalho

É possível usar as informações de manutenção exibidas pelos rótulos de nó do GKE, além de afinidade e antiafinidade de nós, para minimizar a interrupção das cargas de trabalho.

Consulte as seções a seguir para exemplos de como usar essas informações.

Programar pods para nós sem eventos de manutenção programados para o futuro

É possível instruir o GKE a programar apenas pods em nós que não têm eventos de manutenção programados futuros, 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 com manutenção agendada após uma determinada data

É possível instruir o GKE a programar pods apenas para nós que tenham manutenção agendada após uma determinada data, fornecendo o tempo de época Unix:

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

Gerenciar upgrades de 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 ser preparadas para interrupções nas instâncias de computação subjacentes e no próprio cluster do GKE:

• Manutenção do host: para 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. Isso também é descrito nas seções anteriores.
• Upgrades de cluster: para gerenciar a interrupção causada por upgrades de cluster, use as seguintes ferramentas:
  • Janelas de manutenção: programe quando o GKE pode realizar upgrades de cluster e outros tipos de operações de cluster.
  • Exclusões de manutenção: Impeça upgrades e outros tipos de operações de cluster durante um período específico.

Recomendamos que você mantenha seu 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 "Nenhum upgrade secundário ou de nó" para cargas de trabalho de IA.

Denunciar hosts com falha pelo GKE

Nesta seção, descrevemos como, pelo 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 denunciar um host com falha para um nó provisionado usando o modelo de provisionamento de início flexível (prévia), entre em contato com sua equipe de conta.

Cuidado: reportar um host com falha é uma ação que causa interrupção e para sua VM. Antes de denunciar um host, investigue seu ambiente usando ferramentas como o scanner de integridade do cluster (CHS) para identificar a causa raiz do problema. Só denuncie o host como defeituoso se não houver alternativas para resolver o problema.

Um host é uma única máquina de servidor físico no data center que executa uma instância de computação que hospeda seu nó do GKE. É possível denunciar hosts com falha aplicando um rótulo de nó fault-behavior ao nó afetado do GKE. Depois de aplicar o rótulo a um nó específico do GKE, o GKE realiza as seguintes 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 com falha.
4. Aguarde a instância de computação ser reiniciada em uma máquina host íntegra. Para reservas que usam o modo operacional de reserva de toda a capacidade, o Compute Engine restaura a instância de computação no mesmo nó após a conclusão da operação de reparo.
5. Remove o taint e o rótulo fault-behavior do nó.

Depois disso, o nó estará pronto para atender às cargas de trabalho novamente.

Requisitos

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

• Use a versão de patch do GKE 1.32.3-gke.1057001 ou mais recente.
• Você precisa estar executando um dos seguintes tipos de máquinas com GPU: A4X Max, A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPUs).
• Você precisa executar os nós do GKE em uma instância de computação vinculada a uma reserva.
• Seu nó do GKE precisa estar no estado RUNNING. Se você tentar denunciar 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.
• Você pode ter uma limitação de taxa no número de chamadas para essa API por reserva por mês 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.

Denunciar um host com falha

Observação: os dados do SSD local serão excluídos após a invocação bem-sucedida da API, à medida que a instância de computação muda de host. Recomendamos que você faça backup dos dados do SSD local antes de informar um nó com falha pelo GKE.

Para denunciar 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. Denuncie o nó como com falha:

   Importante: depois de denunciar um host como defeituoso, não envie outras solicitações até que a operação seja concluída. O GKE rejeita outras solicitações enquanto a operação está em andamento.

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

   Substitua:

   • NODE_NAME: o nome do nó com falha.
   • FAULT_REASON: o motivo da 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 nem outros padrões de falha comuns, como corrupção silenciosa de dados.
     • SDC: use esse valor para corrupção silenciosa de dados se você notar corrupção de dados, mas não uma falha do sistema. Essa corrupção de dados pode ser causada por defeitos na CPU, bugs de software, como use-after-free ou stomping de memória, problemas no kernel ou outros defeitos. Na maioria das vezes, esse termo é usado para se referir a defeitos causados por hardware.
     • XID: use esse valor se você identificou um erro irrecuperável de GPU com um XID para uma instância de computação.
     • unspecified: use esse valor se não tiver certeza de qual comportamento está causando o problema com sua instância de computação. Esse é o valor padrão. No entanto, recomendamos especificar um dos outros valores, se aplicável.

Depois que você informa um host com falha para um nó, o tempo em que o nó é reiniciado varia de acordo com o modo operacional da reserva especificado na reserva usada pelo nó. Para verificar o modo operacional de uma reserva, consulte 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
Limitação de taxa da API de relatório de host com falha	Nenhum limite de taxa se aplica.	As chamadas para a API podem ter limite de taxa.
Processo de denúncia de host com falha	Quando você informa um host com falha para um nó que é executado no modo de capacidade total, acontece o seguinte: Remover pods: depois que o rótulo é aplicado ao nó com falha, o GKE adiciona 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) e o campo spec.terminationGracePeriodSeconds dos manifestos de pods. Para mais detalhes, consulte Configure o GKE para encerrar as cargas de trabalho normalmente. Informar e corrigir o host com falha: o GKE informa e corrige automaticamente o host com falha chamando a API Compute Engine, o que resulta em uma sequência de operações que geralmente leva de 10 a 12 minutos para informar o host com falha e de 3 a 14 dias, ou até mais, para corrigir o host. Reinicie a instância: depois que a operação de reparo do host for concluída (geralmente de 3 a 14 dias), uma das seguintes situações vai ocorrer: Se a instância estiver no estado REPAIRING e os recursos estiverem disponíveis quando o reparo for concluído, o Compute Engine vai reiniciar automaticamente a instância no host reparado. Caso contrário, se a instância estiver no estado TERMINATED ou se os recursos não estiverem disponíveis quando o reparo for concluído, o estado da instância permanecerá ou mudará para TERMINATED. É preciso reiniciar a instância manualmente quando quiser que ela seja executada. No entanto, a reinicialização da instância pode falhar se os recursos não estiverem disponíveis quando você reiniciar a instância. Por exemplo, isso pode acontecer se outras instâncias já estiverem usando o host reparado.	Quando você informa um host com falha para um nó que é executado no modo gerenciado, acontece o seguinte: Remover pods: depois que o rótulo é aplicado ao nó com falha, o GKE adiciona 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) e o campo spec.terminationGracePeriodSeconds dos manifestos de pods. Para mais detalhes, consulte Configure o GKE para encerrar as cargas de trabalho normalmente. Informar e iniciar o reparo do host com falha: o GKE informa e repara automaticamente o host com falha chamando a API Compute Engine, o que resulta em uma sequência de operações que 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. Migrar e reiniciar a instância: depois que a operação de reparo do host começar (geralmente de 10 a 12 minutos), o Compute Engine tentará reservar mais um host para substituir o host com falha informado na sua capacidade reservada. Se o Compute Engine encontrar um host íntegro (se ele substituir o host com falha ou encontrar um host íntegro correspondente na capacidade reservada), o Compute Engine migrará a instância para esse host. Em seguida, a reinicialização da instância acontece por uma das seguintes maneiras: Se a instância estiver no estado REPAIRING e os recursos estiverem disponíveis antes ou quando o reparo for concluído, o Compute Engine vai reiniciar automaticamente a instância em um host íntegro. Caso contrário, se a instância estiver no estado TERMINATED ou se os recursos não estiverem disponíveis antes ou quando o reparo for concluído, o estado da instância permanecerá ou mudará para TERMINATED. É preciso reiniciar a instância manualmente quando quiser que ela seja executada. No entanto, a reinicialização da instância pode falhar se os recursos não estiverem disponíveis quando você reiniciar a instância. Por exemplo, isso pode acontecer se outras instâncias já estiverem usando o host reparado.

Monitorar o progresso da operação

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

• PodsEvicted: o GKE terminou de desalojar 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 com falha e o nó do GKE está pronto para ser movido para um novo host
• Error: a chamada de API falhou por motivos que incluem um dos requisitos descritos na seção anterior.

Você também pode conferir o rótulo do nó cloud.google.com/report-and-replace-operation para ver o ID da operação do Compute Engine e monitorar o status da operação.

É possível conferir os dois rótulos de nós usando o seguinte comando:

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

Em caso de erros de API, o GKE define o rótulo do nó cloud.google.com/report-and-replace-status=ERROR. O GKE limpa as contaminações do nó e remove o rótulo do nó cloud.google.com/fault-behavior.

Para saber como acompanhar o status detalhado de uma operação de denúncia de host com falha, consulte Analisar operações de denúncia de host com falha.

Para repetir a operação em caso de erros transitórios, como limites de taxa, aplique novamente o rótulo cloud.google.com/fault-behavior ao nó.

A seguir

• Saiba como agendar cargas de trabalho do GKE com o Agendamento com reconhecimento de topologia.

• Saiba como otimizar a rede de clusters usando NCCL/gIB.

• Saiba como resolver problemas e informar erros na API do host.