Sobre snapshots de pods do GKE

Os snapshots de pods do Google Kubernetes Engine (GKE) ajudam a melhorar a latência de inicialização da carga de trabalho restaurando snapshots de pods em execução. Um snapshot de pod salva todo o estado do pod, incluindo alterações de memória e do sistema de arquivos. Ao criar novas réplicas, elas são restauradas do snapshot, permitindo que a carga de trabalho seja retomada em vez de começar de um novo estado.

Este documento oferece uma visão geral conceitual dos snapshots de pods do GKE. Para saber como ativar e usar esse recurso, consulte Restaurar de um snapshot de pod.

Quando usar snapshots de pods

Use snapshots de pods para cargas de trabalho que têm longos tempos de inicialização, por exemplo, cargas de trabalho de inferência de IA que carregam modelos grandes na memória da CPU ou da GPU, ou aplicativos grandes que carregam muitas bibliotecas e dependências. Cargas de trabalho que já têm tempos de inicialização rápidos geralmente não se beneficiam de snapshots de pods.

Como os snapshots de pods funcionam

Os snapshots de pods do GKE armazenam uma cópia exata do estado do processo de um pod em um momento específico. Quando novas réplicas são criadas, em vez de inicializar o pod de um estado novo, ele é restaurado de um snapshot, retomando a execução do ponto em que o snapshot foi feito.

Para usar snapshots de pods, crie definições de recursos personalizados (CRDs, na sigla em inglês) do Kubernetes para configurar o comportamento do snapshot de forma declarativa. Um agente em execução em cada nó do GKE gerencia o ciclo de vida do snapshot. Com base nas políticas definidas, o agente determina quando criar novos snapshots e quando usar os snapshots atuais para restaurar novos pods. Um controlador em execução no plano de controle do GKE limpa snapshots obsoletos e resolve problemas. O Cloud Storage armazena os snapshots de pods.

Conteúdo do snapshot

A tabela a seguir descreve o que está e o que não está incluído em um snapshot de pod:

Categoria Incluído em um snapshot Não incluído em um snapshot
Estado do aplicativo Todo o estado do aplicativo: todos os descritores de arquivos abertos, linhas de execução, registros de CPU e memória.
Sistemas de arquivos O sistema de arquivos raiz do contêiner (rootfs), volumes EmptyDir e montagens tmpfs. Qualquer coisa não coberta pela coluna anterior. Principalmente, volumes permanentes não são verificados.
Rede Conexões de loopback, soquetes de escuta e soquetes de domínio Unix. Conexões externas não são restauradas (elas são encerradas na restauração). Regras adicionadas pelo usuário, como iptables ou nftables, e rotas não são restauradas.

Definições de recursos personalizados

Os snapshots de pods são configurados de forma declarativa com os seguintes CRDs:

  • PodSnapshotStorageConfig: especifica o local de armazenamento dos snapshots. Apenas buckets do Cloud Storage são aceitos.
  • PodSnapshotPolicy: define quais pods serão verificados com base nos seletores de rótulos do Kubernetes. Esse recurso contém a maioria das opções de configuração do recurso, incluindo como os snapshots são acionados e as políticas de retenção.
  • PodSnapshotManualTrigger: (opcional) se você não estiver usando um acionador de carga de trabalho, defina um acionador manual para criar um snapshot de um pod específico.

Acionadores de snapshot

É possível acionar um snapshot de pod das seguintes maneiras:

  • Acionador de carga de trabalho: o aplicativo dentro do pod sinaliza ao agente do GKE que está pronto para um snapshot. Esse tipo de acionador é executado uma vez em um ciclo de carga de trabalho, por exemplo, em um estado pronto da carga de trabalho. Essa abordagem é melhor para melhorar a latência de inicialização de cargas de trabalho com escalonamento horizontal.
  • Acionador manual: é possível acionar um snapshot sob demanda para um pod específico criando um recurso personalizado PodSnapshotManualTrigger. Esse tipo de acionador pode ser executado quantas vezes forem necessárias. Essa abordagem é melhor para situações em que não é possível modificar o aplicativo para sinalizar a prontidão.

Correspondência de snapshots

A correspondência de pods determina se um snapshot de pod é compatível com um pod específico. Essa correspondência é feita criando um hash exclusivo das especificações essenciais de execução do pod, também chamado de especificação de pod destilada. Esse hash é incorporado ao snapshot do pod. Para que um pod posterior seja restaurado desse snapshot de pod, ele precisa gerar um hash idêntico da própria especificação de pod destilada. Esse processo ajuda a garantir que os pods verificados e restaurados sejam idênticos nas configurações de execução.

