Informazioni sugli snapshot dei pod GKE

Gli snapshot dei pod di Google Kubernetes Engine (GKE) contribuiscono a migliorare la latenza di avvio dei workload ripristinando gli snapshot dei pod in esecuzione. Uno snapshot del pod salva l'intero stato del pod, incluse le modifiche alla memoria e al file system. Quando crei nuove repliche, queste vengono ripristinate dallo snapshot, consentendo al workload di riprendere invece di iniziare da un nuovo stato. Questa funzionalità è utile per scalare orizzontalmente i workload, ad esempio i modelli di inferenza AI che caricano pesi elevati in memoria o le applicazioni che caricano dipendenze estese.

Utilizza questo documento per capire come funzionano gli snapshot dei pod GKE e valutare se i tuoi workload possono trarne vantaggio.

Gli amministratori e gli operatori della piattaforma e gli sviluppatori di applicazioni possono utilizzare questo documento per valutare la compatibilità dei workload, pianificare le policy di archiviazione degli snapshot e comprendere in che modo GKE gestisce il checkpointing e il ripristino. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui si fa riferimento nei contenuti diCloud de Confiance by S3NS , consulta Ruoli e attività comuni degli utenti GKE.

Per preparare e utilizzare gli snapshot dei pod nei tuoi cluster, consulta le seguenti guide:

  1. Preparati per gli snapshot dei pod
  2. Attiva uno snapshot del pod
  3. Ripristina un workload da uno snapshot di un pod

Quando utilizzare gli snapshot dei pod

Utilizza gli snapshot dei pod per i workload con tempi di inizializzazione lunghi. Alcuni esempi sono i workload di inferenza AI che caricano modelli di grandi dimensioni nella memoria della CPU o della GPU o le applicazioni di grandi dimensioni che caricano molte librerie e dipendenze. I workload che hanno già tempi di avvio rapidi in genere non traggono vantaggio dagli snapshot dei pod.

Come funzionano gli snapshot dei pod

Gli snapshot dei pod GKE memorizzano una copia esatta dello stato del processo di un pod in un momento specifico. Quando crei nuove repliche, anziché inizializzare il pod da uno stato nuovo, GKE lo ripristina da uno snapshot. Questo ripristino significa che il pod riprende l'esecuzione dal punto in cui è stato acquisito lo snapshot.

Per configurare gli snapshot dei pod in modo dichiarativo, devi creare risorse personalizzate di Kubernetes per definire il comportamento degli snapshot. Un agente eseguito su ogni nodo GKE gestisce il ciclo di vita degli snapshot. In base alle policy che definisci, l'agente determina quando creare nuovi snapshot e quando utilizzare quelli esistenti per ripristinare i nuovi pod. Un controller in esecuzione sul control plane GKE pulisce gli snapshot obsoleti e risolve i problemi. Cloud Storage archivia gli snapshot dei pod.

Contenuti dello snapshot

La tabella seguente elenca gli elementi inclusi ed esclusi da uno snapshot del pod:

Categoria Incluso Esclusa
Stato applicazione
  • Memoria del processo
  • Thread di esecuzione
  • Registri della CPU
  • Descrittori dei file aperti
 Niente (viene acquisito tutto lo stato del processo in memoria)
File system
  • File system root del container (rootfs)
  • emptyDir volumi
  • tmpfs montaggi
  • Oggetti PersistentVolumeClaim
  • Qualsiasi altro tipo di volume o spazio di archiviazione non elencato come incluso
Networking
  • Connessioni di loopback
  • Socket di ascolto
  • Socket di dominio Unix
  • Connessioni esterne attive (chiuse al ripristino)
  • Route personalizzate
  • Regole definite dall'utente (iptables, nftables)

Risorse personalizzate

Per configurare gli snapshot dei pod in modo dichiarativo, utilizza le seguenti risorse personalizzate:

  • PodSnapshotStorageConfig: specifica la località di archiviazione degli snapshot. Supporta solo i bucket Cloud Storage.
  • PodSnapshotPolicy: definisce i pod di cui eseguire lo snapshot in base ai selettori di etichette di Kubernetes. Questa risorsa personalizzata contiene la maggior parte delle opzioni di configurazione per la funzionalità, tra cui il modo in cui vengono attivati gli snapshot, l'ambito degli snapshot e i criteri di conservazione.
  • PodSnapshotManualTrigger (facoltativo): se non utilizzi un trigger del workload, definisce un trigger manuale per creare uno snapshot per un pod specifico.

Per le specifiche di riferimento, consulta il riferimento CustomResourceDefinition di PodSnapshot.

Trigger snapshot

