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 as cargas de trabalho podem se beneficiar deles.

Os administradores e operadores de plataforma e os 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 checkpoint e a restauração. Para mais informações sobre os papéis comuns e as tarefas de exemplo referenciados no conteúdo doCloud de Confiance by S3NS , consulte Tarefas e papéis de usuário comuns 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 de pod
  3. Restaurar uma carga de trabalho de um snapshot de pod

Quando usar snapshots de pod

Use snapshots de pods para cargas de trabalho com tempos de inicialização longos. Os exemplos incluem 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 funcionam os snapshots de pod

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 tirado.

Para configurar snapshots de pods de maneira 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 os 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 os 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
  • Abrir descritores do arquivo
 Nada (todo o estado do processo na memória é capturado)
Sistemas de arquivos
  • Sistema de arquivos raiz do contêiner (rootfs)
  • emptyDir volumes
  • Montagens de tmpfs
  • Objetos PersistentVolumeClaim
  • Qualquer outro tipo de volume ou armazenamento não listado como incluído
Rede
  • Conexões de loopback
  • Soquetes 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. Oferece suporte apenas a buckets do Cloud Storage.
  • PodSnapshotPolicy: define quais pods serão capturados 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 gatilho de carga de trabalho, defina um gatilho 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 de 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 de carga de trabalho pronta. Essa abordagem é ideal para melhorar a latência de inicialização de cargas de trabalho com escalonamento horizontal.
  • Gatilho manual: é possível acionar um snapshot sob demanda para um pod específico criando um recurso personalizado PodSnapshotManualTrigger. Esse tipo de gatilho 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 padrão whole-pod, o GKE verifica o seguinte:

  • Hash de especificação destilado: o GKE gera um hash exclusivo com base em campos de ambiente 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 confirma se os pods de checkpoint e restaurados são idênticos nas configurações de ambiente de execução.

    Os campos a seguir do objeto do pod fazem parte da especificação destilada e influenciam o hash exclusivo:

    • metadata:
      • annotations: apenas as 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 a mesma série de máquinas, fornecedor de CPU e conjunto de atributos de CPU (flags CPUID) que o pod com checkpoint. Por exemplo, os dois nós precisam usar a mesma série N2 ou G2 e os mesmos recursos de processador Intel ou AMD. O GKE Sandbox verifica os recursos da CPU antes de restaurar a memória do processo e o estado da CPU. Portanto, um snapshot com o escopo whole-pod não pode ser restaurado em um nó com recursos de CPU diferentes.

  • 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 de rootfs-only

Quando você configura a política com o escopo rootfs-only (disponível no GKE versão 1.35.3-gke.1031000 e posterior), 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 diferentes recursos, ambientes ou outros campos de configuração. No entanto, a imagem do contêiner e as versões do nó precisam ser compatíveis.
  • Como a memória do processo não é restaurada, é possível restaurar snapshots tirados em uma família de máquinas para outra diferente (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 de 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.

Restauração da prontidão e 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, vai ocorrer uma falha de página. O GKE Sandbox 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 on demand é priorizada em relação ao stream em segundo plano.

Devido a esse carregamento em segundo plano, o acesso à memória pode apresentar 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 é 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 será totalmente responsivo 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 o servidor de modelos está pronto para atender às solicitações. É possível verificar a prontidão do servidor de modelos usando métricas como o tempo até o primeiro token (TTFT) ou sondagens de prontidão de pods.

Estado da GPU

Os snapshots de pods permitem capturar o 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 de modelo, sejam incluídos no snapshot. O GKE pausa o pod e cria 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 de memória adicional ao definir limites de memória para os pods.

Considerações sobre pods restaurados

Do ponto de vista da API do Kubernetes, um novo objeto de pod é criado. Quando o pod é iniciado, se houver um snapshot correspondente, o GKE vai restaurar o pod 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. Os soquetes de detecção, 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 decorrido: o tempo real decorrido avança para o horário atual.
  • Estado do aplicativo: o estado do aplicativo precisa ser exclusivo para cada pod, como IDs de experimento 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 de você criar o snapshot precisam ser recriados.
  • Variáveis de ambiente: é possível alterar 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 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 ServiceAccount do Kubernetes 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 a criação de um pod.

Para lidar com atrasos e simplificar o gerenciamento de multilocatários, em vez de vincular manualmente o IAM a objetos ServiceAccount, use 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 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 os snapshots de pod do GKE, verifique se você atende aos seguintes requisitos:

  • Os pods precisam ser executados no GKE Sandbox porque os snapshots de pods dependem do ambiente isolado que o GKE Sandbox oferece.
  • Para o escopo de snapshot padrão whole-pod, o nó em que o pod é restaurado precisa ter a mesma série de máquinas, o mesmo fornecedor de CPU e os mesmos recursos de CPU do nó em que o snapshot foi criado. As cargas de trabalho somente de CPU podem usar qualquer série de máquinas que não seja E2 compatível com o GKE Sandbox e que atenda a esses requisitos de compatibilidade de hardware. Saiba mais em Limitações.
  • Para usar GPUs com snapshots de pod, você também precisa atender aos seguintes requisitos:
    • Os pods de GPU única são compatíveis com nós de GPU única e de várias GPUs.
    • 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 posteriores, os pods podem usar um subconjunto das GPUs em um nó.
    • Para cargas de trabalho de GPU, use um dos seguintes tipos de máquina de GPU 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 pod do GKE têm as seguintes limitações:

  • Quando você usa o escopo de snapshot padrão whole-pod, um snapshot não pode ser restaurado em uma VM do Compute Engine com recursos de CPU (flags CPUID) diferentes da VM em que o snapshot foi criado:
    • Os snapshots de pod com o escopo whole-pod não são compatíveis com a série de máquinas E2 ou outras séries de máquinas que misturam dinamicamente processadores Intel e AMD ou gerações de CPU. Os snapshots do sistema de arquivos (escopo rootfs-only) são compatíveis com a série de máquinas E2.
    • Mesmo dentro da mesma série de máquinas não E2 e do mesmo fornecedor de CPU, o Compute Engine pode provisionar VMs com diferentes plataformas de CPU ou conjuntos de atributos de CPU por VM. Se um pod for programado em um nó com recursos de CPU incompatíveis, a restauração de um snapshot com o escopo whole-pod vai falhar.
  • Não é possível compartilhar GPUs com GPUs de várias instâncias (MIG).
  • O contêiner secundário do driver CSI do Cloud Storage FUSE não é compatível com snapshots de pod.
  • Os snapshots de pod não são compatíveis com TPUs.

A seguir