Faça a gestão da interrupção de nós do GKE para GPUs e TPUs

Durante o ciclo de vida de um cluster do GKE de execução prolongada, ocorrem interrupções periódicas nas cargas de trabalho devido a interrupções da infraestrutura queTrusted Cloud by S3NS emitem. Estes eventos automáticos podem ocorrer para responder a decisões de agendamento (eventos de preemptção), atualizações do plano de controlo ou de nós, que incluem atualizações automáticas de nós do GKE (eventos de manutenção) ou correção de problemas detetados (eventos de encerramento).

Esta página ajuda a compreender o que significa a interrupção de nós no GKE, a monitorizar as notificações de manutenção e a minimizar o impacto da interrupção nos nós do GKE com GPUs e TPUs anexadas.

Este documento destina-se a administradores e operadores da plataforma que gerem o ciclo de vida da infraestrutura tecnológica subjacente. Para saber mais sobre as funções comuns e exemplos de tarefas que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Trusted Cloud by S3NS

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

Os seus clusters do GKE gerem o ciclo de vida dos nós do GKE. Estes nós são aprovisionados em VMs do Compute Engine, que sofrem periodicamente as seguintes interrupções:

  • Remediação de problemas detetados (TerminationEvent): estes eventos ocorrem porque o Trusted Cloud by S3NS deteta um problema e interrompe a infraestrutura do cluster. Os eventos TerminationEvent não suportam o encerramento controlado. Os eventos TerminationEvent são acionados pelos seguintes problemas:

    • A reparação automática ocorre quando o GKE repara um nó após repetidas verificações de estado falhadas.
    • 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 atualização (MaintenanceEvent): estes eventos ocorrem quando o Trusted Cloud by S3NS tem de 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 o GKE e o utilizador gerem as alterações durante o ciclo de vida de um cluster, consulte Tipos de alterações.

  • Resposta a decisões de agendamento (PreemptionEvent): ocorrem quando o Trusted Cloud by S3NS precisa de antecipar VMs para disponibilizar capacidade para recursos de prioridade mais elevada. Os eventos PreemptionEvent podem ser qualquer um dos seguintes:

    • A remoção ocorre quando a infraestrutura preemptível ou Spot é removida para acomodar uma VM de prioridade mais elevada.
    • Desfragmentação: ocorre quando o GKE antecipa uma fatia de TPU mais pequena para acomodar uma fatia de TPU maior. A desfragmentação só ocorre em fatias de TPU.

Durante o ciclo de vida de um cluster do GKE de execução prolongada, os nós podem sofrer interrupções periódicas nas cargas de trabalho de preparação ou publicação. Quando estas interrupções afetam os seus nós do GKE que executam cargas de trabalho de IA/ML, o GKE tem de reiniciar as cargas de trabalho em execução e o nó subjacente.

Por que motivo as GPUs e as TPUs requerem gestão de interrupções

A maioria das VMs do Compute Engine, com algumas exceções, tem a política de manutenção do anfitrião definida como migração em direto, o que significa que as cargas de trabalho em execução normalmente não sofrem interrupções ou sofrem interrupções mínimas. No entanto, determinadas classes de VMs não suportam a migração em direto, incluindo VMs com GPUs e TPUs anexadas. Quando ocorre um evento do anfitrião na VM numa fatia da TPU, toda a fatia é interrompida e, em seguida, reagendada, porque todos os eventos de manutenção são coordenados ao nível da fatia. Assim, se criar uma fatia de TPU com centenas de VMs, todas essas VMs vão receber o mesmo agendamento de eventos de manutenção.

Quando ocorre um evento de anfitrião, o GKE termina o nó e os respetivos pods. Se os pods forem implementados como parte de uma carga de trabalho maior, como um Job ou uma Deployment, o GKE reinicia os pods no nó afetado.