A destilação simplifica a especificação do pod, mantendo apenas os campos de execução críticos, como image, e removendo campos não essenciais, como nodeName ou nodeSelector. É necessário garantir que os valores desses campos essenciais sejam consistentes entre o pod usado para a verificação e o pod destinado à restauração.

Os campos a seguir do objeto de pod influenciam o hash exclusivo:

  • metadata:
    • annotations: apenas anotações relevantes para o ambiente de execução do gVisor, como anotações que começam com o prefixo dev.gvisor.*.
    • labels: batch.kubernetes.io/job-completion-index
  • spec:
    • volumes: name, volumeSource, hostPath, persistentVolumeClaim, configMap
    • containers:
      • name
      • image
      • command
      • args
      • workingDir
      • ports: name, containerPort, protocol
      • volumeMounts: name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation, subPathExpr
      • volumeDevices: name
      • lifecycle: postStart, preStop
      • terminationMessagePath
      • terminationMessagePolicy
      • securityContext (e todos os subcampos)
      • stdin
      • stdinOnce
      • tty
    • initContainers: os mesmos subcampos que containers.
    • dnsPolicy
    • automountServiceAccountToken
    • hostNetwork
    • hostPID
    • hostIPC
    • shareProcessNamespace
    • securityContext
    • dnsConfig
    • runtimeClassName
    • os
    • hostUsers

Os seguintes critérios adicionais precisam corresponder para serem considerados um snapshot compatível:

  • Hardware: o novo pod precisa ser executado em um nó que tenha a mesma série de máquinas e arquitetura do pod original. A série de máquinas e a arquitetura precisam ser as mesmas. O número de CPUs e a quantidade de memória podem mudar. Os tipos de máquina E2 não são aceitos devido à arquitetura subjacente dinâmica.
  • Controle de versão: a versão do kernel do gVisor e a versão do driver da GPU precisam corresponder.

O GKE gerencia a compatibilidade de snapshots. Se o GKE encontrar um snapshot compatível, ele vai restaurar o novo pod do snapshot. Se não houver um snapshot compatível, o pod será iniciado normalmente.

Prontidão para restauração e carregamento em segundo plano

Quando um pod é restaurado de um snapshot, o kernel do gVisor é restaurado primeiro, o que normalmente leva alguns segundos. Para minimizar a latência de inicialização, o aplicativo é retomado imediatamente após a restauração do kernel. Ele não espera que a memória do aplicativo seja totalmente carregada. A memória do aplicativo é restaurada usando um mecanismo de streaming em segundo plano.

Se o aplicativo tentar acessar uma parte da memória que ainda não foi carregada, ocorrerá uma falha de página. O gVisor intercepta essa falha, pausa a linha de execução do aplicativo e busca imediatamente a página de memória necessária no armazenamento. Essa busca sob demanda tem prioridade sobre o stream em segundo plano.

Devido a esse carregamento em segundo plano, o acesso à memória pode ter uma pequena quantidade de latência nos primeiros segundos após uma restauração, se o aplicativo precisar de memória que ainda não foi transmitida. Essa latência desaparece quando o estado da memória está totalmente sincronizado.

Esse comportamento de carregamento em segundo plano também se aplica ao estado da GPU. Por exemplo, um pod de modelo de linguagem grande (LLM) pode parecer estar no estado Running e responder a verificações de rede, mesmo que a memória da GPU ainda esteja sendo preenchida. O modelo não estará totalmente responsivo para inferência até que o estado da GPU seja totalmente restaurado. Por isso, ao medir a velocidade de restauração, capture quando o servidor de modelo foi iniciado. É possível verificar quando o servidor de modelo é iniciado usando métricas como o tempo até o primeiro token (TTFT, na sigla em inglês) ou probes de prontidão do pod.

Estado da GPU

Os snapshots de pods oferecem suporte à captura do estado das GPUs. Quando você aciona um snapshot para um pod que usa GPUs, a ferramenta cuda-checkpoint da NVIDIA salva o estado da GPU na memória do processo. Isso significa que todos os dados armazenados na GPU, por exemplo, pesos do modelo, estão incluídos no snapshot. Em seguida, o pod é pausado e verificado. Durante a restauração, o processo é invertido.

Como o estado da GPU é gravado na memória do processo, o uso da memória do pod aumenta durante as operações de snapshot e restauração. Considere esse requisito de memória adicional ao definir limites de memória para seus pods.

