Kapazitätsreserven

Mit Kapazitätspuffern können Sie die Startlatenz von Pods für Ihre Google Kubernetes Engine-Arbeitslasten (GKE) reduzieren, indem Sie proaktiv Ebenen von aktiven oder Stand-by-Kapazitätspuffern in Ihrem Cluster deklarieren. Wenn Sie im Voraus Ersatzkapazitä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ä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. Bei plötzlichen Traffic-Spitzen bietet ein aktiver Puffer vorab bereitgestellte Kapazität, die für eine Skalierung mit niedriger Latenz entwickelt wurde. Bei einem anhaltenden Anstieg des Traffics bietet ein Stand-by-Puffer die Pod-Planung zu einem günstigeren Preis als die Vorabbereitstellung.

Kapazitätspuffer bieten folgende Vorteile:

  • Skalierungslatenz minimieren: Aktive Puffer bieten laufende Knoten, die die Latenz minimieren. Stand-by-Puffer werden schnell wieder aufgenommen und bieten eine schnellere Kapazitätsverfügbarkeit als neue Knoten zu geringeren Kosten als aktive Puffer.
  • Kostengünstige Überbereitstellung: Kapazitätspuffer bieten ein Sicherheitsnetz. Bei großen Arbeitslasten ist dieser Ansatz oft kostengünstiger als andere Methoden zur Überbereitstellung (z. B. das Senken der Auslastungsziele von HorizontalPodAutoscaler (HPA)), wodurch die Leerlaufkapazität mit dem Wachstum des Clusters linear ansteigen kann.
  • Arbeitslastanforderungen erfüllen:Sie haben die vollständige Kontrolle über die Konfiguration Ihres Kapazitätspuffers. Sie können beispielsweise benutzerdefinierte DaemonSets einbinden, um Bilder 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 Aufskalierung erfordern, z. B. KI-Agents, KI-Inferenz, Einzelhandelsanwendungen bei Verkaufsveranstaltungen oder Spielserver bei hoher Spieleraktivität.

Funktionsweise von Kapazitätspuffern

Implementieren Sie einen Kapazitätspuffer mit einer benutzerdefinierten Kubernetes-Ressource CapacityBuffer, um einen Puffer mit Ersatzkapazität zu definieren. Der GKE-Cluster-Autoscaler überwacht CapacityBuffer-Ressourcen und behandelt sie als ausstehende Nachfrage, um sicherzustellen, dass Ersatzkapazitä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 mit hoher Priorität skaliert wird, plant GKE die Arbeitslast sofort auf der verfügbaren Kapazität im Puffer. Diese sofortige Planung gilt für die Anzahl der Replikate oder die Ressourcenmenge, die im Puffer reserviert ist, wodurch die typische Verzögerung bei der Knotenbereitstellung vermieden wird. Wenn eine Arbeitslast eine Puffereinheit verwendet, stellt der Cluster-Autoscaler einen neuen Knoten bereit, um den Puffer wieder aufzufüllen.

Strategien für Kapazitätspuffer

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

Aktiver Puffer

Ein aktiver Puffer bietet laufende Knoten für die Skalierung von Arbeitslasten mit niedriger Latenz, 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 bei einer Aufskalierung.

Stand-by-Puffer

Ein Stand-by-Puffer bietet angehaltene Knoten. Die Stand-by-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 für Kapazitätspuffer variiert je nach Puffertyp:

  • Aktive Puffer: Ihnen werden die Standard-GKE-Compute Preise für die laufenden VMs berechnet, die GKE als aktive Pufferkapazität verwaltet. Im Autopilot-Modus gelten die Standardpreise für die Pod-basierte Abrechnung für die laufenden Pods.
  • Stand-by-Puffer: Während VM-Instanzen angehalten werden, fallen keine Compute Kosten (CPU oder Arbeitsspeicher) an. Es fallen geringe Speicherkosten (z. B. für VM-Bootlaufwerke) und Kosten für zugehörige Ressourcen wie statische externe IP-Adressen an. Wenn GKE die Stand-by-VMs wieder aufnimmt, um Arbeitslasten zu hosten, gelten die Standardpreise für die Compute- oder Pod-basierte Abrechnung.

CapacityBuffer CRD

Um einen Kapazitätspuffer zu konfigurieren, 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 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 basierend auf den Ressourcenanfragen einer referenzierten Pod-Vorlage erstellt werden sollen.
  • Prozentual: Definieren Sie die Puffergröße als Prozentsatz eines vorhandenen skalierbaren Objekts, das eine Skalierungs-Unterressource definiert (z. B. ein Deployment, StatefulSet, ReplicaSet oder Job). Die Puffergröße wird dynamisch angepasst, wenn die Referenzarbeitslast skaliert wird. Prozentuale Kapazitätspuffer werden nur für Objekte unterstützt, die die Kubernetes Skalierungs-Unterressource implementieren.

