Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Cloud de Confiance di S3NS. Per maggiori dettagli, consulta Differenze rispetto a Google Cloud.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Attivare uno snapshot dei pod

Autopilot Standard

Per ridurre la latenza di avvio dei workload di Google Kubernetes Engine (GKE), puoi acquisire uno snapshot di un pod in esecuzione e ripristinare nuovi pod da questo snapshot. Questo documento mostra come creare una policy di snapshot dei pod e attivare uno snapshot, dal tuo workload o manualmente. Per ulteriori informazioni sul funzionamento degli snapshot dei pod, consulta Informazioni sugli snapshot dei pod GKE.

Questo documento è rivolto agli amministratori e agli operatori della piattaforma e agli sviluppatori di applicazioni, che possono utilizzarlo per configurare le policy snapshot e attivare gli snapshot. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui si fa riferimento nei contenuti di Cloud de Confiance by S3NS, consulta Ruoli e attività comuni degli utenti GKE.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

Abilita l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Per 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.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Completa i prerequisiti e abilita gli snapshot dei pod nel tuo cluster. Per ulteriori informazioni sulla preparazione del cluster e dello spazio di archiviazione, consulta Preparati per gli snapshot dei pod.

Crea una policy di snapshot

Per abilitare gli snapshot per un pod, crea una risorsa personalizzata PodSnapshotPolicy con un selettore che corrisponda alle etichette del pod:

