Gerenciar a interrupção de nós do GKE para GPUs e TPUs

Durante o ciclo de vida de um cluster do GKE de longa duração, as interrupções nas cargas de trabalho ocorrem devido a interrupções na infraestrutura que Google Cloud problemas. Esses eventos automáticos podem ocorrer para responder a decisões de programação (eventos de remoção), atualizações do plano de controle ou de nós, que incluem upgrades automáticos de nós do GKE (eventos de manutenção) ou correção de problemas detectados (eventos de encerramento).

Nesta página, você vai entender o que significa a interrupção de nós no GKE, monitorar notificações de manutenção e minimizar o impacto da interrupção nos nós do GKE com GPUs e TPUs anexadas.

Este documento é destinado a administradores e operadores de plataforma que gerenciam o ciclo de vida da infraestrutura de tecnologia subjacente. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.

O que significa interrupção de infraestrutura no GKE?

Seus clusters do GKE gerenciam o ciclo de vida dos nós do GKE. Esses nós são provisionados em VMs do Compute Engine, que periodicamente sofrem as seguintes interrupções:

  • Correção de problemas detectados (TerminationEvent): esses eventos ocorrem porque o Google Cloud detecta um problema e interrompe a infraestrutura do cluster. Os eventos TerminationEvent não são compatíveis com o encerramento normal. Os eventos TerminationEvent são acionados pelos seguintes problemas:

    • O reparo automático ocorre quando o GKE repara um nó após repetidas falhas nas verificações de integridade.
    • HostError ocorre quando um erro de hardware ou software na máquina física faz com que a VM pare.

  • Eventos de manutenção ou upgrade (MaintenanceEvent): esses eventos ocorrem quando o Google Cloud precisa interromper uma VM para realizar a manutenção. Os eventos MaintenanceEvent são acionados pelas seguintes tarefas de manutenção:

    Para mais informações sobre como você e o GKE gerenciam mudanças durante o ciclo de vida de um cluster, consulte Tipos de mudanças.

  • Resposta a decisões de programação (PreemptionEvent): ocorrem quando Google Cloud precisa desalojar VMs para disponibilizar capacidade para recursos de maior prioridade. Os eventos PreemptionEvent podem ser qualquer um dos seguintes:

    • Remoção:ocorre quando a infraestrutura preemptiva ou spot é preemptiva para acomodar uma VM de prioridade mais alta.
    • Desfragmentação:ocorre quando o GKE faz a preempção de uma fração de TPU menor para acomodar uma fração de TPU maior. A desfragmentação só ocorre em frações de TPU.

Durante o ciclo de vida de um cluster do GKE de longa duração, os nós podem sofrer interrupções periódicas nas cargas de trabalho de treinamento ou serviço. Quando essas interrupções afetam seus nós do GKE que executam cargas de trabalho de IA/ML, o GKE precisa reiniciar as cargas de trabalho em execução e o nó subjacente.

Por que GPUs e TPUs exigem gerenciamento de interrupções

Com algumas exceções, a maioria das VMs do Compute Engine tem a política de manutenção do host definida como migração em tempo real, o que significa que as cargas de trabalho em execução geralmente sofrem pouca ou nenhuma interrupção. No entanto, algumas classes de VMs não aceitam migração em tempo real, incluindo VMs com anexos GPUs e TPUs. Quando um evento de host acontece com a VM em uma fatia de TPU, toda a fatia é interrompida e reagendada, porque todos os eventos de manutenção são coordenados no nível da fatia. Portanto, se você criar uma fração de TPU com centenas de VMs, todas elas vão receber a mesma programação de eventos de manutenção.

Quando um evento de host ocorre, o GKE encerra o nó e os pods dele. Se os pods forem implantados como parte de uma carga de trabalho maior, como um job ou implantação, o GKE reinicia os pods no nó afetado.

Você ou os frameworks que usa precisam lidar com a configuração da carga de trabalho para reagir adequadamente a eventos de manutenção. Por exemplo, você pode salvar o estado do job de treinamento de IA para reduzir a perda de dados.

Para gerenciar a interrupção nas cargas de trabalho de IA/ML, faça o seguinte:

