Kapazitätsreserven

Mit Kapazitätspuffern können Sie die Pod-Startlatenz für Ihre Google Kubernetes Engine (GKE)-Arbeitslasten reduzieren, indem Sie proaktiv Stufen von aktiven oder Standby-Kapazitätspuffern in Ihrem Cluster deklarieren. Wenn Sie 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 Methoden der Überdimensionierung, z. B. die Senkung der Auslastungsziele für das horizontale Pod-Autoscaling (HPA), was die ungenutzte Kapazität mit zunehmender Clustergröße linear 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 Reservekapazitä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 in der folgenden Prioritätsreihenfolge für die verfügbare Kapazität ein:

  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 Pufferkapazität ist nicht auf die Arbeitslast beschränkt, auf die im Feld scalableRef verwiesen wird. Alle ausstehenden Pods, deren Planungseinschränkungen wie Knotenauswahlen, Toleranzen und Ressourcenanfragen mit der Konfiguration des Pufferknotens übereinstimmen, können 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. Eine Anleitung finden Sie unter Kapazitätspuffer einer bestimmten Arbeitslast zuweisen.

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 Stand-by-Zwischenspeicher verbraucht, füllt Cluster Autoscaler den Stand-by-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-Puffer 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, bieten sie eine minimale Latenz für das Anfordern von Pods während eines Hochskalierungsereignisses.

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, bevor der Knoten wieder Arbeitslasten akzeptiert.

Kosten und Preise

Kapazitätspuffer werden ohne zusätzliche Kosten bereitgestellt, zusätzlich zu Ihren standardmäßigen knotenbasierten Computing-Kosten, die für Standard-Knotenpools und Autopilot-Arbeitslasten, die bestimmte Hardware auswählen, gelten. 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

Zum Konfigurieren eines Kapazitätspuffers 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 Skalierungs-Unterressource von Kubernetes 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 Puffer für latenzempfindliche Arbeitslasten verwenden: Verwenden Sie aktive Puffer für Arbeitslasten, die keine Wiederaufnahmezeiten von 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). Im Hintergrund werden neue Knoten bereitgestellt, 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 Spitzen festlegen: Definieren Sie die Größe des aktiven Puffers, um die anfänglichen plötzlichen Spitzen bei Replikaten abzudecken, die Sie erwarten, bevor Stand-by-Pufferknoten fortgesetzt werden können.
  • Standby-Puffer für anhaltende Last dimensionieren: Definieren Sie Standby-Puffer, die ausreichen, um die erwartete zusätzliche Last abzudecken, damit die Puffer im Hintergrund nach einem Kaltstart 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 beim Kaltstart reduzieren, wenn Arbeitslasten von null skaliert werden: Kombinieren Sie Arbeitslasten, die mit HPA von und auf null skaliert werden (minReplicas: 0), mit Kapazitätspuffern. Wenn die Nachfrage steigt und die Arbeitslast von null hochskaliert wird, plant GKE Pods sofort 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 Rückgang der Nachfrage 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 Trafficspitze 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 Stand-by-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 hochskaliert wird, dauert es 30 Sekunden, bis Standby-Knoten fortgesetzt 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 Spitze 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.

Skalierbarkeit

Für Kapazitätspuffer gibt es keine harten Limits. Wenn Sie jedoch die empfohlene Skalierung überschreiten, kann dies die Knotenbereitstellung und die Pod-Planung verlangsamen. Pufferreplikate sind die simulierten Puffer-Pods, für die ein Puffer Kapazität reserviert, nicht Knoten. Damit die Leistung zuverlässig ist, sollten Sie Ihren Cluster innerhalb der folgenden Richtlinien halten:

Empfohlene Kapazitätspuffergröße pro Cluster
Zwischenspeichertyp Pufferreplikate insgesamt pro Cluster Puffer pro Cluster
Aktive Puffer Bis zu 7.000 Bis zu 100
Stand-by-Puffer Bis zu 5.000 Bis zu 25

Vermeiden Sie es, sowohl für aktive als auch für Standby-Puffer viele Puffer zu erstellen, die jeweils einen separaten Knotenpool erfordern, z. B. Puffer, die unterschiedliche ComputeClasses oder unterschiedliche Einstellungen für die Arbeitslasttrennung verwenden. Wenn Cluster Autoscaler neue Knoten bereitstellt, wird jeweils ein Knotenpool skaliert. Es dauert also länger, Puffer mit neuen Knoten zu füllen und wieder aufzufüllen, wenn Sie weitere Puffer hinzufügen. Diese Einschränkung gilt nicht für das Fortsetzen gesperrter Knoten in Stand-by-Zwischenspeichern.

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.37.1-gke.3020000 oder höher 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, so als würden die Puffer-Pods ausgeführt.
  • 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 in Autopilot-Clustern mit benutzerdefinierten ComputeClasses 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 die Compute Engine-Vorgänge zum Sperren und Fortsetzen 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