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 mudanças na memória e no sistema de arquivos. Quando você cria 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. Esse recurso é útil para escalonar horizontalmente cargas de trabalho, como modelos de inferência de IA que carregam pesos grandes na memória ou aplicativos que carregam dependências extensas.

Use este documento para entender como os snapshots de pods do GKE funcionam e avaliar se suas cargas de trabalho podem se beneficiar deles.

Administradores e operadores de plataforma e desenvolvedores de aplicativos podem usar este documento para avaliar a compatibilidade da carga de trabalho, planejar políticas de armazenamento de snapshots e entender como o GKE gerencia o checkpointing e a restauração. Para mais informações sobre as funções comuns e as tarefas de exemplo referenciadas no conteúdo doGoogle Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Para se preparar e usar snapshots de pods nos clusters, consulte os seguintes guias:

  1. Preparar para snapshots de pods
  2. Acionar um snapshot do pod
  3. Restaurar uma carga de trabalho usando um snapshot de pod

Quando usar snapshots de pod

Use snapshots de pod para cargas de trabalho com tempos de inicialização longos. 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. As cargas de trabalho que já têm tempos de inicialização rápidos geralmente não se beneficiam dos snapshots de pod.

Como os snapshots de pod funcionam

Os snapshots de pods do GKE armazenam uma cópia exata do estado do processo de um pod em um momento específico. Ao criar novas réplicas, em vez de inicializar o pod de um estado novo, o GKE restaura o pod de um snapshot. Essa restauração significa que o pod retoma a execução do ponto em que o snapshot foi capturado.

Para configurar snapshots de pods de forma declarativa, crie recursos personalizados do Kubernetes para definir o comportamento do snapshot. Um agente executado 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 snapshots atuais para restaurar novos pods. Um controlador executado no plano de controle do GKE limpa snapshots obsoletos e resolve problemas. O Cloud Storage armazena seus snapshots de pod.

Conteúdo do snapshot

A tabela a seguir lista o que um snapshot de pod inclui e exclui:

Categoria Incluído Excluído
Estado do aplicativo
  • Memória do processo
  • Linhas de execução
  • Registros de CPU
  • Descritores de arquivos abertos
 Nada (todo o estado do processo na memória é capturado)
Sistemas de arquivos
  • Sistema de arquivos raiz do contêiner (rootfs)
  • emptyDir volumes
  • tmpfs suportes
  • Objetos PersistentVolumeClaim
  • Qualquer outro tipo de volume ou armazenamento não listado como incluído
Rede
  • Conexões de loopback
  • Sockets de detecção
  • Soquetes de domínio Unix
  • Conexões externas ativas (fechadas na restauração)
  • Rotas personalizadas
  • Regras definidas pelo usuário (iptables, nftables)

Recursos personalizados

Para configurar snapshots de pods de forma declarativa, use os seguintes recursos personalizados:

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

Para especificações de referência, consulte a referência de CustomResourceDefinition do PodSnapshot.

Acionadores de snapshot

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

  • Gatilho da carga de trabalho: o aplicativo dentro do pod sinaliza ao agente do GKE que está pronto para um snapshot. Esse tipo de gatilho é executado uma vez em um ciclo de carga de trabalho, por exemplo, em um estado pronto para carga de trabalho. Essa abordagem é melhor para melhorar a latência de inicialização de cargas de trabalho com escalonamento horizontal.
  • Acionamento 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 e compatibilidade de snapshots

Para garantir que um snapshot seja compatível com uma carga de trabalho restaurada, o GKE realiza uma correspondência de compatibilidade entre o pod original com checkpoint e o pod de destino.

O GKE usa as seguintes regras para determinar a compatibilidade:

  • Ordem de seleção: por padrão, o GKE restaura cargas de trabalho do recurso personalizado PodSnapshot mais recente que corresponde ao namespace e à configuração do pod.
  • Critérios de correspondência: a verificação de compatibilidade depende do escopo do snapshot configurado no recurso personalizado PodSnapshotPolicy (whole-pod ou rootfs-only).

Correspondência de escopo whole-pod (padrão)

Para políticas com o escopo whole-pod padrão, o GKE verifica o seguinte:

  • Hash de especificação destilada: o GKE gera um hash exclusivo com base em campos de execução essenciais na especificação do pod. Para que uma restauração seja bem-sucedida, o pod de destino precisa gerar um hash idêntico da especificação destilada. Essa verificação garante que os pods de ponto de verificação e restaurados sejam idênticos nas configurações de tempo de execução.

    Os seguintes campos do objeto Pod fazem parte da especificação refinada e influenciam o hash exclusivo:

    • metadata:
      • annotations: apenas anotações relevantes para o GKE Sandbox, como as 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 de containers.
      • dnsPolicy
      • automountServiceAccountToken
      • hostNetwork
      • hostPID
      • hostIPC
      • shareProcessNamespace
      • securityContext
      • dnsConfig
      • runtimeClassName
      • os
      • hostUsers

  • Compatibilidade de hardware: o pod de destino precisa ser executado em um nó com uma série de máquinas e uma arquitetura de CPU idênticas ao pod original com checkpoint (por exemplo, N2 para N2 ou G2 para G2).

  • Compatibilidade de versão: a versão do kernel do GKE Sandbox e a versão do driver da GPU precisam corresponder à versão capturada no snapshot original.