Monitorar interrupções de nós

A métrica do sistema do GKE a seguir informa a contagem de interrupções de um nó do GKE desde a última amostra. A métrica é amostrada a cada 60 segundos:

  • kubernetes.io/node/interruption_count

Os campos interruption_type (como TerminationEvent, MaintenanceEvent ou PreemptionEvent) e interruption_reason (como HostError, Eviction ou AutoRepair) podem ajudar a explicar por que um nó foi interrompido.

Para conferir um detalhamento das interrupções e das causas nos nós da TPU nos clusters do seu projeto, use a seguinte consulta do PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Para ver apenas os eventos de manutenção do host, atualize a consulta para filtrar o valor HW/SW Maintenance de interruption_reason. Use a seguinte consulta em PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Para ver a contagem de interrupções agregada por pool de nós, use a seguinte consulta do PromQL:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Monitorar notificações de manutenção

O Compute Engine emite notificações quando os nós e as VMs subjacentes são programados para eventos de host e quando esses eventos são ativados. As notificações incluem informações sobre o horário de início planejado, o tipo de evento e outros detalhes.

Na versão 1.31.1-gke.2008000 e mais recente do GKE, é possível monitorar os próximos eventos de manutenção, incluindo os descritos nesta seção.

A manutenção futura está programada, mas não ativa

Antes de uma VM com GPUs ou TPUs anexadas ter um evento de manutenção programado, o Compute Engine envia notificações para todas as VMs. Essas notificações informam o início da janela de manutenção. Quando uma manutenção futura é programada pela VM, mas não está ativa, o GKE adiciona scheduled-maintenance-time ao rótulo do nó.

Para consultar essas notificações no nível do nó, execute o seguinte comando:

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

O resultado será assim:

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

A coluna SCHEDULED-MAINTENANCE-TIME representa segundos, que são mostrados no formato de tempo de época Unix.

Para consultar essas notificações no nível dos metadados do nó, verifique se há notificações de eventos de manutenção nas instâncias.

Para famílias de máquinas otimizadas para aceleradores que oferecem suporte à manutenção avançada, é possível acessar o endpoint upcoming-maintenance, que fornece informações sobre eventos de manutenção programados e iniciados.

Minimizar o impacto da interrupção

O Compute Engine envia notificações sobre os próximos eventos de manutenção e programa uma janela de manutenção. Entre o horário da notificação e o horário de início da janela de manutenção, você pode:

  • Iniciar manualmente um evento de manutenção do host.
  • Deixe o Compute Engine iniciar o evento de manutenção na programação.

Iniciar manualmente um evento de manutenção do host

Quando o Compute Engine emite uma notificação sobre um evento de manutenção programado, é possível iniciar a manutenção manualmente em um horário que esteja alinhado com sua programação operacional, por exemplo, durante períodos de atividade reduzida.

Em um nó no pool de nós, defina o rótulo do nó cloud.google.com/perform-maintenance como true. Exemplo:

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

Se você iniciar um evento de manutenção, o GKE vai executar as seguintes operações:

  1. Adiciona um taint ao nó.
  2. Remove pods sem problemas.
  3. Solicita ao Compute Engine que inicie o evento de manutenção imediatamente, em vez de aguardar o horário programado.

O Compute Engine inicia o evento de manutenção conforme programado

Se você não iniciar um evento de manutenção do host, o Compute Engine vai iniciar o evento de manutenção programada por conta própria. A partir da versão 1.33 do GKE, o nó não é corrompido e os pods não são removidos quando a janela de manutenção começa.

Quando o evento de manutenção começa, um nó pode ser desligado uma ou várias vezes com um curto período de notificação antes do encerramento iminente. Nesses casos, o GKE faz o possível para encerrar as cargas de trabalho e remover os pods normalmente.

Início da manutenção programada

Quando a manutenção programada começa, o Compute Engine atualiza os metadados no diretório http://metadata.google.internal/computeMetadata/v1/instance/attributes/. O Compute Engine atualiza os rótulos de metadados da seguinte maneira:

  • Define maintenance-event como TERMINATE_ON_HOST_MAINTENANCE.
  • Em upcoming-maintenance, define maintenance_status como ONGOING.

