Kapazitätsreserven

Mit Kapazitätspuffern können Sie die Pod-Startlatenz 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 die Reservekapazität im Voraus 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ätspuffern finden Sie unter Kapazitätspuffer konfigurieren.

Wann sollten Kapazitätspuffer verwendet werden?

Verwenden Sie Kapazitätspuffer für Anwendungen, die empfindlich auf Startlatenz reagieren und schnell skaliert werden müssen. Wenn der Traffic plötzlich ansteigt, bietet ein aktiver Puffer vorab bereitgestellte Kapazität, die für eine Skalierung mit niedriger Latenz ausgelegt ist. Wenn Sie einen anhaltenden Anstieg des Traffics feststellen, bietet ein Standby-Zwischenspeicher die Pod-Planung zu geringeren Kosten als die Vorabbereitstellung.

Kapazitätspuffer bieten folgende Vorteile:

  • Skalierungslatenz minimieren: Aktive Puffer stellen laufende Knoten bereit, was die Latenz minimiert. Standby-Puffer werden schnell wieder aufgenommen und bieten eine schnellere Kapazitätsverfügbarkeit als neue Knoten zu geringeren Kosten im Vergleich zu aktiven Puffern.
  • Kostengünstige Überdimensionierung: Kapazitätspuffer dienen als Sicherheitsnetz. Bei umfangreichen Arbeitslasten ist dieser Ansatz oft kostengünstiger als andere Überdimensionierungsmethoden, z. B. das Senken der Auslastungsziele für horizontales Pod-Autoscaling (HPA), was die ungenutzte Kapazität linear mit dem Wachstum Ihres Clusters erhöhen kann.
  • Anforderungen an Arbeitslasten erfüllen: Sie haben die volle Kontrolle über die Konfiguration Ihres Kapazitätspuffers. Sie können benutzerdefinierte DaemonSets einbinden, um Images vorab zu laden, die Startzeit zu optimieren und die Puffergrößen an Ihre Anforderungen anzupassen.

Wir empfehlen Kapazitätspuffer für latenzempfindliche Arbeitslasten, die eine schnelle Hochskalierung erfordern, z. B. KI-Agenten, KI-Inferenz, Einzelhandelsanwendungen während Verkaufsaktionen oder Gameserver während Spitzenzeiten der Spieleraktivität.

Funktionsweise von Kapazitätspuffern

Implementieren Sie einen Kapazitätspuffer, indem Sie mit der benutzerdefinierten Kubernetes-Ressource „CapacityBuffer“ einen Puffer für freie Kapazität 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 Ressourcenanfragen zu erfüllen, stellt der Cluster-Autoscaler zusätzliche Knoten bereit.

Wenn eine Arbeitslast hochskaliert wird, plant GKE ausstehende Pods mit verfügbarer Kapazität in der folgenden Prioritätsreihenfolge:

  1. Knoten in einem aktiven Puffer ausführen
  2. Ausgeführte Knoten in einem Stand-by-Puffer, die noch nicht gesperrt wurden
  3. Gesperrte Knoten in einem Stand-by-Puffer
  4. Neu bereitgestellte Knoten

Damit ausstehende Pods so schnell wie möglich geplant werden, verwendet GKE die verfügbare Pufferkapazität, bevor neue Knoten bereitgestellt werden. Diese Priorität gilt auch dann, wenn eine Regel mit höherer Priorität in einer benutzerdefinierten ComputeClass sonst einen neuen Knoten bereitstellen würde.

Die Zwischenspeicherkapazität ist nicht auf die im Feld scalableRef angegebene Arbeitslast beschränkt. Jeder ausstehende Pod, dessen Planungseinschränkungen wie Knotenauswahlen, Toleranzen und Ressourcenanfragen mit der Konfiguration des Pufferknotens übereinstimmen, kann diese Kapazität beanspruchen. Wenn Sie einen Kapazitätspuffer für eine bestimmte Arbeitslast reservieren möchten, konfigurieren Sie die Arbeitslasttrennung, indem Sie sowohl der Arbeitslast als auch dem Kapazitätspuffer entsprechende Toleranzen und Knotenauswahlen (oder Knotenaffinitäten) hinzufügen.

