Kapazitätsreserven

Mit Kapazitätspuffern können Sie die Startlatenz von Pods für Ihre Google Kubernetes Engine-Arbeitslasten (GKE) reduzieren, indem Sie proaktiv Stufen von aktiven oder Standby-Kapazitätspuffern in Ihrem Cluster deklarieren. Wenn Sie im Voraus zusätzliche Kapazität deklarieren, können Sie Arbeitslasten schneller und kostengünstiger starten.

In diesem Dokument wird die Funktionsweise von Kapazitätspuffern erläutert. Informationen zum Aktivieren und Verwenden von Kapazitätsreserven finden Sie unter Kapazitätsreserven konfigurieren.

Wann sollten Kapazitätspuffer verwendet werden?

Verwenden Sie Kapazitätspuffer für Anwendungen, die auf die Startlatenz reagieren und schnell skaliert werden müssen. Bei plötzlichen Traffic-Spitzen bietet ein aktiver Puffer vorab bereitgestellte Kapazität, die für die Skalierung mit niedriger Latenz konzipiert ist. Wenn Sie einen anhaltenden Anstieg des Traffics feststellen, bietet ein Standby-Puffer eine kostengünstigere Möglichkeit für die Pod-Planung als die Vorab-Bereitstellung.

Kapazitätspuffer bieten folgende Vorteile:

  • Skalierungslatenz minimieren: Aktive Puffer stellen laufende Knoten bereit, was zur Minimierung der Latenz beiträgt. Standby-Puffer werden schnell reaktiviert und bieten eine schnellere Kapazitätsverfügbarkeit als neue Knoten. Außerdem sind sie kostengünstiger als aktive Puffer.
  • Kosteneffiziente Überdimensionierung: Mit Kapazitätspuffern können Sie ein Sicherheitsnetz aufrechterhalten. Bei umfangreichen Arbeitslasten ist dieser Ansatz oft kosteneffizienter als andere Methoden zur Überdimensionierung, z. B. das Senken der Auslastungsziele für horizontales Pod-Autoscaling (Horizontal Pod Autoscaler, HPA), wodurch die Leerlaufkapazität mit dem Wachstum Ihres Clusters linear ansteigen kann.
  • Anforderungen an die Arbeitslast erfüllen:Sie haben die volle Kontrolle über die Konfiguration Ihres Kapazitätsbuffers. Sie können beispielsweise benutzerdefinierte Daemonsets einbinden, um Bilder vorzuladen, die Startzeit zu optimieren und Puffergrößen nach Bedarf anzupassen.

Wir empfehlen Kapazitätsreserven für latenzempfindliche Arbeitslasten, die eine schnelle Aufskalierung erfordern, z. B. KI-Agents, KI-Inferenz, Einzelhandelsanwendungen während Verkaufsaktionen oder Gameserver während Spitzenzeiten.

Funktionsweise von Kapazitätsreserven

Implementieren Sie einen Kapazitätspuffer, indem Sie eine benutzerdefinierte Kubernetes-Ressource vom Typ „CapacityBuffer“ verwenden, um einen Puffer mit freier Kapazität zu definieren. Der GKE-Cluster-Autoscaler überwacht CapacityBuffer-Ressourcen und behandelt sie als ausstehende Nachfrage, um sicherzustellen, dass freie Kapazität verfügbar ist. Wenn Ihr Cluster nicht genügend Kapazität hat, um die im Puffer definierten Ressourcenanforderungen zu erfüllen, stellt der Cluster-Autoscaler zusätzliche Knoten bereit.

Wenn eine Arbeitslast mit hoher Priorität skaliert wird, plant GKE die Arbeitslast sofort für die verfügbare Kapazität im Puffer. Diese sofortige Planung gilt für die Anzahl der Replikate oder die im Puffer reservierte Ressourcenmenge. So wird die typische Verzögerung bei der Knotenbereitstellung vermieden. Wenn für eine Arbeitslast eine Puffereinheit verwendet wird, stellt Cluster Autoscaler einen neuen Knoten bereit, um den Puffer wieder aufzufüllen.

Strategien für Kapazitätsreserven

Sie können Kapazitätspuffer mit verschiedenen Bereitstellungsstrategien konfigurieren, die auf Ihren Anforderungen an Latenz und Kosten basieren.

Aktiver Puffer

Ein aktiver Puffer stellt laufende Knoten für die Skalierung von Arbeitslasten mit niedriger Latenz bereit, die in die reservierte Kapazität passen. Da die Knoten bereits ausgeführt werden, bieten sie eine minimale Latenz für die Inanspruchnahme von Pods während eines Scale-up-Ereignisses.

Stand‑by-Puffer