O GKE processa um evento de manutenção programada do host, dependendo se você o aciona manualmente ou permite que o GKE prossiga automaticamente.

Configure o GKE para encerrar as cargas de trabalho normalmente

Nesta seção, você configura o GKE para gerenciar o ciclo de vida do seu aplicativo e minimizar a interrupção da carga de trabalho. Se você não configurar uma período de carência, o período de carência é de 30 segundos por padrão.

O GKE se esforça para encerrar esses pods da melhor maneira possível e executar a ação de encerramento definida por você, por exemplo, salvando um estado de treinamento. O GKE envia um sinal SIGTERM para os pods no início do período de carência. Se os pods não forem encerrados até o final do período de carência, o GKE envia um sinal SIGKILL de acompanhamento para os processos que ainda estão em execução contêiner no pod.

Para configurar o período de encerramento normal, defina o período de carência de encerramento (segundos) no campo spec.terminationGracePeriodSeconds do manifesto do pod. Por exemplo, para receber um tempo de notificação de 10 minutos, defina o campo spec.terminationGracePeriodSeconds no manifesto do pod como 600 segundos, da seguinte maneira:

    spec:
      terminationGracePeriodSeconds: 600

Recomendamos que você defina um período de carência de rescisão longo o suficiente para que todas as tarefas em andamento sejam concluídas dentro do período de notificação. Se a carga de trabalho usar um framework de ML, como MaxText, Pax ou JAX com o Orbax, as cargas de trabalho vão poder capturar o sinal de desligamento SIGTERM e iniciar um processo de checkpoint. Para saber mais, consulte Checkpoint automático da TPU.

Processo de encerramento sem dificuldades

Quando um evento de manutenção iniciado manualmente começa, o Compute Engine sinaliza o desligamento iminente da máquina atualizando a chave de metadados maintenance-event. O GKE inicia o encerramento suave.

O fluxo de trabalho a seguir mostra como o GKE executa o encerramento otimizado quando há um desligamento iminente do nó:

  1. Em 60 segundos, ocorre o seguinte:
    1. Os componentes do sistema aplicam o rótulo de nó cloud.google.com/active-node-maintenance definido como ONGOING para indicar que as cargas de trabalho estão sendo interrompidas.
    2. O GKE aplica o taint do nó para evitar que novos pods sejam programados nele. O taint tem a chave cloud.google.com/impending-node-termination:NoSchedule. Recomendamos que você não modifique as cargas de trabalho para tolerar esse taint devido ao encerramento conhecido que ocorre.
  2. O componente "maintenance-handler" começa a remover pods, primeiro os de carga de trabalho e depois os do sistema (por exemplo, kube-system).
  3. O GKE envia um sinal de encerramento SIGTERM para os pods de carga de trabalho que estão em execução no nó para alertá-los sobre um encerramento iminente. Os pods podem usar esse alerta para concluir quaisquer tarefas em andamento. O GKE faz o possível para encerrar esses pods normalmente.
  4. Depois que a remoção termina, o GKE atualiza o valor do rótulo cloud.google.com/active-node-maintenance para terminating, indicando que o nó está pronto para ser encerrado.

Em seguida, o nó é encerrado e um substituto é alocado. O GKE limpa os rótulos e as contaminações quando o processo é concluído. Para aumentar a janela de encerramento para suas cargas de trabalho usando GPUs ou TPUs, conclua as etapas na seção Iniciar manualmente um evento de manutenção do host.

Monitorar o progresso de uma finalização suave ativa

É possível filtrar os registros do GKE pelos seguintes eventos de encerramento normal:

  • Quando a VM detecta uma interrupção devido a um encerramento de nó iminente, como um evento de manutenção do host do Compute Engine, o GKE define o cloud.google.com/active-node-maintenance como ONGOING quando as cargas de trabalho estão sendo interrompidas e como terminating quando as cargas de trabalho são concluídas e o nó está pronto para ser encerrado.
  • Ao restringir a programação de novas cargas de trabalho, o GKE aplica o taint cloud.google.com/impending-node-termination:NoSchedule.

