GKE-Pod-Snapshots

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 Änderungen am Arbeitsspeicher und am Dateisystem. Wenn Sie neue Replikate erstellen, werden sie aus dem Snapshot wiederhergestellt. So kann die Arbeitslast fortgesetzt werden, anstatt in einem neuen Zustand zu beginnen.

Dieses Dokument bietet eine konzeptionelle Übersicht über GKE-Pod-Snapshots. Informationen zum Aktivieren und Verwenden dieser Funktion finden Sie unter Aus einem Pod-Snapshot wiederherstellen.

Wann sollten Pod-Snapshots verwendet werden?

Verwenden Sie Pod-Snapshots für Arbeitslasten mit langen Initialisierungszeiten, z. B. KI-Inferenzarbeitslasten, 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 neue Replikate erstellt werden, wird der Pod nicht von einem neuen Zustand aus initialisiert, sondern aus einem Snapshot wiederhergestellt. Die Ausführung wird an dem Punkt fortgesetzt, an dem der Snapshot erstellt wurde.

Wenn Sie Pod-Snapshots verwenden möchten, erstellen Sie benutzerdefinierte Kubernetes-Ressourcendefinitionen (CRDs), um das Snapshot-Verhalten deklarativ zu konfigurieren. 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. Cloud Storage speichert Ihre Pod-Snapshots.

Benutzerdefinierte Ressourcendefinitionen

Pod-Snapshots werden deklarativ mit den folgenden CRDs konfiguriert:

  • PodSnapshotStorageConfig: Gibt den Speicherort für Snapshots an. Es werden nur Cloud Storage-Buckets unterstützt.
  • PodSnapshotPolicy: Definiert, welche Pods auf Grundlage von Kubernetes-Labelselektoren als Snapshot erstellt werden sollen. Diese Ressource enthält die meisten Konfigurationsoptionen für die Funktion, einschließlich der Auslösung von Snapshots und Aufbewahrungsrichtlinien.
  • PodSnapshotManualTrigger: (optional) Wenn Sie keinen Workload-Trigger verwenden, wird ein manueller Trigger definiert, um einen Snapshot für einen bestimmten Pod zu erstellen.

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. Dieser Triggertyp wird einmal in einem Arbeitslastzyklus ausgeführt, z. B. wenn eine Arbeitslast bereit ist. Dieser Ansatz eignet sich am besten, um die Startlatenz von horizontal skalierten Arbeitslasten zu verbessern.
  • Manueller Trigger: Sie können einen Snapshot bei Bedarf für einen bestimmten Pod auslösen, indem Sie eine benutzerdefinierte PodSnapshotManualTrigger-Ressource erstellen. Dieser Triggertyp kann beliebig oft ausgeführt werden. Dieser Ansatz eignet sich am besten für Situationen, in denen Sie Ihre Anwendung nicht ändern können, um die Bereitschaft zu signalisieren.

Snapshot-Abgleich

Beim Pod-Abgleich wird ermittelt, ob ein Pod-Snapshot mit einem bestimmten Pod kompatibel ist. Diese Übereinstimmung wird erreicht, indem ein eindeutiger Hash aus den wesentlichen Laufzeitspezifikationen des Pods erstellt wird, auch als „destillierte Pod-Spezifikation“ bezeichnet. Dieser Hash wird dann in den Pod-Snapshot eingebettet. Damit ein späterer Pod aus diesem Pod-Snapshot wiederhergestellt werden kann, muss er einen identischen Hash aus seiner eigenen komprimierten Pod-Spezifikation generieren. Dieser Prozess trägt dazu bei, dass die Pods mit Checkpoint und die wiederhergestellten Pods in ihren Laufzeitkonfigurationen identisch sind.

Durch die Destillation wird die Pod-Spezifikation vereinfacht, indem nur die kritischen Laufzeitfelder wie image beibehalten und nicht benötigte Felder wie nodeName oder nodeSelector entfernt werden. Sie müssen dafür sorgen, dass die Werte dieser wichtigen Felder zwischen dem Pod, der für die Erstellung von Prüfpunkten verwendet wird, und dem Pod, der für die Wiederherstellung vorgesehen ist, übereinstimmen.

Die folgenden Felder des Pod-Objekts beeinflussen den eindeutigen Hash:

  • metadata:
    • annotations: nur Anmerkungen, die für die gVisor-Laufzeit relevant sind, z. B. Anmerkungen, 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

Die folgenden zusätzlichen Kriterien müssen übereinstimmen, damit ein Snapshot als kompatibel gilt:

  • Hardware: Der neue Pod muss auf einem Knoten mit derselben Maschinenserie und Architektur wie der ursprüngliche Pod ausgeführt werden. Die Maschinenserie und die Architektur müssen identisch sein. Die Anzahl der CPUs und die Speichermenge können sich ändern. E2-Maschinentypen werden aufgrund ihrer dynamischen zugrunde liegenden Architektur nicht unterstützt.
  • Versionsverwaltung: Die gVisor-Kernelversion und die GPU-Treiberversion müssen übereinstimmen.

