Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Attivare uno snapshot dei pod

Autopilot Standard

Scopri come creare criteri di snapshot e attivare uno snapshot dei pod dei workload in esecuzione su Google Kubernetes Engine (GKE).

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

Abilita l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Nota: per le installazioni esistenti di gcloud CLI assicurati di impostare la compute/region proprietà. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Assicurati di aver completato i prerequisiti e di aver abilitato gli snapshot dei pod nel cluster. Per saperne di più, consulta Prepararsi per gli snapshot dei pod.

Creare un criterio di snapshot

Per abilitare gli snapshot per un pod, crea una risorsa PodSnapshotPolicy con un selettore che corrisponda alle etichette del pod.

L'esempio seguente crea un criterio che si applica ai pod con l'etichetta app: my-app e utilizza la configurazione di archiviazione example-pod-snapshot-storage-config. Salva il seguente manifest come 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
```
Sostituisci quanto segue:
- TRIGGER_TYPE: il tipo di trigger. I valori supportati sono workload per i trigger basati sul carico di lavoro o manual per gli snapshot on demand.
- NAMESPACE: lo spazio dei nomi per i pod.
Per un elenco completo di tutti i campi che puoi configurare, consulta la documentazione di PodSnapshotPolicy CustomResourceDefinition (CRD).

Applica il manifest:

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

Configurare criteri di snapshot dei pod aggiuntivi

Puoi configurare criteri aggiuntivi in PodSnapshotPolicy, ad esempio:

Ambito dello snapshot: per specificare quali parti dello stato del pod acquisire in lo snapshot, configura il campo spec.snapshotScope. I valori supportati sono whole-pod (impostazione predefinita) per eseguire il checkpoint dell'intero pod, inclusi lo stato dell'applicazione, la memoria e i file system, o rootfs-only per eseguire il checkpoint solo del file system radice del container. L'ambito rootfs-only richiede la versione GKE 1.35.3-gke.1031000 o successive.
Pulizia automatica: per liberare spazio automaticamente dalle risorse di snapshot dei pod precedenti, configura un criterio di conservazione utilizzando il spec.retentionConfig campo. Puoi specificare una durata utilizzando il campo lastAccessTimeout (ad esempio, 7d), dopo la quale lo snapshot viene eliminato.
Organizzare gli snapshot: puoi raggruppare gli snapshot in modo logico per distinguere tra gli snapshot acquisiti in ambienti simili, ma in contesti diversi. Ad esempio, in uno scenario multi-tenant in cui il pod di base è uguale per tutti gli utenti, puoi isolare gli snapshot per utente o gruppo. Per isolare gli snapshot, specifica le etichette di raggruppamento nel criterio utilizzando il campo snapshotGroupingRules. Quando un pod viene ripristinato, corrisponde solo agli snapshot all'interno dello stesso gruppo di etichette. Per saperne di più su come questo raggruppamento influisce sulla corrispondenza di compatibilità durante il ripristino, consulta Corrispondenza delle regole di raggruppamento.

L'esempio seguente mostra come configurare sia le impostazioni di conservazione sia quelle di raggruppamento in PodSnapshotPolicy. Queste impostazioni possono essere configurate in modo indipendente:

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

Per un elenco completo di tutti i campi che puoi configurare, consulta la documentazione di riferimento di PodSnapshotPolicy.

Ottimizzare le dimensioni degli snapshot

Quando viene attivato uno snapshot dei pod, gVisor acquisisce l'intero stato di tutti i container, tra cui:

Stato dell'applicazione, ad esempio memoria e registri
Modifiche al file system radice e a tmpfs (inclusi i volumi emptyDir)
Stato del kernel, ad esempio descrittori di file aperti, thread e socket

Le dimensioni dello snapshot sono determinate da questi fattori. Gli snapshot più grandi richiedono più tempo per essere salvati e ripristinati. Per ottimizzare le prestazioni, prima di attivare uno snapshot, devi liberare spazio da qualsiasi stato o file dell'applicazione che non sono necessari dopo il ripristino del pod dallo snapshot.

L'ottimizzazione delle dimensioni degli snapshot è particolarmente importante per i carichi di lavoro come i modelli linguistici di grandi dimensioni (LLM). I server LLM spesso scaricano i pesi del modello nell'archivio locale (rootfs o tmpfs) prima di caricarli nella GPU. Quando viene acquisito uno snapshot, vengono salvati sia lo stato della GPU sia i file di peso del modello. In questo scenario, se il modello è di 100 GB, lo snapshot risultante è di circa 200 GB (100 GB di file di modello più 100 GB che rappresentano lo stato della GPU). Dopo che i pesi del modello vengono caricati nella GPU, i file sul file system spesso non sono necessari per l'esecuzione dell'applicazione. Se elimini questi file di modello prima di attivare lo snapshot, puoi ridurre le dimensioni dello snapshot della metà e ripristinare l'applicazione con una latenza notevolmente inferiore.

Attivare uno snapshot

Puoi attivare uno snapshot da un carico di lavoro quando l'applicazione è pronta oppure puoi attivare manualmente uno snapshot on demand per un pod specifico.

Attivare uno snapshot da un carico di lavoro

Per attivare uno snapshot dal codice dell'applicazione, configura l'applicazione in modo che invii un segnale quando è pronta per uno snapshot. Per segnalare la disponibilità, scrivi 1 nel file /proc/gvisor/checkpoint, ad esempio echo 1 > /proc/gvisor/checkpoint. L'operazione di scrittura avvia il processo di snapshot in modo asincrono e restituisce immediatamente. La lettura dallo stesso descrittore del file bloccherà il processo di lettura finché non saranno completati sia lo snapshot sia il ripristino e il carico di lavoro non sarà pronto per riprendere.

L'utilizzo esatto varia a seconda dell'applicazione, ma l'esempio seguente mostra un trigger di snapshot per un'applicazione Python. Per attivare uno snapshot da questo carico di lavoro di esempio, segui questi passaggi:

Salva il seguente manifest come 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"

Sostituisci quanto segue:

NAMESPACE: lo spazio dei nomi per i pod.
KSA_NAME: il nome del KSA.

Esegui il deployment dell'applicazione:
```
kubectl apply -f my-app.yaml
```

Attivare manualmente uno snapshot

Per attivare manualmente uno snapshot on demand per un pod specifico, crea una risorsa PodSnapshotManualTrigger.

L'esempio seguente attiva uno snapshot per un pod denominato my-pod. Salva il seguente manifest come example-manual-trigger.yaml:
```
apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotManualTrigger
metadata:
  name: example-manual-trigger
  namespace: NAMESPACE
spec:
  targetPod: my-pod
```
Sostituisci NAMESPACE con lo spazio dei nomi del pod.

Nota: Il criterio di snapshot che seleziona questo pod deve avere il tipo di trigger impostato su manual.

Applica il manifest:

kubectl apply -f example-manual-trigger.yaml

Per verificare se lo snapshot è stato attivato correttamente, controlla il campo status della risorsa PodSnapshotManualTrigger:

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

Il campo status indica se l'attivazione dello snapshot è riuscita o meno.

Verificare gli snapshot

Puoi verificare che sia stata acquisita un'istantanea controllando la cronologia eventi per gli eventi 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