GKE-Pod-Snapshots

GKE-Pod-Snapshots (Google Kubernetes Engine) können die Startlatenz von Arbeitslasten verbessern, indem Snapshots von laufenden Pods wiederhergestellt werden. In einem Pod-Snapshot wird der gesamte Pod-Status gespeichert, einschließlich Änderungen am Arbeitsspeicher und am Dateisystem. Wenn Sie neue Replikate erstellen, werden diese aus dem Snapshot wiederhergestellt. Die Arbeitslast kann also fortgesetzt werden, anstatt von einem neuen Zustand aus zu starten. Diese Funktion ist hilfreich für die horizontale Skalierung von Arbeitslasten, z. B. KI-Inferenzmodelle, die große Gewichte in den Arbeitsspeicher laden, oder Anwendungen, die umfangreiche Abhängigkeiten laden.

In diesem Dokument wird erläutert, wie GKE-Pod-Snapshots funktionieren und ob Ihre Arbeitslasten davon profitieren können.

Plattformadministratoren und ‑operatoren sowie Anwendungsentwickler können dieses Dokument verwenden, um die Kompatibilität von Arbeitslasten zu bewerten, Richtlinien für die Snapshot-Speicherung zu planen und zu verstehen, wie GKE Checkpointing und Wiederherstellung verwaltet. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die inGoogle Cloud Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Weitere Informationen zur Vorbereitung und Verwendung von Pod-Snapshots in Ihren Clustern finden Sie in den folgenden Anleitungen:

  1. Pod-Snapshots vorbereiten
  2. Pod-Snapshot auslösen
  3. Arbeitslast aus einem Pod-Snapshot wiederherstellen

Wann sollten Pod-Snapshots verwendet werden?

Verwenden Sie Pod-Snapshots für Arbeitslasten mit langen Initialisierungszeiten. Beispiele sind KI-Inferenz-Arbeitslasten, bei denen große Modelle in den CPU- oder GPU-Arbeitsspeicher geladen werden, oder große Anwendungen, bei denen viele Bibliotheken und Abhängigkeiten geladen werden. Arbeitslasten, die bereits schnelle Startzeiten haben, profitieren in der Regel nicht von Pod-Snapshots.

Funktionsweise von Pod-Snapshots

In GKE-Pod-Snapshots wird eine genaue Kopie des Prozessstatus eines Pods zu einem bestimmten Zeitpunkt gespeichert. Wenn Sie neue Replikate erstellen, initialisiert GKE den Pod nicht von einem neuen Zustand aus, sondern stellt ihn aus einem Snapshot wieder her. Bei dieser Wiederherstellung wird die Ausführung des Pods ab dem Zeitpunkt fortgesetzt, an dem der Snapshot erstellt wurde.

Um Pod-Snapshots deklarativ zu konfigurieren, erstellen Sie benutzerdefinierte Kubernetes-Ressourcen, um das Snapshot-Verhalten zu definieren. Ein Agent, der auf jedem GKE-Knoten ausgeführt wird, verwaltet den Snapshot-Lebenszyklus. Anhand der von Ihnen definierten Richtlinien bestimmt der Agent, wann neue Snapshots erstellt und wann vorhandene Snapshots zum Wiederherstellen neuer Pods verwendet werden. Ein Controller, der auf der GKE-Steuerungsebene ausgeführt wird, bereinigt veraltete Snapshots und behebt Probleme. In Cloud Storage werden Ihre Pod-Snapshots gespeichert.

Snapshot-Inhalte

In der folgenden Tabelle ist aufgeführt, was in einem Pod-Snapshot enthalten ist und was nicht:

Kategorie Enthalten Ausgeschlossen
Anwendungsstatus
  • Prozessspeicher
  • Ausführungsthreads
  • CPU-Register
  • Geöffnete Dateideskriptoren
 Nichts (der gesamte In-Memory-Prozessstatus wird erfasst)
Dateisysteme
  • Container-Root-Dateisystem (rootfs)
  • emptyDir Bände
  • tmpfs Halterungen
  • PersistentVolumeClaim-Objekte
  • Alle anderen Volume- oder Speichertypen, die nicht als enthalten aufgeführt sind
