Strategien zur Reduzierung der Startlatenz

Google Kubernetes Engine (GKE) bietet mehrere Strategien, mit denen Sie die Startlatenz von Pods reduzieren können, wenn Ihre Arbeitslasten skaliert werden. Durch die Reduzierung von Verzögerungen bei der Knotenbereitstellung, beim Abrufen von Container-Images und bei der Anwendungsinitialisierung können Sie die Reaktionsfähigkeit des Dienstes bei Trafficspitzen verbessern und die Infrastrukturkosten ausgleichen.

In diesem Dokument können Sie Strategien zur Reduzierung der GKE-Startlatenz während des gesamten Pod-Startlebenszyklus vergleichen und eine einzelne Strategie oder eine mehrschichtige Kombination auswählen, die Ihren Arbeitslastanforderungen entspricht.

Pod-Startlebenszyklus

Wenn eine Arbeitslast in GKE skaliert wird und vorhandene Knoten nicht genügend zuweisbare Kapazität für die neuen Pods haben, umfasst die End-to-End-Startlatenz drei aufeinanderfolgende Phasen:

  • In der Phase der Knotenbereitstellung und Pod-Planung stellt der Cluster Autoscaler eine neue Compute Engine-VM bereit, initialisiert den Knoten und registriert ihn bei der Steuerungsebene, damit der Kubernetes-Scheduler den ausstehenden Pod platzieren kann.
  • In der Phase des Abrufs von Container-Images lädt die Komponente kubelet auf dem Knoten die für den Pod erforderlichen Container-Images aus Ihrer Container Registry herunter und entpackt sie.
  • In der Phase der Anwendungsinitialisierung startet die Containerlaufzeit den Anwendungsprozess, lädt Abhängigkeiten oder Modellgewichte in den Arbeitsspeicher und besteht die Kubernetes-Start- und Bereitschaftsprüfungen.

Verschiedene GKE-Funktionen sind auf bestimmte Phasen dieses Lebenszyklus ausgerichtet. Informationen dazu, welche Phase am meisten zur Startzeit Ihrer Arbeitslast beiträgt, finden Sie unter Startlatenzmesswerte beobachten.

Strategien zur Reduzierung der Startlatenz vergleichen

In der folgenden Tabelle werden Strategien zur Reduzierung der GKE-Startlatenz während des gesamten Pod-Startlebenszyklus verglichen:

Strategie Lebenszyklusphase Latenzprofil Kosten- und Kontingentprofil Clustermodus und Hardwareunterstützung Optimal für
Aktive Kapazitätsreserven (Vorschau) Knotenbereitstellung und Pod-Planung Sofortige Pod-Planung, da Knoten bereits ausgeführt werden.

Standardmäßige knotenbasierte Compute-Preise für ausgeführte VMs.

Verbraucht Compute Engine-Kontingente für vCPU, Arbeitsspeicher, Laufwerk und IP-Adresse Kontingente sowie Kubernetes-Ressourcenkontingente im Namespace.

Standardcluster und Autopilot-Cluster mit benutzerdefinierten Compute-Klassen (knotenbasierte Abrechnung).

Unterstützt CPUs, GPUs und TPUs.

 Abfangen plötzlicher Trafficspitzen und Skalieren latenzempfindlicher GPU, TPU- oder CPU-Arbeitslasten.
Stand‑by Kapazitätsreserven (Vorschau) Knotenbereitstellung und Pod-Planung Setzt angehaltene Knoten in etwa 30 bis 35 Sekunden fort. Das ist schneller als die Bereitstellung eines neuen Knotens.

Keine VM-Compute-Gebühren während des Anhaltens. Es fallen Gebühren für den nichtflüchtigen Speicher für Bootlaufwerke und den gespeicherten Arbeitsspeicherstatus an.

Verbraucht Kontingente für Laufwerke und IP-Adressen während des Anhaltens sowie Kubernetes Ressourcenkontingente im Namespace.

Standardcluster (mit automatischer Knotenbereitstellung) und Autopilot-Cluster mit benutzerdefinierten Compute-Klassen.

Unterstützt nur CPUs (keine GPUs, TPUs oder lokalen SSDs).

 Kostengünstige Burst-Kapazität für anhaltendes Traffic Wachstum.
Schnell startende Knoten Knotenbereitstellung und Pod-Planung Reduziert die Startzeit für kalte Knoten nach dem Best-Effort-Prinzip durch Verwendung vorinitialisierter Hardware. Ohne zusätzliche Kosten.

Autopilot-Cluster und Autopilot-Arbeitslasten in Standardclustern.

Unterstützt geeignete Maschinenreihen für allgemeine Zwecke und GPU-Maschinenreihen ohne lokale SSDs oder Spot-VMs.

 Beschleunigung der grundlegenden Knotenbereitstellung ohne Konfigurations- oder Leerlaufkosten.
Platzhalter-Pods mit niedriger Priorität Knotenbereitstellung und Pod-Planung Sofortige Pod-Planung nach dem Entfernen von Platzhalter Pods mit niedrigerer Priorität.