Wenn eine Arbeitslast Kapazität aus einem aktiven Puffer verbraucht, füllt der Cluster Autoscaler den aktiven Puffer auf, indem er einen Knoten aus einem kompatiblen Standby-Puffer fortsetzt, falls vorhanden, oder einen neuen Knoten bereitstellt. Wenn eine Arbeitslast oder ein aktiver Zwischenspeicher einen Knoten aus einem Standby-Zwischenspeicher verbraucht, füllt Cluster Autoscaler den Standby-Zwischenspeicher auf, indem ein neuer Knoten bereitgestellt und gesperrt wird. Wenn Ihre Arbeitslast wieder herunterskaliert wird und Knoten nicht mehr ausgelastet sind, löscht der Cluster-Autoscaler die überschüssigen laufenden Knoten nach dem Stabilisierungsfenster für das Herunterskalieren, anstatt sie wieder in den Stand-by-Zwischenspeicher zu verschieben. Um den Stand-by-Puffer aufzufüllen, stellt GKE neue Knoten separat bereit und sperrt sie.

Strategien für Kapazitätspuffer

Sie können Kapazitätspuffer mit verschiedenen Bereitstellungsstrategien konfigurieren, je nach Ihren Anforderungen an Latenz und Kosten.

Aktiver Puffer

Ein aktiver Zwischenspeicher stellt laufende Knoten für die latenzarme Skalierung von Arbeitslasten bereit, die in die reservierte Kapazität passen. Da die Knoten bereits ausgeführt werden, ist die Latenz beim Anfordern von Pods während eines Hochskalierungsereignisses minimal.

Stand-by-Puffer

Ein Stand-by-Zwischenspeicher stellt gesperrte Knoten bereit. Die Standby-Strategie ist kostengünstiger als die aktive Strategie, führt aber zu einer kurzen Verzögerung, bis der Knoten wieder Workloads akzeptiert.

Kosten und Preise

Kapazitätspuffer werden ohne zusätzliche Kosten zusätzlich zu Ihren standardmäßigen knotenbasierten Computing-Kosten bereitgestellt, die für Standardknotenpools und Autopilot-Arbeitslasten gelten, die bestimmte Hardware auswählen. Kapazitätspuffer unterstützen das Pod-basierte Abrechnungsmodell nicht.

Die Abrechnung für die zugrunde liegenden Knoten hängt vom Puffertyp ab:

  • Aktive Puffer: Ihnen werden die standardmäßigen knotenbasierten Computing-Preise für die laufenden VMs berechnet, die von der GKE als aktive Pufferkapazität verwaltet werden.
  • Standby-Puffer: Während VM-Instanzen gesperrt sind, fallen keine Rechenkosten (CPU oder Arbeitsspeicher) an. Es fallen geringe Speichergebühren (z. B. für VM-Bootlaufwerke und gespeicherte Arbeitsspeicherzustände) und Kosten für zugehörige Ressourcen wie statische externe IP-Adressen an. Wenn GKE die Standby-VMs zum Hosten von Arbeitslasten fortsetzt, gelten die standardmäßigen knotenbasierten Computing-Preise. Weitere Informationen finden Sie unter Preise für gesperrte Instanzen.

CapacityBuffer-CRD

Wenn Sie einen Kapazitätspuffer konfigurieren möchten, erstellen Sie eine CapacityBuffer-CustomResourceDefinition (CRD). Sie können den Kapazitätspuffer so konfigurieren, dass er verschiedene Kriterien erfüllt:

  • Feste Replikate: Geben Sie eine feste Anzahl von Puffer-Pods an, die basierend auf den Ressourcenanfragen einer referenzierten Pod-Vorlage erstellt werden sollen. Diese Konfiguration ist die einfachste Möglichkeit, einen Zwischenspeicher 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 anhand der Ressourcenanfragen einer referenzierten Pod-Vorlage, wie viele Puffer-Pods erstellt werden sollen.
  • Prozentbasiert: Die Puffergröße wird als Prozentsatz eines vorhandenen skalierbaren Objekts definiert, das eine Skalierungsunterressource definiert (z. B. ein Deployment, StatefulSet, ReplicaSet oder Job). Die Puffergröße wird dynamisch angepasst, wenn die Referenzarbeitslast skaliert wird. Prozentbasierte Kapazitätspuffer werden nur für Objekte unterstützt, die die Kubernetes-Skalierungsunterressource implementieren.

Sie können diese Optionen kombinieren, indem Sie beispielsweise sowohl replicas als auch percentage festlegen, sodass GKE den größeren Wert als Mindestwert verwendet, und limits als Obergrenze festlegen.

Weitere Informationen finden Sie in der Referenzdokumentation zur CapacityBuffer-CRD.

Best Practices