Netzwerk
  • Loopback-Verbindungen
  • Überwachungs-Sockets
  • Unix Domain Sockets
  • Aktive externe Verbindungen (bei Wiederherstellung geschlossen)
  • Benutzerdefinierte Routen
  • Benutzerdefinierte Regeln (iptables, nftables)

Benutzerdefinierte Ressourcen

Verwenden Sie die folgenden benutzerdefinierten Ressourcen, um Pod-Snapshots deklarativ zu konfigurieren:

  • PodSnapshotStorageConfig: Gibt den Speicherort für Snapshots an. Unterstützt nur Cloud Storage-Buckets.
  • PodSnapshotPolicy: Definiert, welche Pods auf Grundlage von Kubernetes-Label-Selektoren als Snapshot erstellt werden. Diese benutzerdefinierte Ressource enthält die meisten Konfigurationsoptionen für die Funktion, einschließlich der Art und Weise, wie Snapshots ausgelöst werden, des Snapshot-Umfangs und der Aufbewahrungsrichtlinien.
  • PodSnapshotManualTrigger (optional): Wenn Sie keinen Arbeitslast-Trigger verwenden, wird ein manueller Trigger zum Erstellen eines Snapshots für einen bestimmten Pod definiert.

Referenzspezifikationen finden Sie in der Referenz zur CustomResourceDefinition „PodSnapshot“.

Snapshot-Trigger

Sie haben folgende Möglichkeiten, einen Pod-Snapshot auszulösen:

  • Arbeitslast-Trigger: Die Anwendung im Pod signalisiert dem GKE-Agent, dass sie für einen Snapshot bereit ist. Diese Art von Trigger wird einmal in einem Arbeitslastzyklus ausgeführt, z. B. wenn eine Arbeitslast bereit ist. Dieser Ansatz eignet sich am besten zur Verbesserung der Startlatenz von horizontal skalierten Arbeitslasten.
  • Manueller Trigger: Sie können einen Snapshot bei Bedarf für einen bestimmten Pod auslösen, indem Sie eine benutzerdefinierte Ressource vom Typ „PodSnapshotManualTrigger“ erstellen. Dieser Triggertyp kann beliebig oft ausgeführt werden. Diese Vorgehensweise eignet sich am besten, wenn Sie Ihre Anwendung nicht so ändern können, dass sie Bereitschaft signalisiert.

Snapshot-Abgleich und ‑Kompatibilität

Damit ein Snapshot mit einer wiederhergestellten Arbeitslast kompatibel ist, führt GKE einen Kompatibilitätsabgleich zwischen dem ursprünglichen Pod mit Checkpoint und dem Ziel-Pod durch.

GKE verwendet die folgenden Regeln, um die Kompatibilität zu ermitteln:

  • Auswahlreihenfolge: Standardmäßig werden Arbeitslasten in GKE aus der neuesten benutzerdefinierten PodSnapshot-Ressource wiederhergestellt, die dem Namespace und der Konfiguration des Pods entspricht.
  • Abgleichskriterien: Die Kompatibilitätsprüfung hängt vom Snapshot-Bereich ab, der in Ihrer benutzerdefinierten Ressource „PodSnapshotPolicy“ konfiguriert ist (whole-pod oder rootfs-only).

whole-pod Umfangsabgleich (Standardeinstellung)

