Acionar um snapshot de pod

Saiba como criar políticas de snapshot e acionar um snapshot de pod das cargas de trabalho em execução no Google Kubernetes Engine (GKE).

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

• Verifique se você concluiu os pré-requisitos e ativou os snapshots de pod no cluster. Para mais informações, consulte Preparar para snapshots de pod.

Criar uma política de snapshot

Para ativar snapshots de um pod, crie um recurso PodSnapshotPolicy com um seletor que corresponda aos rótulos do pod.

1. O exemplo a seguir cria uma política que se aplica a pods com o rótulo app: my-app e usa a configuração de armazenamento example-pod-snapshot-storage-config. Salve o seguinte manifesto como example-pod-snapshot-policy.yaml:

   apiVersion: podsnapshot.gke.io/v1
   kind: PodSnapshotPolicy
   metadata:
     name: example-pod-snapshot-policy
     namespace: NAMESPACE
   spec:
     storageConfigName: example-pod-snapshot-storage-config
     selector:
       matchLabels:
         app: my-app
     triggerConfig:
       type: TRIGGER_TYPE
       postCheckpoint: resume
   

   Substitua:

   • TRIGGER_TYPE: o tipo de acionador. Os valores aceitos são workload para acionadores baseados em carga de trabalho ou manual para snapshots sob demanda.
   • NAMESPACE: o namespace dos seus pods.

   Para uma lista completa de todos os campos que podem ser configurados, consulte a documentação da definição de recurso personalizado (CRD, na sigla em inglês) do PodSnapshotPolicy.

2. Aplique o manifesto:

   kubectl apply -f example-pod-snapshot-policy.yaml
   

Configurar outras políticas de snapshot de pod

É possível configurar outras políticas no PodSnapshotPolicy, como as seguintes:

• Escopo do snapshot: para especificar quais partes do estado do pod serão capturadas no snapshot, configure o campo spec.snapshotScope. Os valores aceitos são whole-pod (padrão) para fazer o checkpoint de todo o pod, incluindo o estado do aplicativo, a memória e os sistemas de arquivos, ou rootfs-only para fazer o checkpoint apenas do sistema de arquivos raiz do contêiner. O escopo rootfs-only requer a versão 1.35.3-gke.1031000 ou mais recente do GKE.

• Limpeza automática: para limpar automaticamente os recursos de snapshot de pod antigos, configure uma política de retenção usando o campo spec.retentionConfig. É possível especificar uma duração usando o campo lastAccessTimeout (por exemplo, 7d), após o qual o snapshot será excluído.

• Organizar snapshots: é possível agrupar snapshots logicamente para diferenciar entre snapshots que foram feitos em ambientes semelhantes, mas em contextos diferentes. Por exemplo, em um cenário multitenant em que o pod base é o mesmo para todos os usuários, é possível isolar os snapshots por usuário ou grupo. Para isolar snapshots, especifique rótulos de agrupamento na política usando o campo snapshotGroupingRules. Quando um pod é restaurado, ele só corresponde a snapshots no mesmo grupo de rótulos. Para mais informações sobre como esse agrupamento afeta a correspondência de compatibilidade durante a restauração, consulte Correspondência de regras de agrupamento.

O exemplo a seguir mostra como configurar as configurações de retenção e agrupamento no PodSnapshotPolicy. Essas configurações podem ser definidas de forma independente:

# ... other fields omitted
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

Para uma lista completa de todos os campos que podem ser configurados, consulte a documentação de referência do PodSnapshotPolicy.

Otimizar o tamanho do snapshot

Quando um snapshot de pod é acionado, o gVisor captura todo o estado de todos os contêineres, incluindo:

• Estado do aplicativo, como memória e registros
• Mudanças no sistema de arquivos raiz e tmpfs (incluindo volumes emptyDir)
• Estado do kernel, como descritores de arquivos abertos, linhas de execução e soquetes

O tamanho do snapshot é determinado por esses fatores. Snapshots maiores levam mais tempo para serem salvos e restaurados. Para otimizar o desempenho, antes de acionar um snapshot, limpe qualquer estado ou arquivo do aplicativo que não seja necessário depois que o pod for restaurado do snapshot.

