GKE-Pod-Snapshots (Google Kubernetes Engine) können die Startlatenz von Arbeitslasten verbessern, indem Snapshots von ausgeführten Pods wiederhergestellt werden. In einem Pod-Snapshot wird der gesamte Pod-Status gespeichert, einschließlich des Arbeitsspeichers und der Änderungen am Root-Dateisystem. Wenn neue Replikate erstellt werden, wird der Pod nicht von einem neuen Zustand aus initialisiert, sondern der Snapshot wird wiederhergestellt. Der Pod setzt die Ausführung dann an dem Punkt fort, an dem der Snapshot erstellt wurde.
In diesem Dokument wird beschrieben, wie Sie GKE-Pod-Snapshots für Ihre Arbeitslasten aktivieren und konfigurieren.
Weitere Informationen zur Funktionsweise von Pod-Snapshots finden Sie unter Pod-Snapshots.
Hinweise
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 diesen Task 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 updateab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Pod-Snapshots aktivieren
Wenn Sie Pod-Snapshots aktivieren möchten, müssen Sie zuerst einen Cluster mit aktiviertem Pod-Snapshot-Feature erstellen oder aktualisieren. Erstellen oder aktualisieren Sie dann einen Knotenpool, der in GKE Sandbox ausgeführt werden soll.
Führen Sie einen der folgenden Schritte aus, um das Feature in einem Cluster zu aktivieren:
Führen Sie den folgenden Befehl aus, um Pod-Snapshots in einem neuen Cluster zu aktivieren:
gcloud beta container clusters create CLUSTER_NAME \ --enable-pod-snapshots \ --cluster-version=CLUSTER_VERSION \ --workload-pool=PROJECT_ID.svc.id.goog \ --workload-metadata=GKE_METADATAErsetzen Sie Folgendes:
CLUSTER_NAME: Der Name Ihres Clusters.CLUSTER_VERSIONist die Version Ihres neuen Clusters, die 1.34.1-gke.3084001 oder höher sein muss.PROJECT_ID: Ihre Projekt-ID.
Führen Sie die folgenden Schritte aus, um Pod-Snapshots in einem vorhandenen Cluster zu aktivieren:
Aktualisieren Sie den Cluster auf Version 1.34.1-gke.3084001 oder höher:
gcloud container clusters upgrade CLUSTER_NAME \ --node-pool=NODEPOOL_NAME \ --cluster-version=CLUSTER_VERSIONErsetzen Sie Folgendes:
CLUSTER_NAME: Der Name Ihres Clusters.NODEPOOL_VERSION: Der Name des Knotenpools.CLUSTER_VERSION: die Version, auf die Sie Ihren neuen Cluster aktualisieren möchten. Sie muss 1.34.1-gke.3084001 oder höher sein.
Pod-Snapshots in Ihrem Cluster aktivieren:
gcloud container clusters update CLUSTER_NAME \ --workload-pool=PROJECT_ID .svc.id.goog" \ --enable-pod-snapshotsErsetzen Sie
PROJECT_IDdurch Ihre Projekt-ID.
Aktivieren Sie GKE Sandbox in Ihrem Standardcluster:
gcloud container node-pools create NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --node-version=NODE_VERSION \ --machine-type=MACHINE_TYPE \ --image-type=cos_containerd \ --sandbox type=gvisorErsetzen Sie die folgenden Variablen:
NODE_POOL_NAMEist der Name des neuen Knotenpools.NODE_VERSIONist die Version, die für den Knotenpool verwendet werden soll.MACHINE_TYPE: Der für die Knoten zu verwendende Maschinentyp.
Weitere Informationen zur Verwendung von gVisor finden Sie unter Arbeitslasten mit GKE Sandbox isolieren.
Snapshots speichern
Pod-Snapshots werden in einem Cloud Storage-Bucket gespeichert, der den Arbeitsspeicher und (optional) den GPU-Status enthält. Für Pod-Snapshots ist die Workload Identity-Föderation für GKE erforderlich, um das Dienstkonto des Pods für die Authentifizierung bei Cloud Storage zu aktivieren und zu verwenden.
Für Pod-Snapshots ist die folgende Konfiguration für den Bucket erforderlich:
- Hierarchische Namespaces: müssen aktiviert sein, um mehr Lese- und Schreibabfragen pro Sekunde zu ermöglichen. Für hierarchische Namespaces muss auch der einheitliche Zugriff auf Bucket-Ebene aktiviert sein.
- Vorläufiges Löschen: Da für Pod-Snapshots parallele zusammengesetzte Uploads verwendet werden, sollten Sie Datenschutzfunktionen wie das vorläufige Löschen deaktivieren. Wenn die Funktion aktiviert bleibt, können die Löschungen der temporären Objekte Ihre Speicherrechnung erheblich in die Höhe treiben.
- Speicherort: Der Speicherort des Cloud Storage-Bucket muss mit dem Speicherort des GKE-Cluster übereinstimmen, da die Leistung beeinträchtigt werden kann, wenn Snapshots über verschiedene Regionen hinweg übertragen werden.
Cloud Storage-Bucket erstellen
Führen Sie die folgenden Schritte aus, um den Bucket und die erforderlichen Berechtigungen zu erstellen:
Cloud Storage-Bucket erstellen Mit dem folgenden Befehl wird ein Bucket mit der erforderlichen Konfiguration erstellt:
gcloud storage buckets create "gs://BUCKET_NAME" \ --uniform-bucket-level-access \ --enable-hierarchical-namespace \ --soft-delete-duration=0d \ --location="LOCATION"Ersetzen Sie Folgendes:
BUCKET_NAME: der Name Ihres Buckets.LOCATION: Der Standort Ihres Buckets.
Eine vollständige Liste der Optionen für die Bucket-Erstellung finden Sie unter
buckets create-Optionen.
Arbeitslasten die Berechtigung zum Zugriff auf den Cloud Storage-Bucket gewähren
Standardmäßig hat GKE keine Berechtigungen für den Zugriff auf Cloud Storage. Zum Lesen und Schreiben von Snapshot-Dateien müssen Sie dem Kubernetes-Dienstkonto (KSA) IAM-Berechtigungen erteilen, das von den Pods Ihrer Arbeitslast verwendet wird.
Rufen Sie Anmeldedaten ab, damit Sie mit
kubectl-Befehlen mit Ihrem Cluster kommunizieren können:gcloud container clusters get-credentials "CLUSTER_NAME"Führen Sie für jeden Pod die folgenden Schritte aus:
Erstellen Sie ein KSA für jeden Pod:
kubectl create serviceaccount "KSA_NAME" \ --namespace "NAMESPACE"Ersetzen Sie Folgendes:
KSA_NAME: Der Name Ihres KSA.NAMESPACE: der Namespace für Ihre Pods.
Gewähren Sie dem KSA die Berechtigung für den Zugriff auf den Bucket:
gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role="roles/storage.bucketViewer"gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role="roles/storage.objectUser"Ersetzen Sie Folgendes:
PROJECT_NUMBER: Ihre Projektnummer.PROJECT_ID: Ihre Projekt-ID.
Optional: Verwaltete Ordner für den Cloud Storage-Bucket erstellen
Durch das Erstellen von Ordnern können Sie Berechtigungen für Snapshots von nicht vertrauenswürdigen Pods isolieren. Das ist in Multi-Tenant-Anwendungsfällen nützlich. So richten Sie verwaltete Ordner ein:
Erstellen Sie eine benutzerdefinierte IAM-Rolle, die nur die erforderlichen Berechtigungen für Pod-Snapshots enthält:
gcloud iam roles create podSnapshotGcsReadWriter \ --project="PROJECT_ID" \ --permissions="storage.objects.get,storage.objects.create,storage.objects.delete,storage.folders.create"Weisen Sie allen KSAs im Ziel-Namespace die Rolle
roles/storage.bucketViewerzu. Mit dieser Rolle können KSAs Bucket-Metadaten lesen, aber sie gewährt keine Lese- oder Schreibberechtigungen für Objekte im Bucket.gcloud storage buckets add-iam-policy-binding "gs://BUCKET_NAME" \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE" \ --role="roles/storage.bucketViewer"Ersetzen Sie Folgendes:
PROJECT_NUMBER: Ihre Projektnummer.PROJECT_ID: Ihre Projekt-ID.
Führen Sie für jedes KSA, in dem Pod-Snapshots gespeichert werden müssen, die folgenden Schritte aus:
Erstellen Sie einen verwalteten Ordner für das KSA:
gcloud storage managed-folders create "gs://BUCKET_NAME/FOLDER_PATH/"Ersetzen Sie
FOLDER_PATHdurch den Pfad zum verwalteten Ordner, z. B.my-app-snapshots.Weisen Sie dem KSA die benutzerdefinierte Rolle
podSnapshotGcsReadWriterfür den verwalteten Ordner zu:gcloud storage managed-folders add-iam-policy-binding "gs://BUCKET_NAME/FOLDER_PATH/" \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role="projects/PROJECT_ID/roles/podSnapshotGcsReadWriter"Ersetzen Sie
KSA_NAMEdurch den Namen des KSA.
Speicher für Snapshots konfigurieren
Wenn Sie angeben möchten, wo Snapshot-Dateien gespeichert werden sollen, erstellen Sie eine PodSnapshotStorageConfig-Ressource.
Im folgenden Beispiel wird GKE so konfiguriert, dass Pod-Snapshots im Pfad
FOLDER_PATH/im Cloud Storage-Bucket BUCKET_NAME gespeichert werden. Speichern Sie das folgende Manifest alsexample-pod-snapshot-storage-config:apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotStorageConfig metadata: name: example-pod-snapshot-storage-config namespace: NAMESPACE spec: snapshotStorageConfig: gcs: bucket: "BUCKET_NAME" path: "FOLDER_PATH"Ersetzen Sie Folgendes:
NAMESPACE: der Namespace für Ihre Pods. Der Standardwert istdefault.BUCKET_NAME: Der Name Ihres Cloud Storage-Buckets.FOLDER_PATH: der Pfad für den verwalteten Cloud Storage-Ordner.
Wenden Sie das Manifest an:
kubectl apply -f example-pod-snapshot-storage-config.yaml
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 für Pods mit dem Label
app: my-appgilt und die Speicherkonfigurationexample-pod-snapshot-storage-configverwendet. Speichern Sie das folgende Manifest alsexample-pod-snapshot-policy.yaml:apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotPolicy metadata: name: example-pod-snapshot-policy namespace: NAMESPACE spec: storageConfigName: example-pod-snapshot-storage-config selector: matchLabels: app: my-app triggerConfig: type: workload postCheckpoint: resumeWenden Sie das Manifest an:
kubectl apply -f example-pod-snapshot-policy.yaml --namespace NAMESPACE
Snapshot-Größe optimieren
Wenn ein Pod-Snapshot ausgelöst wird, erfasst gVisor den gesamten Status aller Container, einschließlich:
- Anwendungsstatus, z. B. Arbeitsspeicher und Register
- Änderungen am Root-Dateisystem und an
tmpfs(einschließlichemptyDir-Volumes) - Kernelstatus, z. B. 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 Large Language Models (LLMs). LLM-Server laden Modellgewichte häufig 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 Modelldateien mit den Gewichten gespeichert. Wenn das Modell in diesem Szenario 100 GB groß ist, hat der resultierende Snapshot etwa 200 GB (100 GB für Modelldateien plus 100 GB für den GPU-Status). Nachdem die Modellgewichte 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 halbieren und die Anwendung mit einer deutlich geringeren Latenz wiederherstellen.
Snapshot auslösen
Sie können einen Snapshot innerhalb einer Arbeitslast auslösen, wenn die Anwendung bereit ist, oder manuell einen On-Demand-Snapshot für einen bestimmten Pod auslösen.
Snapshot über eine Arbeitslast auslösen
Wenn Sie einen Snapshot über Ihren Anwendungscode auslösen möchten, konfigurieren Sie Ihre Anwendung so, dass sie ein Signal sendet, wenn sie für einen Snapshot bereit ist. Schreiben Sie 1 in die Datei /proc/gvisor/checkpoint, um die Bereitschaft zu signalisieren, z. B. echo 1 > /proc/gvisor/checkpoint.. Der Schreibvorgang startet den Snapshot-Vorgang asynchron und wird sofort zurückgegeben. Das Lesen aus demselben Dateideskriptor blockiert den Lesevorgang, bis sowohl der Snapshot als auch die Wiederherstellung abgeschlossen sind und die Arbeitslast fortgesetzt werden kann.
Die genaue Nutzung hängt von Ihrer Anwendung ab. Im folgenden Beispiel wird jedoch ein Snapshot-Trigger für eine Python-Anwendung gezeigt. So lösen Sie einen Snapshot aus dieser Beispielarbeitslast aus:
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 except OSError as e: return e 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"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. Das manuelle Auslösen eines Snapshots ist in GKE-Versionen 1.34.1-gke.3556000 und höher verfügbar.
Im folgenden Beispiel wird ein Snapshot für einen Pod mit dem Namen
my-podausgelöst. Speichern Sie das folgende Manifest alsexample-manual-trigger.yaml:apiVersion: podsnapshot.gke.io/v1alpha1 kind: PodSnapshotManualTrigger metadata: name: example-manual-trigger namespace: NAMESPACE spec: targetPod: my-podWenden Sie das Manifest an:
kubectl apply -f example-manual-trigger.yaml --namespace NAMESPACE
Prüfen Sie das Feld status der PodSnapshotManualTrigger-Ressource, um festzustellen, 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 bestätigen
Sie können prüfen, ob ein Snapshot aufgenommen wurde, indem Sie im Ereignisverlauf nach GKEPodSnapshotting-Ereignissen suchen:
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
Ersetzen Sie POD_NAME durch den Namen Ihres Pods, z. B. my-app oder my-pod.
Die Ausgabe sollte so aussehen:
NAME CREATIONTIME REASON MESSAGE
default/5b449f9c7c-bd7pc 2025-11-05T16:25:11Z GKEPodSnapshotting Successfully checkpointed the pod to PodSnapshot
Snapshots verwalten
Wenn Sie einen Pod-Snapshot erstellen, wird eine PodSnapshot-CRD-Ressource erstellt, um den Zustand des Pods zu diesem Zeitpunkt zu speichern. Das Feld status dieser Ressource gibt an, ob der Snapshot-Vorgang erfolgreich war und ob der Snapshot für die Wiederherstellung verfügbar ist.
Führen Sie den folgenden Befehl aus, um alle PodSnapshot-Ressourcen in einem Namespace aufzurufen:
kubectl get podsnapshots.gke.io --namespace NAMESPACE
Die Ausgabe sollte so aussehen:
NAME STATUS POLICY AGE
de334898-1e7a-4cdb-9f2e-7cc2181c29e4 AllSnapshotsAvailable example-policy 47h
Arbeitslast aus einem Snapshot wiederherstellen
Wenn Sie Ihre Arbeitslast aus dem letzten Snapshot wiederherstellen möchten, können Sie den vorhandenen Pod nach der Erstellung eines Snapshots löschen und dann neu bereitstellen. Alternativ können Sie einen neuen Pod mit einer identischen Spezifikation bereitstellen. GKE stellt den Pod automatisch aus dem entsprechenden Snapshot wieder her.
In den folgenden Schritten wird gezeigt, wie ein Pod aus einem passenden Snapshot wiederhergestellt wird, indem der Pod gelöscht und neu bereitgestellt wird:
Löschen Sie den Pod:
kubectl delete -f POD_NAME.yamlErsetzen Sie
POD_NAMEdurch den Namen Ihres Pods, z. B.my-app.Wenden Sie den Pod noch einmal an:
kubectl apply -f POD_NAME.yamlSo rufen Sie die Logs auf, um die Snapshot-Wiederherstellung zu bestätigen:
kubectl logs my-app --namespace NAMESPACEDie Ausgabe hängt davon ab, wie Sie Ihre Anwendung konfiguriert haben. In der Beispielanwendung wird in den Logs
GKE Pod Snapshot: restoreangezeigt, wenn ein Wiederherstellungsvorgang stattfindet.
Aus einem bestimmten Snapshot wiederherstellen
Standardmäßig stellt GKE Arbeitslasten aus der neuesten PodSnapshot-Ressource wieder her, die dem Pod entspricht. Wenn ein Snapshot erstellt wird, generiert GKE automatisch einen eindeutigen Namen (UUID) für die PodSnapshot-Ressource. Sie können ihn mit dem Befehl kubectl get podsnapshots.gke.io --namespace NAMESPACE aufrufen.
Wenn Sie eine Arbeitslast aus einer älteren oder bestimmten PodSnapshot-Ressource wiederherstellen möchten, fügen Sie der Pod-Spezifikation der Arbeitslast die Annotation podsnapshot.gke.io/ps-name hinzu und geben Sie den Namen der PodSnapshot-Ressource an, die zum Wiederherstellen der Arbeitslast verwendet werden soll:
apiVersion: v1
kind: Pod
metadata:
name: my-app
namespace: NAMESPACE
labels:
app: my-app
annotations:
podsnapshot.gke.io/ps-name: "POD_SNAPSHOT_NAME"
spec:
serviceAccountName: KSA_NAME
runtimeClassName: gvisor
containers:
...
Ersetzen Sie POD_SNAPSHOT_NAME durch den Namen des Snapshots, aus dem Sie die Daten wiederherstellen möchten. Sie können Snapshot-Namen mit dem Befehl kubectl get podsnapshots.gke.io --namespace NAMESPACE abrufen.
Damit GKE den angegebenen Snapshot für die Wiederherstellung verwenden kann, muss der Status der PodSnapshot-Ressource Ready sein und sich im selben Namespace wie der Pod befinden. Wenn PodSnapshot nicht Ready ist oder nicht im selben Namespace wie der Pod vorhanden ist, führt die Arbeitslast einen Kaltstart durch, anstatt aus einem Snapshot wiederherzustellen.
Snapshots deaktivieren
Durch das Entfernen der PodSnapshotPolicy-CRD wird verhindert, dass Snapshots von Pods erstellt und wiederhergestellt werden. Ausgeführte Pods sind vom Löschen der Ressource nicht betroffen. Wenn Sie die Richtlinie jedoch löschen, während ein Pod gespeichert oder wiederhergestellt wird, kann es sein, dass der Pod in einen Fehlerstatus wechselt.
Wenn Sie die Erstellung von Snapshots und die Wiederherstellung für neue Pods, die einer Richtlinie unterliegen, deaktivieren möchten, löschen Sie die PodSnapshotPolicy mit dem folgenden Befehl:
kubectl delete podsnapshotpolicies.podsnapshot.gke.io SNAPSHOT_POLICY --namespace=NAMESPACE
Ersetzen Sie SNAPSHOT_POLICY durch den Namen des PodSnapshotPolicy, den Sie löschen möchten, z. B. example-pod-snapshot-policy.
Sie können auch eine bestimmte PodSnapshot-Ressource löschen, damit Pods nicht mehr aus diesem bestimmten Snapshot wiederhergestellt werden. Durch das Löschen der PodSnapshot-Ressource werden auch die in Cloud Storage gespeicherten Dateien entfernt.
Wenn Sie verhindern möchten, dass ein bestimmter Snapshot für zukünftige Wiederherstellungen verwendet wird, löschen Sie das PodSnapshot-Objekt mit dem folgenden Befehl:
kubectl delete podsnapshots.podsnapshot.gke.io POD_SNAPSHOT_NAME --namespace=NAMESPACE
Ersetzen Sie POD_SNAPSHOT_NAME durch den Namen des Snapshots, den Sie löschen möchten, z. B. example-podsnapshot.
Nächste Schritte
- Weitere Informationen zu Pod-Snapshot-Konzepten
- Weitere Informationen finden Sie unter Benutzerdefinierte Ressourcendefinitionen (CRDs) für Pod-Snapshots.