Bei Richtlinien mit dem Standardbereich whole-pod prüft GKE Folgendes:

  • Hash der komprimierten Spezifikation: GKE generiert einen eindeutigen Hash basierend auf wichtigen Laufzeitfeldern in der Spezifikation des Pods. Damit die Wiederherstellung erfolgreich ist, muss der Ziel-Pod einen identischen Hash aus seiner komprimierten Spezifikation generieren. Bei dieser Prüfung wird sichergestellt, dass die Pods, die per Checkpoint gespeichert und wiederhergestellt wurden, in ihren Laufzeitkonfigurationen identisch sind.

    Die folgenden Felder aus dem Pod-Objekt sind Teil der komprimierten Spezifikation und beeinflussen den eindeutigen Hash:

    • metadata:
      • annotations: nur Annotationen, die für GKE Sandbox relevant sind, z. B. Annotationen, die mit dem Präfix dev.gvisor.* beginnen.
      • labels: batch.kubernetes.io/job-completion-index
    • spec:
      • volumes: name, volumeSource, hostPath, persistentVolumeClaim, configMap
      • containers:
        • name
        • image
        • command
        • args
        • workingDir
        • ports: name, containerPort, protocol
        • volumeMounts: name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation, subPathExpr
        • volumeDevices: name
        • lifecycle: postStart, preStop
        • terminationMessagePath
        • terminationMessagePolicy
        • securityContext (und alle Unterfelder)
        • stdin
        • stdinOnce
        • tty
      • initContainers: dieselben Unterfelder wie containers.
      • dnsPolicy
      • automountServiceAccountToken
      • hostNetwork
      • hostPID
      • hostIPC
      • shareProcessNamespace
      • securityContext
      • dnsConfig
      • runtimeClassName
      • os
      • hostUsers

  • Hardwarekompatibilität: Der Ziel-Pod muss auf einem Knoten mit derselben Maschinenserie und CPU-Architektur wie der ursprüngliche Pod mit Checkpoint ausgeführt werden (z. B. N2 zu N2 oder G2 zu G2).

  • Versionskompatibilität: Die GKE Sandbox-Kernelversion und die GPU-Treiberversion müssen mit der Version übereinstimmen, die im ursprünglichen Snapshot erfasst wurde.

rootfs-only Bereichsabgleich

Wenn Sie Ihre Richtlinie mit dem Bereich rootfs-only konfigurieren (verfügbar in GKE-Version 1.35.3-gke.1031000 und höher), sind die Anforderungen an die Übereinstimmung weniger streng:

  • In GKE wird der Hash der komprimierten Pod-Spezifikation nicht berechnet oder verglichen. Durch diese gelockerte Übereinstimmung können Sie einen Snapshot in einem Ziel-Pod mit anderen Ressourcen, Umgebungen oder anderen Konfigurationsfeldern wiederherstellen. Das zugrunde liegende Container-Image und die Knotenversionen müssen jedoch kompatibel sein.
  • Da der Prozessspeicher nicht wiederhergestellt wird, können Sie Snapshots, die für eine Maschinenfamilie erstellt wurden, in einer anderen Maschinenfamilie (einschließlich E2-Maschinentypen) wiederherstellen.

Abgleich von Gruppierungsregeln

Wenn in der Richtlinie das Feld snapshotGroupingRules verwendet wird, um Snapshots nach bestimmten Labelwerten (z. B. Mandant oder Umgebung) zu gruppieren, muss der wiederhergestellte Pod übereinstimmende Labelschlüssel und ‑werte haben. Der Pod-Snapshot-Controller wählt nur einen Snapshot aus der entsprechenden Gruppe aus. Weitere Informationen zum Einrichten von Gruppierungslabels finden Sie unter Zusätzliche Richtlinien für Pod-Snapshots konfigurieren.

Tagesform und Hintergrundladen wiederherstellen

Wenn ein Pod aus einem Snapshot wiederhergestellt wird, wird zuerst der GKE Sandbox-Kernel wiederhergestellt. Das dauert in der Regel einige Sekunden. Um die Startlatenz zu minimieren, wird die Anwendung sofort nach der Wiederherstellung des Kernels fortgesetzt. Es wird nicht gewartet, bis der Anwendungsspeicher vollständig geladen ist. Der Arbeitsspeicher der Anwendung wird über einen Hintergrundstreaming-Mechanismus wiederhergestellt.

Wenn die Anwendung versucht, einen Teil des Speichers zu lesen, der noch nicht geladen wurde, tritt ein Seitenfehler auf. GKE Sandbox fängt diesen Fehler ab, pausiert den Anwendungs-Thread und ruft die erforderliche Speicherseite sofort aus dem Speicher ab. Dieses On-Demand-Abrufen hat Vorrang vor dem Hintergrundstream.

