Gli snapshot dei pod di Google Kubernetes Engine (GKE) contribuiscono a migliorare la latenza di avvio dei carichi di lavoro ripristinando gli snapshot dei pod in esecuzione. Uno snapshot del pod salva l'intero stato del pod, inclusi la memoria e le modifiche al file system root. Quando vengono create nuove repliche, anziché inizializzare il pod da uno stato iniziale, viene ripristinato lo snapshot. Il pod riprende l'esecuzione dal punto in cui è stato creato lo snapshot.
Questo documento spiega come abilitare e configurare gli snapshot dei pod GKE per i tuoi workload.
Per saperne di più sul funzionamento degli snapshot dei pod, consulta la pagina Informazioni sugli snapshot dei pod.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva 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 comando
gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Abilita snapshot dei pod
Per abilitare gli snapshot dei pod, crea o aggiorna innanzitutto un cluster con la funzionalità di snapshot dei pod abilitata. Poi, crea o aggiorna un pool di nodi da eseguire in GKE Sandbox.
Per attivare la funzionalità su un cluster, completa uno dei seguenti passaggi:
Per abilitare gli snapshot dei pod su un nuovo cluster, esegui questo comando:
gcloud beta container clusters create CLUSTER_NAME \ --enable-pod-snapshots \ --cluster-version=CLUSTER_VERSION \ --workload-pool=PROJECT_ID.svc.id.goog \ --workload-metadata=GKE_METADATASostituisci quanto segue:
CLUSTER_NAME: il nome del tuo cluster.CLUSTER_VERSION: la versione del nuovo cluster, che deve essere 1.34.1-gke.3084001 o versioni successive.PROJECT_ID: il tuo ID progetto.
Per attivare gli snapshot dei pod su un cluster esistente, completa i seguenti passaggi:
Aggiorna il cluster alla versione 1.34.1-gke.3084001 o successiva:
gcloud container clusters upgrade CLUSTER_NAME \ --node-pool=NODEPOOL_NAME \ --cluster-version=CLUSTER_VERSIONSostituisci quanto segue:
CLUSTER_NAME: il nome del tuo cluster.NODEPOOL_VERSION: il nome del tuo node pool.CLUSTER_VERSION: la versione a cui aggiornare il nuovo cluster, che deve essere 1.34.1-gke.3084001 o versioni successive.
Abilita gli snapshot dei pod sul cluster:
gcloud container clusters update CLUSTER_NAME \ --workload-pool=PROJECT_ID .svc.id.goog" \ --enable-pod-snapshotsSostituisci
PROJECT_IDcon l'ID progetto.
Abilita GKE Sandbox sul cluster Standard:
gcloud container node-pools create NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --node-version=NODE_VERSION \ --machine-type=MACHINE_TYPE \ --image-type=cos_containerd \ --sandbox type=gvisorSostituisci le seguenti variabili:
NODE_POOL_NAME: il nome del nuovo pool di nodi.NODE_VERSION: la versione da utilizzare per il pool di nodi.MACHINE_TYPE: il tipo di macchina da utilizzare per i nodi.
Per saperne di più sull'utilizzo di gVisor, consulta Isolare i workload utilizzando GKE Sandbox.
Snapshot dello store
Gli snapshot dei pod vengono archiviati in un bucket Cloud Storage, che contiene la memoria e (facoltativamente) lo stato della GPU. Gli snapshot dei pod richiedono Workload Identity Federation for GKE per abilitare e utilizzare il account di servizio del pod per l'autenticazione su Cloud Storage.
Gli snapshot dei pod richiedono la seguente configurazione per il bucket:
- Spazi dei nomi gerarchici: devono essere abilitati per consentire un numero maggiore di query di lettura e scrittura al secondo. Gli spazi dei nomi gerarchici richiedono anche l'abilitazione dell'accesso uniforme a livello di bucket.
- Eliminazione temporanea: poiché gli snapshot dei pod utilizzano caricamenti compositi paralleli, devi disattivare le funzionalità di protezione dei dati come l'eliminazione temporanea. Se lasciata attiva, l'eliminazione degli oggetti temporanei può aumentare notevolmente la fattura di archiviazione.
- Posizione: la posizione del bucket Cloud Storage deve essere la stessa del cluster GKE, perché le prestazioni potrebbero essere influenzate se gli snapshot vengono trasferiti in regioni diverse.
crea un bucket Cloud Storage
Per creare il bucket e le autorizzazioni richieste, completa i seguenti passaggi:
Creare un bucket Cloud Storage. Il seguente comando crea un bucket con la configurazione richiesta:
gcloud storage buckets create "gs://BUCKET_NAME" \ --uniform-bucket-level-access \ --enable-hierarchical-namespace \ --soft-delete-duration=0d \ --location="LOCATION"Sostituisci quanto segue:
BUCKET_NAME: il nome del bucket.LOCATION: la posizione del bucket.
Per un elenco completo delle opzioni per la creazione di bucket, consulta le opzioni
buckets create.
Concedere ai workload l'autorizzazione per accedere al bucket Cloud Storage
Per impostazione predefinita, GKE non dispone delle autorizzazioni per accedere a Cloud Storage. Per leggere e scrivere file snapshot, devi concedere le autorizzazioni IAM al account di servizio Kubernetes (KSA) utilizzato dai pod del carico di lavoro.
Recupera le credenziali per comunicare con il tuo cluster con i comandi
kubectl:gcloud container clusters get-credentials "CLUSTER_NAME"Per ogni pod, completa i seguenti passaggi:
Crea un KSA per ogni pod:
kubectl create serviceaccount "KSA_NAME" \ --namespace "NAMESPACE"Sostituisci quanto segue:
KSA_NAME: il nome del tuo KSA.NAMESPACE: lo spazio dei nomi per i pod.
Concedi all'account di servizio Kubernetes l'autorizzazione ad accedere al bucket:
gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role="roles/storage.bucketViewer"gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role="roles/storage.objectUser"Sostituisci quanto segue:
PROJECT_NUMBER: il numero del progetto.PROJECT_ID: il tuo ID progetto.
(Facoltativo) Crea cartelle gestite per il bucket Cloud Storage
La creazione di cartelle consente di isolare le autorizzazioni per gli snapshot dai pod reciprocamente non attendibili, il che è utile nei casi d'uso multi-tenant. Per configurare le cartelle gestite, completa i seguenti passaggi:
Crea un ruolo IAM personalizzato che contenga solo le autorizzazioni necessarie per gli snapshot dei pod:
gcloud iam roles create podSnapshotGcsReadWriter \ --project="PROJECT_ID" \ --permissions="storage.objects.get,storage.objects.create,storage.objects.delete,storage.folders.create"Concedi il ruolo
roles/storage.bucketViewera tutti gli account di servizio Kubernetes nello spazio dei nomi di destinazione. Questo ruolo consente agli KSA di leggere i metadati del bucket, ma non concede autorizzazioni di lettura o scrittura per gli oggetti nel bucket.gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE" \ --role="roles/storage.bucketViewer"Sostituisci quanto segue:
PROJECT_NUMBER: il numero del progetto.PROJECT_ID: il tuo ID progetto.
Per ogni KSA che deve archiviare gli snapshot dei pod, completa i seguenti passaggi:
Crea una cartella gestita per l'Arabia Saudita:
gcloud storage managed-folders create "gs://BUCKET_NAME/FOLDER_PATH/"Sostituisci
FOLDER_PATHcon il percorso della cartella gestita, ad esempiomy-app-snapshots.Concedi all'account di servizio di Kubernetes il ruolo personalizzato
podSnapshotGcsReadWriternella cartella gestita:gcloud storage managed-folders add-iam-policy-binding "gs://BUCKET_NAME/FOLDER_PATH/" \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role="projects/PROJECT_ID/roles/podSnapshotGcsReadWriter"Sostituisci
KSA_NAMEcon il nome del KSA.
Configura lo spazio di archiviazione per gli snapshot
Per specificare dove archiviare i file snapshot, crea una risorsa PodSnapshotStorageConfig.
Il seguente esempio configura GKE per archiviare gli snapshot dei pod nel percorso
FOLDER_PATH/all'interno del bucket Cloud Storage BUCKET_NAME. Salva il seguente manifest comeexample-pod-snapshot-storage-config:apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotStorageConfig metadata: name: example-pod-snapshot-storage-config namespace: NAMESPACE spec: snapshotStorageConfig: gcs: bucket: "BUCKET_NAME" path: "FOLDER_PATH"Sostituisci quanto segue:
NAMESPACE: lo spazio dei nomi per i pod. Per impostazione predefinita, questo valore èdefault.BUCKET_NAME: il nome del bucket Cloud Storage.FOLDER_PATH: il percorso della cartella gestita di Cloud Storage.
Applica il manifest:
kubectl apply -f example-pod-snapshot-storage-config.yaml
Crea una policy 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 una policy che si applica ai pod con l'etichetta
app: my-appe utilizza la configurazione di archiviazioneexample-pod-snapshot-storage-config. Salva il seguente manifest comeexample-pod-snapshot-policy.yaml:apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotPolicy metadata: name: example-pod-snapshot-policy namespace: NAMESPACE spec: storageConfigName: example-pod-snapshot-storage-config selector: matchLabels: app: my-app triggerConfig: type: workload postCheckpoint: resumeApplica il manifest:
kubectl apply -f example-pod-snapshot-policy.yaml --namespace NAMESPACE
Ottimizzare le dimensioni dello snapshot
Quando viene attivato uno snapshot del pod, gVisor acquisisce l'intero stato di tutti i container, tra cui:
- Stato dell'applicazione, ad esempio memoria e registri
- Modifiche al file system root e a
tmpfs(inclusi i volumiemptyDir) - Stato del kernel, ad esempio descrittori di file aperti, thread e socket
La dimensione dello snapshot è determinata da questi fattori. Gli snapshot più grandi richiedono più tempo per il salvataggio e il ripristino. Per ottimizzare le prestazioni, prima di attivare uno snapshot, devi pulire lo stato o i file dell'applicazione che non sono necessari dopo il ripristino del pod dallo snapshot.
L'ottimizzazione delle dimensioni degli snapshot è particolarmente importante per i workload 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 dei pesi del modello. In questo
scenario, se il modello è di 100 GB, lo snapshot risultante è di circa 200 GB (100 GB
di file del modello più 100 GB che rappresentano lo stato della GPU). Dopo che i pesi del modello
sono stati caricati nella GPU, i file sul file system spesso non
sono necessari per l'esecuzione dell'applicazione. Eliminando questi file del 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 dall'interno di un workload quando l'applicazione è pronta oppure puoi attivare manualmente uno snapshot on demand per un pod specifico.
Attivare uno snapshot da un workload
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 viene restituita immediatamente. La lettura dallo stesso descrittore di file
bloccherà il processo di lettura finché lo snapshot e il ripristino non saranno completi
e il workload non sarà pronto per riprendere.
L'utilizzo esatto varia a seconda dell'applicazione, ma il seguente esempio mostra un trigger di snapshot per un'applicazione Python. Per attivare uno snapshot da questo workload di esempio, completa i seguenti 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 except OSError as e: return e 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"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'attivazione manuale di uno snapshot è disponibile
in GKE 1.34.1-gke.3556000 e versioni successive.
L'esempio seguente attiva uno snapshot per un pod denominato
my-pod. Salva il seguente manifest comeexample-manual-trigger.yaml:apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotManualTrigger metadata: name: example-manual-trigger namespace: NAMESPACE spec: targetPod: my-podApplica il manifest:
kubectl apply -f example-manual-trigger.yaml --namespace NAMESPACE
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 stato acquisito uno snapshot controllando la cronologia degli 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
Sostituisci POD_NAME con il nome del tuo pod, ad esempio my-app o my-pod.
L'output è simile al seguente:
NAME CREATIONTIME REASON MESSAGE
default/5b449f9c7c-bd7pc 2025-11-05T16:25:11Z GKEPodSnapshotting Successfully checkpointed the pod to PodSnapshot
Gestire gli snapshot
Quando crei uno snapshot del pod, viene creata una risorsa CRD PodSnapshot per
memorizzare lo stato del pod in quel momento. Il campo status di questa risorsa indica
se l'operazione di snapshot è andata a buon fine e se lo snapshot è disponibile per i ripristini.
Per visualizzare tutte le risorse PodSnapshot in uno spazio dei nomi, esegui questo comando:
kubectl get podsnapshots.gke.io --namespace NAMESPACE
L'output è simile al seguente:
NAME STATUS POLICY AGE
de334898-1e7a-4cdb-9f2e-7cc2181c29e4 AllSnapshotsAvailable example-policy 47h
Ripristina un workload da uno snapshot
Per ripristinare il workload dall'ultimo snapshot, puoi eliminare il pod esistente dopo aver acquisito uno snapshot e poi eseguire di nuovo il deployment del pod. In alternativa, puoi eseguire il deployment di un nuovo pod con una specifica identica. GKE ripristina automaticamente il pod dallo snapshot corrispondente.
I seguenti passaggi mostrano come viene ripristinato un pod da uno snapshot corrispondente eliminando e ridistribuendo il pod:
Elimina il pod:
kubectl delete -f POD_NAME.yamlSostituisci
POD_NAMEcon il nome del tuo pod, ad esempiomy-app.Applica di nuovo il pod:
kubectl apply -f POD_NAME.yamlVisualizza i log per confermare il ripristino dello snapshot:
kubectl logs my-app --namespace NAMESPACEL'output dipende da come hai configurato l'applicazione. Nell'applicazione di esempio, i log mostrano
GKE Pod Snapshot: restorequando si verifica un'operazione di ripristino.
Esegui il ripristino da uno snapshot specifico
Per impostazione predefinita, GKE ripristina i carichi di lavoro dalla risorsa PodSnapshot
più recente che corrisponde al pod. Quando viene acquisito uno snapshot, GKE
genera automaticamente un nome univoco (UUID) per la risorsa PodSnapshot, che puoi
visualizzare eseguendo kubectl get podsnapshots.gke.io --namespace NAMESPACE.
Per ripristinare un workload da una risorsa PodSnapshot più vecchia o specifica, aggiungi l'annotazione podsnapshot.gke.io/ps-name alla specifica del pod del workload, specificando il nome della risorsa PodSnapshot da utilizzare per il ripristino del workload:
apiVersion: v1
kind: Pod
metadata:
name: my-app
namespace: NAMESPACE
labels:
app: my-app
annotations:
podsnapshot.gke.io/ps-name: "POD_SNAPSHOT_NAME"
spec:
serviceAccountName: KSA_NAME
runtimeClassName: gvisor
containers:
...
Sostituisci POD_SNAPSHOT_NAME con il nome dello snapshot
da cui vuoi eseguire il ripristino. Puoi ottenere i nomi degli snapshot eseguendo il comando kubectl get podsnapshots.gke.io --namespace NAMESPACE.
Affinché GKE utilizzi lo snapshot specificato per il ripristino, la condizione di stato della risorsa PodSnapshot deve essere Ready ed esistere nello stesso spazio dei nomi del pod. Se PodSnapshot non è Ready o non esiste nello stesso spazio dei nomi del pod, il workload esegue un avvio a freddo anziché il ripristino da uno snapshot.
Disattivare gli snapshot
La rimozione della CRD PodSnapshotPolicy impedisce la creazione di snapshot e il ripristino dei pod. I pod in esecuzione non sono interessati dall'eliminazione delle risorse. Tuttavia, se
elimini il criterio mentre un pod viene salvato o ripristinato, il pod potrebbe entrare in uno
stato di errore.
Per disattivare la creazione di snapshot e il ripristino per i nuovi pod regolati da un criterio,
elimina PodSnapshotPolicy eseguendo questo comando:
kubectl delete podsnapshotpolicies.podsnapshot.gke.io SNAPSHOT_POLICY --namespace=NAMESPACE
Sostituisci SNAPSHOT_POLICY con il nome del
PodSnapshotPolicy che vuoi eliminare, ad esempio
example-pod-snapshot-policy.
Puoi anche eliminare una risorsa PodSnapshot specifica in modo che i pod non vengano più ripristinati da quello snapshot specifico. L'eliminazione della risorsa
PodSnapshot rimuove anche i file archiviati in Cloud Storage.
Per impedire l'utilizzo di uno snapshot specifico per i ripristini futuri,
elimina l'oggetto PodSnapshot eseguendo il seguente comando:
kubectl delete podsnapshots.podsnapshot.gke.io POD_SNAPSHOT_NAME --namespace=NAMESPACE
Sostituisci POD_SNAPSHOT_NAME con il nome dello snapshot che vuoi eliminare, ad esempio example-podsnapshot.
Passaggi successivi
- Scopri di più sui concetti relativi agli snapshot dei pod.
- Consulta le definizioni di risorse personalizzate (CRD) degli snapshot dei pod.