Realizar manutenção de host para nós que executam cargas de trabalho de treinamento e inferência

Neste documento, explicamos como realizar a manutenção do host das instâncias do Compute Engine subjacentes para nós em clusters do Google Kubernetes Engine (GKE). Você só precisa gerenciar ativamente essa manutenção para determinados tipos de instâncias do Compute Engine que não são migradas em tempo real, incluindo instâncias com GPUs e TPUs. As estratégias descritas neste documento funcionam bem para cargas de trabalho de treinamento e inferência. Se você só precisa realizar manualmente a manutenção de host para um nó individual ou se as cargas de trabalho podem tolerar a manutenção automática de host, consulte Entender como fazer a manutenção de host no GKE.

Essas estratégias realizam a manutenção do host para grupos de nós e, opcionalmente, iniciam upgrades de cluster do GKE.

Use a estratégia paralela para os nós de cargas de trabalho em que é possível ter um único período de inatividade, como para os nós de cargas de trabalho de treinamento. Use a estratégia contínua para os nós de cargas de trabalho em que é possível ter lotes de inatividade, mantendo a disponibilidade da maioria dos recursos, como para os nós de cargas de trabalho de inferência.

Usar uma estratégia paralela para atualizar os nós das cargas de trabalho de treinamento

Essa estratégia realiza mudanças simultaneamente em um grupo de nós que usam aceleradores. É possível usar essa estratégia para treinar cargas de trabalho. Ou é possível usá-lo para outros tipos de cargas de trabalho em que o método menos disruptivo de realizar mudanças é ter uma única janela de inatividade completa para todos os nós no grupo e as cargas de trabalho executadas neles.

A estratégia segue estas etapas gerais:

1. Interromper cargas de trabalho: selecione os pools de nós e interrompa as cargas de trabalho em execução neles ou mova as cargas de trabalho para outros nós que permaneçam disponíveis.
2. Acionar a manutenção do host: aplique o rótulo de manutenção a todos os nós selecionados ao mesmo tempo e aguarde a conclusão do processo em todos os nós.
3. Fazer upgrade da versão do GKE: mude a versão do GKE dos nós.
4. Reiniciar cargas de trabalho: depois que todas as manutenções e upgrades do host forem concluídos, reinicie as cargas de trabalho.

As instruções fornecidas realizam mudanças em um único pool de nós. No entanto, é possível adaptar as etapas para realizar alterações em vários pools de nós ao mesmo tempo. Antes de começar, verifique se você tem pelo menos algumas horas em que essa carga de trabalho não precisa ser executada nesses nós.

Para minimizar as interrupções ao receber mudanças críticas nas instâncias do Compute Engine e nos nós do GKE, use esse período de inatividade para realizar a manutenção do host e os upgrades de versão do GKE. No entanto, é possível realizar apenas a manutenção do host se você não quiser fazer upgrade da versão dos nós do GKE.

Considerações antes de começar

Antes de começar, leia as considerações a seguir:

• Evite reimplantar cargas de trabalho: para evitar atrasos desnecessários devido a PodDisruptionBudgets, não reimplante nenhuma carga de trabalho até concluir todas as etapas.
• Planeje interrupções: garanta que as cargas de trabalho possam ser interrompidas por um período. Essas etapas levam várias horas para serem concluídas, principalmente devido ao tempo necessário para a manutenção do host.

Realizar atualizações para todos os nós simultaneamente

Para realizar a manutenção do host e, opcionalmente, upgrades de versão do GKE, siga estas etapas:

1. Prepare as cargas de trabalho: interrompa as cargas de trabalho ou verifique se elas fizeram um snapshot ou checkpoint recente.