Weitere Informationen finden Sie in der Referenzdokumentation zur CapacityBuffer CRD.

Best Practices

Beachten Sie die folgenden Empfehlungen, um die Kosteneffizienz und Reaktionsfähigkeit bei der Konfiguration von Kapazitätspuffern zu optimieren:

  • Kostengünstige Strategie mit Stand-by-Puffern: Priorisieren Sie Stand-by-Puffer, wenn Ihre Arbeitslasten eine kurze Verzögerung bei der Aufskalierung von etwa 30 Sekunden tolerieren können. Mit dieser Strategie werden kalte Knotenstarts 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, die keine Knoten-Fortsetzungszeiten tolerieren können, wenn die Pod-Planungszeit so kurz wie möglich sein muss.
  • Hybride Strategie für ein ausgewogenes Verhältnis zwischen Leistung und Kosten: Kombinieren Sie einen kleinen aktiven Puffer mit einem größeren Stand-by-Puffer für eine kostengünstige Einrichtung. GKE priorisiert das Auffüllen des aktiven Puffers, indem Knoten aus dem Stand-by-Puffer wieder aufgenommen werden (ca. 30 Sekunden), während im Hintergrund neue Knoten bereitgestellt werden, um den Stand-by-Puffer wieder aufzufüllen. Diese Einrichtung fängt anfängliche Spitzen mit aktiver Kapazität ab und berücksichtigt ein nachhaltiges Wachstum mit der kostengünstigeren Stand-by-Kapazität.
  • Größe der aktiven Puffer für anfängliche Spitzen anpassen: Definieren Sie die Größe Ihres aktiven Puffers so, dass er die anfänglichen plötzlichen Replikationsspitzen abdeckt, die Sie erwarten, bevor Stand-by-Pufferknoten wieder aufgenommen werden können.
  • Größe der Stand-by-Puffer für anhaltende Last anpassen: Definieren Sie Stand-by-Puffer, die ausreichen, um die erwartete längere Last abzudecken, damit Puffer im Hintergrund aus einem Kaltstart wieder aufgefüllt werden können. Mit einem ausreichend großen Stand-by-Puffer lässt sich die maximale Latenz bei der Pod-Planung auf die Zeit reduzieren, die zum Fortsetzen eines Knotens benötigt wird, also etwa 30 Sekunden. Wenn der Kapazitätspuffer verwendet und wieder aufgefüllt wird, wechseln neue Pufferknoten in einen aktiven Zustand, bevor sie angehalten werden. Diese Strategie trägt dazu bei, die aktive Kapazität bei einer längeren Last zu erhöhen.
  • Puffersimulator verwenden: Experimentieren Sie mit verschiedenen Größen für aktive und Stand-by- Puffer, um das beste Ergebnis für Ihre spezifische Arbeitslast zu erzielen. Führen Sie Simulationen des Arbeitslastskalierungsverhaltens mit dem Open-Source-GKE-Puffersimulator unter https://github.com/gke-labs/buffers-simulator aus, um die Regeln für die Puffergröße zu optimieren und Ihre Leistungsziele zu erreichen.

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 Stand-by-Puffer verfügbar.
  • Kapazitätspuffer unterstützen nur Arbeitslasten, die ein knotenbasiertes Abrechnungsmodell für Standardknotenpools und Autopilot-Knotenpools verwenden, die bestimmte Hardware auswählen. Kapazitätspuffer unterstützen keine Arbeitslasten, 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 Ressourcenanfragen in Ihrem CapacityBuffer erstellen. Wenn Sie die automatische Knotenbereitstellung nicht aktivieren, skaliert der Cluster-Autoscaler nur vorhandene Knotenpools.
  • Sowohl aktive als auch Stand-by-Kapazitätspuffer werden auf die Compute Engine-Kontingente angerechnet.

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

  • Sie werden nur in Standardclustern mit aktivierter automatischer Knotenbereitstellung unterstützt.
  • Knoten mit angehängten GPUs oder TPUs werden nicht unterstützt.
  • Lokale SSDs werden nicht unterstützt.
  • Kundenverwaltete Verschlüsselungsschlüssel (CMEK) werden nicht unterstützt.
  • Vertrauliche Google Kubernetes Engine-Knoten werden nicht unterstützt.
  • Sie sollten mit den Einschränkungen im Zusammenhang mit den Vorgängen zum Anhalten und Fortsetzen von Compute Engine vertraut sein. Einige wichtige Einschränkungen:
    • 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 Länge des Anhaltevorgangs ist proportional zur Arbeitsspeichergröße.
    • Die Wiederaufnahme hängt von der Verfügbarkeit der zugrunde liegenden Ressourcen ab, die für die Wiederaufnahme erforderlich sind.

Nächste Schritte