Ein Standby-Puffer stellt angehaltene Knoten bereit. Die Standby-Strategie ist kostengünstiger als die aktive Strategie, führt aber zu einer kurzen Verzögerung beim Fortsetzen des Knotens, bevor er Arbeitslasten akzeptiert.

Kosten und Preise

Die Abrechnung von Kapazitätsreserven hängt vom Reservetyp ab:

  • Aktive Puffer: Für die laufenden VMs, die von GKE als aktive Pufferkapazität verwaltet werden, werden die standardmäßigen GKE-Compute-Preise berechnet. In Autopilot gelten für die ausgeführten Pods die Standardabrechnungspreise für Pods.
  • Standby-Puffer: Während VM-Instanzen angehalten werden, fallen keine Rechenkosten (CPU oder Arbeitsspeicher) an. Es fallen geringe Speichergebühren an (z. B. für VM-Bootlaufwerke) sowie Kosten für zugehörige Ressourcen wie statische externe IP-Adressen. Wenn GKE die Standby-VMs reaktiviert, um Arbeitslasten zu hosten, gelten die Abrechnungstarife für Standard-Compute oder Pods.

CapacityBuffer CRD

Zum Konfigurieren eines Kapazitätspuffers erstellen Sie eine CapacityBuffer CustomResourceDefinition (CRD). Sie können den Kapazitätspuffer so konfigurieren, dass er unterschiedliche Kriterien erfüllt:

  • Feste Replikate: Geben Sie eine feste Anzahl von Puffer-Pods an, die auf Grundlage der Ressourcenanforderungen einer referenzierten Pod-Vorlage erstellt werden sollen. Diese Konfiguration ist die einfachste Möglichkeit, einen Puffer mit einer bekannten Größe zu erstellen.
  • Ressourcenlimits: Geben Sie die Gesamtmenge an CPU und Arbeitsspeicher an, die der Puffer reservieren soll. Der Controller berechnet, wie viele Puffer-Pods auf Grundlage der Ressourcenanforderungen einer referenzierten Pod-Vorlage erstellt werden sollen.
  • Prozentual: Die Puffergröße wird als Prozentsatz eines vorhandenen skalierbaren Objekts definiert, das eine Scale-Unterressource definiert (z. B. ein Deployment, StatefulSet, ReplicaSet oder Job). Die Puffergröße wird dynamisch angepasst, wenn die Referenzarbeitslast skaliert wird. Prozentuale Kapazitätsreserven werden nur für Objekte unterstützt, die die Kubernetes-Unterressource „scale“ implementieren.

Weitere Informationen finden Sie in der Referenzdokumentation zur CapacityBuffer CRD.

Best Practices

Wenn Sie Kapazitätsreserven konfigurieren, um die Kosteneffizienz und Reaktionsfähigkeit zu optimieren, sollten Sie die folgenden Empfehlungen beachten:

  • Kostenoptimale, Standby-First-Strategie verwenden: Standby-Puffer priorisieren, wenn Ihre Arbeitslasten eine kurze Hochskalierungsverzögerung von etwa 30 Sekunden tolerieren können. Mit dieser Strategie werden Kaltstarts neuer VMs vermieden, ohne dass die vollen Kosten für aktive VMs anfallen.
  • Aktive Puffer für latenzempfindliche Arbeitslasten verwenden: Verwenden Sie aktive Puffer für Arbeitslasten, bei denen die Wiederaufnahmezeiten von Knoten nicht toleriert werden können und die Pod-Planungszeit so kurz wie möglich sein muss.
  • Hybridstrategie verwenden, um Leistung und Kosten in Einklang zu bringen: Kombinieren Sie einen kleinen aktiven Puffer mit einem größeren Standby-Puffer, um eine kostengünstige Einrichtung zu erzielen. GKE priorisiert das Auffüllen des aktiven Puffers, indem Knoten aus dem Standby-Puffer reaktiviert werden (was etwa 30 Sekunden dauert). Gleichzeitig werden im Hintergrund neue Knoten bereitgestellt, um den Standby-Puffer wieder aufzufüllen. Bei dieser Einrichtung werden anfängliche Spitzen mit aktiver Kapazität abgefedert und nachhaltiges Wachstum wird mit der kostengünstigeren Standby-Kapazität abgedeckt.
  • Aktive Puffer für anfängliche Spitzenwerte dimensionieren: Legen Sie die Größe Ihres aktiven Puffers fest, um die anfänglichen plötzlichen Replikaspitzen abzudecken, die Sie erwarten, bevor die Standby-Pufferknoten fortgesetzt werden können.
  • Standby-Puffer für anhaltende Last dimensionieren: Definieren Sie Standby-Puffer, die ausreichen, um die erwartete erweiterte Last abzudecken, damit die Puffer nach einem Kaltstart im Hintergrund wieder aufgefüllt werden können. Mit einem ausreichend großen Standby-Puffer kann die maximale Pod-Planungslatenz auf die Zeit reduziert werden, die zum Fortsetzen eines Knotens benötigt wird, was etwa 30 Sekunden dauert. Wenn der Kapazitätspuffer verwendet und wieder aufgefüllt wird, wechseln neue Puffernodes in einen aktiven Zustand, bevor sie angehalten werden. Diese Strategie trägt dazu bei, die aktive Kapazität bei längerer Belastung zu steigern.
  • Puffer-Simulator verwenden: Experimentieren Sie mit verschiedenen aktiven und Standby-Puffergrößen, um das beste Ergebnis für Ihre spezifische Arbeitslast zu erzielen. Mit dem Open-Source-Simulator für GKE-Puffer unter https://github.com/gke-labs/buffers-simulator können Sie Simulationen des Skalierungsverhaltens von Arbeitslasten ausführen, um die Regeln für die Puffergröße zu optimieren und Ihre Leistungsziele zu erreichen.
  • Kaltstartlatenz beim Skalieren von Arbeitslasten von null reduzieren: Kombinieren Sie Arbeitslasten, die mit HPA auf null und von null skaliert werden (minReplicas: 0), mit Kapazitätspuffern. Wenn die Nachfrage steigt und die Arbeitslast von null skaliert wird, plant GKE Pods sofort auf vorgewärmten Pufferknoten, anstatt auf die Bereitstellung neuer Rechenknoten zu warten.

