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

Este documento oferece uma visão geral conceitual dos snapshots de pods do GKE. Para ativar e usar esse recurso, consulte os seguintes documentos:

  1. Preparar snapshots de pods
  2. Acionar um snapshot de pod
  3. Restaurar uma carga de trabalho 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) 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, threads, 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.

CustomResourceDefinitions

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 incluídos no snapshot 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, 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.

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 e compatibilidade de snapshots

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

A compatibilidade é determinada pelas seguintes regras:

  • Ordem de seleção: por padrão, o GKE restaura cargas de trabalho do recurso PodSnapshot mais recente que corresponde ao namespace e à configuração do pod.
  • Critérios de correspondência: a verificação de compatibilidade varia dependendo do escopo do snapshot configurado na PodSnapshotPolicy (whole-pod versus 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:

  1. Hash de especificação destilada: o GKE gera um hash exclusivo com base nos 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 verificados e restaurados sejam idênticos nas configurações de execução.

    Os campos a seguir do objeto de pod fazem parte da especificação destilada e 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: mesmos subcampos que containers.
      • dnsPolicy
      • automountServiceAccountToken
      • hostNetwork
      • hostPID
      • hostIPC
      • shareProcessNamespace
      • securityContext
      • dnsConfig
      • runtimeClassName
      • os
      • hostUsers

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

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

Correspondência de escopo rootfs-only

Ao configurar a 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 de especificação do pod destilado. Essa correspondência flexível permite restaurar um snapshot para um pod de destino que tenha recursos, ambientes ou outros campos de configuração diferentes do pod original verificado, desde que a imagem do contêiner e as versões do nó subjacentes sejam compatíveis.
  • Como a memória do processo não é restaurada, é possível restaurar snapshots feitos em uma família de máquinas para uma família de máquinas 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 (por exemplo, por locatário ou ambiente), o pod restaurado precisará ter exatamente as mesmas chaves e valores de rótulo. O controlador de snapshot de pod seleciona apenas um snapshot do grupo correspondente. Para mais informações sobre como configurar rótulos de agrupamento, consulte Configurar políticas de snapshot de pod adicionais políticas.

Prontidão de 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. Devido a esse atraso, 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. Ao acionar 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 incluído no snapshot. Durante a restauração, o processo é invertido.

Como o estado da GPU é gravado na memória do processo, o uso de 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 do host.
  • Tempo de relógio de parede: o tempo de relógio de parede avança para a hora 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 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 a ServiceAccount (KSA) do Kubernetes de cada 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 às KSAs, é possível 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 da 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 ao usar o escopo de snapshot whole-pod padrão. Os snapshots do sistema de arquivos (rootfs-only) 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)
  • O contêiner sidecar do driver CSI do Cloud Storage FUSE não é aceito com snapshots de pods.
  • Os snapshots de pods não oferecem suporte a tipos de máquina TPU.

A seguir