2. Iniciar e monitorar a manutenção do host:

   • Sub-blocos de reservas que usam a programação de manutenção agrupada: acionam a manutenção em reservas, blocos de reserva ou sub-blocos de reserva usando o subcomando gcloud compute reservations correspondente. Por exemplo, o comando a seguir inicia a manutenção de um sub-bloco:

     gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
         --block-name=BLOCK_NAME \
         --sub-block-name=SUB_BLOCK_NAME \
         --zone=ZONE
     

     Substitua:

     • RESERVATION_NAME: o nome da reserva.
     • BLOCK_NAME: o nome do bloco de reserva.
     • SUB_BLOCK_NAME: o nome do sub-bloco de reserva.
     • ZONE: a zona em que a reserva existe.

     O Compute Engine começa a drenar e atualizar todas as instâncias no sub-bloco simultaneamente. Esse processo pode levar algumas horas.

     Para monitorar, verifique o estado da manutenção no campo de metadados upcomingGroupMaintenance nos recursos de reserva. Para mais informações, consulte Ver o estado de manutenção.

   • Instâncias que usam programação de manutenção independente: acione a manutenção para instâncias por demanda ou para reservas que não usam sub-blocos aplicando o rótulo cloud.google.com/perform-maintenance=true aos nós no pool de nós:

     kubectl label nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME cloud.google.com/perform-maintenance=true --overwrite
     

     O Compute Engine começa a drenar e atualizar as instâncias subjacentes simultaneamente. Esse processo pode levar algumas horas. Para mais informações, consulte Processo de encerramento normal.

     Para monitorar o status da manutenção, verifique os nós. O GKE remove o rótulo de manutenção quando a manutenção é concluída, se ele tiver sido aplicado. Quando a manutenção terminar, você vai encontrar um registro com a seguinte mensagem no Cloud Logging:

     Maintenance window has completed for this instance. All maintenance
     notifications on the instance have been removed.
     

3. Opcional: faça upgrade da versão dos nós do GKE: siga as instruções para fazer upgrade da versão do GKE dos nós.

Usar uma estratégia contínua para atualizar os nós das cargas de trabalho de inferência

Essa estratégia descreve uma abordagem manual para realizar manutenção em nós do GKE que executam cargas de trabalho de inferência. Envolve a atualização de nós em lotes para manter a disponibilidade do serviço. Esse método é mais adequado para cargas de trabalho que podem tolerar uma determinada porcentagem de réplicas temporariamente off-line.

A estratégia segue estas etapas gerais:

1. Identificar e agrupar nós: escolha os pools de nós que serão atualizados. Agrupe os nós em lotes dimensionados de acordo com a tolerância a falhas da carga de trabalho.
2. Iterar em lotes: para cada lote, aplique o rótulo de manutenção e monitore o lote de nós até que o rótulo seja removido.
3. Fazer upgrade da versão do GKE: depois que todos os lotes concluírem a manutenção do host, mude a versão dos nós do GKE.

Considerações antes de começar

Antes de começar, leia as considerações a seguir:

• Entenda sua implantação: o sucesso requer conhecimento detalhado da distribuição de cargas de trabalho, do posicionamento de réplicas e dos domínios de falha. Mantenha uma capacidade de veiculação suficiente durante todo o processo.
• Planejar tamanhos de lote: atualize os nós em lotes. O tamanho de cada lote é determinado pela tolerância a falhas da carga de trabalho. Os fatores a serem considerados incluem:
  • O número de réplicas por modelo de exibição.
  • A distribuição de réplicas entre nós e domínios de falha.
  • PodDisruptionBudgets pode ajudar a aplicar o número máximo de pods que ficam inativos simultaneamente.
  • Recomendação: para simplificar o gerenciamento, considere dedicar pools de nós diferentes a conjuntos de réplicas diferentes, o que permite isolar domínios de falha no nível do pool de nós.
