Informazioni sugli snapshot dei pod GKE

Standard

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

Questo documento fornisce una panoramica concettuale degli snapshot dei pod GKE. Per scoprire come attivare 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 GKE memorizzano 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 iniziale, 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 ai criteri che definisci, l'agente determina quando creare nuovi snapshot e quando utilizzare snapshot esistenti per ripristinare 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.

Definizioni di risorse personalizzate

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

PodSnapshotStorageConfig: specifica la posizione di archiviazione degli snapshot. Sono supportati solo i bucket Cloud Storage.
PodSnapshotPolicy: definisce quali pod creare snapshot in base ai selettori di etichette Kubernetes. Questa risorsa contiene la maggior parte delle opzioni di configurazione della funzionalità, inclusi i criteri di conservazione e le modalità di attivazione degli snapshot.
PodSnapshotManualTrigger: (facoltativo) se non utilizzi un trigger del workload, definisce un trigger manuale per creare uno snapshot per un pod specifico.

Attivatori di 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 workload, ad esempio quando il 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 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, chiamato anche specifica del pod distillata. Questo hash viene poi incorporato nello snapshot del pod. Affinché un pod successivo venga ripristinato da questo snapshot del pod, deve generare un hash identico dalla propria specifica del pod distillata. Questo processo contribuisce a 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 influiscono sull'hash univoco:

metadata:
- annotations: solo le annotazioni pertinenti al runtime gVisor, ad esempio quelle 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 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 e l'architettura della macchina 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 dinamica sottostante.
Controllo delle versioni: la versione del 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 si avvia normalmente.

Ripristina il caricamento in background e la preparazione

Quando un pod viene ripristinato da uno snapshot, viene ripristinato prima il kernel gVisor, 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 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. 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 necessita 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 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 è stato avviato il server del modello. Puoi controllare quando viene avviato il server del modello utilizzando metriche come Time-to-First-Token (TTFT) o probe di disponibilità del pod.

Stato della 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 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, l'utilizzo della memoria 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 viene avviato il pod, se esiste uno snapshot corrispondente per il pod, il pod viene ripristinato da questo snapshot, incluso lo stato originale della memoria e del processo. 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 di rete e le route vengono riconfigurate. Le connessioni di rete attive esistenti al momento dello snapshot vengono chiuse al ripristino. I socket di ascolto continuano a funzionare.
Nome host: il pod ripristinato assume una nuova identità e riceve un nuovo nome host.
Stato dell'applicazione: lo stato dell'applicazione che deve essere univoco per ogni pod, come gli ID esperimento o i valori iniziali dei numeri casuali, deve essere reinizializzato dopo un ripristino.
Secret: le chiavi di crittografia e i certificati creati prima dell'acquisizione 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 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 del file è lo stesso di /proc/<pid>/environ.

Stato che cambia dopo il ripristino

Non tutto lo stato viene mantenuto durante il ripristino. Le seguenti parti dello stato del pod cambiano in modo che il pod possa assumere una nuova identità:

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.
Tempo reale: il tempo reale viene spostato in avanti fino all'ora corrente.

Limitazioni e requisiti

Gli snapshot dei pod 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.
Gli snapshot dei pod funzionano con i pod con una sola GPU. Sono supportate solo le seguenti configurazioni multi-GPU:
- 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 parziale della GPU non è supportato. Se un nodo ha più GPU, un pod deve utilizzarle tutte. Ad esempio, non puoi utilizzare gli snapshot dei pod con quattro pod che utilizzano ciascuno una GPU su una macchina con quattro GPU.
L'utilizzo del container sidecar del driver CSI di Cloud Storage FUSE con gli snapshot dei pod non è supportato.

Passaggi successivi

Per scoprire come utilizzare gli snapshot dei pod, consulta Ripristinare da uno snapshot del pod.