Kapazitätsreserven

Mit Kapazitätsreserven 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ätsreserven 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ätsreserven beschrieben. 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 entwickelt wurde. Wenn Sie einen anhaltenden Anstieg des Traffics feststellen, bietet ein Standby-Puffer die Pod-Planung zu einem günstigeren Preis 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 Überbereitstellung: Mit Kapazitätspuffern können Sie ein Sicherheitsnetz aufrechterhalten. Bei umfangreichen Arbeitslasten ist dieser Ansatz oft kosteneffizienter als andere Methoden zur Überbereitstellung, z. B. das Senken der Zielauslastung des horizontalen Pod-Autoscalers (HPA), wodurch die Leerlaufkapazität mit dem Wachstum Ihres Clusters linear ansteigen kann.
  • Arbeitslastanforderungen erfüllen:Sie haben die volle Kontrolle über die Konfiguration Ihres Kapazitätsbuffers. Sie können beispielsweise benutzerdefinierte Daemonsets einbinden, um Images vorab zu laden, die Startzeit zu optimieren und Puffergrößen an Ihre Anforderungen anzupassen.

Wir empfehlen Kapazitätsreserven für latenzempfindliche Arbeitslasten, die eine schnelle Aufskalierung erfordern, z. B. KI-Agents, KI-Inferenz, Einzelhandelsanwendungen bei Verkaufsaktionen oder Gameserver bei Spitzenaktivitäten von Spielern.

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 Ressourcenmenge, die im Puffer reserviert ist. So wird die typische Verzögerung bei der Knotenbereitstellung vermieden. Wenn für eine Arbeitslast eine Puffereinheit verwendet wird, stellt der Cluster Autoscaler einen neuen Knoten bereit, um den Puffer wieder aufzufüllen.

Strategien für Kapazitätsreserven

Sie können Kapazitätsreserven konfigurieren, indem Sie verschiedene Bereitstellungsstrategien verwenden, 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 ausgesetzte 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

Kapazitätsreserven werden zusätzlich zu den standardmäßigen knotenbasierten Compute-Kosten ohne Aufpreis bereitgestellt. Diese Kosten gelten für Standard-Knotenpools und Autopilot-Arbeitslasten, für die bestimmte Hardware ausgewählt wird. Kapazitätsreserven unterstützen das Pod-basierte Abrechnungsmodell nicht.

Die Abrechnung der zugrunde liegenden Knoten hängt vom Puffertyp ab:

  • Aktive Puffer: Für die laufenden VMs, die von GKE als aktive Pufferkapazität verwaltet werden, werden die standardmäßigen knotenbasierten Compute-Raten berechnet.
  • Standby-Puffer: Während VM-Instanzen angehalten werden, fallen keine Compute-Kosten (CPU oder Arbeitsspeicher) an. Es fallen geringe Speichergebühren an (z. B. für VM-Bootlaufwerke und gespeicherten Arbeitsspeicherstatus) sowie Kosten für zugehörige Ressourcen wie statische externe IP-Adressen. Wenn GKE die Standby-VMs reaktiviert, um Arbeitslasten zu hosten, gelten die standardmäßigen knotenbasierten Compute-Preise. Weitere Informationen finden Sie unter Preise für angehaltene Instanzen.

CapacityBuffer CRD

Zum Konfigurieren eines Kapazitätsbuffers 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 für den Puffer reserviert werden 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-Unterrressource „scale“ implementieren.

Weitere Informationen finden Sie in der CRD-Referenzdokumentation für CapacityBuffer.

Best Practices

Wenn Sie Kapazitätspuffer konfigurieren, sollten Sie die folgenden Empfehlungen berücksichtigen, um Kosteneffizienz und Reaktionsfähigkeit zu optimieren:

  • Kostenoptimale Strategie mit Standby-Puffer verwenden: Priorisieren Sie Standby-Puffer, wenn Ihre Arbeitslasten eine kurze Skalierungsverzögerung von etwa 30 Sekunden tolerieren können. Mit dieser Strategie werden Kaltstarts von neuen 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, die keine Knotenwiederaufnahmezeiten tolerieren können, wenn 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 ein kostengünstiges Setup zu erhalten. 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 mit der kostengünstigeren Standby-Kapazität abgedeckt.
  • Größe der aktiven Puffer für anfängliche Spitzen festlegen: 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 sich die Puffer nach einem Kaltstart im Hintergrund wieder füllen 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, also etwa 30 Sekunden. Wenn der Kapazitäts-Puffer verwendet und wieder aufgefüllt wird, wechseln neue Pufferknoten in den aktiven Zustand, bevor sie angehalten werden. Diese Strategie trägt dazu bei, die aktive Kapazität bei einer längeren Last zu erhöhen.
  • 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 das Skalierungsverhalten von Arbeitslasten simulieren, 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ätsreserven. 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 werden nur für Arbeitslasten unterstützt, 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.
  • Bei 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. Zu den wichtigsten Einschränkungen gehören:
    • Knoten mit Laufwerken, die durch vom Kunden bereitgestellte Verschlüsselungsschlüssel (Customer-Supplied Encryption Keys, CSEK) geschützt sind, 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