É da sua responsabilidade, ou das frameworks que usa, processar a configuração da carga de trabalho para reagir adequadamente aos eventos de manutenção. Por exemplo, pode guardar o estado da sua tarefa de preparação de IA para reduzir a perda de dados.

Para gerir a interrupção em cargas de trabalho de IA/ML, pode fazer o seguinte:

Monitorize interrupções de nós

A seguinte métrica do sistema do GKE comunica 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 indicar o motivo pelo qual um nó foi interrompido.

Para obter uma discriminação das interrupções e das respetivas causas nos nós de TPU nos clusters no seu projeto, use a seguinte consulta 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 anfitrião, atualize a consulta para filtrar o valor HW/SW Maintenance para o interruption_reason. Use a seguinte consulta 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 conjunto de nós, use a seguinte consulta 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}]))

Monitorize as notificações de manutenção

O Compute Engine envia notificações quando os nós e as respetivas VMs subjacentes estão agendados para eventos do anfitrião disruptivos e quando estes eventos ficam ativos. As notificações incluem informações sobre a hora de início planeada, o tipo de evento e outros detalhes.

Na versão 1.31.1-gke.2008000 e posteriores do GKE, pode monitorizar eventos de manutenção futuros, incluindo os eventos descritos nesta secção.

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

Antes de uma VM com GPUs ou TPUs anexadas ter um evento de manutenção agendado, o Compute Engine envia notificações para todas as respetivas VMs. Estas notificações comunicam o início do período de manutenção. Quando uma manutenção futura é agendada pela VM, mas não está ativa, o GKE adiciona scheduled-maintenance-time à etiqueta do nó.

Para consultar estas notificações ao 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 é semelhante ao seguinte:

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

A coluna SCHEDULED-MAINTENANCE-TIME representa os segundos, que são apresentados no formato de tempo epoch Unix.

Para consultar estas notificações ao nível dos metadados do nó, verifique se existem notificações de eventos de manutenção nas instâncias.

Para famílias de máquinas otimizadas para aceleradores que suportam a manutenção avançada, pode aceder ao ponto final upcoming-maintenance que fornece informações sobre eventos de manutenção agendados e iniciados.

Minimize o impacto das interrupções

O Compute Engine envia notificações sobre eventos de manutenção futuros e agenda um período de manutenção. Entre a hora da notificação e a hora de início do período de manutenção, pode optar por:

  • Inicie manualmente um evento de manutenção do anfitrião.
  • Permita que o Compute Engine inicie o evento de manutenção dentro do horário.

Inicie manualmente um evento de manutenção do anfitrião

Quando o Compute Engine emite uma notificação sobre um evento de manutenção agendado, pode iniciar manualmente a manutenção a uma hora que se alinhe com o seu horário operacional, por exemplo, durante períodos de atividade reduzida.

Num nó no node pool, defina a etiqueta do nó cloud.google.com/perform-maintenance como true. Por exemplo:

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

Se iniciar um evento de manutenção, o GKE executa as seguintes operações:

  1. Contamina o nó.
  2. Remove os pods de forma elegante.
  3. Pede ao Compute Engine para iniciar o evento de manutenção imediatamente, em vez de aguardar pela hora agendada.

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

Se não iniciar um evento de manutenção do anfitrião, o Compute Engine inicia o evento de manutenção agendado por si só. A partir da versão 1.33 do GKE, o nó não é contaminado e os pods não são removidos quando a janela de manutenção começa.

Quando o evento de manutenção é iniciado, um nó pode ser encerrado uma ou várias vezes com um curto período de notificação antes da respetiva terminação iminente. Nestes casos, o GKE faz o seu melhor para terminar as cargas de trabalho e expulsar os pods de forma adequada.

Início da manutenção agendada

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 as etiquetas de metadados da seguinte forma:

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

O GKE processa um evento de manutenção do anfitrião agendado, consoante o acione manualmente ou deixe o GKE prosseguir automaticamente.

Configure o GKE para terminar as suas cargas de trabalho de forma elegante