Correspondência de escopo rootfs-only

Ao configurar sua política com o escopo rootfs-only (disponível no GKE versão 1.35.3-gke.1031000 e mais recentes), os requisitos de correspondência são menos rigorosos:

  • O GKE não calcula nem compara o hash da especificação do pod destilado. Essa correspondência flexível permite restaurar um snapshot para um pod de destino com recursos, ambientes ou outros campos de configuração diferentes. No entanto, a imagem do contêiner e as versões do nó subjacentes precisam ser compatíveis.
  • Como a memória do processo não é restaurada, é possível restaurar snapshots feitos em uma família de máquinas para outra (incluindo tipos de máquina E2).

Correspondência de regras de agrupamento

Se a política usar o campo snapshotGroupingRules para agrupar snapshots por valores de rótulo específicos (como locatário ou ambiente), o pod restaurado precisará ter chaves e valores de rótulo correspondentes. O controlador de snapshot do pod seleciona um snapshot apenas do grupo correspondente. Para mais informações sobre como configurar rótulos de agrupamento, consulte Configurar outras políticas de snapshot de pod.

Restaurar a disposição e o carregamento em segundo plano

Quando um pod é restaurado de um snapshot, o kernel do GKE Sandbox é restaurado primeiro, o que geralmente 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 ler uma parte da memória que ainda não foi carregada, ocorrerá uma falha de página. O GKE Sandbox intercepta essa falha, pausa a thread do aplicativo e busca imediatamente a página de memória necessária do 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 breve latência nos primeiros segundos após uma restauração se o aplicativo solicitar memória não 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 vai responder totalmente para inferência até que o estado da GPU seja completamente restaurado. Devido a esse atraso, ao medir a velocidade de restauração, verifique se você está medindo quando o servidor de modelos está pronto para disponibilizar solicitações. É possível verificar a prontidão do servidor de modelo usando métricas como tempo até o primeiro token (TTFT, na sigla em inglês) ou testes 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. Essa etapa ajuda a garantir que os dados armazenados na GPU, como pesos do modelo, sejam incluídos no snapshot. O GKE pausa o pod e faz um snapshot. Durante a restauração, o GKE reverte essa operação.

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 adicional de memória ao definir limites para seus pods.

Considerações sobre pods restaurados

Do ponto de vista da API Kubernetes, um novo objeto Pod é criado. Quando o pod é iniciado, se houver um snapshot correspondente, o GKE vai restaurar o pod desse snapshot, incluindo a memória e o estado do processo originais. 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. Os soquetes de escuta, as conexões de loopback e as 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 do 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 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 consegue encontrá-las e substituí-las de maneira 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 de /proc/<pid>/environ.

Multilocação e identidade

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

Para resolver atrasos e simplificar o gerenciamento multitenant, em vez de vincular manualmente o IAM a objetos ServiceAccount, use uma conta de serviço do nó do GKE para criar tokens de curta duração sob demanda. Para configurar snapshots de pod com essa abordagem, use o campo tokenSource no recurso personalizado PodSnapshotStorageConfig com um dos seguintes valores:

  • podKSA (padrão): usa vinculações manuais do IAM entre o objeto ServiceAccount do pod e o bucket do Cloud Storage.
  • federatedP4SA: usa um token específico do caminho gerado pela conta de serviço do nó.

Requisitos

Para usar snapshots de pods do GKE, confira se você atende aos seguintes requisitos:

  • Os pods precisam ser executados no GKE Sandbox porque os snapshots de pod dependem do ambiente isolado fornecido pelo GKE Sandbox.
  • Para usar GPUs com snapshots de pod, você precisa atender aos seguintes requisitos:
    • Os pods de GPU única são compatíveis com nós de GPU única e múltipla.
    • Os pods com várias GPUs são compatíveis apenas com GPUs L4 (tipos de máquina g2-standard-*).
    • Nas versões 1.35.0-gke.1738000 e anteriores do GKE, um pod executado em um nó com 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ó.
    • Use um dos seguintes tipos de máquina compatíveis:
      • 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)

Limitações

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

  • Os snapshots de pod não oferecem suporte a tipos de máquina E2 quando usam o escopo de snapshot whole-pod padrão. Os snapshots do sistema de arquivos (rootfs-only) são compatíveis com tipos de máquina E2.
  • O compartilhamento de GPU com GPU de várias instâncias (MIG) não é compatível.
  • O contêiner secundário do driver CSI do Cloud Storage FUSE não é compatível com snapshots de pod.
  • Os snapshots de pods não são compatíveis com TPUs.

A seguir