Esegui il ripristino da uno snapshot del pod

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 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 un cluster con la funzionalità di snapshot dei pod abilitata. Per i cluster Standard, devi anche creare o aggiornare un pool di nodi da eseguire in GKE Sandbox. GKE Sandbox è supportato per impostazione predefinita con i cluster Autopilot.

Per abilitare gli snapshot dei pod su un cluster, completa una delle seguenti procedure, a seconda della modalità di funzionamento di GKE che vuoi utilizzare:

Autopilot

  • Per abilitare gli snapshot dei pod su un nuovo cluster, esegui questo comando:

      gcloud container clusters create-auto CLUSTER_NAME \
      --enable-pod-snapshots \
      --location=CONTROL_PLANE_LOCATION \
      --cluster-version=CLUSTER_VERSION

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • CONTROL_PLANE_LOCATION: la posizione del control plane del cluster.
    • CLUSTER_VERSION: la versione del nuovo cluster, che deve essere 1.35.3-gke.1234000 o versioni successive.

  • Per attivare gli snapshot dei pod su un cluster esistente, completa i seguenti passaggi:

    1. Esegui l'upgrade del cluster alla versione 1.35.3-gke.1234000 o successive:

        gcloud container clusters upgrade CLUSTER_NAME \
      --cluster-version=CLUSTER_VERSION \
      --location=CONTROL_PLANE_LOCATION

      Sostituisci quanto segue:

      • CLUSTER_NAME: il nome del tuo cluster.
      • CONTROL_PLANE_LOCATION: la posizione del control plane del cluster.
      • CLUSTER_VERSION: la versione del nuovo cluster, che deve essere 1.35.3-gke.1234000 o versioni successive.

    2. Abilita gli snapshot dei pod sul cluster:

        gcloud container clusters update CLUSTER_NAME \
      --enable-pod-snapshots \
      --location=CONTROL_PLANE_LOCATION

Gli snapshot dei pod non supportano i tipi di macchine E2. In Autopilot, GKE potrebbe utilizzare i nodi E2 per impostazione predefinita. Per contribuire a garantire che i tuoi workload vengano eseguiti su hardware compatibile, devi utilizzare una ComputeClass personalizzata per dare la priorità alle famiglie di macchine compatibili.

Per creare e utilizzare una ComputeClass personalizzata, completa i seguenti passaggi:

  1. Salva il seguente manifest come non-e2-class.yaml:

      apiVersion: cloud.google.com/v1
  kind: ComputeClass
  metadata:
    name: non-e2-class
  spec:
    priorities:
    - machineFamily: n2
    - machineFamily: c3
    activeMigration:
      optimizeRulePriority: false
    whenUnsatisfiable: DoNotScaleUp

  2. Applica il manifest:

      kubectl apply -f non-e2-class.yaml

  3. Nella specifica del pod, fai riferimento a ComputeClass utilizzando il selettore di nodi cloud.google.com/compute-class:

      spec:
    nodeSelector:
      cloud.google.com/compute-class: non-e2-class
    ...

