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 fazem migração em tempo real, incluindo instâncias com GPUs e TPUs. As estratégias descritas neste documento funcionam bem para treinamento e inferência. Se você só precisar realizar a manutenção manual do host para um nó individual ou se as cargas de trabalho puderem tolerar a manutenção automática do host, consulte Entenda como fazer a manutenção do host no GKE.

Essas estratégias realizam a manutenção do host para grupos de nós e, opcionalmente, iniciam upgrades do 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 os nós de cargas de trabalho de treinamento. Use a estratégia de atualização gradual para os nós de cargas de trabalho em que é possível ter lotes de tempo de inatividade, mantendo a disponibilidade da maioria dos recursos, como para os nós de cargas de trabalho de inferência.

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

Essa estratégia faz mudanças simultâneas em um grupo de nós que usam aceleradores. Você pode usar essa estratégia para treinar cargas de trabalho. Ou você pode usar para outros tipos de cargas de trabalho em que o método menos destrutivo de fazer mudanças é ter uma única janela de inatividade completa para todos os nós do grupo e as cargas de trabalho executadas neles.

A estratégia segue estas etapas gerais:

1. Interrompa as 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 permanecem 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. Faça upgrade da versão do GKE: mude a versão do GKE dos nós.
4. Reinicie as cargas de trabalho: depois que toda a manutenção e os upgrades do host forem concluídos, reinicie as cargas de trabalho.

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

Para minimizar a interrupção 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 reimplemente nenhuma carga de trabalho até concluir todas as etapas.
• Planeje interrupções: garanta que suas 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.

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

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

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

2. Iniciar manutenção do host: aplique o rótulo de manutenção a todos os nós no pool de nós selecionado:

   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 esvaziar e atualizar as instâncias simultaneamente. Esse processo pode levar algumas horas. Para mais informações, consulte Processo de encerramento normal.

3. Monitore o status da manutenção do host: o GKE remove o rótulo de manutenção quando ela é concluída. 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.
   

4. 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.

Use uma estratégia gradual para atualizar os nós das cargas de trabalho de inferência

Esta estratégia descreve uma abordagem manual para realizar a manutenção em nós do GKE que executam cargas de trabalho de inferência. Isso 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. Identifique e agrupe nós em lotes: escolha os pools de nós a serem atualizados. Agrupe os nós em lotes dimensionados de acordo com a tolerância a falhas da sua carga de trabalho.
2. Iterar 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. Faça 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 exige conhecimento detalhado da distribuição da carga de trabalho, do posicionamento de réplicas e dos domínios de falha. Mantenha capacidade de veiculação suficiente durante todo o processo.
• Planeje tamanhos de lote: atualize os nós em lotes. O tamanho de cada lote é determinado pela tolerância a falhas da sua carga de trabalho. Considere os seguintes fatores:
  • O número de réplicas por modelo de serviço.
  • A distribuição de réplicas entre nós e domínios de falha.
  • Os PodDisruptionBudgets podem ajudar a aplicar o número máximo de pods que estão inativos simultaneamente.
  • Recomendação: para simplificar o gerenciamento, dedique diferentes pools de nós a diferentes conjuntos de réplicas, o que permite isolar domínios de falha no nível do pool de nós.
• Calcular 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 toda a manutenção seja concluída dentro dos prazos necessários:
    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.
• Analise tipos específicos de carga de trabalho: considere o seguinte para os respectivos tipos de configuração:
  • Mix de Especialistas (MOE): verifique se sua estratégia de agrupamento mantém o número mínimo necessário de réplicas para cada modelo.
  • Veiculação desagregada: acompanhe 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ê desative um pool de nós inteiro por vez. Planeje seus domínios de falha em vários pools de nós de acordo com isso.

Fazer atualizações graduais em lotes

Para fazer atualizações rotativas, siga estas etapas:

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

   • Receba todos os nós do 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.

   • Receber 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. Dividir nós em lotes: divida os nós identificados em lotes iguais. Determine o tamanho do lote usando a fórmula descrita no item da 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 aplique 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.

   2. Monitore o status da manutenção do host. O GKE remove o rótulo de manutenção quando ela é concluída. 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 duas 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: execute esta 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. Consulte as instruções na seção a seguir.

Faça upgrade da versão do GKE dos nós

Considere o número de nós que você quer fazer upgrade ao mesmo tempo. Com a estratégia paralela, você fez a manutenção do host para todo o pool de nós ou vários pools ao mesmo tempo. Com a estratégia gradual, você fez 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 cada um dos seus pools de nós tiver 20 ou menos nós por zona, use upgrades súbitos. Se cada um dos seus pools de nós tiver mais de 20 nós por zona, exclua e recrie os pools.
• Estratégia de rolling: se seus lotes tiverem 20 nós, por zona, por pool de nós ou menos, use upgrades súbitos. Se os lotes tiverem mais de 20 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 quando você usa a capacidade de uma reserva sem 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 seguinte comando. 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: uma meta de upgrade automático recomendada para o pool de nós. Para mais informações, consulte Receber informações de upgrade para pools de nós do cluster Standard. Se o cluster não tiver um destino de upgrade automático recomendado, confira as entradas mais recentes de Atualizações de versão nas notas da versão 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 do cluster Standard. Se o cluster não tiver um destino de upgrade automático recomendado, confira as entradas mais recentes de Atualizações de versão nas notas da versão do GKE.