Puoi attivare uno snapshot del pod nei seguenti modi:

  • Trigger del workload: l'applicazione all'interno del pod segnala all'agente GKE che è pronta per uno snapshot. Questo tipo di trigger viene eseguito una volta in un ciclo di workload, ad esempio in uno stato di workload pronto. Questo approccio è ideale per migliorare la latenza di avvio dei workload con scalabilità orizzontale.
  • Trigger manuale: puoi attivare uno snapshot on demand per un pod specifico creando una risorsa personalizzata PodSnapshotManualTrigger. Questo tipo di trigger può essere eseguito tutte le volte necessarie. Questo approccio è ideale per le situazioni in cui non puoi modificare l'applicazione per segnalare l'idoneità.

Corrispondenza e compatibilità degli snapshot

Per garantire che uno snapshot sia compatibile con un workload ripristinato, GKE esegue la corrispondenza di compatibilità tra il pod originale con checkpoint e il pod di destinazione.

GKE utilizza le seguenti regole per determinare la compatibilità:

  • Ordine di selezione: per impostazione predefinita, GKE ripristina i workload dalla risorsa personalizzata PodSnapshot più recente che corrisponde allo spazio dei nomi e alla configurazione del pod.
  • Criteri di corrispondenza: il controllo di compatibilità dipende dallo scope dello snapshot configurato nella risorsa personalizzata PodSnapshotPolicy (whole-pod o rootfs-only).

Corrispondenza dell'ambito whole-pod (predefinita)

Per le policy con l'ambito whole-pod predefinito, GKE controlla quanto segue:

  • Hash della specifica distillata: GKE genera un hash univoco basato sui campi di runtime essenziali nella specifica del pod. Affinché un ripristino vada a buon fine, il pod di destinazione deve generare un hash identico dalla sua specifica distillata. Questo controllo verifica che i pod sottoposti a checkpoint e ripristinati siano identici nelle loro configurazioni di runtime.

    I seguenti campi dell'oggetto Pod fanno parte della specifica distillata e influenzano l'hash univoco:

    • metadata:
      • annotations: solo le annotazioni pertinenti a GKE Sandbox (ad esempio le annotazioni che iniziano con il prefisso dev.gvisor.*).
      • labels: batch.kubernetes.io/job-completion-index
    • spec:
      • volumes: name, volumeSource, hostPath, persistentVolumeClaim, configMap
      • containers:
        • name
        • image
        • command
        • args
        • workingDir
        • ports: name, containerPort, protocol
        • volumeMounts: name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation, subPathExpr
        • volumeDevices: name
        • lifecycle: postStart, preStop
        • terminationMessagePath
        • terminationMessagePolicy
        • securityContext (e tutti i campi secondari)
        • stdin
        • stdinOnce
        • tty
      • initContainers: gli stessi campi secondari di containers.
      • dnsPolicy
      • automountServiceAccountToken
      • hostNetwork
      • hostPID
      • hostIPC
      • shareProcessNamespace
      • securityContext
      • dnsConfig
      • runtimeClassName
      • os
      • hostUsers

  • Compatibilità hardware: il pod di destinazione deve essere eseguito su un nodo con la stessa serie di macchine, lo stesso fornitore di CPU e lo stesso set di funzionalità della CPU (flag CPUID) del pod di cui è stato eseguito il checkpoint. Ad esempio, entrambi i nodi devono utilizzare la stessa serie N2 o G2 e le stesse funzionalità del processore Intel o AMD. GKE Sandbox verifica le funzionalità della CPU prima di ripristinare la memoria del processo e lo stato della CPU, pertanto uno snapshot con l'ambito whole-pod non può essere ripristinato su un nodo con funzionalità della CPU diverse.

  • Compatibilità delle versioni: la versione kernel di GKE Sandbox e la versione del driver GPU devono corrispondere alla versione acquisita nello snapshot originale.

rootfs-only ambito corrispondente

Quando configuri la policy con l'ambito rootfs-only (disponibile in GKE versione 1.35.3-gke.1031000 e successive), i requisiti di corrispondenza sono meno rigidi:

  • GKE non calcola né confronta l'hash della specifica del pod distillata. Questa corrispondenza meno rigida ti consente di ripristinare uno snapshot in un pod di destinazione con risorse, ambienti o altri campi di configurazione diversi. Tuttavia, l'immagine container sottostante e le versioni dei nodi devono essere compatibili.
  • Poiché la memoria di processo non viene ripristinata, puoi ripristinare gli snapshot acquisiti su una famiglia di macchine in una famiglia di macchine diversa (inclusi i tipi di macchine E2).

