Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Pod-Snapshot auslösen

Autopilot Standard

Hier erfahren Sie, wie Sie Snapshot-Richtlinien erstellen und einen Pod-Snapshot Ihrer ausgeführten Arbeitslasten in Google Kubernetes Engine (GKE) auslösen.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere Versionen der gcloud CLI unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das Attribut compute/region fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Prüfen Sie, ob Sie die Voraussetzungen erfüllt und Pod-Snapshots in Ihrem Cluster aktiviert haben. Weitere Informationen finden Sie unter Pod-Snapshots vorbereiten.

Snapshot-Richtlinie erstellen

Wenn Sie Snapshots für einen Pod aktivieren möchten, erstellen Sie eine PodSnapshotPolicy-Ressource mit einem Selektor, der mit den Labels des Pods übereinstimmt.

Im folgenden Beispiel wird eine Richtlinie erstellt, die auf Pods mit dem Label app: my-app angewendet wird und die Speicherkonfiguration example-pod-snapshot-storage-config verwendet. Speichern Sie das folgende Manifest als example-pod-snapshot-policy.yaml:
```
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
```
Ersetzen Sie Folgendes:
- TRIGGER_TYPE: der Typ des Triggers. Unterstützte Werte sind workload für arbeitslastbasierte Trigger oder manual für On-Demand-Snapshots.
- NAMESPACE: der Namespace für Ihre Pods.
Eine vollständige Liste aller konfigurierbaren Felder finden Sie in der Dokumentation zur PodSnapshotPolicy-CustomResourceDefinition (CRD).

Wenden Sie das Manifest an:

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

Zusätzliche Pod-Snapshot-Richtlinien konfigurieren

Sie können in Ihrer PodSnapshotPolicy zusätzliche Richtlinien konfigurieren, z. B.:

Snapshot-Bereich: Wenn Sie angeben möchten, welche Teile des Pod-Status in dem Snapshot erfasst werden sollen, konfigurieren Sie das spec.snapshotScope Feld. Unterstützte Werte sind whole-pod (Standard), um den gesamten Pod einschließlich Anwendungsstatus, Arbeitsspeicher und Dateisystemen zu speichern, oder rootfs-only, um nur das Root-Dateisystem des Containers zu speichern. Für den Bereich rootfs-only ist GKE-Version 1.35.3-gke.1031000 oder höher erforderlich.
Automatische Bereinigung: Wenn Sie alte Pod-Snapshot Ressourcen automatisch bereinigen möchten, konfigurieren Sie eine Aufbewahrungsrichtlinie mit dem spec.retentionConfig Feld. Sie können mit dem Feld lastAccessTimeout eine Dauer angeben (z. B. 7d), nach der der Snapshot gelöscht wird.
Snapshots organisieren: Sie können Snapshots logisch gruppieren, um zwischen Snapshots zu unterscheiden, die in ähnlichen Umgebungen, aber in unterschiedlichen Kontexten erstellt wurden. In einem Multi-Tenant-Szenario, in dem der Basis-Pod für alle Nutzer gleich ist, können Sie die Snapshots beispielsweise nach Nutzer oder Gruppe isolieren. Wenn Sie Snapshots isolieren möchten, geben Sie mit dem Feld snapshotGroupingRules Gruppierungs-Labels in der Richtlinie an. Wenn ein Pod wiederhergestellt wird, wird er nur mit Snapshots in derselben Labelgruppe verglichen. Weitere Informationen dazu, wie sich diese Gruppierung auf den Kompatibilitätsabgleich bei der Wiederherstellung auswirkt, finden Sie unter Gruppierungsregeln abgleichen.

Im folgenden Beispiel wird gezeigt, wie Sie sowohl die Aufbewahrungs- als auch die Gruppierungseinstellungen in Ihrer PodSnapshotPolicy konfigurieren. Diese Einstellungen können unabhängig voneinander festgelegt werden:

# ... other fields omitted
spec:
  snapshotScope: rootfs-only
  retentionConfig:
    lastAccessTimeout: 7d
  snapshotGroupingRules:
    groupByLabelValue:
      labels: ["tenant", "environment"]
      groupRetentionPolicy:
        maxSnapshotCountPerGroup: 5

Eine vollständige Liste aller konfigurierbaren Felder finden Sie in der Referenzdokumentation zu PodSnapshotPolicy.

Snapshot-Größe optimieren

Wenn ein Pod-Snapshot ausgelöst wird, erfasst gVisor den gesamten Status aller Container, einschließlich:

Anwendungsstatus wie Arbeitsspeicher und Register
Änderungen am Root-Dateisystem und an tmpfs (einschließlich emptyDir-Volumes)
Kernel-Status wie offene Dateideskriptoren, Threads und Sockets

Die Größe des Snapshots wird durch diese Faktoren bestimmt. Das Speichern und Wiederherstellen größerer Snapshots dauert länger. Um die Leistung zu optimieren, sollten Sie vor dem Auslösen eines Snapshots alle Anwendungsstatus oder Dateien bereinigen, die nach der Wiederherstellung des Pods aus dem Snapshot nicht mehr benötigt werden.