Considerações sobre pods restaurados

Do ponto de vista da API Kubernetes, um novo pod é criado. Quando o pod é iniciado, se houver um snapshot correspondente, ele será restaurado desse snapshot, incluindo a memória original e o estado do processo. No entanto, alguns aspectos do estado do pod precisam mudar para que ele funcione como uma instância nova e exclusiva.

Considere as seguintes mudanças de estado após uma restauração:

  • Interfaces de rede: o pod restaurado recebe um novo endereço IP. Todas as interfaces e rotas são reconfiguradas. As conexões de rede ativas que existiam no momento do snapshot são fechadas na restauração. Soquetes de escuta, conexões de loopback e conexões de soquete de domínio Unix continuam funcionando.
  • Nome do host: o pod restaurado assume uma nova identidade e recebe um novo nome de host.
  • Tempo real: o tempo real avança para a hora atual.
  • Estado do aplicativo: o estado do aplicativo precisa ser exclusivo para cada pod, como IDs de experimentos ou sementes de números aleatórios, e precisa ser reinicializado após uma restauração.
  • Secrets: as chaves de criptografia e os certificados criados antes da criação do snapshot precisam ser recriados.
  • Variáveis de ambiente: é possível mudar as variáveis de ambiente entre um snapshot e uma restauração. No entanto, como as variáveis de ambiente são armazenadas na memória do aplicativo, o GKE Sandbox não pode encontrá-las e substituí-las de forma confiável. Se a carga de trabalho depender de novas variáveis de ambiente após uma restauração, o pod precisará atualizá-las manualmente. As novas variáveis de ambiente estão disponíveis no arquivo /proc/gvisor/spec_environ. O formato do arquivo é o mesmo que /proc/<pid>/environ.

Multilocação e identidade

Os snapshots de pods exigem vinculações manuais do IAM para que cada ServiceAccount (KSA) do Kubernetes do pod acesse o Cloud Storage. As vinculações manuais do IAM podem levar tempo para serem propagadas, o que pode ser um problema se você precisar fazer snapshots imediatamente após criar um pod.

Para ajudar a resolver atrasos e simplificar o gerenciamento de multilocação, em vez de vincular manualmente o IAM aos KSAs, você pode usar uma conta de serviço de nó do GKE para criar tokens de curta duração sob demanda. Para configurar snapshots de pods com essa abordagem, use o campo tokenSource no objeto PodSnapshotStorageConfig com um dos seguintes valores:

  • podKSA (padrão): vinculação manual do IAM do KSA do pod ao bucket do Cloud Storage.
  • federatedP4SA: use um token específico do caminho criado pela conta de serviço do nó.

Limitações e requisitos

Os snapshots de pods do GKE têm as seguintes limitações:

  • Os pods precisam ser executados no GKE Sandbox porque os snapshots de pods dependem do ambiente de execução de contêiner do gVisor fornecido pelo GKE Sandbox.
  • Os snapshots de pods não oferecem suporte a tipos de máquina E2.
  • O suporte a GPU para snapshots de pods tem os seguintes requisitos e limitações:
    • Pods de GPU única são aceitos em nós de GPU única e de várias GPUs.
    • Pods de várias GPUs só são aceitos em GPUs L4 (tipos de máquina g2-standard-*).
    • O compartilhamento de GPU com a GPU de várias instâncias (MIG) está indisponível.
    • Nas versões 1.35.0-gke.1738000 e anteriores do GKE, um pod em execução em um nó de várias GPUs precisa usar todas as GPUs disponíveis nesse nó. Nas versões 1.35.0-gke.1738000 e mais recentes, os pods podem usar um subconjunto das GPUs em um nó.
    • Os snapshots de pods oferecem suporte aos seguintes tipos de máquina:
      • g2-standard-4 (1 x L4)
      • g2-standard-8 (1 x L4)
      • g2-standard-12 (1 x L4)
      • g2-standard-16 (1 x L4)
      • g2-standard-32 (1 x L4)
      • g2-standard-48 (4 x L4)
      • g2-standard-96 (8 x L4)
      • a2-highgpu-1g (1 x A100-40GB)
      • a2-ultragpu-1g (1 x A100-80GB)
      • a3-highgpu-1g (1 x H100-80GB)
  • Não é possível usar o contêiner secundário do driver CSI do Cloud Storage FUSE com snapshots de pods.
  • Os snapshots de pods não oferecem suporte a tipos de máquina da TPU.

A seguir