Aufgrund dieses Hintergrundladens kann es in den ersten Sekunden nach einer Wiederherstellung zu einer kurzen Latenz beim Speicherzugriff kommen, wenn die Anwendung nicht gestreamten Speicher anfordert. Diese Latenz verschwindet, wenn der Speicherstatus vollständig synchronisiert ist.

Dieses Verhalten beim Laden im Hintergrund gilt auch für den GPU-Status. Ein Pod für ein Large Language Model (LLM) kann beispielsweise den Status Running haben und auf Netzwerkprüfungen reagieren, obwohl der GPU-Arbeitsspeicher noch belegt wird. Das Modell reagiert erst wieder vollständig auf Inferenzanfragen, wenn der GPU-Status vollständig wiederhergestellt ist. Messen Sie daher die Wiederherstellungsgeschwindigkeit erst, wenn der Modellserver bereit ist, Anfragen zu bearbeiten. Sie können die Bereitschaft des Modell-Servers anhand von Messwerten wie der Zeit bis zum ersten Token (Time to First Token, TTFT) oder Pod-Bereitschaftstests prüfen.

GPU-Status

Pod-Snapshots unterstützen das Erfassen des GPU-Status. Wenn Sie einen Snapshot für einen Pod auslösen, der GPUs verwendet, speichert das NVIDIA-Tool cuda-checkpoint den GPU-Status im Prozessspeicher. Dieser Schritt trägt dazu bei, dass auf der GPU gespeicherte Daten wie Modellgewichte im Snapshot enthalten sind. GKE pausiert den Pod und erstellt einen Snapshot. Bei der Wiederherstellung macht GKE diesen Vorgang rückgängig.

Da der GPU-Status in den Prozessarbeitsspeicher geschrieben wird, steigt die Pod-Arbeitsspeichernutzung während Snapshot- und Wiederherstellungsvorgängen. Berücksichtigen Sie diesen zusätzlichen Arbeitsspeicherbedarf, wenn Sie Arbeitsspeicherlimits für Ihre Pods festlegen.

Hinweise zu wiederhergestellten Pods

Aus Sicht der Kubernetes API wird ein neues Pod-Objekt erstellt. Wenn der Pod gestartet wird und ein entsprechender Snapshot für den Pod vorhanden ist, stellt GKE den Pod aus diesem Snapshot wieder her, einschließlich des ursprünglichen Arbeitsspeicher- und Prozessstatus. Einige Aspekte des Pod-Status müssen sich jedoch ändern, damit er als neue, eindeutige Instanz fungieren kann.

Beachten Sie die folgenden Statusänderungen nach einer Wiederherstellung:

  • Netzwerkschnittstellen: Der wiederhergestellte Pod erhält eine neue IP-Adresse. Alle Schnittstellen und Routen werden neu konfiguriert. Aktive Netzwerkverbindungen, die zum Zeitpunkt des Snapshots bestanden, werden bei der Wiederherstellung geschlossen. Listening-Sockets, Loopback-Verbindungen und Unix Domain Socket-Verbindungen funktionieren weiterhin.
  • Hostname: Der wiederhergestellte Pod erhält eine neue Identität und einen neuen Hostnamen.
  • Echtzeit: Die Echtzeit wird auf die aktuelle Zeit aktualisiert.
  • Anwendungsstatus: Der Anwendungsstatus muss für jeden Pod eindeutig sein, z. B. Experiment-IDs oder Zufallszahlengenerator-Seeds, und muss nach einer Wiederherstellung neu initialisiert werden.
  • Secrets: Verschlüsselungsschlüssel und Zertifikate, die vor dem Erstellen des Snapshots erstellt wurden, müssen neu erstellt werden.
  • Umgebungsvariablen: Sie können Umgebungsvariablen zwischen einem Snapshot und einer Wiederherstellung ändern. Da Umgebungsvariablen jedoch im Anwendungsspeicher gespeichert werden, kann GKE Sandbox sie nicht zuverlässig finden und ersetzen. Wenn Ihre Arbeitslast nach einer Wiederherstellung auf neue Umgebungsvariablen angewiesen ist, müssen diese im Pod manuell aktualisiert werden. Die neuen Umgebungsvariablen sind in der Datei /proc/gvisor/spec_environ verfügbar. Das Dateiformat ist dasselbe wie für /proc/<pid>/environ.