Nesta secção, configura o GKE para gerir o ciclo de vida da sua aplicação e minimizar a interrupção da sua carga de trabalho. Se não configurar um período de tolerância, a predefinição é de 30 segundos.

O GKE faz o seu melhor para terminar estes pods de forma elegante e executar a ação de terminação que definir, por exemplo, guardar um estado de preparação. O GKE envia um sinal SIGTERM aos pods no início do período de tolerância. Se os pods não terminarem até ao final do período de tolerância, o GKE envia um sinal SIGKILL de seguimento a todos os processos que ainda estejam em execução em qualquer contentor no pod.

Para configurar o período de encerramento gradual, defina o período de tolerância de encerramento (segundos) no campo spec.terminationGracePeriodSeconds do manifesto do pod. Por exemplo, para receber uma notificação 10 minutos antes, defina o campo spec.terminationGracePeriodSeconds no manifesto do pod para 600 segundos, da seguinte forma:

    spec:
      terminationGracePeriodSeconds: 600

Recomendamos que defina um período de tolerância de encerramento suficientemente longo para que todas as tarefas em curso terminem dentro do prazo de notificação. Se a sua carga de trabalho usar uma framework de ML, como MaxText, Pax ou JAX com o Orbax, as cargas de trabalho podem capturar o sinal SIGTERM de encerramento e iniciar um processo de criação de pontos de verificação. Para saber mais, consulte o artigo TPU Autocheckpoint.

Processo de rescisão controlada

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

O fluxo de trabalho seguinte mostra como o GKE executa a terminação graciosa do nó quando existe um encerramento do nó iminente:

  1. No prazo de 60 segundos, ocorre o seguinte:
    1. Os componentes do sistema aplicam a etiqueta do nó cloud.google.com/active-node-maintenance definida como ONGOING para indicar que as cargas de trabalho estão a ser paradas.
    2. O GKE aplica a mancha do nó para impedir que novos pods sejam agendados no nó. A restrição tem a chave cloud.google.com/impending-node-termination:NoSchedule. Recomendamos que não modifique as suas cargas de trabalho para tolerar esta contaminação devido à terminação conhecida que ocorre.
  2. O componente maintenance-handler começa a despejar os pods despejando primeiro os pods de carga de trabalho e, em seguida, os pods do sistema (por exemplo, kube-system).
  3. O GKE envia um sinal de encerramento SIGTERM aos pods de carga de trabalho que estão a ser executados no nó para os alertar para um encerramento iminente. Os pods podem usar este alerta para concluir quaisquer tarefas em curso. O GKE faz o seu melhor para terminar estes pods de forma elegante.
  4. Após a conclusão da remoção, o GKE atualiza o valor da etiqueta cloud.google.com/active-node-maintenance para terminating para indicar que o nó está pronto para ser terminado.

Posteriormente, ocorre a rescisão do nó e é atribuído um nó de substituição. O GKE limpa as etiquetas e as restrições quando o processo termina. Para aumentar o período de encerramento das suas cargas de trabalho com GPUs ou TPUs, conclua os passos na secção Inicie manualmente um evento de manutenção do anfitrião.

Monitorize o progresso de um encerramento gradual ativo

Pode filtrar os registos do GKE pelos seguintes eventos de encerramento elegante:

  • Quando a VM deteta uma interrupção devido a um encerramento de nó iminente, como um evento de manutenção do anfitrião do Compute Engine, o GKE define o valor de cloud.google.com/active-node-maintenance como ONGOING quando as cargas de trabalho estão a ser paradas e como terminating quando as cargas de trabalho terminam e o nó está pronto para ser terminado.
  • Quando restringe a agendamento de novas cargas de trabalho, o GKE aplica a restrição.cloud.google.com/impending-node-termination:NoSchedule

Minimize a interrupção das cargas de trabalho em execução com a manutenção oportuna

