Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Acionar um snapshot de pod

Autopilot Standard

Para reduzir a latência de inicialização das cargas de trabalho do Google Kubernetes Engine (GKE), faça um snapshot de um pod em execução e restaure novos pods com base nele. Neste documento, mostramos como criar uma política de snapshot de pod e acionar um snapshot, seja da carga de trabalho ou manualmente. Para mais informações sobre como os snapshots de pod funcionam, consulte Sobre os snapshots de pod do GKE.

Os administradores e operadores da plataforma e os desenvolvedores de aplicativos podem usar este documento para configurar políticas de snapshot e acionar snapshots. Para mais informações sobre os papéis comuns e as tarefas de exemplo referenciados no conteúdo do Cloud de Confiance by S3NS, consulte Tarefas e papéis de usuário comuns do GKE.

Antes de começar

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

Ative a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Para usar a Google Cloud CLI nesta tarefa, instale e 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.
Observação:em instalações prévias da CLI gcloud, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Conclua os pré-requisitos e ative os snapshots de pod no cluster. Para mais informações sobre como preparar o cluster e o armazenamento, consulte Preparar para snapshots de pod.

Criar uma política de snapshot

Para ativar snapshots para um pod, crie um recurso personalizado PodSnapshotPolicy com um seletor que corresponda aos rótulos do pod:

