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.

O que é Pod Snapshot?

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 retoma a execução exatamente de onde estava.

Diferente de Volume Snapshot (que captura apenas dados persistentes), Pod Snapshot congela toda a runtime do seu aplicativo, incluindo a memória com o modelo de IA já carregado, todas as dependências inicializadas, e qualquer estado computado.

Por que Isso Importa

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

Como Funciona Internamente

Pod Snapshot usa as capacidades de checkpoint/restore do gVisor, um runtime de contêiner sandboxed do Google. O processo é assim:

1. Um Pod em execução é congelado em um ponto no tempo
2. gVisor captura: memória da heap, stack, file descriptors, 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 retoma da exata linha de código onde foi pausado

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

Requisitos e Limitações

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

Implementando Pod Snapshots

Passo 1: Preparar o Cluster com GKE Sandbox

Primeiro, crie um node pool com GKE Sandbox habilitado:

gcloud container node-pools create snapshot-pool \
  --cluster=seu-cluster \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --sandbox=gvisor \
  --num-nodes=1

Ou, se já tem um cluster, adicione a flag ao criá-lo:

gcloud container clusters create seu-cluster \
  --zone=us-central1-a \
  --enable-sandbox

Passo 2: Configurar PodSnapshotStorageConfig

Crie um bucket no Cloud Storage para armazenar seus snapshots:

gsutil mb gs://seu-bucket-snapshots-gke

Agora, configure onde os snapshots serão salvos. Crie pod-snapshot-storage.yaml:

apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotStorageConfig
metadata:
  name: default-storage-config
  namespace: kube-system
spec:
  snapshotStorageConfig:
    gcs:
      bucket: seu-bucket-snapshots-gke
      path: /snapshots
    tokenSource: podKSA  # Usa a service account do Pod

Aplique:

kubectl apply -f pod-snapshot-storage.yaml

Passo 3: Criar uma PodSnapshotPolicy

Agora defina quais Pods devem ter snapshots. Crie pod-snapshot-policy.yaml:

apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotPolicy
metadata:
  name: ai-inference-snapshots
  namespace: default
spec:
  storageConfigName: default-storage-config
  selector:
    matchLabels:
      snapshot: enabled  # Pods com essa label serão snapshotados
  triggerConfig:
    type: manual  # ou 'scheduled' para snapshots automáticos
  postCheckpoint: resume  # Retoma o Pod após snapshot
  snapshotGroupingRules:
    maxSnapshotsPerPod: 3  # Mantenha apenas 3 snapshots por Pod

Aplique:

kubectl apply -f pod-snapshot-policy.yaml

Passo 4: Deployar uma Aplicação com Snapshot

Crie um Deployment que será feito o snapshot. Exemplo com uma carga de trabalho de inferência:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-inference
spec:
  replicas: 1
  selector:
    matchLabels:
      app: llm-inference
      snapshot: enabled  # Habilita snapshot para esse Pod
  template:
    metadata:
      labels:
        app: llm-inference
        snapshot: enabled
    spec:
      nodeSelector:
        cloud.google.com/gke-sandbox: gvisor  # Executa em nodes com GKE Sandbox
      containers:
      - name: inference
        image: seu-registry/llm-inference:latest
        resources:
          requests:
            memory: "40Gi"
            nvidia.com/gpu: 1
          limits:
            memory: "40Gi"
            nvidia.com/gpu: 1
        env:
        - name: MODEL_PATH
          value: /models/mistral-70b
        volumeMounts:
        - name: models
          mountPath: /models
      volumes:
      - name: models
        emptyDir: {}  # Modelo é carregado em tempo de execução

Aplique:

kubectl apply -f llm-inference-deployment.yaml

Passo 5: Criar um Snapshot Manualmente

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:

apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshot
metadata:
  name: llm-inference-checkpoint-v1
  namespace: default
spec:
  podName: llm-inference-xxxxx
  containerName: inference
  checkpointPath: /snapshots/llm-inference-v1

Verifique o status:

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

Passo 6: Restaurar a Partir de um Snapshot

Ao criar um novo Pod, referencie o snapshot para restaurá-lo instantaneamente:

apiVersion: v1
kind: Pod
metadata:
  name: llm-inference-restored
  namespace: default
spec:
  nodeSelector:
    cloud.google.com/gke-sandbox: gvisor
  containers:
  - name: inference
    image: seu-registry/llm-inference:latest
    resources:
      requests:
        memory: "40Gi"
        nvidia.com/gpu: 1
    restoreFrom:
      podsnapshot: llm-inference-checkpoint-v1  # Restaura deste snapshot

Boas Práticas

Snapshot após warmup — crie snapshots só depois que o modelo/app estiver completamente inicializado e pronto.

Nomeie com versão — use nomes descritivos: 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 de limpeza automática.

Teste restauração — crie snapshots em produção mas teste restauração em staging primeiro.

Múltiplas regiões — para DR, replique snapshots entre regiões do GCP.

Conclusão

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

---

Gostou do conteúdo?

• ✅ Inscreva-se na newsletter para receber mais dicas práticas sobre Go, Cloud e Kubernetes diretamente no seu e-mail!
• 🚀 Conheça a Imersão Golang e leve seus conhecimentos em Go para o próximo nível!

Faça parte da comunidade!

Receba os melhores conteúdos sobre Go, Kubernetes, arquitetura de software, Cloud e esteja sempre atualizado com as tendências e práticas do mercado.