• Calcule as restrições de tempo: considere os seguintes fatores de tempo:
  • Cada lote pode levar várias horas para concluir a etapa de manutenção do host.
  • Calcule o tamanho mínimo do lote para garantir que todas as manutenções sejam concluídas dentro dos prazos exigidos:
    1. MAINTENANCE_BLOCKS = floor(HOURS_TO_MAINTENANCE / 4) (em que HOURS_TO_MAINTENANCE é o tempo total disponível).
    2. MIN_PER_BATCH = TOTAL_NODE_COUNT / MAINTENANCE_BLOCKS
  • O tamanho do lote escolhido precisa ser igual ou maior que MIN_PER_BATCH.
• Revise tipos de carga de trabalho específicos: considere o seguinte para os respectivos tipos de configuração:
  • Mix de Especialistas (MoE): verifique se a estratégia de lote mantém o número mínimo necessário de réplicas para cada modelo.
  • Disaggregated serving: rastreie todas as réplicas envolvidas na configuração desagregada ao planejar lotes.
  • Pools de nós de vários hosts (TPU, MNNVL): para essas configurações, é provável que você remova um pool de nós inteiro por vez. Planeje os domínios de falha em vários pools de nós de acordo.

Fazer atualizações graduais em lotes

Para realizar atualizações graduais de manutenção do host, é possível atualizar a capacidade de reservas que usam a programação de manutenção agrupada em lotes de um ou mais sub-blocos ou atualizar conjuntos específicos de nós no cluster por nome com programação de manutenção independente.

Escolha a estratégia adequada para seus recursos:

Atualizar reservas em lotes de sub-blocos

Para realizar a manutenção contínua do host para reservas de capacidade em lotes de sub-blocos, siga estas etapas:

1. Identificar reservas para manutenção: identifique o nome da reserva de capacidade e os blocos ou sub-blocos de reserva usados pelo cluster do GKE. Para isso, faça uma pesquisa usando os rótulos de nó do GKE e o comando gcloud compute reservations:

   1. Liste o nome da reserva e os IDs de topologia de bloco físico e sub-bloco dos nós no pool de nós:

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME \
          -o custom-columns='NAME:.metadata.name,RESERVATION:.metadata.labels.cloud\.google\.com/reservation-name,BLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-block,SUBBLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-subblock'
      

      Substitua NODE_POOL_NAME pelo nome do pool de nós.

      Anote os valores de saída: o nome da reserva (por exemplo, nvidia-gb300-m7kp2xq9vd4j1), o ID do bloco (por exemplo, 3f2a8c9b1d4e0756f8a2b3c1d9e4f0a5) e o ID do sub-bloco (por exemplo, e7b91f4a3c2d58069e1a4b7f3d2c8056).

   2. Para identificar o nome do recurso do bloco de reserva, consulte a lista de blocos de reserva do Compute Engine usando o nome da reserva e filtre pelo ID do bloco:

      gcloud compute reservations blocks list RESERVATION_NAME \
          --zone=ZONE \
          --project=PROJECT_ID \
          --filter="physicalTopology.block=BLOCK_ID"
      

      Substitua:

      • RESERVATION_NAME: o nome da reserva.
      • ZONE: a zona em que a reserva existe.
      • PROJECT_ID: o ID do projeto em que a reserva existe.
      • BLOCK_ID: o ID do bloco recuperado dos rótulos do nó.

      Anote o nome do bloco na saída.

   3. Para identificar o nome do recurso do sub-bloco de reserva, consulte a lista de sub-blocos de reserva usando o nome da reserva e do bloco e filtre pelo ID do sub-bloco:

      gcloud compute reservations sub-blocks list RESERVATION_NAME \
          --block-name=BLOCK_NAME \
          --zone=ZONE \
          --project=PROJECT_ID \
          --filter="physicalTopology.subBlock=SUBBLOCK_ID"
      

      Substitua:

      • RESERVATION_NAME: o nome da reserva.
      • BLOCK_NAME: o nome do recurso do bloco de reserva.
      • ZONE: a zona em que a reserva existe.
      • PROJECT_ID: o ID do projeto em que a reserva existe.
      • SUBBLOCK_ID: o ID do sub-bloco recuperado dos rótulos do nó.

      A saída mostra detalhes sobre o sub-bloco de reserva correspondente, incluindo o nome do recurso.