Salve o seguinte manifesto example-pod-snapshot-policy.yaml como : Este exemplo cria uma política que se aplica a pods com o rótulo app: my-app. A política usa o recurso personalizado example-pod-snapshot-storage-config PodSnapshotStorageConfig, que você criou em Preparar para snapshots de pods, para definir o local de armazenamento do snapshot:
```
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:
- NAMESPACE: o namespace dos pods. Use o mesmo namespace que recebeu acesso ao Cloud Storage em Preparar para snapshots de pod.
- TRIGGER_TYPE: o tipo de gatilho. Os valores compatíveis são workload para gatilhos baseados em carga de trabalho ou manual para snapshots on demand.
Neste exemplo, a configuração postCheckpoint: resume mantém o pod em execução depois que o GKE cria o snapshot.

Para uma lista completa dos campos que podem ser configurados, consulte a especificação de PodSnapshotPolicy.

Aplique o manifesto:

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

Definir outras configurações da política de snapshot de pod

O recurso personalizado PodSnapshotPolicy também é compatível com configurações opcionais além do seletor, da configuração de armazenamento e do gatilho necessários. Essas configurações adicionais controlam o que cada snapshot captura, por quanto tempo o GKE mantém os snapshots e como o GKE agrupa os snapshots para restaurações:

Escopo do snapshot: para especificar quais partes do estado do pod serão capturadas no snapshot, configure o campo spec.snapshotScope. Os valores compatíveis são whole-pod (padrão) e rootfs-only. O escopo whole-pod captura todo o pod, incluindo o estado do aplicativo, a memória e os sistemas de arquivos. O escopo rootfs-only captura apenas o sistema de arquivos raiz do contêiner. O escopo rootfs-only requer o GKE versão 1.35.3-gke.1031000 ou posterior.
Limpeza automática: para limpar automaticamente recursos personalizados antigos do PodSnapshot, 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. Depois que esse período expirar, o GKE vai excluir o snapshot.
Agrupamento de snapshots: para isolar snapshots tirados em ambientes semelhantes, mas em contextos diferentes, especifique rótulos de agrupamento no campo spec.snapshotGroupingRules. Por exemplo, em um cenário multilocatário em que o pod base é o mesmo para todos os usuários, é possível isolar os snapshots por usuário ou grupo. Durante uma restauração, o GKE seleciona um snapshot apenas do 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.

É possível configurar o escopo, a retenção e as configurações de agrupamento do snapshot de maneira independente. O exemplo a seguir mostra as três configurações em um recurso personalizado PodSnapshotPolicy:

# Multiple lines are omitted here
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

Para uma lista completa dos campos que podem ser configurados, consulte a especificação de PodSnapshotPolicy.

Otimizar o tamanho do snapshot

Snapshots maiores levam mais tempo para serem salvos e restaurados. Antes de acionar um snapshot, reduza o tamanho dele excluindo todos os arquivos temporários ou o estado do aplicativo que o aplicativo não precisa depois que o GKE restaura o pod do snapshot.

Com o escopo de snapshot padrão whole-pod, o GKE Sandbox captura todo o estado de todos os contêineres, incluindo:

Estado do aplicativo, como memória e registros
Alterações no sistema de arquivos raiz e nas montagens tmpfs (incluindo volumes emptyDir)
Estado do kernel, como descritores do arquivo abertos, linhas de execução e soquetes

Otimizar o 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 você cria um snapshot, o GKE Sandbox salva o estado da GPU e os arquivos de peso do modelo. Nesse cenário, se o modelo tiver 100 GB, o snapshot resultante terá aproximadamente 200 GB (100 GB de arquivos de modelo, mais 100 GB representando o estado da GPU). Depois que o aplicativo carrega os pesos do modelo na GPU, ele geralmente não precisa dos arquivos no sistema de arquivos para ser 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

Escolha um dos seguintes métodos para acionar um snapshot:

Gatilho de carga de trabalho: use esse método quando for possível modificar o aplicativo para sinalizar que ele está pronto para um snapshot, por exemplo, após a conclusão da inicialização. Esse método é ideal para melhorar a latência de inicialização de cargas de trabalho de escalonamento horizontal. Um gatilho de carga de trabalho é executado apenas uma vez em um ciclo de carga de trabalho.
Acionador manual: use esse método quando não for possível modificar o aplicativo para sinalizar a prontidão ou quando quiser snapshots sob demanda de um pod específico. É possível criar um gatilho manual quantas vezes forem necessárias.

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 estiver pronto para um snapshot. Para sinalizar a prontidão, grave o valor 1 no arquivo /proc/gvisor/checkpoint, por exemplo, executando o comando 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 bloqueia o processo de leitura até que a operação de snapshot ou restauração seja concluída e a carga de trabalho esteja pronta para ser retomada.

Antes de acionar um snapshot de uma carga de trabalho, verifique se uma política de snapshot seleciona o pod. O valor do campo triggerConfig.type nessa política precisa ser definido como workload.

O uso exato varia de acordo com o aplicativo, mas o exemplo a seguir mostra um gatilho de snapshot para um aplicativo Python. Para acionar um snapshot dessa carga de trabalho de exemplo, siga estas etapas:

Salve o seguinte manifesto my-app.yaml como : Neste exemplo, o rótulo app: my-app corresponde ao seletor na política de snapshot de exemplo, e a configuração runtimeClassName: gvisor executa o pod no GKE Sandbox:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
spec:
  serviceAccountName: SERVICEACCOUNT_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 readiness at the 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 pods.
SERVICEACCOUNT_NAME: o nome do objeto ServiceAccount ao qual você concedeu acesso ao Cloud Storage em Preparar para snapshots de pod.

Implante o aplicativo:
```
kubectl apply -f my-app.yaml
```
Depois que o aplicativo é iniciado e sinaliza que está pronto, o GKE Sandbox faz o snapshot. Para confirmar se o snapshot foi criado, consulte Verificar snapshots.

Acionar um snapshot manualmente

Antes de acionar um snapshot manualmente, verifique se o pod de destino está em execução e se uma política de snapshot o seleciona. O valor do campo triggerConfig.type nessa política precisa ser definido como manual.

Para acionar manualmente um snapshot sob demanda para um pod específico, crie um recurso personalizado PodSnapshotManualTrigger seguindo estas etapas:

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

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

Substitua NAMESPACE pelo namespace dos pods.