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ório 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 passam por eventos de host que podem ser prejudiciais às cargas de trabalho de IA. Como os eventos de host ocorrem na infraestrutura subjacente Google 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 oferecem suporte à 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 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 mais recente, é 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ó do GKE correspondente 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 cargas de trabalho

Iniciar manualmente um evento de manutenção de host

Depois que o Compute Engine emitir uma notificação sobre um evento de manutenção programado, você poderá iniciar a manutenção manualmente em um horário que esteja alinhado à 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 do host, o Compute Engine concluirá automaticamente a manutenção programada regularmente.

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

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

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

É possível usar as informações de manutenção exibidas pelos rótulos de nó do GKE , juntamente com a afinidade de nóe a antiafinidade , 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 que não têm eventos de manutenção programados para o futuro

É possível instruir o GKE a programar apenas pods para nós que não têm 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 têm manutenção programada após uma determinada data

É possível instruir o GKE a programar apenas pods para nós que têm 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:

• 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 clusters: para gerenciar interrupções de upgrades de clusters, use as seguintes ferramentas:
  • Janelas de manutenção: Programe quando o GKE pode realizar upgrades de clusters e outros tipos de operações de cluster.
  • Exclusões de manutenção: impeça upgrades de clusters e outros tipos de operações de cluster durante um período específico.

Recomendamos que você mantenha o cluster registrado em um canal de lançamento. Os clusters do GKE, por padrão, são registrados no canal de lançamento normal. 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 escopos de exclusão de manutenção adicionais maintenance exclusion scopes. Recomendamos o escopo "sem upgrades secundários ou de nós" para cargas de trabalho de IA.

Informar hosts com falha pelo GKE

Esta seção descreve como, pelo GKE, é possível informar um host com falha que tenha instâncias de computação provisionadas usando o modelo de provisionamento vinculado à reserva. Se você quiser reportar um host com falha para um nó provisionado usando o modelo de provisionamento de início flexível (Pré-lançamento), então entre em contato com a equipe de conta.

Cuidado: informar um host com falha é uma ação prejudicial que interrompe a VM. Antes de informar um host, investigue seu ambiente usando ferramentas como o verificador de integridade do cluster (CHS) para identificar a causa raiz do problema. Só informe o host como com falha 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 o nó do GKE. É possível informar hosts com falha aplicando um rótulo de nó fault-behavior ao nó do GKE afetado. Depois de aplicar o rótulo de nó a um nó específico do GKE, o GKE realiza as seguintes etapas:

1. Remove as cargas de trabalho do nó.
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 até que a instância de computação seja restaurada em uma máquina host íntegra. Para reservas que usam o modo operacional de reserva capacidade total, 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 cargas de trabalho novamente.

Requisitos

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

• Você precisa executar a versão de patch 1.32.3-gke.1057001 do GKE ou mais recente.
• Você precisa executar um dos seguintes tipos de máquinas de 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 que esteja 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.
• 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 blocos. As limitações de taxa não se aplicam se a reserva usar o modo operacional de reservacapacidade total.

Informar um host com falha

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

Para informar 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 apresentando problemas de desempenho. Salve o NODE_NAME.

2. Informe o nó como com falha:

   Importante: depois de informar um host como com falha, 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 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 XID nos registros, e nenhum dos outros padrões de falha usuais, como corrupção de dados silenciosa, for detectado.
     • SDC: use esse valor para corrupção de dados silenciosa, se você encontrar 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 uso após a liberação ou stomping de memória, 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ê identificar 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.

Depois de informar um host com falha para um nó, o horário em que o nó é reiniciado varia de acordo com o modo operacional de reserva especificado na reserva que o nó usa. Para verificar o modo operacional de 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	Nenhuma limitação de taxa se aplica.	As chamadas para a API podem ser limitadas por taxa.
Processo de relatório de host com falha	Quando você informa um host com falha para um nó executado no modo de capacidade total, o seguinte ocorre: Remover pods: depois que o rótulo é aplicado ao nó com falha, o GKE mancha o nó para bloquear a programação de novos pods. O GKE também começa a remover os pods em execução no nó. O GKE respeita os orçamentos de interrupção de pods (PDBs) e o spec.terminationGracePeriodSeconds campo dos manifestos de pods. Para mais detalhes, consulte Configurar o GKE para encerrar as cargas de trabalho normalmente. Informar e reparar o 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, em seguida, pode levar de 3 a 14 dias, ou até mais, para reparar o host. Reiniciar a instância: depois que a operação de reparo do host é concluída (geralmente de 3 a 14 dias), uma das seguintes situações ocorre: Se a instância estiver no estado REPAIRING e os recursos estiverem disponíveis quando o reparo for concluído, o Compute Engine 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. Você precisa reiniciar a instância manualmente quando quiser que ela seja executada. No entanto, a reinicialização da instância poderá 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ó executado no modo gerenciado, o seguinte ocorre: Remover pods: depois que o rótulo é aplicado ao nó com falha, o GKE mancha o nó para bloquear a programação de novos pods. O GKE também começa a remover os pods em execução no nó. O GKE respeita os orçamentos de interrupção de pods (PDBs) e o spec.terminationGracePeriodSeconds campo dos manifestos de pods. Para mais detalhes, consulte Configurar 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, em seguida, pode levar 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ça (geralmente de 10 a 12 minutos), o Compute Engine tenta reservar mais um host para substituir o host com falha informado na 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 ocorre de 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 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. Você precisa reiniciar a instância manualmente quando quiser que ela seja executada. No entanto, a reinicialização da instância poderá 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 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 informado 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.

Também é possível conferir o rótulo de nó cloud.google.com/report-and-replace-operation para conferir o ID da operação do Compute Engine e monitorar o status da operação.

É possível conferir esses dois rótulos de nó 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 de nó cloud.google.com/report-and-replace-status=ERROR. O GKE limpa os taints de nó e remove o rótulo de nó cloud.google.com/fault-behavior.

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.

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

A seguir

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

• Saiba como otimizar a rede de computadores do cluster usando NCCL/gIB.

• Saiba como resolver problemas de erros de API de relatório de host com falha.