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 para nós em clusters do Google Kubernetes Engine (GKE). Só é necessário gerenciar ativamente essa manutenção para determinados tipos de instâncias do Compute Engine que não migram 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ó precisar realizar a manutenção do host manualmente para um nó individual ou se as cargas de trabalho puderem tolerar a manutenção automática do host , consulte Entender 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 cluster do GKE.

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

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

Essa estratégia realiza mudanças simultaneamente para um grupo de nós que usam aceleradores. Você pode usar essa estratégia para cargas de trabalho de treinamento. Ou, você pode usá-la 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 do 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 toda a manutenção e os upgrades do host forem concluídos, reinicie as cargas de trabalho.

As instruções fornecidas realizam mudanças para um único pool de nós. No entanto, é possível adaptar as etapas para realizar mudanças em vários pools de nós ao mesmo tempo. Antes de começar 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 para as instâncias do Compute Engine e os nós do GKE, use esse período de inatividade para realizar a manutenção do host e os upgrades da 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

Revise as seguintes considerações antes de começar:

  • 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.
  • Planejar interrupções: verifique se as cargas de trabalho podem 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 da versão do GKE, siga estas etapas:

  1. Preparar 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 o agendamento de manutenção agrupado: acione 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 esvaziar e atualizar todas as instâncias no sub-bloco simultaneamente. Esse processo pode levar algumas horas.

      Para monitorar, confira o estado da manutenção verificando o campo de metadados upcomingGroupMaintenance nos recursos de reserva. Para mais informações, consulte Conferir o estado de manutenção.

    • Instâncias que usam o agendamento de manutenção independente: acione a manutenção de instâncias sob demanda ou de 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 esvaziar e atualizar as instâncias 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 foi aplicado. Quando a manutenção terminar, você poderá 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: fazer 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 gradual para atualizar os nós de cargas de trabalho de inferência

Essa estratégia descreve uma abordagem manual para realizar a manutenção em nós do GKE que executam cargas de trabalho de inferência. Ela 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 a serem atualizados. Agrupe os nós em lotes dimensionados de acordo com a tolerância a falhas da 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. 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

Revise as seguintes considerações antes de começar:

  • Entender a implantação: o sucesso exige conhecimento detalhado de sua distribuição da carga de trabalho, posicionamento da réplica e domínios de falha. Mantenha 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 seguinte:
    • O número de réplicas por modelo de veiculação.
    • A distribuição de réplicas em nós e domínios de falha.
    • PodDisruptionBudgets podem ajudar a aplicar o número máximo de pods que estão inativos simultaneamente.
    • Recomendação: para simplificar o gerenciamento, considere dedicar 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 termine 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.
  • Analisar tipos de carga de trabalho específicos: considere o seguinte para os respectivos tipos de configuração:
    • Mistura 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.
    • Veiculação desagregada: verifique se você acompanha 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.

Realizar atualizações graduais em lotes

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

Escolha a estratégia adequada para seus recursos:

Atualizar reservas em lotes de sub-blocos

Para realizar a manutenção gradual 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 de reserva ou sub-blocos de reserva usados pelo cluster do GKE. Para fazer isso, realize uma pesquisa usando rótulos de nós do GKE e o gcloud compute reservations comando:

    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.

      Observe 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ó.

      Grave 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 o nome 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 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 da 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. Realizar a manutenção do host: para cada lote, siga estas 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 gcloud compute reservations sub-blocks perform-maintenance comando:

      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 esvaziar e atualizar todas as instâncias no sub-bloco simultaneamente. Esse processo pode levar algumas horas.

    2. Monitore o status da manutenção conferindo o estado da manutenção verificando o campo de metadados upcomingGroupMaintenance nos recursos de reserva. Para mais informações, consulte Conferir 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: fazer upgrade da versão dos nós do GKE: realize esta 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 terminaram 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 gradual do host para instâncias sob 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 esta lista. Para identificar nós, use um dos seguintes métodos ou selecione-os manualmente:

    • Receba 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.

    • Receba 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. Realizar a manutenção do host: para cada lote, siga estas etapas:

    1. Selecione um lote de nós e acione a manutenção na camada da instância usando a API instances aplicando 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 de nós separados por espaços do lote. Por exemplo, node-1 node-2 node-3.

      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.

    2. Monitore o status da manutenção do host. O GKE remove o rótulo de manutenção quando a manutenção é concluída, se ele foi aplicado. Quando a manutenção terminar, você poderá 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: fazer upgrade da versão dos nós do GKE: realize 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 terminaram 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 fazer upgrade 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 gradual, 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 gradual: 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, 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 excessiva. 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 esse 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:

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 upgrades para pools de nós de cluster padrão. 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 de lançamento do GKE.