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

Questo documento fornisce una panoramica concettuale degli snapshot dei pod di GKE. Per scoprire come abilitare e utilizzare questa funzionalità, consulta Ripristinare da uno snapshot del 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, devi creare 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 control plane 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 del 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.

Definizioni di risorse personalizzate

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 le modalità di attivazione 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 del 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 degli snapshot

La corrispondenza dei pod determina se uno snapshot del pod è compatibile con un pod specifico. Questa corrispondenza viene ottenuta creando un hash univoco dalle specifiche di runtime essenziali del pod, chiamate anche specifiche del pod distillate. Questo hash viene quindi incorporato nello snapshot del pod. Per ripristinare un pod successivo da questo snapshot del pod, è necessario generare un hash identico dalle proprie specifiche del pod distillate. Questa procedura consente di garantire che i pod sottoposti a checkpoint e ripristinati siano identici nelle configurazioni di runtime.

La distillazione semplifica la specifica del pod mantenendo solo i campi di runtime critici, come image, e rimuovendo i campi non essenziali come nodeName o nodeSelector. Devi assicurarti che i valori di questi campi essenziali siano coerenti tra il pod utilizzato per il checkpoint e il pod destinato al ripristino.

I seguenti campi dell'oggetto pod 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

Per essere considerato uno snapshot compatibile, devono corrispondere i seguenti criteri aggiuntivi:

  • Hardware: il nuovo pod deve essere eseguito su un nodo con la stessa serie di macchine e la stessa architettura del pod originale. La serie di macchine e l'architettura devono essere le stesse. Il numero di CPU e la quantità di memoria possono variare. I tipi di macchine E2 non sono supportati a causa della loro architettura sottostante dinamica.
  • Controllo delle versioni: la versione kernel gVisor e la versione del driver GPU devono corrispondere.

GKE gestisce la compatibilità degli snapshot. Se GKE trova uno snapshot compatibile, ripristina il nuovo pod dallo snapshot. Se non esiste uno snapshot compatibile, il pod viene avviato normalmente.

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 di 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. Questo 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 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. Per questo motivo, 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 della 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 del 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 essere modificati 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 semi 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.

Multitenancy e identità

Gli snapshot dei pod richiedono associazioni IAM manuali per ogni account di servizio Kubernetes (KSA) del 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 multitenant, anziché associare manualmente IAM ai KSA, puoi utilizzare facoltativamente 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 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 dal account di servizio del nodo.

Limiti e requisiti

Gli snapshot dei pod di GKE presentano le seguenti limitazioni:

  • 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.
  • Il supporto della 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)
  • L'utilizzo del container sidecar del driver CSI di Cloud Storage FUSE con gli snapshot dei pod non è supportato.
  • Gli snapshot dei pod non supportano i tipi di macchine TPU.

Passaggi successivi