Die Optimierung der Snapshot-Größe ist besonders wichtig für Arbeitslasten wie große Sprachmodelle (Large Language Models, LLMs). LLM-Server laden Modellgewichtungen oft in den lokalen Speicher (rootfs oder tmpfs) herunter, bevor sie in die GPU geladen werden. Wenn ein Snapshot erstellt wird, werden sowohl der GPU-Status als auch die Dateien mit den Modellgewichtungen gespeichert. Wenn das Modell in diesem Szenario 100 GB groß ist, ist der resultierende Snapshot etwa 200 GB groß (100 GB Modelldateien plus 100 GB für den GPU-Status). Nachdem die Modellgewichtungen in die GPU geladen wurden, sind die Dateien im Dateisystem oft nicht mehr erforderlich, damit die Anwendung ausgeführt werden kann. Wenn Sie diese Modelldateien löschen, bevor Sie den Snapshot auslösen, können Sie die Snapshot-Größe um die Hälfte reduzieren und die Anwendung mit einer deutlich geringeren Latenz wiederherstellen.

Snapshot auslösen

Sie können einen Snapshot aus einer Arbeitslast heraus auslösen, wenn die Anwendung bereit ist, oder Sie können manuell einen On-Demand-Snapshot für einen bestimmten Pod auslösen.

Snapshot aus einer Arbeitslast auslösen

Wenn Sie einen Snapshot aus Ihrem Anwendungscode heraus auslösen möchten, konfigurieren Sie Ihre Anwendung so, dass sie ein Signal sendet, wenn sie für einen Snapshot bereit ist. Um die Bereitschaft zu signalisieren, schreiben Sie 1 in die Datei /proc/gvisor/checkpoint, z. B. echo 1 > /proc/gvisor/checkpoint. Der Schreibvorgang startet den Snapshot-Prozess asynchron und wird sofort zurückgegeben. Wenn Sie aus demselben Dateideskriptor lesen, wird der Lesevorgang blockiert, bis sowohl der Snapshot als auch die Wiederherstellung abgeschlossen sind und die Arbeitslast bereit ist, fortgesetzt zu werden.

Die genaue Verwendung variiert je nach Anwendung. Das folgende Beispiel zeigt jedoch einen Snapshot-Trigger für eine Python-Anwendung. Führen Sie die folgenden Schritte aus, um einen Snapshot aus dieser Beispielarbeitslast auszulösen:

Speichern Sie das folgende Manifest als my-app.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: NAMESPACE
  labels:
    app: my-app
spec:
  serviceAccountName: KSA_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 the application being ready to snapshot at 20th count
            trigger_snapshot()
          i += 1
          time.sleep(1)
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
      requests:
        cpu: "250m"
        memory: "256Mi"

Ersetzen Sie Folgendes:

NAMESPACE: der Namespace für Ihre Pods.
KSA_NAME: der Name Ihres KSA.

Stellen Sie die Anwendung bereit:
```
kubectl apply -f my-app.yaml
```

Snapshot manuell auslösen

Wenn Sie manuell einen On-Demand-Snapshot für einen bestimmten Pod auslösen möchten, erstellen Sie eine PodSnapshotManualTrigger-Ressource.

Im folgenden Beispiel wird ein Snapshot für einen Pod mit dem Namen my-pod ausgelöst. Speichern Sie das folgende Manifest als example-manual-trigger.yaml:
```
apiVersion: podsnapshot.gke.io/v1
kind: PodSnapshotManualTrigger
metadata:
  name: example-manual-trigger
  namespace: NAMESPACE
spec:
  targetPod: my-pod
```
Ersetzen Sie NAMESPACE durch den Namespace Ihres Pods.

Hinweis: Für die Snapshot-Richtlinie, die diesen Pod auswählt, muss der Triggertyp auf manual festgelegt sein.

Wenden Sie das Manifest an:

kubectl apply -f example-manual-trigger.yaml

Prüfen Sie das Feld status der PodSnapshotManualTrigger-Ressource, um zu bestätigen, ob der Snapshot erfolgreich ausgelöst wurde:

kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io example-manual-trigger -n NAMESPACE -o yaml

Das Feld status gibt an, ob das Auslösen des Snapshots erfolgreich war oder fehlgeschlagen ist.

Snapshots prüfen

Sie können prüfen, ob ein Snapshot erstellt wurde, indem Sie den Ereignisverlauf nach GKEPodSnapshotting-Ereignissen durchsuchen:

kubectl get events -o \
custom-columns=NAME:involvedObject.name,CREATIONTIME:.metadata.creationTimestamp,REASON:.reason,MESSAGE:.message \
--namespace NAMESPACE \
--field-selector involvedObject.name=POD_NAME,reason=GKEPodSnapshotting