Standardmäßige Compute-Preise für ausgeführte Knoten.

Erfordert manuelle Bereitstellung und PriorityClass-Verwaltung.

 Standard- und Autopilot-Cluster. Reservieren von freier Kapazität in Clustern, die die Pod-basierte Abrechnung oder Versionen vor 1.35 verwenden.
Image-Streaming Abruf von Container-Images Ermöglicht das Starten von Containern, ohne auf den Download des gesamten Images warten zu müssen.

Ohne zusätzliche Kosten.

Erfordert Artifact Registry oder geeignete Docker Hub-Repositories.

 Autopilot (standardmäßig aktiviert) und Standard Cluster. Reduzierung der Image-Abrufzeiten für große Container-Images.
Sekundäre Bootlaufwerke Abruf von Container-Images Hängt einen vorab gefüllten nichtflüchtigen Speicher parallel zur Knotenbereitstellung an neue Knoten an. Die Kosten werden für den angehängten Persistent Disk auf jedem Knoten und für die Speicherung von Speicherabbildern in Rechnung gestellt. Standard- und Autopilot-Cluster. Vorabladen großer Container-Images oder statischer Datasets wie Modellgewichte für maschinelles Lernen.
Pod Snapshots Initialisieren der Anwendung Stellt neue Pod-Replikate direkt aus einem gespeicherten Prüfpunkt des Prozess Arbeitsspeichers und des Dateisystemstatus wieder her. Die Kosten werden für die Speicherung von Snapshots in Cloud Storage in Rechnung gestellt.

Standard- und Autopilot-Cluster, auf denen Pods in GKE Sandbox ausgeführt werden.

Unterstützt geeignete CPU- und GPU-Maschinentypen (keine TPUs).

 Umgehen der zeitaufwendigen Initialisierung für KI-Inferenzmodelle und Anwendungen mit aufwendigen Startroutinen.
CPU Boost beim Starten (Vorschau) Initialisieren der Anwendung Erhöht vorübergehend die CPU-Anforderungen und ‑Limits während des Pod-Starts und ändert dann die Größe direkt. Verbraucht während des Startzeitraums vorübergehend zusätzliche Knoten-CPU-Kapazität. Standard- und Autopilot-Cluster mit aktiviertem vertikalem Pod Autoscaling. Beschleunigung der CPU-gebundenen Initialisierung für Laufzeiten wie Java, Python oder Node.js.

Strategie nach Pod-Startphase auswählen

In den folgenden Abschnitten werden die verfügbaren Optionen für jede Phase des Pod-Startlebenszyklus beschrieben.

Knotenbereitstellung und Pod-Planung beschleunigen

Wenn ausstehende Pods nicht auf vorhandenen Knoten platziert werden können, ist das Warten auf den Start eines neuen Knotens oft der größte Faktor für die Latenz beim Hochskalieren. Sie können diese Verzögerung mit den folgenden Strategien reduzieren oder beseitigen:

  • Verwenden Sie Kapazitätsreserven, um zusätzliche Knotenkapazität deklarativ zu reservieren:
    • Konfigurieren Sie eine aktive Reserve (buffer.x-k8s.io/active-capacity-Strategie), damit vorab bereitgestellte Knoten ausgeführt werden und Pods sofort geplant werden können. Aktive Reserven unterstützen CPU-, GPU- und TPU-Arbeitslasten.
    • Konfigurieren Sie eine Stand‑by-Reserve (buffer.gke.io/standby-capacity-Strategie), um vorab bereitgestellte CPU-Knoten im angehaltenen Zustand zu halten. Wenn Arbeitslasten skaliert werden, setzt GKE Stand‑by-Knoten in etwa 30 bis 35 Sekunden fort. So werden die vollen Compute-Kosten für die Ausführung von VMs im Leerlauf vermieden.
  • Verwenden Sie schnell startende Knoten für die automatische, nach dem Best-Effort-Prinzip durchgeführte Hardware Vorinitialisierung für geeignete Autopilot-Arbeitslasten und GPU-Maschinen serien. Wenn GKE neue Knoten für eine geeignete Arbeitslast bereitstellt, werden automatisch schnell startende Knoten verwendet. Dazu gehören auch Knoten, die erstellt wurden, um eine Kapazitätsreserve in einer kompatiblen benutzerdefinierten Autopilot-Compute-Klasse wieder aufzufüllen.
  • Stellen Sie Platzhalter-Pods mit niedriger Priorität mit Kubernetes-PriorityClasses bereit, wenn Ihre Arbeitslasten das Pod-basierte Abrechnungsmodell von Autopilot verwenden oder auf GKE-Versionen vor 1.35 ausgeführt werden. Für Cluster, die die knotenbasierte Abrechnung für unterstützte GKE-Versionen verwenden, sind deklarative Kapazitätsreserven besser geeignet, da sie keine Verwaltung von Platzhalter-Deployments oder Pod-Entfernungsschleifen erfordern.