Pode minimizar a interrupção das cargas de trabalho em execução acionando automaticamente a manutenção quando o GKE deteta que os nós com GPUs ou TPUs estão inativos. Para ativar esta funcionalidade, crie um novo conjunto de nós. Não pode ativar a manutenção oportunista num conjunto de nós existente.

Crie um novo node pool com manutenção oportuna

O comando seguinte demonstra como pode criar um conjunto de nós com a manutenção oportuna 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 seu node pool do GKE.
  • CLUSTER_NAME : o nome do seu cluster do GKE.
  • NODE_IDLE_TIME : a quantidade de tempo que um nó pode permanecer inativo (ou seja, não estão a ser executadas cargas de trabalho que consomem aceleradores) antes de a manutenção ser acionada. O valor representa a duração em segundos, com até nove dígitos fracionários, e termina com o caráter s, por exemplo: 80000s.
  • MIN_NODES : o número mínimo de nós que têm de estar disponíveis num node pool. Esta opção bloqueia a manutenção se fizer com que o número de nós em execução fique abaixo deste valor, por exemplo: 10.
  • WINDOW : o período, em segundos, durante o qual a manutenção oportuna pode ser executada. O valor termina com um caráter s. Por exemplo, um valor de 14 dias, ou 1209600s, implica que a manutenção oportuna só pode ser executada nas duas semanas anteriores à data de manutenção agendada. Um valor de 28 dias, ou 2419200s, permite que a manutenção oportuna seja executada em qualquer altura durante o período de manutenção agendado. Este período para a manutenção do anfitrião do Compute Engine é diferente dos períodos de manutenção do GKE, que determinam quando a manutenção do cluster do GKE pode ocorrer e são configurados separadamente.

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

Considere o seguinte exemplo. Tem um node pool com quatro nós e a configuração de manutenção oportuna está definida como --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. Neste cenário, ocorre o seguinte:

  • node1 tem uma carga de trabalho da GPU em execução. Este nó não está inativo, pelo que é ignorado.
  • node2 está inativo há 60 segundos. Este nó não está inativo há tempo suficiente, pelo que é ignorado.
  • node3 está inativo há 600 segundos. Este nó cumpre o requisito de inatividade.
  • node4 está inativo há 600 segundos. Este nó cumpre o requisito de inatividade.

Tanto node3 como node4 cumprem o requisito de inatividade. No entanto, apenas um destes nós aciona a manutenção oportuna porque o valor da opção min-nodes está definido como 3.

Verifique a configuração e o estado dos nós com manutenção oportuna

Verifique se a manutenção oportunista está configurada para um nó executando o seguinte comando:

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

Substitua NODE_NAME pelo nome do nó que quer verificar.

Verifique se um nó configurado com manutenção oportuna está atualmente em manutenção:

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

Se o nó for acionado pela manutenção oportuna, a anotação maintenance-state mostra opportunistic-triggered como true.

Limitações

Tenha em atenção as seguintes limitações da manutenção oportuna:

  • Esta funcionalidade só pode ser usada com pools de nós de GPU e TPU.
  • A manutenção oportuna não é compatível com o redimensionamento automático de clusters porque o redimensionador automático de clusters já reduz a escala dos nós inativos.
  • Para pools de nós da TPU com vários anfitriões, o valor da definição min-nodes-per-pool deve ser 0, uma vez que estes pools de nós são atómicos.
  • A versão mínima suportada do GKE é 1.33.3-gke.1118000.
  • Apenas é suportada a manutenção planeada que inclua a can_reschedule=TRUE notificação.
  • Para desativar esta funcionalidade, tem de recriar o conjunto de nós sem as respetivas flags. Em alternativa, pode desativar manualmente a funcionalidade em nós específicos com cloud.google.com/opportunistic-disable=true.
  • Em casos raros, a manutenção pode demorar mais tempo a ser concluída num nó. Os clientes que usam esta funcionalidade podem ter menos nós disponíveis, até ao valor da definição min-nodes-per-pool, durante um determinado período.

O que se segue?