Corrispondenza delle regole di raggruppamento

Se la policy utilizza il campo snapshotGroupingRules per raggruppare gli snapshot in base a valori di etichetta specifici (ad esempio tenant o ambiente), il pod ripristinato deve avere chiavi e valori di etichetta corrispondenti. Il controller degli snapshot dei pod seleziona uno snapshot solo dal gruppo corrispondente. Per saperne di più su come configurare le etichette di raggruppamento, consulta Configura impostazioni aggiuntive della policy degli snapshot dei pod.

Ripristina l'idoneità e il caricamento in background

Quando un pod viene ripristinato da uno snapshot, viene ripristinato prima il kernel di GKE Sandbox, il che in genere richiede alcuni secondi. Per ridurre al minimo la latenza di avvio, l'applicazione riprende immediatamente dopo il ripristino del kernel. Non attende il caricamento completo della memoria dell'applicazione. La memoria dell'applicazione viene ripristinata utilizzando un meccanismo di streaming in background.

Se l'applicazione tenta di leggere una parte della memoria che non è stata ancora caricata, si verifica un errore di pagina. GKE Sandbox intercetta questo errore, mette in pausa il thread dell'applicazione e recupera immediatamente la pagina di memoria richiesta dallo spazio di archiviazione. Questo recupero on demand ha la priorità rispetto allo stream in background.

A causa di questo caricamento in background, l'accesso alla memoria potrebbe subire una breve latenza per i primi secondi dopo un ripristino se l'applicazione richiede memoria non in streaming. Questa latenza scompare quando lo stato della memoria è completamente sincronizzato.

Questo comportamento di caricamento in background si applica anche allo stato della GPU. Ad esempio, un pod di un modello linguistico di grandi dimensioni (LLM) potrebbe sembrare nello stato Running e rispondere ai controlli di rete anche se la memoria della GPU è ancora in fase di popolamento. Il modello non sarà completamente reattivo per l'inferenza finché lo stato della GPU non sarà completamente ripristinato. A causa di questo ritardo, quando misuri la velocità di ripristino, assicurati di misurare quando il server di modelli è pronto per gestire le richieste. Puoi verificare l'idoneità del server di modelli utilizzando metriche come il tempo al primo token (TTFT) o i probe di idoneità dei pod.

Stato GPU

Gli snapshot dei pod supportano l'acquisizione dello stato delle GPU. Quando attivi uno snapshot per un pod che utilizza GPU, lo strumento NVIDIA cuda-checkpoint salva lo stato della GPU nella memoria di processo. Questo passaggio contribuisce a garantire che i dati archiviati sulla GPU, come i pesi del modello, siano inclusi nello snapshot. GKE mette in pausa il pod e acquisisce uno snapshot. Durante il ripristino, GKE inverte questa operazione.

Poiché lo stato della GPU viene scritto nella memoria del processo, la memoria utilizzata del pod aumenta durante le operazioni di snapshot e ripristino. Tieni conto di questo requisito di memoria aggiuntivo quando imposti i limiti di memoria per i pod.

Considerazioni per i pod ripristinati

Dal punto di vista dell'API Kubernetes, viene creato un nuovo oggetto Pod. All'avvio del pod, se esiste uno snapshot corrispondente, GKE ripristina il pod da quello snapshot, inclusi la memoria e lo stato del processo originali. Tuttavia, alcuni aspetti dello stato del pod devono cambiare affinché funzioni come una nuova istanza univoca.

Tieni presente le seguenti modifiche di stato dopo un ripristino:

  • Interfacce di rete: il pod ripristinato riceve un nuovo indirizzo IP. Tutte le interfacce e le route vengono riconfigurate. Le connessioni di rete attive esistenti al momento dello snapshot vengono chiuse al ripristino. I socket di ascolto, le connessioni di loopback e le connessioni socket di dominio Unix continuano a funzionare.
  • Nome host: il pod ripristinato assume una nuova identità e riceve un nuovo nome host.
  • Ora effettiva: l'ora effettiva passa all'ora corrente.
  • Stato dell'applicazione: lo stato dell'applicazione deve essere univoco per ogni pod, ad esempio ID esperimento o seed di numeri casuali, e deve essere reinizializzato dopo un ripristino.
  • Secret: le chiavi di crittografia e i certificati creati prima di acquisire lo snapshot devono essere ricreati.
  • Variabili di ambiente: puoi modificare le variabili di ambiente tra uno snapshot e un ripristino. Tuttavia, poiché le variabili di ambiente sono archiviate nella memoria dell'applicazione, GKE Sandbox non può trovarle e sostituirle in modo affidabile. Se il tuo workload si basa su nuove variabili di ambiente dopo un ripristino, il pod deve aggiornarle manualmente. Le nuove variabili di ambiente sono disponibili nel file /proc/gvisor/spec_environ. Il formato file è lo stesso di /proc/<pid>/environ.