Beachten Sie die folgenden Empfehlungen, um die Kosteneffizienz und Reaktionsfähigkeit beim Konfigurieren von Kapazitätspuffern zu optimieren:

  • Kostenoptimierte Standby-First-Strategie verwenden: Priorisieren Sie Standby-Puffer, wenn Ihre Arbeitslasten eine kurze Verzögerung beim Hochskalieren 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 Zwischenspeicher für latenzempfindliche Arbeitslasten verwenden: Verwenden Sie aktive Zwischenspeicher für Arbeitslasten, die keine Wiederaufnahmezeiten für Knoten tolerieren, wenn die Pod-Planungszeit so gering 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 fortgesetzt werden (dauert etwa 30 Sekunden), während im Hintergrund neue Knoten bereitgestellt werden, um den Standby-Puffer aufzufüllen. Bei dieser Einrichtung werden anfängliche Spitzen mit aktiver Kapazität abgefangen und anhaltendes Wachstum wird mit der kostengünstigeren Standby-Kapazität bewältigt.
  • Größe der aktiven Puffer für anfängliche Bursts festlegen: Definieren Sie die Größe des aktiven Puffers, um die anfänglichen plötzlichen Replikatspitzen abzudecken, die Sie erwarten, bevor 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 im Hintergrund von einem Kaltstart aus wieder aufgefüllt werden können. Ein ausreichend großer Stand-by-Puffer kann die maximale Pod-Planungslatenz auf die Zeit reduzieren, die zum Fortsetzen eines Knotens erforderlich ist, also etwa 30 Sekunden. Wenn der Kapazitätspuffer verwendet und wieder aufgefüllt wird, wechseln neue Pufferknoten in einen aktiven Zustand, bevor sie gesperrt werden. Diese Strategie hilft, die aktive Kapazität bei einer längeren Last zu erhöhen.
  • Puffersimulator verwenden: Experimentieren Sie mit verschiedenen aktiven und Stand-by-Puffergrößen, um das beste Ergebnis für Ihre spezifische Arbeitslast zu erzielen. Führen Sie Simulationen des Skalierungsverhaltens von Arbeitslasten mit dem Open-Source-GKE-Puffersimulator unter https://github.com/gke-labs/buffers-simulator aus, um Ihre Regeln für die Puffergröße zu optimieren und Ihre Leistungsziele zu erreichen.
  • Latenz bei Kaltstarts reduzieren, wenn Arbeitslasten von null skaliert werden: Kombinieren Sie Arbeitslasten, die mit HPA auf und von null skaliert werden (minReplicas: 0), mit Kapazitätspuffern. Wenn die Nachfrage steigt und die Arbeitslast von null hochskaliert wird, plant GKE sofort Pods auf vorgewärmten Pufferknoten, anstatt auf die Bereitstellung neuer Compute-Knoten zu warten.
  • Berücksichtigen Sie das Autoscaling-Profil optimize-utilization für Standardcluster: Da Kapazitätspuffer bereits Reservekapazität vorhalten, können Sie das Autoscaling-Profil optimize-utilization (--autoscaling-profile=optimize-utilization) so konfigurieren, dass Cluster Autoscaler nicht ausgelastete Knoten nach einem Nachfragerückgang schneller herunterskaliert. Bei diesem Profil werden Pods auch dichter auf Knoten gepackt. Prüfen Sie daher, ob ein dichteres Bin-Packing den Verfügbarkeitsanforderungen Ihrer Arbeitslast entspricht, bevor Sie es aktivieren.

Puffergröße berechnen

Wenn Sie einen aktiven Puffer mit einem Standby-Puffer kombinieren, können Sie die Anzahl der Pufferreplikate oder simulierten Puffer-Pods schätzen, die erforderlich sind, um eine Traffic-Spitze abzufangen. Berechnen Sie diese Schätzung anhand der erwarteten Hochskalierungsrate in Pods pro Sekunde, der Latenz für die Wiederaufnahme von Standby-Knoten und der Latenz für die Erstellung von Kaltknoten. Diese Latenzen variieren je nach VM-Maschinenserie und Knotenkonfiguration. Die Latenz für die Wiederaufnahme von Standby-Knoten beträgt beispielsweise in der Regel 30 bis 35 Sekunden und die Latenz für die Erstellung neuer Knoten in der Regel 60 bis 120 Sekunden, je nach Maschinenserie. Informationen zum Messen der tatsächlichen Latenzen für Ihren Cluster finden Sie unter Messwerte zur Startlatenz überwachen.

  1. Berechnen Sie die Größe des aktiven Puffers, um die Pods abzudecken, die erstellt werden, während Standby-Knoten fortgesetzt werden:

    \[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]

  2. Berechnen Sie die Größe des Stand-by-Puffers, um die verbleibenden Pods abzudecken, die erstellt werden, während die Bereitstellung neuer kalter Knoten abgeschlossen wird:

    \[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]

