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. Ein Pod-Snapshot speichert den gesamten Pod-Status, einschließlich Änderungen am Arbeitsspeicher und am Dateisystem. Wenn Sie neue Replikate erstellen, werden sie aus dem Snapshot wiederhergestellt, sodass die Arbeitslast fortgesetzt werden kann, anstatt von einem neuen Zustand aus zu starten. Diese Funktion ist hilfreich für horizontal skalierbare Arbeitslasten, z. B. KI-Inferenzmodelle, die große Gewichtungen 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 die Prüfpunkterstellung und Wiederherstellung verwaltet. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die inCloud de Confiance by S3NS -Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

In den folgenden Anleitungen erfahren Sie, wie Sie Pod-Snapshots in Ihren Clustern vorbereiten und verwenden:

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

Wann Pod-Snapshots verwendet werden sollten

Verwenden Sie Pod-Snapshots für Arbeitslasten mit langen Initialisierungszeiten. Beispiele hierfür sind KI-Inferenzarbeitslasten, bei denen große Modelle in den CPU- oder GPU-Arbeitsspeicher geladen werden, oder große Anwendungen, die viele Bibliotheken und Abhängigkeiten laden. 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 Grund auf, sondern stellt ihn aus einem Snapshot wieder her. Diese Wiederherstellung bedeutet, dass der Pod die Ausführung ab dem Punkt fortsetzt, 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 sollen. 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 ein Pod-Snapshot enthält und was nicht:

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, von welchen Pods basierend auf Kubernetes-Label-Selectoren Snapshots erstellt werden sollen. 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 Arbeitslasttrigger verwenden, wird ein manueller Trigger definiert, um einen Snapshot für einen bestimmten Pod zu erstellen.

Referenzspezifikationen finden Sie in der PodSnapshot-CustomResourceDefinition-Referenz.

Snapshot-Trigger

Sie können einen Pod-Snapshot auf folgende Weise auslö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 die 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 für einen bestimmten Pod bei Bedarf auslösen, indem Sie eine benutzerdefinierte PodSnapshotManualTrigger-Ressource erstellen. Diese Art von Trigger kann beliebig oft ausgeführt werden. Dieser Ansatz eignet sich am besten für Situationen, in denen 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 Prüfpunkt und dem Ziel-Pod durch.

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

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

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 destillierten 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, demselben CPU-Anbieter und demselben CPU-Feature-Set (CPUID-Flags) wie der Prüfpunkt-Pod ausgeführt werden. Beide Knoten müssen beispielsweise dieselbe N2- oder G2-Serie und dieselben Intel- oder AMD-Prozessorfunktionen verwenden. GKE Sandbox prüft die CPU-Funktionen, bevor der Prozessspeicher und der CPU-Status wiederhergestellt werden. Ein Snapshot mit dem Bereich whole-pod kann daher nicht auf einem Knoten mit anderen CPU-Funktionen wiederhergestellt werden.

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

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:

• Die GKE berechnet oder vergleicht den Hash der destillierten Pod-Spezifikation nicht. 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, in einer anderen Maschinenfamilie (einschließlich E2-Maschinentypen) wiederherstellen.

Ü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 Labelschlüssel und -werte haben. Der Pod-Snapshot-Controller wählt einen Snapshot nur aus der übereinstimmenden Gruppe aus. Weitere Informationen zum Einrichten von Gruppierungslabels finden Sie unter Zusätzliche Einstellungen für Pod-Snapshot-Richtlinien konfigurieren.

Bereitschaft 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 Anwendungsspeicher wird mithilfe eines Hintergrund-Streaming-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 Anwendungsthread und ruft die erforderliche Speicherseite sofort aus dem Speicher ab. Dieses On-Demand-Abrufen wird gegenüber dem Hintergrundstream priorisiert.

