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

Esta página ajuda a entender, configurar e monitorar eventos de interrupção que podem ocorrer em nós do Google Kubernetes Engine (GKE) que executam cargas de trabalho de inteligência artificial (IA) ou machine learning (ML), incluindo:

Durante o ciclo de vida de um cluster do GKE de longa duração, as interrupções nas cargas de trabalho devidos a eventos de manutenção automática emitidos pelo Google Cloud para os recursos do Compute Engine subjacentes a infraestrutura do GKE. 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

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. As VMs do Compute Engine passam periodicamente eventos de host causados por uma variedade de como atualizações de hardware ou software, manutenção e de segurança. Os eventos do host são emitidos para o ambiente infraestrutura e ignorar Políticas e exclusões de manutenção do GKE.

Com algumas exceções, a maioria das VMs do Compute Engine tem política de manutenção do host definida como migração em tempo real, ou seja, há pouca ou nenhuma interrupção das cargas de trabalho em execução. No entanto, algumas classes de VMs não aceitam migração em tempo real, incluindo VMs com anexos GPUs e TPUs em que seus recursos de IA/ML e as cargas de trabalho sejam executadas. Além disso, o GKE também pode reiniciar TPUs sob demanda usando a preempção, que permite que o GKE provisione TPUs maiores, devido até a desfragmentação motivos.

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 uma implantação, O GKE reinicia os pods no nó afetado. Você decide os frameworks que você usa para lidar com as cargas de trabalho ou jobs para reagir de maneira apropriada à interrupção. Por exemplo, você pode salvar o estado do job de treinamento de IA para reduzir a perda de dados.

Processo de encerramento sem dificuldades

O fluxo de trabalho a seguir mostra como o GKE executa o nó otimizado após a emissão de uma interrupção pelo Compute Engine:

  1. O Compute Engine emite um valor atualizado de TERMINATE_ON_HOST_MAINTENANCE para a chave metadados da VM maintenance-event.

  2. Em 60 segundos, ocorre o seguinte:

    1. Os componentes do sistema aplicam o novo rótulo de nó a seguir definido como true para indicar que a manutenção está em andamento: cloud.google.com/active-node-maintenance

    2. O GKE aplica o taint do nó para evitar que novos pods sejam programados no nó: cloud.google.com/impending-node-termination:NoSchedule. Recomendamos que você modifique as cargas de trabalho para tolerar esse taint devido a o encerramento conhecido que ocorre.

  3. O componente maintenance-handler começa a remover pods em ordem de carga de trabalho Primeiro, os pods e depois os do sistema (por exemplo, kube-system).

  4. O GKE envia um sinal de encerramento SIGTERM para alertar a carga de trabalho em execução Pods no nó de 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.

As notificações maintenance-event ocorrem quando a VM do Compute Engine subjacente de um nó do GKE passa por um evento de host que leva ao encerramento do nó. Quando isso ocorre, o Compute Engine atualiza a chave de metadados maintenance-event. A janela de notificação de manutenção avançada antes do encerramento do nó é da seguinte forma:

  • GPU: 60 minutos.
  • TPU: 5 minutos.

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, concluir as etapas na seção Configure o GKE para encerrar as cargas de trabalho normalmente.

Lidar com a interrupção da carga de trabalho no GKE

Para gerenciar eventos de encerramento do GKE e reduzir interrupções nos workloads dos clusters, o GKE monitora essas notificações e faz o seguinte:

  • O GKE notifica as cargas de trabalho com antecedência de um encerramento iminente: quando um nó do GKE precisa ser interrompido para um evento de manutenção do host, o GKE envia um sinal SIGTERM para os pods em execução no nó no início do período de aviso avançado. Os sinais do SO, como SIGTERM, podem ser processados de forma nativa pela maioria das bibliotecas padrão, por exemplo, Python e Go. Os frameworks que podem capturar SIGTERM incluem MaxText, Pax e JAX com Orbax.
  • O GKE encerra normalmente suas cargas de trabalho: é possível Configure o GKE para encerrar normalmente suas cargas de trabalho com um pod período de carência de encerramento. Os pods podem reagir ao sinal SIGTERM para concluir tarefas em andamento e executar qualquer ação de encerramento definida, como salvar um estado de treinamento. Durante o encerramento sem dificuldades, o GKE tenta ao máximo encerrar os pods normalmente e executar processos de limpeza ou de encerramento que você define em seu aplicativo, por exemplo, armazenando dados de carga de trabalho para reduzir perda de dados ou salvar um estado de treinamento.

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 de cargas de trabalho, siga as e instruções para GPUs ou TPUs.

GPU

No manifesto do pod, defina o campo spec.terminationGracePeriodSeconds como um máximo de 3.600 segundos (60 minutos). Por exemplo, para receber um tempo de notificação de 10 minutos, no manifesto do pod, defina o campo spec.terminationGracePeriodSeconds 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.

TPU

Para alocar o tempo máximo para executar seus processos de limpeza, defina o spec.terminationGracePeriodSeconds para 300 segundos (cinco minutos) na sua manifesto do pod. Por exemplo:

    spec:
      terminationGracePeriodSeconds: 300

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 SIGTERM e iniciar um processo de checkpoint. Para saber mais, consulte Checkpoint automático da TPU.

Monitorar o progresso de uma finalização suave ativa

Nos clusters do GKE com o plano de controle em execução na versão 1.29.1-gke.1425000 ou posterior, o GKE implanta um componente de nó chamado gpu-maintenance-handler. Esse componente é executado em todos os nós de GPU e TPU, com um componente do plano de controle correspondente. Esses componentes fazem o seguinte:

  • Processar eventos de encerramento normal.
  • Responda a eventos de interrupção iminentes na VM do GKE: encaminhar um sinal SIGTERM para as cargas de trabalho em execução de um nó. Essas interrupções são registradas como solicitações de remoção de pod e exclusão.

O GKE adiciona um rótulo e um taint aos nós com status de encerramento iminente. O GKE monitora notificações de eventos do host, manutenção, usando o componente do sistema maintenance-handler em execução em cada Nó de GPU e TPU.

O GKE registra os seguintes eventos de encerramento suave:

Quando o GKE termina a finalização suave, os rótulos e taints são limpos.

Para monitorar o status de uma terminação otimizada ativa causada por uma interrupção, é possível ver os registros gpu-maintenance-handler usando o console ou a CLI do Google Cloud.

gcloud

  1. Localize os nomes dos nós e pods que estão executando instâncias do gpu-maintenance-handler executando o seguinte comando:

    kubectl get pods -l name=maintenance-handler -A -o wide

    Cada linha da saída inclui o nome do nó, o nome do pod e status.

  2. Verificar os registros:

    kubectl logs -n=kube-system MAINTENANCE_HANDLER_POD_NAME

    Substitua MAINTENANCE_HANDLER_POD_NAME pelo nome da instância do gerenciador.

    Se um evento de manutenção é detectado, o pod registra uma mensagem, aplica rótulos e as remoções começam.

  3. Verifique os rótulos e os taints do nó:

    kubectl describe node NODE_NAME

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

    A saída mostra a lista de rótulos e contaminações de nó a serem observados.

Console

  1. Acesse a página do Explorador de registros no console do Google Cloud:

    Acessar a ferramenta Análise de registros

  2. No campo Consulta, insira a seguinte consulta:

    resource.type="k8s_container"
resource.labels.namespace_name="kube-system"
resource.labels.container_name="maintenance-handler"
resource.labels.cluster_name="CLUSTER_NAME"

    Substitua CLUSTER_NAME: o nome do cluster.

A seguir