Standard

  • Per abilitare gli snapshot dei pod su un nuovo cluster, esegui questo comando:

      gcloud container clusters create CLUSTER_NAME \
      --enable-pod-snapshots \
      --cluster-version=CLUSTER_VERSION \
      --workload-pool=PROJECT_ID.svc.id.goog \
      --workload-metadata=GKE_METADATA \
      --location=CONTROL_PLANE_LOCATION

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • CLUSTER_VERSION: la versione del nuovo cluster, che deve essere 1.35.3-gke.1234000 o versioni successive.
    • PROJECT_ID: il tuo ID progetto.
    • CONTROL_PLANE_LOCATION: la posizione del control plane del cluster.

  • Per attivare gli snapshot dei pod su un cluster esistente, completa i seguenti passaggi:

    1. Esegui l'upgrade del cluster alla versione 1.35.3-gke.1234000 o successive:

        gcloud container clusters upgrade CLUSTER_NAME \
      --node-pool=NODEPOOL_NAME \
      --cluster-version=CLUSTER_VERSION \
      --location=CONTROL_PLANE_LOCATION

      Sostituisci quanto segue:

      • CLUSTER_NAME: il nome del tuo cluster.
      • NODEPOOL_VERSION: il nome del tuo pool di nodi.
      • CLUSTER_VERSION: la versione a cui aggiornare il nuovo cluster, che deve essere 1.35.3-gke.1234000 o versioni successive.
      • CONTROL_PLANE_LOCATION: la posizione del control plane del cluster.

    2. Abilita gli snapshot dei pod sul cluster:

      gcloud beta container clusters update CLUSTER_NAME \
   --enable-pod-snapshots \
   --location=CONTROL_PLANE_LOCATION

      Sostituisci quanto segue:

      • PROJECT_ID con l'ID progetto.
      • CONTROL_PLANE_LOCATION: la posizione del control plane del cluster.

Per eseguire i pod in GKE Sandbox su un cluster Standard, crea o aggiorna un pool di nodi con gVisor abilitato. Per aggiornare un pool di nodi, utilizza il flag --sandbox type=gvisor. Per creare un pool di nodi con gVisor abilitato, esegui questo comando:

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --location=CONTROL_PLANE_LOCATION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Sostituisci 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.
  • CONTROL_PLANE_LOCATION: la posizione del control plane del cluster.

Per saperne di più sull'utilizzo di gVisor, consulta Isolare i workload utilizzando GKE Sandbox.

Snapshot del negozio

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:

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

Concedi 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 service account Kubernetes (KSA) utilizzato dai pod del carico di lavoro. In alternativa alla concessione di singole autorizzazioni, puoi concedere token di breve durata.

  1. Recupera le credenziali per comunicare con il tuo cluster con i comandi kubectl:

    gcloud container clusters get-credentials "CLUSTER_NAME"

  2. Per ogni pod, completa i seguenti passaggi:

    1. 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 dei pod.

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

Abilita la multitenancy utilizzando token di breve durata

In alternativa alla concessione delle autorizzazioni ai singoli KSA, puoi abilitare il multitenancy utilizzando token di breve durata con ambito limitato. Questo approccio consente di evitare il ritardo di propagazione associato ai binding IAM manuali. Anziché concedere autorizzazioni a ogni KSA, esegui una concessione una tantum del ruolo roles/storage.admin sul bucket di archiviazione degli snapshot all'account di servizio dei nodi GKE. Il account di servizio del nodo crea poi token di breve durata on demand per percorsi specifici.

L'attivazione dei token con gli snapshot dei pod richiede GKE versione 1.35.3-gke.1234000 o successive.

Per abilitare la multitenancy, completa i seguenti passaggi:

  1. Per concedere all'account di servizio del nodo l'autorizzazione ad accedere al bucket, esegui questo comando:

    gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role="roles/storage.admin"

  2. Quando configuri l'archiviazione per gli snapshot, imposta il valore del campo tokenSource su federatedP4SA.

Concedi al controller l'autorizzazione per accedere al bucket Cloud Storage

Per consentire al controller snapshot dei pod di eliminare gli snapshot all'interno del bucket Cloud Storage, al service agent GKE deve essere concessa l'autorizzazione Utente oggetti Storage.

  1. Concedi il ruolo roles/storage.objectUser:

    gcloud projects add-iam-policy-binding "PROJECT_ID" \
  --member="serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
  --role="roles/storage.objectUser" \
  --condition="expression=resource.name.startsWith(\"projects/_/buckets/BUCKET_NAME\"),title=restrict_to_bucket,description=Restricts access to one bucket only"

    Sostituisci quanto segue:

    • PROJECT_NUMBER: il numero del progetto.
    • PROJECT_ID: il tuo ID progetto.
    • BUCKET_NAME: il nome del bucket.