2. Dividir as reservas em lotes: divida os sub-blocos de reserva de capacidade identificados em lotes iguais. Determine o tamanho do lote usando a fórmula descrita no item de lista Calcular restrições de tempo na seção Considerações antes de começar. Cada lote corresponde a um ou mais sub-blocos de reserva, e cada lote precisa ter pelo menos o tamanho de um sub-bloco.

3. Realize a manutenção do host: para cada lote, conclua as seguintes etapas:

   1. Selecione um lote de sub-blocos de reserva e acione a manutenção do host. É possível acionar a manutenção em reservas, blocos de reserva ou sub-blocos de reserva. Para tipos de máquina como A4X, A4X Max, TPU v6e e TPU7x, é necessário acionar a manutenção dessa maneira. A manutenção é realizada em grupos de sub-blocos. Use o comando gcloud compute reservations sub-blocks perform-maintenance:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
          --block-name=BLOCK_NAME \
          --sub-block-name=SUB_BLOCK_NAME \
          --zone=ZONE
      

      Substitua:

      • RESERVATION_NAME: o nome da reserva.
      • BLOCK_NAME: o nome do bloco de reserva.
      • SUB_BLOCK_NAME: o nome do sub-bloco de reserva.
      • ZONE: a zona em que a reserva existe.

      O Compute Engine começa a drenar e atualizar todas as instâncias no sub-bloco simultaneamente. Esse processo pode levar algumas horas.

   2. Monitore o status da manutenção verificando o estado dela no campo de metadados upcomingGroupMaintenance nos recursos de reserva. Para mais informações, consulte Ver o estado de manutenção da reserva.

   3. Repita as etapas anteriores para cada lote restante até concluir a manutenção do host para todos os lotes.

4. Opcional: faça upgrade da versão dos nós do GKE: realize essa etapa somente depois que a manutenção do host for concluída para todos os sub-blocos de reserva, para evitar cenários em que os nós do GKE são implantados em hosts que ainda não concluíram a manutenção. Siga as instruções para fazer upgrade da versão do GKE dos nós.

Atualizar nós em lotes

Para realizar a manutenção contínua do host para instâncias por demanda ou reservas que não oferecem suporte a sub-blocos em lotes, siga estas etapas:

1. Identificar nós para manutenção: identifique todos os nós em que você quer realizar a manutenção e salve essa lista. Para identificar nós, use um dos seguintes métodos ou selecione-os manualmente:

   • Encontre todos os nós no cluster que usam aceleradores (TPUs ou GPUs):

     kubectl get nodes -o json | jq -r '.items[] | select(.spec.taints[]? | select(.key=="nvidia.com/gpu" or .key=="google.com/tpu")) | .metadata.name'
     

   • Receba todos os nós em um pool de nós específico:

     kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME --no-headers -o custom-columns=":metadata.name"
     

     Substitua NODE_POOL_NAME pelo nome do pool de nós.

   • Encontre todos os nós com um rótulo específico:

     kubectl get nodes -l LABEL -o jsonpath='{.items[*].metadata.name}'
     

     Substitua LABEL pelo rótulo do nó.

2. Divida os nós em lotes: divida os nós identificados em lotes iguais. Determine o tamanho do lote usando a fórmula descrita no item de lista Calcular restrições de tempo na seção Considerações antes de começar.