A otimização do tamanho do snapshot é particularmente importante para cargas de trabalho como modelos de linguagem grandes (LLMs). Os servidores de LLM geralmente fazem o download dos pesos do modelo para o armazenamento local (rootfs ou tmpfs) antes de carregá-los na GPU. Quando um snapshot é feito, o estado da GPU e os arquivos de peso do modelo são salvos. Nesse cenário, se o modelo for de 100 GB, o snapshot resultante será de aproximadamente 200 GB (100 GB de arquivos de modelo, mais 100 GB representando o estado da GPU). Depois que os pesos do modelo são carregados na GPU, os arquivos no sistema de arquivos geralmente não são necessários para que o aplicativo seja executado. Ao excluir esses arquivos de modelo antes de acionar o snapshot, é possível reduzir o tamanho do snapshot pela metade e restaurar o aplicativo com uma latência significativamente menor.

Acionar um snapshot

É possível acionar um snapshot de dentro de uma carga de trabalho quando o aplicativo estiver pronto ou acionar manualmente um snapshot sob demanda para um pod específico.

Acionar um snapshot de uma carga de trabalho

Para acionar um snapshot no código do aplicativo, configure o aplicativo para enviar um sinal quando ele estiver pronto para um snapshot. Para sinalizar prontidão, grave 1 no arquivo /proc/gvisor/checkpoint, por exemplo echo 1 > /proc/gvisor/checkpoint. A operação de gravação inicia o processo de snapshot de forma assíncrona e retorna imediatamente. A leitura do mesmo descritor do arquivo vai bloquear o processo de leitura até que o snapshot e a restauração sejam concluídos e a carga de trabalho esteja pronta para ser retomada.

O uso exato vai variar dependendo do aplicativo, mas o exemplo a seguir mostra um acionador de snapshot para um aplicativo Python. Para acionar um snapshot dessa carga de trabalho de exemplo, conclua as etapas a seguir:

1. Salve o seguinte manifesto como my-app.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
     namespace: NAMESPACE
     labels:
       app: my-app
   spec:
     serviceAccountName: KSA_NAME
     runtimeClassName: gvisor
     containers:
     - name: my-container
       image: python:3.10-slim
       command: ["python3", "-c"]
       args:
         - |
           import time
           def trigger_snapshot():
             try:
               with open("/proc/gvisor/checkpoint", "r+") as f:
                 f.write("1")
                 res = f.read().rstrip()
                 print(f"GKE Pod Snapshot: {res}")
             except FileNotFoundError:
               print("GKE Pod Snapshot file does not exist -- Pod Snapshots is disabled")
               return
           i = 0
           while True:
             print(f"Count: {i}", flush=True)
             if (i == 20): #simulate the application being ready to snapshot at 20th count
               trigger_snapshot()
             i += 1
             time.sleep(1)
       resources:
         limits:
           cpu: "500m"
           memory: "512Mi"
         requests:
           cpu: "250m"
           memory: "256Mi"
   

   Substitua:

   • NAMESPACE: o namespace dos seus pods.
   • KSA_NAME: o nome da sua KSA.

2. Implante o aplicativo:

   kubectl apply -f my-app.yaml
   

Acionar um snapshot manualmente

Para acionar manualmente um snapshot sob demanda para um pod específico, crie um recurso PodSnapshotManualTrigger.

1. O exemplo a seguir aciona um snapshot para um pod chamado my-pod. Salve o seguinte manifesto como example-manual-trigger.yaml:

   apiVersion: podsnapshot.gke.io/v1
   kind: PodSnapshotManualTrigger
   metadata:
     name: example-manual-trigger
     namespace: NAMESPACE
   spec:
     targetPod: my-pod
   

   Substitua NAMESPACE pelo namespace do pod.

2. Aplique o manifesto:

   kubectl apply -f example-manual-trigger.yaml
   

Para confirmar se o snapshot foi acionado, verifique o campo status do recurso PodSnapshotManualTrigger:

kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io example-manual-trigger -n NAMESPACE -o yaml

O campo status indica se o acionamento do snapshot foi bem-sucedido ou falhou.

Verificar snapshots

Para confirmar se um snapshot foi feito, verifique o histórico de eventos de eventos GKEPodSnapshotting:

kubectl get events -o \
custom-columns=NAME:involvedObject.name,CREATIONTIME:.metadata.creationTimestamp,REASON:.reason,MESSAGE:.message \
--namespace NAMESPACE \
--field-selector involvedObject.name=POD_NAME,reason=GKEPodSnapshotting

Substitua:

• POD_NAME: o nome do pod, por exemplo, my-app ou my-pod.
• NAMESPACE: o namespace dos seus pods.

A saída será assim:

NAME                                    CREATIONTIME           REASON               MESSAGE
default/5b449f9c7c-bd7pc                2025-11-05T16:25:11Z   GKEPodSnapshotting   Successfully checkpointed the pod to PodSnapshot

A seguir

Saiba como restaurar uma carga de trabalho de um snapshot de pod.