(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:

  1. 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"

  2. Concedi il ruolo roles/storage.bucketViewer a tutti i KSA nello spazio dei nomi di destinazione. Questo ruolo consente ai 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.

  3. Per ogni KSA che deve archiviare gli snapshot dei pod, completa i seguenti passaggi:

    1. Crea una cartella gestita per l'Arabia Saudita:

      gcloud storage managed-folders create "gs://BUCKET_NAME/FOLDER_PATH/"

      Sostituisci FOLDER_PATH con il percorso della cartella gestita, ad esempio my-app-snapshots.

    2. Concedi all'account di servizio di Kubernetes il ruolo personalizzato podSnapshotGcsReadWriter nella 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_NAME con il nome del KSA.

Configura lo spazio di archiviazione per gli snapshot

Per specificare dove archiviare i file snapshot, crea una risorsa PodSnapshotStorageConfig.

  1. 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 come example-pod-snapshot-storage-config:

    apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotStorageConfig
metadata:
  name: example-pod-snapshot-storage-config
spec:
  snapshotStorageConfig:
    gcs:
      bucket: "BUCKET_NAME"
      path: "FOLDER_PATH"
      tokenSource: "TOKEN_SOURCE"

    Sostituisci quanto segue:

    • BUCKET_NAME: il nome del bucket Cloud Storage.
    • FOLDER_PATH: il percorso della cartella gestita di Cloud Storage.
    • TOKEN_SOURCE: il provider di identità per l'accesso. Utilizza podKSA (impostazione predefinita) o federatedP4SA per l'architettura multi-tenant.

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

  1. L'esempio seguente crea una policy 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 TRIGGER_TYPE con il tipo di trigger. I valori supportati sono workload per i trigger basati sul carico di lavoro o manual per gli snapshot on demand.

    Per un elenco completo di tutti i campi che puoi configurare, consulta la documentazione relativa alla definizione di risorsa personalizzata (CRD) PodSnapshotPolicy.

  2. Applica il manifest:

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

Configurare policy snapshot dei pod aggiuntive

Puoi configurare criteri aggiuntivi in PodSnapshotPolicy, ad esempio:

  • Pulizia automatica: per liberare spazio dalle risorse snapshot pod precedenti, configura una policy di conservazione utilizzando il campo spec.retentionConfig. Puoi specificare una durata utilizzando il campo lastAccessTimeout (ad esempio, 7d), dopo la quale lo snapshot viene eliminato.

  • Organizza gli snapshot: puoi raggruppare gli snapshot in modo logico per differenziare quelli scattati in ambienti simili, ma in contesti diversi. Ad esempio, in uno scenario multi-tenant in cui il pod di base potrebbe essere uguale per tutti gli utenti, potresti isolare gli snapshot per utente o gruppo. Per isolare gli snapshot, specifica le etichette di raggruppamento nella policy utilizzando il campo snapshotGroupingRules.

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

# ... other fields omitted
spec:
  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 CRD PodSnapshotPolicy.

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 volumi emptyDir)
  • 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 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 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). Una volta caricati i pesi del modello nella GPU, spesso i file sul file system 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 del 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 l'esempio seguente mostra un trigger di snapshot per un'applicazione Python. Per attivare uno snapshot da questo workload di esempio, completa i seguenti passaggi:

  1. 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"

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

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

  2. Applica 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 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 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.podsnapshot.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 nuovamente 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:

  1. Elimina il pod:

    kubectl delete -f POD_NAME.yaml

    Sostituisci POD_NAME con il nome del tuo pod, ad esempio my-app.

  2. Applica di nuovo il pod:

    kubectl apply -f POD_NAME.yaml

  3. Visualizza i log per confermare il ripristino dello snapshot:

    kubectl logs my-app --namespace NAMESPACE

    L'output dipende da come hai configurato l'applicazione. Nell'applicazione di esempio, i log mostrano GKE Pod Snapshot: restore quando si verifica un'operazione di ripristino.

