Informazioni sugli snapshot dei pod GKE

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 dei 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 carico di lavoro di riprendere anziché iniziare da un nuovo stato.

Questo documento fornisce una panoramica concettuale degli snapshot dei pod di GKE. Per abilitare e utilizzare questa funzionalità, consulta i seguenti documenti:

  1. Prepararsi per gli snapshot dei pod
  2. Attivare uno snapshot dei pod
  3. Ripristinare un carico di lavoro da uno snapshot dei pod

Quando utilizzare gli snapshot dei pod

Utilizza gli snapshot dei pod per i carichi di lavoro con tempi di inizializzazione lunghi, ad esempio i carichi di lavoro 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 carichi di lavoro 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 di GKE archiviano una copia esatta dello stato del processo di un pod in un momento specifico. Quando vengono create nuove repliche, anziché inizializzare il pod da uno stato nuovo, il pod viene ripristinato da uno snapshot, riprendendo l'esecuzione dal punto in cui è stato creato lo snapshot.

Per utilizzare gli snapshot dei pod, crea definizioni di risorse personalizzate (CRD) di Kubernetes per configurare in modo dichiarativo il comportamento degli snapshot. Un agente in esecuzione 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 gli snapshot esistenti per ripristinare i nuovi pod. Un controller in esecuzione sul piano di controllo GKE pulisce gli snapshot obsoleti e risolve i problemi. Cloud Storage archivia gli snapshot dei pod.

Contenuti degli snapshot

La tabella seguente descrive cosa è incluso e cosa non è incluso in uno snapshot dei pod:

Categoria Incluso in uno snapshot Non incluso in uno snapshot
Stato dell'applicazione L'intero stato dell'applicazione: tutti i descrittori dei file aperti, i thread, i registri della CPU e la memoria.
File system Il file system root del container (rootfs), i volumi EmptyDir e i montaggi tmpfs. Tutto ciò che non è coperto dalla colonna precedente. In particolare, i volumi permanenti non vengono sottoposti a checkpoint.
Networking Connessioni loopback, socket di ascolto e socket di dominio Unix. Le connessioni esterne non vengono ripristinate (vengono terminate al momento del ripristino). Le regole aggiunte dall'utente, come iptables o nftables, e le route non vengono ripristinate.

CustomResourceDefinitions

Gli snapshot dei pod vengono configurati in modo dichiarativo con le seguenti CRD:

  • PodSnapshotStorageConfig: specifica la località di archiviazione degli snapshot. Sono supportati solo i bucket Cloud Storage.
  • PodSnapshotPolicy: definisce i pod di cui creare snapshot in base ai selettori di etichette Kubernetes. Questa risorsa contiene la maggior parte delle opzioni di configurazione della funzionalità, tra cui la modalità di attivazione degli snapshot, l'ambito degli snapshot e le policy di conservazione.
  • PodSnapshotManualTrigger: (facoltativo) se non utilizzi un trigger del carico di lavoro, definisce un trigger manuale per creare uno snapshot per un pod specifico.

Trigger snapshot

Puoi attivare uno snapshot dei pod nei seguenti modi:

  • Trigger del carico di lavoro: 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 carico di lavoro, ad esempio in uno stato di carico di lavoro pronto. Questo approccio è ideale per migliorare la latenza di avvio dei carichi di lavoro 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 che è necessario. Questo approccio è ideale per le situazioni in cui non puoi modificare l'applicazione per segnalare la disponibilità.

Corrispondenza e compatibilità degli snapshot

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

La compatibilità è determinata dalle seguenti regole:

  • Ordine di selezione: per impostazione predefinita, GKE ripristina i carichi di lavoro da la risorsa PodSnapshot più recente che corrisponde allo spazio dei nomi e alla configurazione del pod.
  • Criteri di corrispondenza: il controllo di compatibilità varia a seconda dell'ambito dello snapshot configurato in PodSnapshotPolicy (whole-pod rispetto a rootfs-only).