Multi-tenancy e identità

Gli snapshot dei pod richiedono associazioni manuali di Identity and Access Management (IAM) per l'oggetto ServiceAccount Kubernetes di ogni pod per utilizzare Cloud Storage. La propagazione delle associazioni IAM manuali può richiedere del tempo, il che potrebbe essere un problema se devi creare snapshot immediatamente dopo la creazione di un pod.

Per risolvere i ritardi e semplificare la gestione multi-tenant, invece di associare manualmente IAM agli oggetti ServiceAccount, puoi utilizzare un account di servizio del nodo GKE per creare token di breve durata on demand. Per configurare gli snapshot dei pod con questo approccio, utilizza il campo tokenSource nella risorsa personalizzata PodSnapshotStorageConfig con uno dei seguenti valori:

  • podKSA (predefinito): utilizza le associazioni IAM manuali tra l'oggetto ServiceAccount del pod e il bucket Cloud Storage.
  • federatedP4SA: utilizza un token specifico per il percorso generato dal service account del nodo.

Requisiti

Per utilizzare gli snapshot dei pod GKE, assicurati di soddisfare i seguenti requisiti:

  • I pod devono essere eseguiti in GKE Sandbox perché gli snapshot dei pod dipendono dall'ambiente isolato fornito da GKE Sandbox.
  • Per lo scope dello snapshot whole-pod predefinito, il nodo in cui viene ripristinato il pod deve avere la stessa serie di macchine, lo stesso fornitore di CPU e le stesse funzionalità della CPU del nodo in cui è stato acquisito lo snapshot. I workload solo CPU possono utilizzare qualsiasi serie di macchine non E2 supportata da GKE Sandbox che soddisfi questi requisiti di compatibilità hardware. Per ulteriori informazioni, vedi Limitazioni.
  • Per utilizzare le GPU con gli snapshot dei pod, devi soddisfare anche i seguenti requisiti:
    • I pod con una singola GPU sono supportati sia sui nodi con una singola GPU sia su quelli con più GPU.
    • I pod multi-GPU sono supportati solo su GPU L4 (tipi di macchine g2-standard-*).
    • Nelle versioni di GKE 1.35.0-gke.1738000 e precedenti, un pod che viene eseguito su un nodo multi-GPU deve utilizzare tutte le GPU disponibili su quel nodo. Nelle versioni 1.35.0-gke.1738000 e successive, i pod possono utilizzare un sottoinsieme di GPU su un nodo.
    • Per i workload GPU, devi utilizzare uno dei seguenti tipi di macchine GPU supportati:
      • g2-standard-4 (1 x L4)
      • g2-standard-8 (1 x L4)
      • g2-standard-12 (1 x L4)
      • g2-standard-16 (1 x L4)
      • g2-standard-32 (1 x L4)
      • g2-standard-48 (4 x L4)
      • g2-standard-96 (8 x L4)
      • a2-highgpu-1g (1 x A100-40GB)
      • a2-ultragpu-1g (1 x A100-80GB)
      • a3-highgpu-1g (1 x H100-80GB)

Limitazioni

Gli snapshot dei pod GKE presentano le seguenti limitazioni:

  • Quando utilizzi lo scope dello snapshot whole-pod predefinito, uno snapshot non può essere ripristinato su una VM di Compute Engine con funzionalità della CPU (flag CPUID) diverse da quelle della VM in cui è stato acquisito lo snapshot:
    • Gli snapshot dei pod con l'ambito whole-pod non supportano la serie di macchine E2 o altre serie di macchine che combinano dinamicamente processori Intel e AMD o generazioni di CPU. Gli snapshot del file system (scope rootfs-only) supportano la serie di macchine E2.
    • Anche all'interno della stessa serie di macchine non E2 e dello stesso fornitore di CPU, Compute Engine potrebbe eseguire il provisioning di VM con piattaforme CPU diverse o set di funzionalità della CPU per VM. Se un pod è pianificato su un nodo con funzionalità della CPU non corrispondenti, il ripristino di uno snapshot con l'ambito whole-pod non riesce.
  • La condivisione della GPU con GPU multi-istanza (MIG) non è supportata.
  • Il container sidecar del driver CSI di Cloud Storage FUSE non è supportato con gli snapshot dei pod.
  • Gli snapshot dei pod non supportano le TPU.

Passaggi successivi