GKE verwaltet die Snapshot-Kompatibilität. Wenn GKE einen kompatiblen Snapshot findet, wird der neue Pod aus dem Snapshot wiederhergestellt. Wenn kein kompatibler Snapshot vorhanden ist, wird der Pod normal gestartet.

Tagesform und Hintergrundbelastung wiederherstellen

Wenn ein Pod aus einem Snapshot wiederhergestellt wird, wird zuerst der gVisor-Kernel wiederhergestellt. Das dauert in der Regel einige Sekunden. Um die Startlatenz zu minimieren, wird die Anwendung sofort fortgesetzt, nachdem der Kernel wiederhergestellt wurde. Es wird nicht gewartet, bis der Arbeitsspeicher der Anwendung vollständig geladen ist. Der Arbeitsspeicher der Anwendung wird durch einen Hintergrundstreaming-Mechanismus wiederhergestellt.

Wenn die Anwendung versucht, auf einen Teil des Speichers zuzugreifen, der noch nicht geladen wurde, tritt ein Seitenfehler auf. gVisor 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 der Speicherzugriff in den ersten Sekunden nach einer Wiederherstellung eine geringe Latenz aufweisen, wenn die Anwendung Speicher benötigt, der noch nicht gestreamt wurde. 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 großes Sprachmodell (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 Anfragen, wenn der GPU-Status vollständig wiederhergestellt ist. Achten Sie daher beim Messen der Wiederherstellungsgeschwindigkeit darauf, dass Sie erfassen, wann der Modellserver gestartet wurde. Sie können anhand von Messwerten wie „Time-to-First-Token“ (TTFT) oder Bereitschaftsprüfungen für Pods prüfen, wann der Modellserver gestartet wird.

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. Das bedeutet, dass alle auf der GPU gespeicherten Daten, z. B. Modellgewichte, im Snapshot enthalten sind. Der Pod wird dann pausiert und es wird ein Snapshot erstellt. Bei der Wiederherstellung wird der Vorgang umgekehrt.

Da der GPU-Status in den Prozessspeicher geschrieben wird, steigt die Pod-Speichernutzung 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 neuer Pod erstellt. Wenn der Pod gestartet wird und ein entsprechender Snapshot für den Pod vorhanden ist, wird der Pod aus diesem Snapshot wiederhergestellt, einschließlich des ursprünglichen Arbeitsspeichers und Prozessstatus. Damit der Pod als neue, eindeutige Instanz fungieren kann, müssen sich jedoch einige Aspekte des Pod-Status ändern.

Beachten Sie die folgenden Statusänderungen nach einer Wiederherstellung:

  • Netzwerkschnittstellen: Der wiederhergestellte Pod erhält eine neue IP-Adresse. Alle Netzwerkschnittstellen und Routen werden neu konfiguriert. Aktive Netzwerkverbindungen, die zum Zeitpunkt des Snapshots bestanden, werden bei der Wiederherstellung geschlossen. Listening-Sockets funktionieren weiterhin.
  • Hostname: Der wiederhergestellte Pod erhält eine neue Identität und einen neuen Hostnamen.
  • Anwendungsstatus: Der Anwendungsstatus, der für jeden Pod eindeutig sein muss, z. B. Test-IDs oder Zufallszahl-Seeds, muss nach einer Wiederherstellung neu initialisiert werden.
  • Secrets: Verschlüsselungsschlüssel und Zertifikate, die vor der Erstellung 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.

Status, der sich nach dem Wiederherstellen ändert

Beim Wiederherstellen werden nicht alle Status beibehalten. Die folgenden Teile des Pod-Status ändern sich, damit der Pod eine neue Identität annehmen kann:

  • Netzwerkschnittstellen: Der wiederhergestellte Pod erhält eine neue IP-Adresse. Alle Schnittstellen und Routen werden neu konfiguriert. Aktive Netzwerkverbindungen, die zum Zeitpunkt der Momentaufnahme 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 springt auf die aktuelle Zeit vor.

Beschränkungen und Anforderungen

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

  • Pods müssen in GKE Sandbox ausgeführt werden, da Pod-Snapshots von der gVisor-Containerlaufzeit abhängen, die von GKE Sandbox bereitgestellt wird.
  • Pod-Snapshots unterstützen keine E2-Maschinentypen.
  • Pod-Snapshots funktionieren mit Pods mit einer einzelnen GPU. Es werden nur die folgenden Multi-GPU-Konfigurationen unterstützt:
    • 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)
  • Die teilweise GPU-Nutzung wird nicht unterstützt. Wenn ein Knoten mehrere GPUs hat, muss ein Pod alle verwenden. Sie können beispielsweise keine Pod-Snapshots mit vier Pods verwenden, die jeweils eine GPU auf einer Maschine mit vier GPUs verwenden.
  • Die Verwendung des Sidecar-Containers für den Cloud Storage FUSE CSI-Treiber mit Pod-Snapshots wird nicht unterstützt.

Nächste Schritte