Pod Snapshot no GKE: Reduzindo Cold Start em Cargas de Trabalho Pesadas

Se você trabalha com cargas de trabalho de AI/ML ou aplicações que levam minutos para inicializar no GKE, Pod Snapshot é uma feature que pode mudar o jogo. Neste post, vou explicar o que é, por que importa e como implementar.

Pod Snapshot é um recurso do GKE que captura o estado completo de um Pod em execução — incluindo memória, estado da CPU, GPU e alterações no sistema de arquivos — e o salva no Cloud Storage.

Quando um novo Pod precisa ser criado, em vez de começar do zero, o GKE restaura esse snapshot e o Pod retorna à execução exatamente de onde estava.

Diferente de Volume Snapshot (que captura apenas dados persistentes), Pod Snapshot congela todo o runtime da sua aplicação, incluindo a memória com o modelo de IA já carregado, todas as dependências inicializadas e qualquer estado computado.

Cargas de trabalho de AI/ML são notoriamente lentas para inicializar. Um modelo de 70B parâmetros pode levar vários minutos apenas para ser carregado na memória da GPU. Com Pod Snapshot, você reduz esse tempo para segundos.

Números reais do GCP

• Modelo 70B: Startup normal ≈ 300s | Com snapshot ≈ 80s (73% mais rápido)
• Modelo 8B: Startup normal ≈ 60s | Com snapshot ≈ 16s (73% mais rápido)

Cenários onde Pod Snapshot brilha

• Inferência de AI/ML — reduz latência de cold start para usuários.
• Batch jobs pesados — inicia processamento em segundos em vez de minutos.
• Aplicações com muitas dependências — Node.js, Python com libs grandes.
• Auto-scaling — novos replicas escalam instantaneamente.

Pod Snapshot usa as capacidades de checkpoint/restore do gVisor, um runtime de contêiner sandboxado do Google.

O processo é:

1. Um Pod em execução é congelado em um ponto no tempo.
2. O gVisor captura memória da heap, stack, file descriptors e estado de rede.
3. O estado é serializado e enviado ao Cloud Storage.
4. Quando um novo Pod precisa ser criado com esse snapshot, o estado é restaurado.
5. O Pod retorna da exata linha de código onde foi pausado.

Isso funciona apenas com GKE Sandbox habilitado (que executa contêineres com gVisor).

Antes de implementar, verifique:

• Versão do GKE: 1.35.3-gke.1234000 ou posterior (GA desde maio de 2026)
• GKE Sandbox: Deve estar habilitado no cluster ou node pool
• Tipos de máquina: Não funciona com E2 (use N2, C2, A2 ou superior)
• Storage: Bucket do Cloud Storage para armazenar snapshots
• Permissões: Acesso à API de Compute Engine e Cloud Storage

Passo 1: Preparar o Cluster com GKE Sandbox

Primeiro, crie um node pool com GKE Sandbox habilitado.

(YAML) PodSnapshotPolicy

A imagem mostra um arquivo semelhante a:

apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotPolicy

metadata:
  name: ai-inference-snapshots
  namespace: default

spec:
  storageConfigName: default-storage-config

  selector:
    matchLabels:
      snapshot: enabled

  triggerConfig:
    type: manual

  snapshotConfig:
    maxSnapshotsPerPod: 3

Aplicação:

kubectl apply -f pod-snapshot-policy.yaml

Crie um Deployment que será alvo do snapshot.

O exemplo mostrado contém:

• apiVersion: apps/v1
• kind: Deployment
• deployment chamado llm-inference
• label snapshot: enabled
• nodeSelector para gke-sandbox
• imagem do container
• requests e limits
• volume /models
• variável de ambiente apontando para um modelo 70B.

Aplicação:

kubectl apply -f llm-inference-deployment.yaml

Após o Pod estar em execução e o modelo carregado, crie um snapshot:

kubectl create podsnapshot llm-inference-checkpoint \
    --pod=llm-inference-xxxxx \
    --namespace=default

Ou via YAML.

Verifique o status

kubectl get podsnapshot -n default

kubectl describe podsnapshot llm-inference-checkpoint-v1 \
    -n default

Ao criar um novo Pod, referencie o snapshot para restauração imediata.

O YAML mostrado utiliza:

• kind: Pod
• restartPolicy
• nodeSelector
• mesmo container anterior
• referência para:

podSnapshot: llm-inference-checkpoint-v1

Snapshot após warmup

Crie snapshots somente depois que o modelo ou aplicação estiver completamente inicializado e pronto.

Nomeie com versão

Use nomes descritivos como:

• llm-7b-v1
• inference-gpu-latest

Limite retenção

Use maxSnapshotsPerPod para não encher o bucket com snapshots antigos.

Monitore custo

Snapshots no Cloud Storage têm custo. Implemente políticas automáticas de limpeza.

Teste restauração

Crie snapshots em produção, mas teste a restauração primeiro em staging.

Múltiplas regiões

Para disaster recovery, replique snapshots entre regiões do GCP.

Pod Snapshot é uma feature poderosa para reduzir cold start em cargas de trabalho pesadas no GKE.

Se você roda inferência de modelos de AI/ML, essa é uma vitória rápida — reduz latência em 70–80% sem mudanças de código.

Comece com um Pool pequeno com GKE Sandbox, crie snapshots de sua carga de trabalho e teste a restauração. Você verá o impacto imediatamente.