Corrispondenza dell'ambito whole-pod (impostazione predefinita)

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

  1. Hash della specifica distillata: GKE genera un hash univoco basato sui campi di runtime essenziali nella specifica del pod. Affinché il ripristino vada a buon fine, il pod di destinazione deve generare un hash identico dalla sua specifica distillata. Questo controllo garantisce che i pod con 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 al runtime gVisor (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: stessi campi secondari di containers.
      • dnsPolicy
      • automountServiceAccountToken
      • hostNetwork
      • hostPID
      • hostIPC
      • shareProcessNamespace
      • securityContext
      • dnsConfig
      • runtimeClassName
      • os
      • hostUsers

  2. Compatibilità hardware: il pod di destinazione deve essere eseguito su un nodo con la stessa serie di macchine e architettura della CPU del pod originale con checkpoint (ad esempio, da N2 a N2 o da G2 a G2).

  3. Compatibilità delle versioni: la versione del kernel gVisor e la versione del driver GPU devono corrispondere alla versione acquisita nello snapshot originale.

Corrispondenza dell'ambito rootfs-only

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

  • GKE non calcola né confronta l'hash della specifica del pod distillato. Questa corrispondenza rilassata ti consente di ripristinare uno snapshot in un pod di destinazione con risorse, ambienti o altri campi di configurazione diversi dal pod originale con checkpoint, a condizione che l'immagine container e le versioni dei nodi sottostanti siano compatibili.
  • Poiché la memoria del processo non viene ripristinata, puoi ripristinare gli snapshot creati 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 etichette specifici (ad esempio, per tenant o ambiente), il pod ripristinato deve avere esattamente le stesse chiavi e gli stessi valori delle etichette. Il controller degli snapshot dei pod seleziona solo uno snapshot dal gruppo corrispondente. Per ulteriori informazioni su come configurare le etichette di raggruppamento, consulta Configurare policy di snapshot dei pod aggiuntive policies.

Disponibilità del ripristino e caricamento in background

Quando un pod viene ripristinato da uno snapshot, viene ripristinato prima il kernel gVisor, 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 accedere a una parte della memoria che non è ancora stata caricata, si verifica un errore di pagina. gVisor intercetta questo errore, mette in pausa il thread dell'applicazione e recupera immediatamente la pagina di memoria richiesta dallo spazio di archiviazione. Il recupero on demand ha la priorità rispetto allo stream in background.

A causa di questo caricamento in background, l'accesso alla memoria potrebbe avere una piccola quantità di latenza per i primi secondi dopo un ripristino se l'applicazione ha bisogno di memoria che non è ancora stata trasmessa 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 acquisire il momento in cui il server del modello è stato avviato. Puoi verificare quando il server del modello viene avviato utilizzando metriche come il tempo al primo token (TTFT) o i probe di disponibilità dei pod.

Stato GPU

Gli snapshot dei pod supportano l'acquisizione dello stato delle GPU. Quando attivi uno snapshot per un pod che utilizza le GPU, lo strumento cuda-checkpoint NVIDIA salva lo stato della GPU nella memoria del processo. Ciò significa che tutti i dati archiviati sulla GPU, ad esempio i pesi del modello, sono inclusi nello snapshot. Il pod viene quindi messo in pausa e viene creato uno snapshot. Durante il ripristino, il processo viene invertito.

Poiché lo stato della GPU viene scritto nella memoria del processo, la memoria utilizzata dai pod aumenta durante le operazioni di snapshot e ripristino. Devi tenere 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 pod. Quando il pod viene avviato, se esiste uno snapshot corrispondente, il pod viene ripristinato da questo 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 dello 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 momento del ripristino. I socket di ascolto, le connessioni 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 gli ID esperimento o i seed di numeri casuali, e deve essere reinizializzato dopo un ripristino.
  • Secret: le chiavi di crittografia e i certificati creati prima della creazione dello 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 vengono archiviate nella memoria dell'applicazione, GKE Sandbox non può trovarle e sostituirle in modo affidabile. Se il carico di lavoro 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 del file è lo stesso di /proc/<pid>/environ.

Multi-tenancy e identità

Gli snapshot dei pod richiedono associazioni IAM manuali per l'account di servizio Kubernetes (KSA) di ogni pod per accedere a Cloud Storage. La propagazione delle associazioni IAM manuali può richiedere tempo, il che potrebbe essere un problema se devi creare snapshot immediatamente dopo aver creato un pod.

Per contribuire a risolvere i ritardi e semplificare la gestione multi-tenant, anziché associare manualmente IAM ai KSA, puoi utilizzare facoltativamente un account di servizio dei nodi GKE per creare token di breve durata on demand. Per configurare gli snapshot dei pod con questo approccio, utilizza il campo tokenSource nell'oggetto PodSnapshotStorageConfig con uno dei seguenti valori:

  • podKSA (impostazione predefinita): associazione IAM manuale del KSA del pod al bucket Cloud Storage.
  • federatedP4SA: utilizza un token specifico per il percorso creato dall'account di servizio del nodo.

Limiti e requisiti

Gli snapshot dei pod di GKE presentano i seguenti limiti:

  • I pod devono essere eseguiti in GKE Sandbox perché gli snapshot dei pod dipendono dal runtime del container gVisor fornito da GKE Sandbox.
  • Gli snapshot dei pod non supportano i tipi di macchine E2 quando si utilizza l'ambito dello snapshot whole-pod predefinito. Gli snapshot del file system (rootfs-only) supportano i tipi di macchine E2.
  • Il supporto GPU per gli snapshot dei pod presenta i seguenti requisiti e limitazioni:
    • I pod con una sola GPU sono supportati sia sui nodi con una sola GPU sia sui nodi con più GPU.
    • I pod con più GPU sono supportati solo sulle GPU L4 (tipi di macchine g2-standard-*).
    • La condivisione della GPU con la GPU multi-istanza (MIG) non è supportata.
    • Nelle versioni di GKE 1.35.0-gke.1738000 e precedenti, un pod in esecuzione su un nodo con più 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 delle GPU su un nodo.
    • Gli snapshot dei pod supportano i seguenti tipi di macchine:
      • 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)
  • Il container collaterale del driver CSI di Cloud Storage FUSE non è supportato con gli snapshot dei pod.
  • Gli snapshot dei pod non supportano i tipi di macchine TPU.

Passaggi successivi