3. Realize a manutenção do host: para cada lote, conclua as seguintes etapas:

   1. Selecione um lote de nós e acione a manutenção na camada da instância usando a API instances ao aplicar o rótulo de manutenção:

      kubectl label nodes LIST_OF_NODES_IN_BATCH cloud.google.com/perform-maintenance=true --overwrite
      

      Substitua LIST_OF_NODES_IN_BATCH por uma lista separada por espaços de nós do lote. Por exemplo, node-1 node-2 node-3.

      O Compute Engine começa a drenar e atualizar as instâncias subjacentes simultaneamente. Esse processo pode levar algumas horas. Para mais informações, consulte Processo de encerramento normal.

   2. Monitorar o status da manutenção do host. O GKE remove o rótulo de manutenção quando a manutenção é concluída, se ele tiver sido aplicado. Quando a manutenção terminar, você vai encontrar um registro com a seguinte mensagem no Logging:

      Maintenance window has completed for this instance. All maintenance
      notifications on the instance have been removed.
      

   3. Repita as etapas anteriores para cada lote restante até concluir a manutenção do host para todos os lotes.

4. Opcional: faça upgrade da versão dos nós do GKE: realize essa etapa somente depois que a manutenção do host for concluída para todos os nós, para evitar cenários em que os nós do GKE são implantados em hosts que ainda não concluíram a manutenção. Siga as instruções para fazer upgrade da versão do GKE dos nós.

Fazer upgrade da versão do GKE dos nós

Considere o número de nós que você quer atualizar ao mesmo tempo. Com a estratégia paralela, você realizou a manutenção do host para todo o pool de nós ou vários pools de nós ao mesmo tempo. Com a estratégia contínua, você realizou a manutenção do host em lotes. Determine qual método de upgrade você vai usar com base no tamanho dos grupos de nós:

• Estratégia paralela: se os pools de nós tiverem 100 ou menos nós por zona, use upgrades súbitos. Se os pools de nós tiverem mais de 100 nós por zona, exclua e recrie os pools de nós.
• Estratégia contínua: se os lotes tiverem 100 nós, por zona, por pool de nós ou menos, use upgrades súbitos. Se os lotes tiverem mais de 100 nós por zona e por pool de nós, exclua e recrie os nós.

Usar upgrades súbitos

1. Configure upgrades súbitos, usando a configuração maxUnavailable para determinar quantos nós podem ficar indisponíveis ao mesmo tempo, por zona, em um pool de nós. Por exemplo, se você tiver 18 nós em uma zona em um pool de nós, defina o valor do campo maxUnavailable como 18.

   Essa configuração funciona melhor ao usar a capacidade de uma reserva em que você não tem capacidade extra. Para mais informações sobre por que usar essa configuração, consulte Fazer upgrade em um ambiente com restrição de recursos.

2. Faça upgrade do pool de nós executando o comando a seguir. Se você quiser fazer upgrade de vários pools de nós, execute este comando para cada pool de nós:

   gcloud container clusters upgrade CLUSTER_NAME \
       --node-pool NODE_POOL_NAME \
       --cluster-version VERSION \
       --location CONTROL_PLANE_LOCATION \
       --quiet
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster.
   • NODE_POOL_NAME: o nome do pool de nós.
   • VERSION: um destino de upgrade automático recomendado para o pool de nós. Para mais informações, consulte Receber informações de upgrade para pools de nós de cluster padrão. Se o cluster não tiver um destino de upgrade automático recomendado, verifique as entradas mais recentes de Atualizações de versão nas notas de lançamento do GKE.
   • CONTROL_PLANE_LOCATION: o local do plano de controle do cluster.

Excluir e recriar os nós

Exclua o pool de nós e recrie-o usando a versão mais recente:

1. Exclua o pool de nós:

   gcloud container node-pools delete NODE_POOL_NAME \
       --cluster CLUSTER_NAME \
       --location CONTROL_PLANE_LOCATION
   

2. Recrie o pool de nós, transmitindo a nova versão usando a flag --cluster-version. Transmita o destino de upgrade automático recomendado para o pool de nós. Para mais informações, consulte Receber informações de upgrade para pools de nós de cluster padrão. Se o cluster não tiver um destino de upgrade automático recomendado, verifique as entradas mais recentes de Atualizações de versão nas notas de lançamento do GKE.