Esegui il ripristino da uno snapshot specifico

Per impostazione predefinita, GKE ripristina i workload dalla risorsa PodSnapshot più recente che corrisponde al pod. Quando viene creato 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 precedente 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.

Risoluzione dei problemi

La sezione seguente contiene informazioni utili per risolvere i problemi comuni relativi agli snapshot dei pod.

Rischi di mutazione post-checkpoint con i PVC

Si verifica un rischio significativo durante il flusso di lavoro "checkpoint e ripristino" se il tuo pod utilizza una richiesta di volume permanente (PVC). Se configuri un workload in modo che riprenda immediatamente dopo un checkpoint (utilizzando il campo postCheckpoint: resume), l'applicazione rimane attiva e può modificare il PVC dopo il checkpoint.

  • Problema di arresto controllato: dopo il ciclo di checkpoint e ripristino, quando elimini un pod, Kubernetes avvia una sequenza di arresto controllato inviando un segnale SIGTERM al processo principale nel container. Molte applicazioni implementano una logica di arresto normale durante la quale potrebbero attivare routine di pulizia, eliminando o aggiornando i file temporanei sulla PVC.
  • Errore di ripristino: se queste modifiche vengono apportate al PVC dopo l'acquisizione dello snapshot del pod, la procedura di ripristino si aspetterà lo stato del PVC così com'era nell'esatto momento del checkpoint, il che potrebbe causare errori di ripristino o incoerenza dei dati.
  • Mitigazione consigliata: se l'utilizzo di un PVC è necessario per il carico di lavoro, non riprendere il carico di lavoro dopo un checkpoint. Utilizza la configurazione postCheckpoint: stop in PodSnapshotPolicy. Questa configurazione contribuisce a garantire che il processo non abbia l'opportunità di eseguire scritture ausiliarie o modifiche dello stato dopo il completamento della fase di checkpointing.

Montaggi ConfigMap e mascheramento delle directory

Quando si integrano i dati di configurazione in un container, il metodo di montaggio può influire sull'integrità di uno snapshot.

Se un ConfigMap viene montato utilizzando un montaggio del volume standard, Kubernetes considera l'intera directory di destinazione come un montaggio esterno. Poiché i montaggi esterni vengono ignorati durante gli snapshot, l'intera directory viene esclusa dallo snapshot.

Nell'esempio seguente, le modifiche alla directory /etc/my-app/ non vengono acquisite nello snapshot perché l'intera directory è un montaggio esterno:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config.json: |
    {
      "mode": "local"
    }
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: gvisor
  containers:
    - name: my-app-container
      image: my-app-image
      volumeMounts:
        - mountPath: /etc/my-app
          name: config-volume
  volumes:
    - name: config-volume
      configMap:
        name: my-config

Per risolvere il problema, utilizza un subPath. Un subPath contribuisce a garantire che solo il file di configurazione specifico venga trattato come un montaggio esterno. Questa configurazione ha come target il file esatto, il che consente ai file e alla struttura rimanenti all'interno della directory principale di rimanere parte del file system locale del container, che viene acquisito correttamente durante il processo di checkpointing.

L'esempio seguente mostra la configurazione di volumeMounts utilizzando un subPath:

      volumeMounts:
        - mountPath: /etc/my-app/config.json
          name: config-volume
          subPath: config.json

Volumi anonimi impliciti

Alcune immagini container definiscono i volumi all'interno dei metadati (tramite l'istruzione VOLUME nel Dockerfile). Anche se la specifica del pod non definisce un volume, Kubernetes crea automaticamente un volume anonimo per qualsiasi percorso definito come volume nell'immagine di base. Ad esempio, l'immagine alpine/git definisce /git come volume implicito.

Questi volumi anonimi vengono trattati come montaggi esterni e, come i PVC, non vengono controllati. Ti consigliamo di controllare le immagini di base e assicurarti che i dati critici non siano archiviati in questi volumi impliciti.

Passaggi successivi