Wenn Ihre Arbeitslast beispielsweise mit 2 Pods pro Sekunde skaliert wird, dauert es 30 Sekunden, bis Standby-Knoten wieder aufgenommen werden, und 90 Sekunden, bis neue kalte Knoten bereitgestellt werden:

  • Ihr aktiver Puffer benötigt \( 2 \times 30 = 60 \)  Replikate, um die ersten 30 Sekunden der Lastspitze abzufangen.
  • Ihr Stand-by-Puffer benötigt \( (2 \times 90) - 60 = 120 \) Replikate, um die verbleibenden 60 Sekunden abzudecken, während der Cluster-Autoscaler im Hintergrund neue kalte Knoten bereitstellt, um Ihre Puffer aufzufüllen. Wenn die Spitze länger als 90 Sekunden mit derselben Rate anhält, sind diese wiederhergestellten Knoten bereit, eingehende Pods ohne Wartezeit zu verarbeiten.

Wenn Sie diese Schätzungen mit den Skalierungsmustern Ihrer Arbeitslasten vergleichen möchten, führen Sie Simulationen mit dem GKE-Puffersimulator aus.

Anforderungen und Einschränkungen

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

  • Kapazitätspuffer sind für GKE-Cluster mit Version 1.35.2-gke.1842000 oder höher für aktive Puffer und Version 1.36.0-gke.2253000 für Standby-Puffer verfügbar.
  • Kapazitätspuffer unterstützen nur Arbeitslasten, die ein knotenbasiertes Abrechnungsmodell für Standard-Knotenpools und Autopilot-Knotenpools, die bestimmte Hardware auswählen, verwenden. Kapazitätspuffer unterstützen keine Arbeitslasten, die das Pod-basierte Abrechnungsmodell verwenden.
  • Bei Standardclustern empfehlen wir, die automatische Erstellung von Knotenpools zu aktivieren. Mit der automatischen Erstellung von Knotenpools kann Cluster Autoscaler neue Knotenpools basierend auf den Ressourcenanfragen in Ihrem CapacityBuffer erstellen. Wenn Sie die automatische Erstellung von Knotenpools nicht aktivieren, skaliert Cluster Autoscaler nur vorhandene Knotenpools hoch.
  • Aktive und Stand-by-Kapazitätspuffer verbrauchen Kontingente unterschiedlich:
    • Knoten, die in einem aktiven Puffer ausgeführt werden, werden auf Ihre Compute Engine-Kontingente für vCPUs, Arbeitsspeicher, Laufwerke und IP-Adressen angerechnet.
    • Gesperrte Knoten in einem Stand-by-Puffer werden während der Sperrung nicht auf die vCPU- oder Arbeitsspeicherkontingente von Compute Engine angerechnet. Sie verbrauchen jedoch weiterhin IP-Adresskontingente und Laufwerkskontingente, einschließlich des Persistent disk standard (GB)-Kontingents, das zum Speichern des Arbeitsspeichers der gesperrten VM verwendet wird.
    • In Kubernetes werden sowohl aktive als auch gesperrte Stand-by-Puffereinheiten auf die Kubernetes-Ressourcenkontingente in Ihrem Namespace angerechnet, als ob die Puffer-Pods ausgeführt würden.
  • Wenn die Abhängigkeit Ihrer CapacityBuffer-Konfiguration (z. B. ein PodTemplate) eine benutzerdefinierte ComputeClass auswählt, muss die Abhängigkeit alle Toleranzen, Knotenauswahlen oder Laufzeitklassen definieren, 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 ComputeClasses.

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

  • Sie werden in Standardclustern mit aktivierter automatischer Erstellung von Knotenpools 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.
  • Stand-by-Puffer unterstützen zwar kundenverwaltete Verschlüsselungsschlüssel (CMEK) für den Speicher des Knotens, der Arbeitsspeicher des Knotens wird jedoch während der Sperrung mit Google-owned and Google-managed encryption keys verschlüsselt.
  • Confidential Google Kubernetes Engine-Knoten werden nicht unterstützt.
  • Stand-by-Puffer unterstützen nur Container-Optimized OS- und Ubuntu-Knoten-Images von GKE. Windows Server-Knoten werden nicht unterstützt. Wenn Sie ein benutzerdefiniertes Knotenbetriebssystem verwenden, müssen Sie darauf achten, dass das Betriebssystem Vorgänge zum Sperren und Fortsetzen von Compute Engine unterstützt.
  • Sie sollten mit den Einschränkungen im Zusammenhang mit dem Anhalten und Fortsetzen von Compute Engine-Vorgängen vertraut sein. Zu den wichtigsten Einschränkungen gehören:
    • Knoten mit Laufwerken, die durch vom Kunden bereitgestellte Verschlüsselungsschlüssel (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 Knotenbetriebssystem muss ACPI-S3-Ruhezustandssignale unterstützen.
    • Die Dauer des Sperrvorgangs ist proportional zur Speichergröße.

Nächste Schritte