Mehrmandantenfähigkeit und Identität

Für Pod-Snapshots sind manuelle IAM-Bindungen (Identity and Access Management) für das Kubernetes-ServiceAccount-Objekt jedes Pods erforderlich, damit Cloud Storage verwendet werden kann. Es kann einige Zeit dauern, bis die manuellen IAM-Bindungen übernommen werden. Das kann problematisch sein, wenn Sie sofort nach dem Erstellen eines Pods Snapshots erstellen müssen.

Um Verzögerungen zu vermeiden und die Verwaltung von Mandanten zu vereinfachen, können Sie anstelle der manuellen Bindung von IAM an ServiceAccount-Objekte ein GKE-Knotendienstkonto verwenden, um bei Bedarf kurzlebige Tokens zu erstellen. Wenn Sie Pod-Snapshots mit diesem Ansatz konfigurieren möchten, verwenden Sie das Feld tokenSource in der benutzerdefinierten Ressource „PodSnapshotStorageConfig“ mit einem der folgenden Werte:

  • podKSA (Standard): verwendet manuelle IAM-Bindungen zwischen dem ServiceAccount-Objekt des Pods und dem Cloud Storage-Bucket.
  • federatedP4SA: Verwendet ein pfadspezifisches Token, das vom Dienstkonto des Knotens erstellt wurde.

Voraussetzungen

Wenn Sie GKE-Pod-Snapshots verwenden möchten, müssen Sie die folgenden Anforderungen erfüllen:

  • Pods müssen in der GKE Sandbox ausgeführt werden, da Pod-Snapshots von der isolierten Umgebung abhängen, die GKE Sandbox bietet.
  • Damit Sie GPUs mit Pod-Snapshots verwenden können, müssen die folgenden Anforderungen erfüllt sein:
    • Pods mit einer einzelnen GPU werden sowohl auf Knoten mit einer einzelnen GPU als auch auf Knoten mit mehreren GPUs unterstützt.
    • Pods mit mehreren GPUs werden nur auf L4-GPUs (g2-standard-*-Maschinentypen) unterstützt.
    • In GKE-Versionen bis 1.35.0-gke.1738000 muss ein Pod, der auf einem Multi-GPU-Knoten ausgeführt wird, alle auf diesem Knoten verfügbaren GPUs verwenden. In Version 1.35.0-gke.1738000 und höher können Pods eine Teilmenge der GPUs auf einem Knoten verwenden.
    • Sie müssen einen der folgenden unterstützten Maschinentypen verwenden:
      • g2-standard-4 (1 x L4)
      • g2-standard-8 (1 x L4)
      • g2-standard-12 (1 x L4)
      • g2-standard-16 (1 x L4)
      • g2-standard-32 (1 x L4)
      • g2-standard-48 (4 × L4)
      • g2-standard-96 (8 × L4)
      • a2-highgpu-1g (1 × A100-40 GB)
      • a2-ultragpu-1g (1 × A100-80GB)
      • a3-highgpu-1g (1 × H100-80GB)

Beschränkungen

Für GKE-Pod-Snapshots gelten die folgenden Einschränkungen:

  • Pod-Snapshots unterstützen keine E2-Maschinentypen, wenn der Standard-Snapshot-Bereich whole-pod verwendet wird. Dateisystem-Snapshots (rootfs-only) werden für E2-Maschinentypen unterstützt.
  • Die GPU-Freigabe mit Multi-Instance-GPU (MIG) wird nicht unterstützt.
  • Der Sidecar-Container für den Cloud Storage FUSE CSI-Treiber wird nicht mit Pod-Snapshots unterstützt.
  • Pod-Snapshots unterstützen keine TPUs.

Nächste Schritte