Minimizar a interrupção das cargas de trabalho em execução com manutenção oportunista

É possível minimizar a interrupção das cargas de trabalho em execução acionando automaticamente a manutenção quando o GKE detecta que os nós com GPUs ou TPUs estão inativos. Para ativar esse recurso, crie um novo pool de nós. Não é possível ativar a manutenção oportunista em um pool de nós atual.

Criar um pool de nós com manutenção oportunista

O comando a seguir demonstra como criar um pool de nós com a manutenção oportunista ativada:

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

Substitua os seguintes valores:

  • NODE_POOL_NAME: o nome do pool de nós do GKE.
  • CLUSTER_NAME : o nome do cluster do GKE.
  • NODE_IDLE_TIME : o período em que um nó pode ficar inativo (ou seja, sem cargas de trabalho que consomem aceleradores em execução) antes que a manutenção seja acionada. O valor representa a duração em segundos, com até nove dígitos fracionários, e termina com o caractere s. Por exemplo: 80000s.
  • MIN_NODES : o número mínimo de nós que precisam estar disponíveis em um pool de nós. Essa opção bloqueia a manutenção se ela fizer com que o número de nós em execução fique abaixo desse valor. Por exemplo: 10.
  • WINDOW : a janela de tempo, em segundos, em que a manutenção oportunista pode ser executada. O valor termina com um caractere s. Por exemplo, um valor de 14 dias, ou 1209600s, implica que a manutenção oportunista só pode ser executada nas duas semanas antes da data programada. Um valor de 28 dias, ou 2419200s, permite que a manutenção oportunista seja executada a qualquer momento durante o período programado. Essa janela para manutenção do host do Compute Engine é diferente das janelas de manutenção do GKE, que determinam quando a manutenção do cluster do GKE pode ocorrer e são configuradas separadamente.

Exemplo de configuração para manutenção oportunista

Veja o exemplo a seguir. Você tem um pool de nós com quatro nós, e a configuração de manutenção oportunista está definida como --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. Nesse cenário, acontece o seguinte:

  • node1 tem uma carga de trabalho de GPU em execução. Esse nó não está ocioso, então é ignorado.
  • node2 ficou inativo por 60 segundos. Este nó não ficou inativo por tempo suficiente e, por isso, foi ignorado.
  • node3 está inativo há 600 segundos. Esse nó atende ao requisito de inatividade.
  • node4 está inativo há 600 segundos. Esse nó atende ao requisito de inatividade.

node3 e node4 atendem ao requisito de inatividade. No entanto, apenas um desses nós vai acionar a manutenção oportunista porque o valor da opção min-nodes está definido como 3.

Verificar a configuração e o estado dos nós com manutenção oportunista

Para verificar se a manutenção oportunista está configurada para um nó, execute o seguinte comando:

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

Substitua NODE_NAME pelo nome do nó que você quer verificar.

Verifique se um nó configurado com manutenção oportunista está passando por manutenção:

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

Se o nó for acionado por uma manutenção oportunista, a anotação maintenance-state vai mostrar opportunistic-triggered como true.

Limitações

Conheça as seguintes limitações da manutenção oportunista:

  • Esse recurso só pode ser usado com pools de nós de GPU e TPU.
  • A manutenção oportunista não é compatível com o escalonamento automático de clusters porque o escalonador automático de clusters já reduz verticalmente os nós ociosos.
  • Para pools de nós de TPU de vários hosts, o valor da configuração min-nodes-per-pool precisa ser 0 porque esses pools são atômicos.
  • A versão mínima compatível do GKE é 1.33.3-gke.1118000.
  • Somente a manutenção planejada que inclui a notificação can_reschedule=TRUE é compatível.
  • Para desativar esse recurso, recrie o pool de nós sem as flags correspondentes. Ou você pode desativar manualmente o recurso em nós específicos com cloud.google.com/opportunistic-disable=true.
  • Em casos raros, a manutenção pode levar mais tempo para ser concluída em um nó. Os clientes que usam esse recurso podem ter menos nós disponíveis, até o valor da configuração min-nodes-per-pool, por um período.

A seguir