Salva il seguente manifest come example-pod-snapshot-policy.yaml. Questo esempio crea una policy che si applica ai pod con l'etichetta app: my-app. La policy utilizza la risorsa personalizzata PodSnapshotStorageConfig example-pod-snapshot-storage-config, che hai creato in Preparati per gli snapshot dei pod, per definire la località di archiviazione degli snapshot:
```
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 quanto segue:
- NAMESPACE: lo spazio dei nomi dei pod. Utilizza lo stesso spazio dei nomi a cui hai concesso l'accesso a Cloud Storage in Preparati per gli snapshot dei pod.
- TRIGGER_TYPE: il tipo di trigger. I valori supportati sono workload per i trigger basati sul workload o manual per gli snapshot on demand.
In questo esempio, l'impostazione postCheckpoint: resume mantiene il pod in esecuzione dopo che GKE ha acquisito lo snapshot.

Per un elenco completo dei campi che puoi configurare, consulta la specifica PodSnapshotPolicy.

Applica il manifest:

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

Configura impostazioni aggiuntive della policy di snapshot dei pod

La risorsa personalizzata PodSnapshotPolicy supporta anche impostazioni facoltative oltre al selettore, alla configurazione dello spazio di archiviazione e al trigger obbligatori. Queste impostazioni aggiuntive controllano cosa acquisisce ogni snapshot, per quanto tempo GKE conserva gli snapshot e come GKE raggruppa gli snapshot per i ripristini:

Scope dello snapshot: per specificare quali parti dello stato del pod acquisire nello snapshot, configura il campo spec.snapshotScope. I valori supportati sono whole-pod (predefinito) e rootfs-only. L'ambito whole-pod acquisisce l'intero pod, inclusi lo stato dell'applicazione, la memoria e i file system. L'ambito rootfs-only acquisisce solo il file system radice del container. L'ambito rootfs-only richiede GKE 1.35.3-gke.1031000 o versioni successive.
Pulizia automatica: per pulire automaticamente le risorse personalizzate PodSnapshot precedenti, configura una policy di conservazione utilizzando il campo spec.retentionConfig. Puoi specificare una durata utilizzando il campo lastAccessTimeout, ad esempio 7d. Trascorso questo periodo di tempo, GKE elimina lo snapshot.
Raggruppamento di snapshot: per isolare gli snapshot acquisiti in ambienti simili, ma in contesti diversi, specifica le etichette di raggruppamento nel campo spec.snapshotGroupingRules. Ad esempio, in uno scenario multi-tenant in cui il pod di base è uguale per tutti gli utenti, puoi isolare gli snapshot per utente o gruppo. Durante un ripristino, GKE seleziona uno snapshot solo dallo stesso gruppo di etichette. Per saperne di più su come questo raggruppamento influisce sulla corrispondenza di compatibilità durante il ripristino, consulta Corrispondenza delle regole di raggruppamento.

Puoi configurare le impostazioni di scope, conservazione e raggruppamento degli snapshot in modo indipendente. L'esempio seguente mostra tutte e tre le impostazioni in una risorsa personalizzata PodSnapshotPolicy:

# Multiple lines are omitted here
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

Per un elenco completo dei campi che puoi configurare, consulta la specifica PodSnapshotPolicy.

Ottimizza le dimensioni degli snapshot

Gli snapshot più grandi richiedono più tempo per il salvataggio e il ripristino. Prima di attivare uno snapshot, riducine le dimensioni eliminando i file temporanei o lo stato dell'applicazione non necessari dopo che GKE ha ripristinato il pod dallo snapshot.

Con lo scope dello snapshot whole-pod predefinito, GKE Sandbox acquisisce l'intero stato di tutti i container, inclusi i seguenti:

Stato dell'applicazione, ad esempio memoria e registri
Modifiche al file system radice e ai punti di montaggio tmpfs (inclusi i volumi emptyDir)
Stato del kernel, ad esempio descrittori dei file aperti, thread e socket

L'ottimizzazione delle dimensioni degli snapshot è particolarmente importante per workload come i modelli linguistici di grandi dimensioni (LLM). I server LLM spesso scaricano i pesi del modello nello spazio di archiviazione locale (rootfs o tmpfs) prima di caricarli nella GPU. Quando acquisisci uno snapshot, GKE Sandbox salva 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). Dopo che l'applicazione ha caricato i pesi del modello nella GPU, spesso non ha bisogno dei file nel file system per l'esecuzione. Eliminando questi file di modello prima di attivare lo snapshot, puoi dimezzare le dimensioni dello snapshot e ripristinare l'applicazione con una latenza notevolmente inferiore.

Attiva uno snapshot

Scegli uno dei seguenti metodi per attivare uno snapshot:

Trigger del workload: utilizza questo metodo quando puoi modificare l'applicazione per segnalare che è pronta per uno snapshot, ad esempio dopo il completamento dell'inizializzazione. Questo metodo è ideale per migliorare la latenza di avvio dei workload con scalabilità orizzontale. Un trigger del workload viene eseguito una sola volta in un ciclo del workload.
Trigger manuale: utilizza questo metodo quando non puoi modificare l'applicazione per segnalare l'idoneità o quando vuoi snapshot on demand di un pod specifico. Puoi creare un trigger manuale tutte le volte che vuoi.

Attiva 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 l'idoneità, scrivi il valore 1 nel file /proc/gvisor/checkpoint, ad esempio eseguendo il comando echo 1 > /proc/gvisor/checkpoint. L'operazione di scrittura avvia il processo di snapshot in modo asincrono e restituisce immediatamente il risultato. La lettura dallo stesso descrittore del file blocca il processo di lettura fino al completamento dell'operazione di snapshot o ripristino e finché il workload non è pronto per essere ripreso.

Prima di attivare uno snapshot da un workload, assicurati che una policy di snapshot selezioni il pod. Il valore del campo triggerConfig.type in questa policy deve essere impostato su workload.

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, segui questi passaggi:

Salva il seguente manifest come my-app.yaml. In questo esempio, l'etichetta app: my-app corrisponde al selettore nella policy snapshot di esempio e l'impostazione runtimeClassName: gvisor esegue il pod in GKE Sandbox:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
spec:
  serviceAccountName: SERVICEACCOUNT_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
        i = 0
        while True:
          print(f"Count: {i}", flush=True)
          if (i == 20): # Simulate readiness at the 20th count
            trigger_snapshot()
          i += 1
          time.sleep(1)
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "250m"
        memory: "256Mi"

Sostituisci quanto segue:

NAMESPACE: lo spazio dei nomi dei pod.
SERVICEACCOUNT_NAME: il nome dell'oggetto ServiceAccount a cui hai concesso l'accesso a Cloud Storage in Preparati per gli snapshot dei pod.

Esegui il deployment dell'applicazione:
```
kubectl apply -f my-app.yaml
```
Dopo l'avvio dell'applicazione e la segnalazione che è pronta, GKE Sandbox acquisisce lo snapshot. Per verificare che lo snapshot sia stato creato correttamente, consulta Verifica gli snapshot.

Attiva manualmente uno snapshot

Prima di attivare manualmente uno snapshot, assicurati che il pod di destinazione sia in esecuzione e che una policy di snapshot selezioni il pod. Il valore del campo triggerConfig.type in questa policy deve essere impostato su manual.

Per attivare manualmente uno snapshot on demand per un pod specifico, crea una risorsa personalizzata PodSnapshotManualTrigger seguendo questi passaggi:

Salva il seguente manifest come example-manual-trigger.yaml. Questo esempio attiva uno snapshot per un pod denominato my-pod:
```
apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotManualTrigger
metadata:
  name: example-manual-trigger
  namespace: NAMESPACE
spec:
  targetPod: my-pod
```
Sostituisci NAMESPACE con lo spazio dei nomi dei tuoi pod.