Risolvere i problemi relativi agli snapshot dei pod

Questo documento mostra come risolvere i problemi comuni relativi agli snapshot dei pod GKE e alle risorse associate.

Queste informazioni sono importanti per gli sviluppatori di applicazioni e gli amministratori e gli operatori di piattaforme che utilizzano gli snapshot dei pod per controllare e ripristinare i carichi di lavoro. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Cloud de Confiance by S3NS contenuti, consulta Ruoli e attività comuni degli utenti GKE.

Rischi di mutazione post-checkpoint con i PVC

Se il pod utilizza un Persistent Volume Claim (PVC), si verifica un rischio significativo durante il flusso di lavoro "checkpoint e ripristino": se configuri un carico di lavoro in modo che riprenda immediatamente dopo un checkpoint (utilizzando il campo postCheckpoint: resume), l'applicazione rimane attiva e può modificare il PVC dopo il checkpoint.

• Problema di arresto controllato: dopo il ciclo di checkpoint e ripristino, quando elimini un pod, Kubernetes avvia una sequenza di arresto controllato inviando un segnale SIGTERM al processo principale nel container. Molte applicazioni implementano una logica di arresto normale durante la quale potrebbero attivare routine di pulizia per eliminare o aggiornare i file temporanei sul PVC.
• Errore di ripristino: se queste modifiche vengono apportate al PVC dopo l'acquisizione dello snapshot del pod, la procedura di ripristino si aspetterà lo stato del PVC così com'era al momento esatto del checkpoint, il che potrebbe causare errori di ripristino o incoerenza dei dati.
• Mitigazione consigliata: se l'utilizzo di un PVC è necessario per il carico di lavoro, non riprendere il carico di lavoro dopo un checkpoint. Utilizza la configurazione postCheckpoint: stop in PodSnapshotPolicy. Questa configurazione consente di garantire che il processo non abbia la possibilità di eseguire scritture ausiliarie o modifiche dello stato dopo il completamento della fase di checkpoint.

Montaggi di ConfigMap e mascheramento delle directory

Quando integri i dati di configurazione in un container, il metodo di montaggio può influire sull'integrità di uno snapshot.

Se un ConfigMap viene montato utilizzando un montaggio del volume standard, Kubernetes tratta l'intera directory di destinazione come un montaggio esterno. Poiché i montaggi esterni vengono ignorati durante gli snapshot, l'intera directory viene esclusa dallo snapshot.

Nell'esempio seguente, le modifiche apportate alla directory /etc/my-app/ non vengono acquisite nello snapshot perché l'intera directory è un montaggio esterno:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config.json: |
    {
      "mode": "local"
    }
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: gvisor
  containers:
    - name: my-app-container
      image: my-app-image
      volumeMounts:
        - mountPath: /etc/my-app
          name: config-volume
  volumes:
    - name: config-volume
      configMap:
        name: my-config

Per risolvere il problema, utilizza un subPath. Un subPath consente di garantire che solo il file di configurazione specifico venga trattato come un montaggio esterno. Questa configurazione ha come target il file esatto, il che consente ai file e alla struttura rimanenti all'interno della directory principale di rimanere parte del file system locale del container, che viene acquisito correttamente durante il processo di checkpoint.

L'esempio seguente mostra la configurazione volumeMounts che utilizza un subPath:

      volumeMounts:
        - mountPath: /etc/my-app/config.json
          name: config-volume
          subPath: config.json

Volumi anonimi impliciti

Alcune immagini container definiscono i volumi all'interno dei relativi metadati tramite l'istruzione VOLUME nel Dockerfile. Anche se la specifica del pod non definisce un volume, Kubernetes crea automaticamente un volume anonimo per qualsiasi percorso definito come volume nell'immagine di base. Ad esempio, l'immagine alpine/git definisce /git come volume implicito.

Questi volumi anonimi vengono trattati come montaggi esterni e, come i PVC, non vengono sottoposti a checkpoint. Controlla le immagini di base per assicurarti che i dati critici non siano archiviati in volumi impliciti.