Anforderungen und Einschränkungen

Für Kapazitätsreserven gelten die folgenden Anforderungen und Einschränkungen:

  • Kapazitätsreserven sind für GKE-Cluster mit Version 1.35.2-gke.1842000 oder höher für aktive Reserven und Version 1.36.0-gke.2253000 für Standby-Reserven verfügbar.
  • Kapazitätsreserven unterstützen nur Arbeitslasten, die ein knotenbasiertes Abrechnungsmodell für Standard-Knotenpools und Autopilot-Knotenpools mit ausgewählter Hardware verwenden. Kapazitätsreserven werden nicht für Arbeitslasten unterstützt, die das Pod-basierte Abrechnungsmodell verwenden.
  • In Standardclustern empfehlen wir, die automatische Knotenbereitstellung zu aktivieren. Mit der automatischen Knotenbereitstellung kann der Cluster Autoscaler neue Knotenpools basierend auf den Ressourcenanforderungen in Ihrem CapacityBuffer erstellen. Wenn Sie die automatische Knotenbereitstellung nicht aktivieren, skaliert Cluster Autoscaler nur vorhandene Knotenpools.
  • Sowohl aktive als auch Standby-Kapazitätsreserven werden auf Compute Engine-Kontingente angerechnet.
  • Wenn in Ihrer CapacityBuffer-Konfigurationsabhängigkeit (z. B. ein PodTemplate) eine benutzerdefinierte ComputeClass ausgewählt wird, müssen in der Abhängigkeit alle Toleranzen, Knotenauswahlen oder Laufzeitklassen definiert werden, die für die Planung auf den bereitgestellten Knoten erforderlich sind (z. B. Anforderungen für GKE Sandbox). Eine Anleitung finden Sie in der Dokumentation zu benutzerdefinierten Compute-Klassen.

Für Standby-Puffer gelten die folgenden zusätzlichen Einschränkungen:

  • Sie werden in Standardclustern mit aktivierter automatischer Knotenbereitstellung unterstützt.
  • Sie werden auf Autopilot-Clustern mit Version 1.36.0-gke.2853000 oder höher unterstützt.
  • Knoten mit angehängten GPUs oder TPUs werden nicht unterstützt.
  • Lokale SSDs werden nicht unterstützt.
  • Confidential Google Kubernetes Engine-Knoten werden nicht unterstützt.
  • Sie sollten mit den Einschränkungen im Zusammenhang mit Compute Engine-Vorgängen zum Anhalten und Fortsetzen vertraut sein. Hier einige wichtige Einschränkungen:
    • Knoten mit durch vom Kunden bereitgestellte Verschlüsselungsschlüssel (Customer-Supplied Encryption Keys, CSEK) geschützten Laufwerken werden nicht unterstützt.
    • Knoten mit mehr als 208 GB Arbeitsspeicher werden nicht unterstützt.
    • Bare-Metal-Instanzen werden nicht unterstützt.
    • Das Betriebssystem des Knotens muss ACPI S3-Ruhezustandssignale unterstützen.
    • Die Dauer des Sperrvorgangs ist proportional zur Größe des Arbeitsspeichers.
    • Die Wiederaufnahme hängt von der Verfügbarkeit der zugrunde liegenden Ressourcen ab, die für die Wiederaufnahme erforderlich sind.

Nächste Schritte