Abruf von Container-Images beschleunigen

Nachdem der Scheduler einen Pod auf einem Knoten platziert hat, muss der Knoten das Container-Image abrufen, bevor der Container gestartet werden kann. Sie können die Latenz beim Abrufen von Images mit den folgenden Strategien reduzieren:

  • Aktivieren Sie Image-Streaming, damit Container gestartet werden können, sobald die erforderlichen Dateien über das Netzwerk gestreamt werden, während der Rest des Images im Hintergrund heruntergeladen wird. In Autopilot-Clustern ist das Image-Streaming standardmäßig für geeignete Images in Artifact Registry aktiviert.
  • Konfigurieren Sie sekundäre Bootlaufwerke, um große Container-Basisebenen oder statische Datasets auf ein benutzerdefiniertes Speicherabbild vorab zu laden. Wenn GKE einen Knoten erstellt, wird parallel zur Knotenbereitstellung ein Persistent Disk angehängt, der aus Ihrem Speicherabbild instanziiert wurde.
  • Führen Sie ein DaemonSet aus, um Container-Images während des Knoteninitialisierungszeitraums vorab in Stand‑by-Reserven zu laden während des Knoteninitialisierungszeitraums (buffer.gke.io/standby-capacity-init-time Annotation). Bevor GKE einen Stand‑by-Knoten anhält, ruft das DaemonSet Ihre Arbeitslast-Images auf das Bootlaufwerk des Knotens ab, damit die Images bereits im Cache gespeichert sind, wenn der Knoten fortgesetzt wird.

Anwendungsinitialisierung beschleunigen

Auch wenn ein Knoten ausgeführt wird und das Container-Image vorhanden ist, kann es lange dauern, bis Anwendungen Frameworks geladen, Just-in-Time-Code (JIT) kompiliert oder Modellgewichte in den Arbeitsspeicher geladen haben. Sie können die Initialisierungszeit mit den folgenden Strategien reduzieren:

  • Konfigurieren Sie Pod-Snapshots, um einen Prüfpunkt des Arbeitsspeichers und des Dateisystemstatus eines ausgeführten Pods in GKE Sandbox zu erfassen. Wenn Ihre Arbeitslast horizontal skaliert wird, stellt GKE neue Replikate aus dem Snapshot in Cloud Storage wieder her, sodass die Ausführung des Pods an dem Punkt fortgesetzt wird, an dem der Snapshot erstellt wurde, anstatt von einem neuen Zustand aus zu initialisieren.
  • Konfigurieren Sie den CPU-Boost beim Starten für einen VerticalPodAutoscaler, um einem Pod während der Zulassung und Initialisierung zusätzliche CPU zuzuweisen. Sobald der Pod den Status Ready erreicht und die konfigurierte Boost-Dauer abgelaufen ist, skaliert GKE die CPU-Anforderung des Pods direkt wieder auf die Baseline-Ebene herunter, ohne den Container neu zu starten.

Strategien für die End-to-End-Optimierung kombinieren

Da diese Strategien in verschiedenen Phasen des Pod-Startlebenszyklus ausgeführt werden, können Sie sie kombinieren, um die End-to-End-Skalierungszeit zu optimieren:

  • Kombinieren Sie eine kleine aktive Kapazitätsreserve mit einer größeren Stand‑by-Kapazitätsreserve. Bei einer plötzlichen Trafficspitze fängt die aktive Reserve sofort den ersten Burst von Pods ab. In der Zwischenzeit setzt GKE Knoten aus der Stand‑by-Reserve in etwa 30 bis 35 Sekunden fort, um die aktive Reserve wieder aufzufüllen und anhaltendes Wachstum zu bewältigen. Im Hintergrund stellt der Cluster Autoscaler neue Knoten bereit und hält sie an, um die Stand‑by-Reserve wieder aufzufüllen.
  • Aktivieren Sie für Stand‑by-Kapazitätsreserven das Image-Streaming oder laden Sie Container-Images mit einem DaemonSet vorab, bevor der Knoten angehalten wird , so dass der Knoten beim Fortsetzen keine großen Container-Images herunterladen muss.
  • Kombinieren Sie den CPU-Boost beim Starten oder Pod-Snapshots mit Kapazitätsreserven oder schnell startenden Knoten, damit der Pod nach der Planung durch GKE auf einem vorab bereitgestellten oder vorinitialisierten Knoten keine CPU-Drosselung während des Starts erfährt oder direkt aus einem gespeicherten Snapshot wiederhergestellt wird.

Um die Auswirkungen einer einzelnen oder kombinierten Strategie auf Ihre Arbeitslasten zu messen, sehen Sie sich die Diagramme Verteilung der Pod-Startlatenz und Latenz bis zur ersten Bereitschaft des Pods in Cloud Monitoring an und prüfen Sie die Logs zur Planungslatenz in Cloud Logging. Eine Anleitung finden Sie unter Startlatenzmesswerte beobachten.

Nächste Schritte