GKE-Pod-Snapshots

Mit Pod-Snapshots in der Google Kubernetes Engine (GKE) können Sie die Startlatenz von Arbeitslasten verbessern, indem Sie Snapshots von laufenden Pods wiederherstellen. 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 in einem neuen Zustand zu beginnen. 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 erfahren Sie, 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

GKE-Pod-Snapshots speichern eine genaue Kopie des Prozessstatus eines Pods zu einem bestimmten Zeitpunkt. 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.

Wenn Sie Pod-Snapshots deklarativ konfigurieren möchten, 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
  • Gemerkte Information wird verarbeitet
  • 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 das Feature, einschließlich der Art und Weise, wie Snapshots ausgelöst werden, des Snapshot-Bereichs 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:

  • Arbeitslasttrigger: Die Anwendung im Pod signalisiert dem GKE-Agenten, 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, um die Startlatenz von horizontal skalierenden Arbeitslasten zu verbessern.
  • 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. Diese Art von Trigger kann beliebig oft ausgeführt werden. Diese Vorgehensweise eignet sich am besten, wenn Sie Ihre Anwendung nicht ändern können, um Bereitschaft zu signalisieren.

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 Prüfpunkt und dem Ziel-Pod durch.

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

  • 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 PodSnapshotPolicy-Ressource konfiguriert ist (whole-pod oder rootfs-only).

whole-pod-Bereichsabgleich (Standard)

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

  • Distillierter Spezifikations-Hash: GKE generiert einen eindeutigen Hash basierend auf wichtigen Laufzeitfeldern in der Pod-Spezifikation. Damit eine Wiederherstellung erfolgreich ist, muss der Ziel-Pod einen identischen Hash aus seiner destillierten Spezifikation generieren. Bei dieser Prüfung wird überprüft, ob die per Prüfpunkt gesicherten und wiederhergestellten Pods 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 diesen weniger strengen Abgleich 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 auf einer Maschinenfamilie erstellt wurden, auf einer anderen Maschinenfamilie wiederherstellen, einschließlich E2-Maschinentypen.

Übereinstimmende 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 Label-Schlü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 Hintergrund-Streaming-Mechanismus wiederhergestellt.

Wenn die Anwendung versucht, einen Teil des Speichers zu lesen, der noch nicht geladen wurde, tritt ein Seitenfehler auf. Die GKE-Sandbox fängt diesen Fehler ab, pausiert den Anwendungsthread und ruft die erforderliche Speicherseite sofort aus dem Speicher ab. Dieses On-Demand-Abrufen wird gegenüber dem Hintergrundstream priorisiert.

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 sein GPU-Speicher noch gefüllt wird. Das Modell reagiert erst dann vollständig auf Inferenzen, wenn der GPU-Status vollständig wiederhergestellt ist. Achten Sie aufgrund dieser Verzögerung beim Messen der Wiederherstellungsgeschwindigkeit darauf, dass Sie messen, wann der Modellserver bereit ist, Anfragen zu verarbeiten. Sie können die Bereitschaft des Modellservers mit Messwerten wie der Zeit bis zum ersten Token (TTFT) oder Pod-Bereitschaftsprüfungen 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. So wird sichergestellt, dass Daten, die auf der GPU gespeichert sind, z. B. Modellgewichte, im Snapshot enthalten sind. GKE pausiert den Pod und erstellt einen Snapshot. Während der Wiederherstellung kehrt GKE diesen Vorgang um.

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 Speicher- und Prozessstatus. Damit der Pod als neue, eindeutige Instanz fungieren kann, müssen sich jedoch einige Aspekte des Pod-Status ändern.

Nach einer Wiederherstellung können sich folgende Statusänderungen ergeben:

  • Netzwerkschnittstellen: Der wiederhergestellte Pod erhält eine neue IP-Adresse. Alle Schnittstellen und Routen werden neu konfiguriert. Aktive Netzwerkverbindungen, die zum Zeitpunkt des Snapshots vorhanden waren, werden bei der Wiederherstellung geschlossen. Listening-Sockets, Loopback-Verbindungen und Unix-Domain-Socket-Verbindungen funktionieren weiterhin.
  • Hostname: Der wiederhergestellte Pod nimmt eine neue Identität an und erhält einen neuen Hostnamen.
  • Tatsächlich verstrichene Zeit: Die tatsächlich verstrichene Zeit springt auf die aktuelle Zeit vor.
  • Anwendungsstatus: Der Anwendungsstatus muss für jeden Pod eindeutig sein, z. B. Experiment-IDs oder Zufallszahlen-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 bei /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. Die manuellen IAM-Bindungen können einige Zeit in Anspruch nehmen, bis sie übernommen werden. Das kann problematisch sein, wenn Sie Snapshots unmittelbar nach dem Erstellen eines Pods erstellen müssen.

Um Verzögerungen zu vermeiden und die Verwaltung mehrerer Mandanten zu vereinfachen, können Sie anstelle der manuellen Bindung von IAM an ServiceAccount-Objekte ein GKE-Knotendienstkonto verwenden, um kurzlebige Tokens bei Bedarf 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 GKE Sandbox ausgeführt werden, da Pod-Snapshots von der isolierten Umgebung abhängen, die GKE Sandbox bietet.
  • Wenn Sie GPUs mit Pod-Snapshots verwenden möchten, 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.
    • Multi-GPU-Pods 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 den Versionen 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 x 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) unterstützen E2-Maschinentypen.
  • 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