Fehlerbehebung bei Pod-Snapshots

In diesem Dokument wird beschrieben, wie Sie häufige Probleme mit GKE-Pod-Snapshots und den zugehörigen Ressourcen beheben.

Diese Informationen sind wichtig für Anwendungsentwickler und Plattformadministratoren und -operatoren, die Pod-Snapshots verwenden, um Arbeitslasten zu sichern und wiederherzustellen. Weitere Informationen zu den häufig verwendeten Rollen und Beispielaufgaben, auf die wir in Inhalten verweisen Cloud de Confiance by S3NS , finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Risiken durch Änderungen nach dem Checkpoint bei PVCs

Wenn Ihr Pod einen Persistent Volume Claim (PVC) verwendet, besteht während des Ablaufs „Checkpoint und Fortsetzen“ ein erhebliches Risiko: Wenn Sie eine Arbeitslast so konfigurieren, dass sie sofort nach einem Checkpoint fortgesetzt wird (mit dem Feld postCheckpoint: resume), bleibt die Anwendung aktiv und kann den PVC nach dem Checkpoint ändern.

• Problem mit ordnungsgemäßem Herunterfahren: Wenn Sie nach dem Checkpoint- und Fortsetzungszyklus einen Pod löschen, initiiert Kubernetes eine ordnungsgemäße Herunterfahrsequenz, indem ein SIGTERM Signal an den Hauptprozess im Container gesendet wird. Viele Anwendungen implementieren eine Logik für das ordnungsgemäße Herunterfahren, bei der möglicherweise Bereinigungsroutinen ausgelöst werden, um temporäre Dateien auf dem PVC zu löschen oder zu aktualisieren.
• Fehler bei der Wiederherstellung: Wenn diese Änderungen nach der Erstellung des Pod Snapshots am PVC vorgenommen werden, erwartet die Wiederherstellungsprozedur den PVC-Status, der zum Zeitpunkt des Checkpoints vorhanden war. Dies kann zu Fehlern bei der Wiederherstellung oder zu Dateninkonsistenzen führen.
• Empfohlene Maßnahmen: Wenn die Verwendung eines PVC für die Arbeitslast erforderlich ist, setzen Sie die Arbeitslast nach einem Checkpoint nicht fort. Verwenden Sie die Konfiguration postCheckpoint: stop in Ihrer PodSnapshotPolicy. Diese Konfiguration trägt dazu bei, dass der Prozess nach Abschluss der Checkpoint-Phase keine zusätzlichen Schreibvorgänge oder Statusänderungen ausführen kann.

ConfigMap-Bereitstellungen und Verzeichnisausblendung

Wenn Sie Konfigurationsdaten in einen Container einbinden, kann sich die Bereitstellungsmethode auf die Integrität eines Snapshots auswirken.

Wenn eine ConfigMap mit einer Standard-Volume-Bereitstellung bereitgestellt wird, behandelt Kubernetes das gesamte Zielverzeichnis als externe Bereitstellung. Da externe Bereitstellungen bei Snapshots übersprungen werden, wird das gesamte Verzeichnis aus dem Snapshot ausgeschlossen.

Im folgenden Beispiel werden keine Änderungen im Verzeichnis /etc/my-app/ im Snapshot erfasst, da das gesamte Verzeichnis eine externe Bereitstellung ist:

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

Verwenden Sie zur Behebung dieses Problems einen subPath. Ein subPath trägt dazu bei, dass nur die spezifische Konfigurationsdatei als externe Bereitstellung behandelt wird. Diese Konfiguration zielt auf die genaue Datei ab, sodass die übrigen Dateien und die Struktur im übergeordneten Verzeichnis Teil des lokalen Dateisystems des Containers bleiben, das während des Checkpoint-Vorgangs ordnungsgemäß erfasst wird.

Das folgende Beispiel zeigt die volumeMounts-Konfiguration, die einen subPath verwendet:

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

Implizite anonyme Volumes

Bestimmte Container-Images definieren Volumes in ihren Metadaten über die Anweisung VOLUME in der Dockerfile. Auch wenn in Ihrer Pod-Spezifikation kein Volume definiert ist, erstellt Kubernetes automatisch ein anonymes Volume für jeden Pfad, der im Basis-Image als Volume definiert ist. Im Image alpine/git ist /git als implizites Volume definiert.

Diese anonymen Volumes werden als externe Bereitstellungen behandelt und wie PVCs nicht gesichert. Prüfen Sie Ihre Basis-Images, um sicherzustellen, dass keine kritischen Daten in impliziten Volumes gespeichert sind.