Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

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

Pod-Snapshot auslösen

Autopilot Standard

Um die Startlatenz für Google Kubernetes Engine (GKE)-Arbeitslasten zu reduzieren, können Sie einen Snapshot eines laufenden Pods erstellen und neue Pods daraus wiederherstellen. In diesem Dokument erfahren Sie, wie Sie eine Pod-Snapshot-Richtlinie erstellen und einen Snapshot auslösen, entweder über Ihre Arbeitslast oder manuell. Weitere Informationen zur Funktionsweise von Pod-Snapshots finden Sie unter Informationen zu GKE-Pod-Snapshots.

Plattformadministratoren und -operatoren sowie Anwendungsentwickler können dieses Dokument verwenden, um Snapshot-Richtlinien zu konfigurieren und Snapshots auszulösen. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die in Cloud de Confiance by S3NS-Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

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, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut 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.

Erfüllen Sie die Voraussetzungen und aktivieren Sie Pod-Snapshots in Ihrem Cluster. Weitere Informationen zum Vorbereiten des Clusters und des Speichers finden Sie unter Pod-Snapshots vorbereiten.

Snapshot-Richtlinie erstellen

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

Speichern Sie das folgende Manifest als example-pod-snapshot-policy.yaml. In diesem Beispiel wird eine Richtlinie erstellt, die für Pods mit dem Label app: my-app gilt. Die Richtlinie verwendet die benutzerdefinierte Ressource example-pod-snapshot-storage-config (PodSnapshotStorageConfig), die Sie unter Pod-Snapshots vorbereiten erstellt haben, um den Speicherort für Snapshots zu definieren:
```
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:
- NAMESPACE: der Namespace für Ihre Pods. Verwenden Sie denselben Namespace, für den Sie unter Pod-Snapshots vorbereiten Zugriff auf Cloud Storage gewährt haben.
- TRIGGER_TYPE: der Triggertyp. Unterstützte Werte sind workload für arbeitslastbasierte Trigger oder manual für On-Demand-Snapshots.
In diesem Beispiel sorgt die Einstellung postCheckpoint: resume dafür, dass der Pod nach dem Erstellen des Snapshots durch GKE weiter ausgeführt wird.

Eine vollständige Liste der konfigurierbaren Felder finden Sie in der PodSnapshotPolicy-Spezifikation.

Wenden Sie das Manifest an:

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

Zusätzliche Einstellungen für die Pod-Snapshot-Richtlinie konfigurieren

Ihre benutzerdefinierte PodSnapshotPolicy-Ressource unterstützt neben dem erforderlichen Selektor, der Speicherkonfiguration und dem Trigger auch optionale Einstellungen. Mit diesen zusätzlichen Einstellungen wird gesteuert, was in jedem Snapshot erfasst wird, wie lange GKE Snapshots aufbewahrt und wie GKE Snapshots für Wiederherstellungen gruppiert:

Snapshot-Bereich: Konfigurieren Sie das Feld spec.snapshotScope, um anzugeben, welche Teile des Pod-Status im Snapshot erfasst werden sollen. Unterstützte Werte sind whole-pod (Standard) und rootfs-only. Der Bereich whole-pod erfasst den gesamten Pod, einschließlich Anwendungsstatus, Arbeitsspeicher und Dateisystemen. Der Bereich rootfs-only erfasst nur das Container-Stammdateisystem. Für den Bereich rootfs-only ist die GKE-Version 1.35.3-gke.1031000 oder höher erforderlich.
Automatische Bereinigung: Wenn Sie alte benutzerdefinierte PodSnapshot-Ressourcen automatisch bereinigen möchten, konfigurieren Sie eine Aufbewahrungsrichtlinie mit dem Feld spec.retentionConfig. Sie können eine Dauer mit dem Feld lastAccessTimeout angeben, z. B. 7d. Nach Ablauf dieser Dauer löscht GKE den Snapshot.
Snapshot-Gruppierung: Wenn Sie Snapshots isolieren möchten, die in ähnlichen Umgebungen, aber in unterschiedlichen Kontexten erstellt wurden, geben Sie im Feld spec.snapshotGroupingRules Gruppierungs-Labels an. In einem Szenario mit mehreren Mandanten, in dem der Basis-Pod für alle Nutzer gleich ist, können Sie die Snapshots beispielsweise nach Nutzer oder Gruppe isolieren. Während einer Wiederherstellung wählt GKE nur einen Snapshot aus derselben Labelgruppe aus. Weitere Informationen dazu, wie sich diese Gruppierung auf die Kompatibilitätsprüfung während der Wiederherstellung auswirkt, finden Sie unter Abgleich von Gruppierungsregeln.

Sie können die Einstellungen für Snapshot-Bereich, Aufbewahrung und Gruppierung unabhängig voneinander konfigurieren. Das folgende Beispiel zeigt alle drei Einstellungen in einer benutzerdefinierten PodSnapshotPolicy-Ressource:

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

Eine vollständige Liste der konfigurierbaren Felder finden Sie in der PodSnapshotPolicy-Spezifikation.

Snapshot-Größe optimieren

Das Speichern und Wiederherstellen größerer Snapshots dauert länger. Bevor Sie einen Snapshot auslösen, reduzieren Sie seine Größe, indem Sie temporäre Dateien oder Anwendungsstatus löschen, die Ihre Anwendung nicht mehr benötigt, nachdem GKE den Pod aus dem Snapshot wiederhergestellt hat.

Mit dem Standard-Snapshot-Bereich whole-pod erfasst GKE Sandbox den gesamten Status aller Container, einschließlich der folgenden:

Anwendungsstatus, z. B. Arbeitsspeicher und Register
Änderungen am Root-Dateisystem und an tmpfs-Bereitstellungen (einschließlich emptyDir-Volumes)
Kernel-Status, z. B. geöffnete Dateideskriptoren, Threads und Sockets

Die Optimierung der Snapshot-Größe ist besonders wichtig für Arbeitslasten wie Large Language Models (LLMs). LLM-Server laden Modellgewichtungen häufig in den lokalen Speicher (rootfs oder tmpfs) herunter, bevor sie in die GPU geladen werden. Wenn Sie einen Snapshot erstellen, speichert GKE Sandbox sowohl den GPU-Status als auch die Modellgewichtungsdateien. 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 Anwendung die Modellgewichtungen in die GPU geladen hat, benötigt sie die Dateien im Dateisystem oft nicht mehr, um ausgeführt zu werden. Wenn Sie diese Modelldateien löschen, bevor Sie den Snapshot auslösen, können Sie die Snapshot-Größe halbieren und die Anwendung mit deutlich geringerer Latenz wiederherstellen.

Snapshot auslösen

Wählen Sie eine der folgenden Methoden aus, um einen Snapshot auszulösen:

Arbeitslast-Trigger: Verwenden Sie diese Methode, wenn Sie Ihre Anwendung so ändern können, dass sie signalisiert, dass sie für einen Snapshot bereit ist, z. B. nach Abschluss der Initialisierung. Diese Methode eignet sich am besten, um die Startlatenz von horizontal skalierenden Arbeitslasten zu verbessern. Ein Arbeitslast-Trigger wird nur einmal in einem Arbeitslastzyklus ausgeführt.
Manueller Trigger: Verwenden Sie diese Methode, wenn Sie Ihre Anwendung nicht so ändern können, dass sie die Bereitschaft signalisiert, oder wenn Sie On-Demand-Snapshots eines bestimmten Pods erstellen möchten. Sie können beliebig viele manuelle Trigger erstellen.

Snapshot aus einer Arbeitslast auslösen

Wenn Sie einen Snapshot aus dem 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 den Wert 1 in die Datei /proc/gvisor/checkpoint, z. B. durch Ausführen des Befehls echo 1 > /proc/gvisor/checkpoint. Der Schreibvorgang startet den Snapshot-Prozess asynchron und gibt sofort eine Antwort zurück. Das Lesen aus demselben Dateideskriptor blockiert den Lesevorgang, bis der Snapshot- oder Wiederherstellungsvorgang abgeschlossen ist und die Arbeitslast fortgesetzt werden kann.

Bevor Sie einen Snapshot von einer Arbeitslast auslösen, muss der Pod durch eine Snapshot-Richtlinie ausgewählt werden. Der Wert des Felds triggerConfig.type in dieser Richtlinie muss auf workload festgelegt sein.

Die genaue Verwendung variiert je nach Anwendung. Das folgende Beispiel zeigt jedoch einen Snapshot-Trigger für eine Python-Anwendung. So lösen Sie einen Snapshot für diese Beispielarbeitslast aus:

Speichern Sie das folgende Manifest als my-app.yaml. In diesem Beispiel entspricht das Label app: my-app der Auswahl in der Beispiel-Snapshot-Richtlinie und die Einstellung runtimeClassName: gvisor führt den Pod in GKE Sandbox aus:

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"

Ersetzen Sie Folgendes:

NAMESPACE: der Namespace für Ihre Pods.
SERVICEACCOUNT_NAME: der Name des ServiceAccount-Objekts, dem Sie unter Pod-Snapshots vorbereiten Zugriff auf Cloud Storage gewährt haben.

Stellen Sie die Anwendung bereit:
```
kubectl apply -f my-app.yaml
```
Nachdem die Anwendung gestartet wurde und signalisiert hat, dass sie bereit ist, erstellt GKE Sandbox den Snapshot. Informationen dazu, wie Sie prüfen, ob der Snapshot erfolgreich erstellt wurde, finden Sie unter Snapshots prüfen.

Snapshot manuell auslösen

Bevor Sie einen Snapshot manuell auslösen, müssen Sie prüfen, ob der Ziel-Pod ausgeführt wird und ob eine Snapshot-Richtlinie den Pod auswählt. Der Wert des Felds triggerConfig.type in dieser Richtlinie muss auf manual festgelegt sein.

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

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

Wenden Sie das Manifest an:

kubectl apply -f example-manual-trigger.yaml

Prüfen Sie im Abschnitt status der benutzerdefinierten Ressource „PodSnapshotManualTrigger“, ob der Snapshot erfolgreich ausgelöst wurde:
```
kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io \
    example-manual-trigger \
    --namespace NAMESPACE -o yaml
```
Ersetzen Sie NAMESPACE durch den Namespace für Ihre Pods.

Wenn der Trigger erfolgreich war, wird im Feld status.conditions angezeigt, dass der Prüfpunkt abgeschlossen wurde, und im Feld status.snapshotCreated wird der Name der erstellten benutzerdefinierten PodSnapshot-Ressource angezeigt.

Snapshots prüfen

Prüfen Sie im Ereignisverlauf, ob GKE einen Snapshot erstellt hat. Suchen Sie nach GKEPodSnapshotting-Ereignissen:

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