Aufgrund dieses Hintergrundladevorgangs 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. Beispielsweise kann ein Pod für ein Large Language Model (LLM) den Status Running haben und auf Netzwerkprüfungen reagieren, obwohl der GPU-Speicher noch belegt 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 Status von GPUs. Wenn Sie einen Snapshot für einen Pod auslösen, der GPUs verwendet, speichert das NVIDIA-Tool cuda-checkpoint den GPU-Status im Prozessspeicher. Mit diesem Schritt wird sichergestellt, dass auf der GPU gespeicherte Daten wie Modellgewichtungen im Snapshot enthalten sind. Die GKE pausiert den Pod und erstellt einen Snapshot. Während der Wiederherstellung kehrt GKE diesen Vorgang um.

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 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. Einige Aspekte des Pod-Status müssen sich jedoch ändern, damit er als neue, eindeutige Instanz funktioniert.

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 vorhanden waren, 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.
• Tatsächlich verstrichene Zeit: Die tatsächlich verstrichene Zeit springt zur aktuellen Zeit.
• Anwendungsstatus: Der Anwendungsstatus muss für jeden Pod eindeutig sein, z. B. Test-IDs oder Zufallszahlengeneratoren, 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 die GKE Sandbox sie nicht zuverlässig finden und ersetzen. Wenn Ihre Arbeitslast nach einer Wiederherstellung auf neuen Umgebungsvariablen basiert, müssen diese vom Pod manuell aktualisiert werden. Die neuen Umgebungsvariablen sind in der Datei /proc/gvisor/spec_environ verfügbar. Das Dateiformat ist dasselbe wie /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, um Cloud Storage zu verwenden. Die manuelle IAM-Bindung kann einige Zeit in Anspruch nehmen. Das kann ein Problem sein, wenn Sie sofort nach dem Erstellen eines Pods Snapshots 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 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 die folgenden Anforderungen erfüllt sein:

• Pods müssen in GKE Sandbox ausgeführt werden, da Pod-Snapshots von der isolierten Umgebung abhängen, die GKE Sandbox bietet.
• Für den Standard-Snapshot-Bereich whole-pod muss der Knoten, auf dem der Pod wiederhergestellt wird, dieselbe Maschinenserie, denselben CPU-Anbieter und dieselben CPU-Features wie der Knoten haben, auf dem der Snapshot erstellt wurde. Für reine CPU-Arbeitslasten können alle von GKE Sandbox unterstützten Nicht-E2-Maschinenserien verwendet werden, die diese Hardwarekompatibilitätsanforderungen erfüllen. Weitere Informationen finden Sie unter Einschränkungen.
• Wenn Sie GPUs mit Pod-Snapshots verwenden möchten, müssen Sie außerdem die folgenden Anforderungen erfüllen:
  • 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 Knoten mit mehreren GPUs ausgeführt wird, alle auf diesem Knoten verfügbaren GPUs verwenden. In Versionen ab 1.35.0-gke.1738000 können Pods eine Teilmenge der GPUs auf einem Knoten verwenden.
  • Für GPU-Arbeitslasten müssen Sie einen der folgenden unterstützten GPU-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 x L4)
    • g2-standard-96 (8 x L4)
    • a2-highgpu-1g (1 x A100-40GB)
    • a2-ultragpu-1g (1 x A100-80GB)
    • a3-highgpu-1g (1 x H100-80GB)

Beschränkungen

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

• Wenn Sie den Standard-Snapshot-Bereich whole-pod verwenden, kann ein Snapshot nicht auf einer Compute Engine-VM mit anderen CPU-Features (CPUID-Flags) als der VM wiederhergestellt werden, auf der der Snapshot erstellt wurde:
  • Pod-Snapshots mit dem Bereich whole-pod unterstützen die E2-Maschinenserie oder andere Maschinenserien, die Intel- und AMD-Prozessoren oder CPU-Generationen dynamisch kombinieren, nicht. Dateisystem-Snapshots (Bereich rootfs-only) unterstützen die E2-Maschinenserie.
  • Selbst innerhalb derselben Nicht-E2-Maschinenserie und desselben CPU-Anbieters kann Compute Engine VMs mit unterschiedlichen CPU-Plattformen oder VM-spezifischen CPU-Feature-Sets bereitstellen. Wenn ein Pod auf einem Knoten mit nicht übereinstimmenden CPU-Features geplant wird, schlägt die Wiederherstellung eines Snapshots mit dem Bereich whole-pod fehl.
• Die GPU-Freigabe mit Multi-Instanz-GPU (MIG) wird nicht unterstützt.
• Der Sidecar-Container des Cloud Storage FUSE-CSI-Treibers wird bei Pod-Snapshots nicht unterstützt.
• Pod-Snapshots unterstützen keine TPUs.

Nächste Schritte

• Pod-Snapshots vorbereiten