GKE-Cluster-Autoscaling

Auf dieser Seite wird erläutert, wie die Größe von Knotenpools von Standard-Clustern in Google Kubernetes Engine (GKE) automatisch an die Anforderungen Ihrer Arbeitslasten angepasst wird. Bei hoher Nachfrage fügt der Cluster-Autoscaler Knoten zum Knotenpool hinzu. Informationen zum Konfigurieren des Cluster Autoscalers finden Sie unter Cluster automatisch skalieren.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die die Kapazitäts- und Infrastrukturanforderungen planen und die Systemarchitektur und -ressourcen optimieren, um die niedrigsten Gesamtbetriebskosten für ihr Unternehmen oder ihre Geschäftseinheit zu erzielen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Mit Autopilot-Clustern müssen Sie sich keine Gedanken über die Bereitstellung von Knoten oder die Verwaltung von Knotenpools machen, da Knotenpools automatisch über die automatische Knotenbereitstellung bereitgestellt und automatisch skaliert werden, um die Anforderungen Ihrer Arbeitslasten zu erfüllen.

Machen Sie sich vor dem Lesen dieser Seite mit den grundlegenden Kubernetes-Konzepten und der Funktionsweise von Ressourcenanfragen und ‑limits vertraut.

Best Practice:

Planen und entwerfen Sie Ihre Clusterkonfiguration gemeinsam mit den Administratoren und Architekten, Entwicklern oder einem anderen Team Ihrer Organisation, das für die Implementierung und Wartung Ihrer Anwendung verantwortlich ist.

Vorteile des Cluster-Autoscalings

Cluster Autoscaler von GKE passt die Anzahl der Knoten in einem bestimmten Knotenpool automatisch an die Anforderungen Ihrer Arbeitslasten an. Wenn die Nachfrage gering ist, skaliert das Cluster-Autoscaling auf eine von Ihnen festgelegte Mindestgröße herunter. Dadurch können Sie die Verfügbarkeit Ihrer Arbeitslasten bei Bedarf erhöhen und haben gleichzeitig eine Kontrolle über die Kosten. Sie müssen weder Knoten manuell hinzufügen oder entfernen noch Ihre Knotenpools überdimensionieren. Stattdessen geben Sie eine Mindest- und eine maximale Größe für den Knotenpool an. Alles andere erfolgt automatisch.

Falls Ressourcen beim Autoscaling des Clusters gelöscht oder verschoben werden, kann es bei den Arbeitslasten zu vorübergehenden Unterbrechungen kommen. Umfasst eine Arbeitslast beispielsweise einen Controller mit einem einzelnen Replikat, kann der Pod dieses Replikats auf einen anderen Knoten verschoben werden, wenn der aktuelle Knoten gelöscht wird. Bevor Sie Cluster Autoscaler aktivieren, sollten Sie daher Ihre Arbeitslasten so gestalten, dass mögliche Unterbrechungen toleriert werden bzw. dass wichtige Pods nicht unterbrochen werden.

Best Practice:

Damit Arbeitslasten Unterbrechungen gegenüber toleranter sind, sollten Sie sie mit einem Controller mit mehreren Replikaten bereitstellen, z. B. als Deployment.

Sie können die Leistung des Cluster Autoscaler mit Image-Streaming erhöhen, wodurch Remote-Image-Daten remote von geeigneten Container-Images gestreamt werden und gleichzeitig das Image lokal im Cache gespeichert wird, um Arbeitslasten auf neuen Knoten zuzulassen, damit diese schneller starten.

So funktioniert Cluster Autoscaler

Cluster Autoscaler funktioniert pro Knotenpool. Wenn Sie einen Knotenpool mit Cluster Autoscaler konfigurieren, geben Sie eine Mindest- und eine maximale Größe für den Knotenpool an.

Cluster Autoscaler vergrößert bzw. verkleinert den Knotenpool automatisch durch Hinzufügen oder Entfernen von VM-Instanzen in der zugrunde liegenden verwalteten Instanzgruppe (MIG) von Compute Engine für den Knotenpool. Cluster Autoscaler trifft die Skalierungsentscheidungen auf Grundlage der Ressourcenanforderungen (statt der tatsächlichen Ressourcennutzung) der Pods, die auf den Knoten des Knotenpools ausgeführt werden. Das Tool überprüft regelmäßig den Status von Pods und Knoten und ergreift folgende Maßnahmen:

  • Wenn Pods auf keinem der aktuellen Knoten geplant werden können, fügt Cluster Autoscaler Knoten hinzu, bis die maximale Größe des Knotenpools erreicht ist. Weitere Informationen dazu, wann Cluster Autoscaler die Größe eines Clusters ändert, finden Sie unter Wann ändert Cluster Autoscaler die Größe eines Clusters?
  • Wenn GKE entscheidet, dem Knotenpool neue Knoten hinzuzufügen, fügt Cluster Autoscaler so viele Knoten hinzu, wie erforderlich, bis die Limits pro Knotenpool oder pro Cluster erreicht sind.
  • Cluster Autoscaler wartet nicht, bis ein Knoten gestartet ist, bevor er den nächsten erstellt. Sobald GKE entschieden hat, wie viele Knoten erstellt werden sollen, erfolgt die Erstellung parallel. Ziel ist es, die Zeit zu minimieren, die nicht planbare Pods benötigen, um Active zu werden.
  • Wenn einige Knoten aufgrund eines ausgeschöpften Kontingents nicht erstellt werden können, wartet Cluster Autoscaler, bis Ressourcen erfolgreich geplant werden können.
  • Wenn Knoten nicht ausgelastet sind und alle Pods auch mit weniger Knoten im Knotenpool geplant werden können, entfernt Cluster Autoscaler Knoten bis zur Mindestgröße des Knotenpools.
  • Wenn sich auf einem Knoten Pods befinden, die nicht auf andere Knoten im Cluster verschoben werden können, versucht Cluster Autoscaler nicht, diesen Knoten herunterzuskalieren.
  • Wenn Pods zu anderen Knoten verschoben werden können, der Knoten jedoch nach Ablauf eines Zeitlimits nicht ordnungsgemäß beendet werden kann, wird er zwangsweise beendet. Dieser Zeitraum beträgt eine Stunde für GKE-Versionen 1.32.7-gke.1079000 oder höher und 10 Minuten für frühere GKE-Versionen. Der maximal berücksichtigte Kulanzzeitraum lässt sich für GKE-Cluster nicht konfigurieren. Weitere Informationen zur Funktionsweise der Herunterskalierung finden Sie in der Open-Source-Dokumentation in den FAQ zu Cluster Autoscaler unter Funktionsweise der Herunterskalierung.

Die Häufigkeit, mit der Cluster Autoscaler einen Cluster auf nicht planbare Pods prüft, hängt weitgehend von der Größe des Clusters ab. In kleinen Clustern kann die Prüfung alle paar Sekunden erfolgen. Es ist nicht möglich, einen genauen Zeitraum für diese Prüfung zu definieren.

Wenn Ihren Knoten Ressourcen fehlen, weil Ihre Pods zu wenige Ressourcen angefordert oder als Standardeinstellung unzureichende Ressourcen festgelegt haben, wird dies von Cluster Autoscaler nicht korrigiert. Sie können dafür sorgen, dass Cluster Autoscaler so präzise wie möglich funktioniert, wenn Sie explizite Ressourcenanforderungen für Ihre Arbeitslasten stellen.

Aktivieren Sie das Compute Engine-Autoscaling für verwaltete Instanzgruppen nicht für Clusterknoten. Cluster Autoscaler von GKE arbeitet getrennt von der Autoscaling-Funktion in Compute Engine. Dies kann dazu führen, dass Knotenpools beim vertikalen oder horizontalen Skalieren fehlschlagen, da der Compute Engine Autoscaler mit dem Cluster Autoscaler von GKE in Konflikt steht.

Einsatzkriterien

Bei der Änderung der Größe eines Knotenpools geht der Cluster Autoscaler von folgenden Annahmen aus:

  • Alle replizierten Pods auf einem anderen Knoten können neu gestartet werden. Dies führt unter Umständen zu einer kurzen Störung.
  • Nutzer oder Administratoren verwalten Knoten nicht manuell. Cluster Autoscaler kann alle manuellen Knotenverwaltungsvorgänge überschreiben.
  • Alle Knoten in einem einzelnen Knotenpool haben dieselben Labels.
  • Cluster Autoscaler berücksichtigt die relativen Kosten jedes Instanztyps in den verschiedenen Pools und versucht, den kostengünstigsten Knotenpool zu erweitern. Für dieses Verhalten des Cluster-Autoscalers gelten jedoch die folgenden Bedingungen:
    • Der Cluster Autoscaler berücksichtigt die geringeren Kosten für Knotenpools mit Spot-VMs, die auf Abruf verfügbar sind. Das Cluster Autoscaling berücksichtigt jedoch auch die Verfügbarkeit von Ressourcen in jeder Zone und wählt möglicherweise die teurere, aber verfügbare Ressource aus.
    • Wenn in mehreren Knotenpools Spot-VMs verwendet werden, wählt Cluster Autoscaler nicht automatisch die kostengünstigste Option aus. Um die kostengünstige Nutzung von Spot-VMs zu optimieren und dieses Szenario zu verhindern, empfehlen wir die Verwendung von benutzerdefinierten Compute-Klassen.
  • Cluster Autoscaler berücksichtigt die Init-Containeranfragen, bevor Pods geplant werden. Init-Containeranfragen können alle nicht zugewiesenen Ressourcen verwenden, die auf den Knoten verfügbar sind. Dadurch wird möglicherweise verhindert, dass Pods geplant werden. Cluster Autoscaler folgt denselben Berechnungsregeln für Anfragen, die Kubernetes verwendet. Weitere Informationen finden Sie in der Kubernetes-Dokumentation zur Verwendung von Init-Containern.
  • Nach dem Erstellen des Clusters oder Knotenpools hinzugefügte Labels werden nicht verfolgt. Von Cluster Autoscaler erstellte Knoten erhalten Labels, die zum Zeitpunkt der Knotenpoolerstellung mithilfe von --node-labels definiert wurden.
  • In GKE-Version 1.21 oder früher berücksichtigt Cluster Autoscaler die Markierungsinformationen der vorhandenen Knoten aus einem Knotenpool, um den gesamten Knotenpool darzustellen. Ab GKE-Version 1.22 kombiniert Cluster Autoscaler Informationen aus vorhandenen Knoten im Cluster und im Knotenpool. Cluster Autoscaler erkennt auch die manuellen Änderungen, die Sie am Knoten und Knotenpool vornehmen.
Best Practice:

Aktivieren Sie Cluster Autoscaler nicht, wenn Ihre Anwendungen nicht für Unterbrechungen geeignet sind.

Zonenübergreifender Ausgleich

Wenn Ihr Knotenpool mehrere verwaltete Instanzgruppen mit demselben Instanztyp enthält, versucht Cluster Autoscaler, diese Größen der verwalteten Instanzgruppen beim Hochskalieren im Gleichgewicht zu halten. Dies kann eine ungleichmäßige Verteilung von Knoten zwischen verwalteten Instanzgruppen in mehreren Zonen eines Knotenpools verhindern. GKE berücksichtigt beim Herunterskalieren nicht die Autoscaling-Richtlinie.

Cluster Autoscaler gleicht beim Hochskalieren nur Zonen aus. Cluster Autoscaler skaliert nicht ausgelastete Knoten herunter, unabhängig von den relativen Größen der zugrunde liegenden verwalteten Instanzgruppen in einem Knotenpool. Dies kann dazu führen, dass die Knoten ungleichmäßig auf die Zonen verteilt werden.

Standortrichtlinie

Ab der GKE-Version 1.24.1-gke.800 können Sie die Standortrichtlinie von GKE Cluster Autoscaler ändern. Sie können die Verteilungsrichtlinie für Cluster Autoscaler steuern. Geben Sie dazu das Flag location_policy mit einem der folgenden Werte an:

  • BALANCED: Diese Richtlinie weist Cluster Autoscaler an, Knotenpoolressourcen nach Möglichkeit gleichmäßig auf die ausgewählten Zonen zu verteilen. Dabei werden Pod-Anforderungen (z. B. Affinität) und die Verfügbarkeit von Ressourcen berücksichtigt. Diese Richtlinie ist die Standardrichtlinie für Knotenpools mit Reservierungen oder On-Demand-Knoten. Sie können sie aber auch für Spot-VMs verwenden. BALANCED wird für Knotenpools im Bereitstellungsmodus „Flex-Start“ nicht unterstützt.
  • ANY: Diese Richtlinie weist den Cluster-Autoscaler an, in allen angegebenen Zonen nach der angeforderten Kapazität zu suchen. Das Cluster-Autoscaling priorisiert nicht verwendete Reservierungen und Zonen mit genügend Kapazität, was zu einer Konzentration der Knotenpoolressourcen führen kann. Sie ist die Standardrichtlinie für den Bereitstellungsmodus „Flex-Start“ und Knotenpools, die Spot-VMs verwenden. Sie kann aber auch für Knotenpools mit Reservierungen oder On-Demand-Knoten verwendet werden.
Best Practice:

Verwenden Sie die BALANCED-Richtlinie, wenn für Ihre Arbeitslasten nur leicht verfügbare Beschleunigerressourcen verwendet werden und sie von einer Verteilung über Zonen hinweg profitieren (z. B. für eine bessere Fehlertoleranz). Verwenden Sie die ANY-Richtlinie, um die Nutzung nicht verwendeter Reservierungen und eine höhere Verfügbarkeit knapper Rechenressourcen (z. B. Beschleuniger) zu priorisieren.

Reservierungen

Ab GKE-Version 1.27 berücksichtigt der Cluster Autoscaler immer Reservierungen, wenn Entscheidungen zur vertikalen Skalierung getroffen werden. Die Knotenpools mit übereinstimmenden nicht verwendeten Reservierungen werden priorisiert, wenn der Knotenpool zum Hochskalieren ausgewählt wird, auch wenn der Knotenpool nicht der effizienteste ist. Außerdem werden nicht verwendete Reservierungen beim Balancing von multizonalen Hochskalierungen immer priorisiert.

Der Cluster-Autoscaler prüft jedoch nur in seinem eigenen Projekt auf Reservierungen. Wenn also eine kostengünstigere Knotenoption im eigenen Projekt des Clusters verfügbar ist, wählt der Autoscaler möglicherweise diese Option anstelle der gemeinsamen Reservierung aus. Wenn Sie Reservierungen für mehrere Projekte freigeben müssen, sollten Sie benutzerdefinierte Compute-Klassen verwenden. Damit können Sie die Priorität konfigurieren, die der Cluster Autoscaler zum Skalieren von Knoten verwendet, einschließlich freigegebener Reservierungen.

Standardwerte

Für Knotenpools von Spot-VMs ist die Standardrichtlinie zur Verteilung für Cluster Autoscaler ANY. In dieser Richtlinie haben Spot-VMs ein niedrigeres Risiko, vorzeitig beendet zu werden.

Für nicht abrufbare Knotenpools ist die Standardrichtlinie zur Verteilung für Cluster Autoscaler BALANCED.

Mindest- und Maximalgröße von Knotenpools

Wenn Sie einen neuen Knotenpool erstellen, können Sie die Mindest- und Maximalgröße für jeden Knotenpool in Ihrem Cluster angeben. Das Cluster-Autoscaling trifft die Neuskalierungsentscheidungen innerhalb dieser Skalierungseinschränkungen. Um den Mindestwert zu aktualisieren, ändern Sie die Größe des Clusters manuell auf eine Größe innerhalb der neuen Einschränkungen, nachdem Sie den neuen Mindestwert angegeben haben. Das Cluster-Autoscaling trifft dann Entscheidungen zur Neuskalierung anhand der neuen Einschränkungen.

Aktuelle Knotenpoolgröße Cluster Autoscaler-Aktion Skalierungseinschränkungen
Unter dem von Ihnen angegebenen Mindestwert Cluster Autoscaler skaliert hoch, um ausstehende Pods bereitzustellen. Das Herunterskalieren ist deaktiviert. Der Knotenpool wird nicht unter den von Ihnen angegebenen Wert herunterskaliert.
Innerhalb der von Ihnen angegebenen Mindest- und Maximalgröße Cluster Autoscaler kann je nach Bedarf hoch- oder herunterskalieren. Der Knotenpool hält die von Ihnen angegebenen Größenlimits ein.
Höher als der von Ihnen angegebene Höchstwert Cluster Autoscaler skaliert nur die Knoten herunter, die sicher entfernt werden können. Das Skalieren nach oben ist deaktiviert. Der Knotenpool wird nicht über den von Ihnen angegebenen Wert hinaus skaliert.

Bei Standardclustern skaliert der Cluster Autoscaler einen Cluster niemals automatisch auf null Knoten herunter. Zur Ausführung von System-Pods muss immer mindestens ein Knoten im Cluster verfügbar sein. Wenn die aktuelle Anzahl von Knoten null ist, weil sie manuell entfernt werden, kann Cluster Autoscaler und die automatische Knotenbereitstellung von null Knotenclustern hochskalieren.

Weitere Informationen zu Entscheidungen des Autoscalers finden Sie unter Einschränkungen von Cluster Autoscaler.

Limits für die automatische Skalierung

Sie können die minimale und maximale Anzahl an Knoten festlegen, die Cluster Autoscaler beim Skalieren eines Knotenpools verwenden soll. Mit den Flags --min-nodes und --max-nodes können Sie die minimale und maximale Anzahl an Knoten pro Zone festlegen.

Ab der GKE-Version 1.24 können Sie die Flags --total-min-nodes und --total-max-nodes für neue Cluster verwenden. Diese Flags legen die minimale und maximale Anzahl von Knoten im Knotenpool in allen Zonen fest.

Beispiel: Mindest- und Höchstzahl an Knoten

Mit dem folgenden Befehl wird beispielsweise ein automatisch skalierter Cluster mit mehreren Zonen und sechs Knoten erstellt. Die Knoten sind anfangs auf drei Zonen verteilt, wobei mindestens ein Knoten pro Zone und maximal vier Knoten pro Zone vorhanden sein müssen:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

In diesem Beispiel kann die Gesamtgröße des Clusters zwischen drei und zwölf Knoten liegen, verteilt auf die drei Zonen. Wenn eine der Zonen ausfällt, kann die Gesamtgröße des Clusters zwischen zwei und acht Knoten betragen.

Beispiel: Gesamtzahl der Knoten

Mit folgendem Befehl, der in der GKE-Version 1.24 oder höher verfügbar ist, wird ein automatisch skalierender Cluster mit mehreren Zonen und sechs Knoten erstellt. Die Knoten sind anfangs auf drei Zonen verteilt, wobei mindestens drei Knoten und maximal zwölf Knoten im Knotenpool über alle Zonen hinweg vorhanden sind:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

In diesem Beispiel kann die Gesamtgröße des Clusters unabhängig von der Verteilung zwischen Zonen zwischen drei und zwölf Knoten liegen.

Autoscaling-Profile

Die Entscheidung, wann ein Knoten entfernt werden soll, bedeutet einen Kompromiss zwischen der Optimierung der Auslastung und der Verfügbarkeit von Ressourcen. Mit dem Entfernen zu wenig genutzter Knoten wird die Clusterauslastung verbessert. Neue Arbeitslasten müssen jedoch möglicherweise warten, bis Ressourcen noch einmal bereitgestellt werden, bevor sie ausgeführt werden können.

Sie können angeben, welches Autoscaling-Profil bei solchen Entscheidungen verwendet werden soll. Folgende Profile sind verfügbar:

  • balanced: Das Standardprofil, bei dem mehr Ressourcen für eingehende Pods verfügbar gehalten werden, um die Zeit zu verkürzen, die für die Aktivierung der Ressourcen für Standardcluster erforderlich ist. Das balanced-Profil ist für Autopilot-Cluster nicht verfügbar.
  • optimize-utilization: Priorisieren der Auslastungsoptimierung, anstatt freie Ressourcen im Cluster zu belassen. Wenn Sie dieses Profil aktivieren, skaliert der Cluster Autoscaler den Cluster stärker herunter. Es können mehr Knoten in kürzerer Zeit mit GKE entfernt werden. GKE plant Pods vorzugsweise in Knoten, die bereits eine hohe CPU-, Arbeitsspeicher- oder GPU-Zuweisung haben. Andere Faktoren beeinflussen die Planung, z. B. die Verteilung der Pods, die zum selben Deployment, StatefulSet oder Dienst gehören.

Das Autoscaling-Profil optimize-utilization hilft Cluster Autoscaler, nicht ausgelastete Knoten zu identifizieren und zu entfernen. Damit diese Optimierung erfolgt, legt GKE den Namen des Planers in der Pod-Spezifikation auf gke.io/optimize-utilization-scheduler fest. Pods, die einen benutzerdefinierten Planer angeben, sind nicht betroffen.

Der folgende Befehl aktiviert das Autoscaling-Profil optimize-utilization in einem vorhandenen Cluster:

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

Pod-Planung und -Unterbrechungen berücksichtigen

Cluster Autoscaler berücksichtigt beim Herunterskalieren die in Pods festgelegten Planungs- und Bereinigungsregeln. Diese Einschränkungen können das Löschen eines Knotens durch Cluster Autoscaler verhindern. Ein Knoten wird unter Umständen nicht gelöscht, wenn er einen Pod mit einer der folgenden Bedingungen enthält:

  • Die Affinitäts- oder Anti-Affinitätsregeln des Pods verhindern eine Neuplanung.
  • Der Pod wird nicht von einem Controller wie einem Deployment, StatefulSet, Job oder ReplicaSet verwaltet.
  • Der Pod hat einen lokalen Speicher und die Version der GKE-Steuerungsebene ist niedriger als 1.22. In GKE-Clustern mit Steuerungsebenenversion 1.22 oder höher blockieren Pods mit lokalem Speicher nicht mehr das Herunterskalieren.
  • Der Pod hat die Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
  • Das Löschen des Knotens würde das konfigurierte PodDisruptionBudget überschreiten.

Weitere Informationen zu Cluster Autoscaler und zur Vermeidung von Störungen finden Sie in den FAQ zu Cluster Autoscaler:

TPUs in GKE automatisch skalieren

GKE unterstützt Tensor Processing Units (TPUs), um ML-Arbeitslasten zu beschleunigen. Sowohl der TPU-Slice-Knotenpool mit einem einzelnen Host als auch der TPU-Slice-Knotenpool mit mehreren Hosts unterstützen Autoscaling und die automatische Bereitstellung.

Mit dem Flag --enable-autoprovisioning in einem GKE-Cluster erstellt oder löscht GKE TPU-Slice-Knotenpools mit einem oder mehreren Hosts mit einer TPU-Version und Topologie, die die Anforderungen ausstehender Arbeitslasten erfüllt.

Wenn Sie --enable-autoscaling verwenden, skaliert GKE den Knotenpool basierend auf seinem Typ so:

  • Einzelner Host TPU-Slice-Knotenpool: GKE fügt dem vorhandenen Knotenpool TPU-Knoten hinzu oder entfernt sie. Der Knotenpool kann eine beliebige Anzahl von TPU-Knoten zwischen null und der maximalen Größe des Knotenpools enthalten, wie durch --max-nodes und die --total-max-nodes-Flags bestimmt. Wenn der Knotenpool skaliert wird, haben alle TPU-Knoten im Knotenpool denselben Maschinentyp und dieselbe Topologie. Weitere Informationen zum Erstellen eines TPU-Slice-Knotenpools mit einem Host finden Sie unter Knotenpool erstellen.

  • TPU-Slice-Knotenpool mit mehreren Hosts: GKE skaliert den Knotenpool in kleinstmöglichen Schritten von null auf die Anzahl der Knoten, die für die TPU-Topologie erforderlich sind. Bei einem TPU-Knotenpool mit dem Maschinentyp ct5lp-hightpu-4t und der Topologie 16x16 enthält der Knotenpool beispielsweise 64 Knoten. GKE Autoscaling sorgt dafür, dass dieser Knotenpool genau 0 oder 64 Knoten hat. Beim Herunterskalieren entfernt GKE alle geplanten Pods und leert den gesamten Knotenpool auf null. Weitere Informationen zum Erstellen eines TPU-Slice-Knotenpools mit mehreren Hosts finden Sie unter Knotenpool erstellen.

Spot-VMs und Cluster-Autoscaler

Da der Cluster Autoscaler die kostengünstigsten Knotenpools bevorzugt, werden beim Hochskalieren Spot-VMs hinzugefügt, sofern Ihre Arbeitslasten und die Ressourcenverfügbarkeit dies zulassen.

Auch wenn Cluster Autoscaler das Hinzufügen von Spot-VMs bevorzugt, wird dadurch nicht garantiert, dass die meisten Ihrer Pods auf diesen VM-Typen ausgeführt werden. Spot-VMs können vorzeitig beendet werden. Aufgrund dieser Vorabbenachrichtigung werden Pods auf Spot-VMs eher entfernt. Wenn sie entfernt werden, haben sie nur 15 Sekunden Zeit, um die Verbindung zu beenden.

Stellen Sie sich beispielsweise ein Szenario mit 10 Pods und einer Mischung aus On-Demand- und Spot-VMs vor:

  • Sie beginnen mit 10 Pods, die auf On-Demand-VMs ausgeführt werden, da die Spot-VMs nicht verfügbar waren.
  • Sie benötigen nicht alle 10 Pods. Der Cluster-Autoscaler entfernt daher zwei Pods und fährt die zusätzlichen On-Demand-VMs herunter.
  • Wenn Sie wieder 10 Pods benötigen, fügt Cluster Autoscaler Spot-VMs hinzu (da sie günstiger sind) und plant zwei Pods auf ihnen. Die anderen acht Pods verbleiben auf den On-Demand-VMs.
  • Wenn der Cluster Autoscaler wieder herunterskaliert werden muss, werden Spot-VMs wahrscheinlich zuerst vorzeitig beendet, sodass die meisten Ihrer Pods auf On-Demand-VMs ausgeführt werden.

Um Spot-VMs zu priorisieren und das oben beschriebene Szenario zu vermeiden, empfehlen wir die Verwendung von benutzerdefinierten Compute-Klassen. Mit benutzerdefinierten Compute-Klassen können Sie Prioritätsregeln erstellen, die Spot-VMs beim Hochskalieren bevorzugen, indem sie ihnen eine höhere Priorität als On-Demand-Knoten zuweisen. Um die Wahrscheinlichkeit zu maximieren, dass Ihre Pods auf Knoten ausgeführt werden, die von Spot-VMs unterstützt werden, konfigurieren Sie die aktive Migration.

Das folgende Beispiel zeigt eine Möglichkeit, benutzerdefinierte Compute-Klassen zu verwenden, um Spot-VMs zu priorisieren. Weitere Informationen zu ComputeClass-Parametern finden Sie in der CRD-Dokumentation zu ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  # Defines a prioritized list of machine types and configurations for node provisioning.
  priorities:
  - machineType: g2-standard-24
    # Specifically requests Spot VMs for this configuration. GKE will try to provision these VMs first.
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  # If GKE can't satisfy the preceding rule, request on-demand nodes with the same configuration
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  # Configures active migration behavior for workloads using this ComputeClass.
  activeMigration:
    optimizeRulePriority: true
    # Enables Cluster Autoscaler to attempt to migrate workloads to Spot VMs
    # if Spot capacity becomes available and the workload is currently
    # running on an on-demand VM (based on the priority rules in this example).

Im vorherigen Beispiel wird mit der Prioritätsregel eine Präferenz für das Erstellen von Knoten mit dem Maschinentyp g2-standard-24 und Spot-VMs deklariert. Wenn keine Spot-VMs verfügbar sind, verwendet GKE On-Demand-VMs als Fallback-Option. Diese Compute-Klasse aktiviert auch activeMigration, sodass Cluster Autoscaler Arbeitslasten auf Spot-VMs migrieren kann, wenn die Kapazität verfügbar wird.

Wenn Sie keine benutzerdefinierten Compute-Klassen verwenden können, fügen Sie eine Knotenaffinität, ‑markierung oder ‑toleranz hinzu. Mit der folgenden Knotenaffinitätsregel wird beispielsweise eine Präferenz für die Planung von Pods auf Knoten deklariert, die von Spot-VMs unterstützt werden. GKE fügt diesen Knotentypen automatisch das Label cloud.google.com/gke-spot=true hinzu:

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        # set to "true". GKE automatically applies this label to Spot VMs.
        - key: cloud.google.com/gke-spot
          operator: Equal
          values:
          - true

Weitere Informationen zur Verwendung von Knotenaffinitäten, Markierungen und Toleranzen zum Planen von Spot-VMs finden Sie im Blogbeitrag.

ProvisioningRequest CRD

ProvisioningRequest ist eine benutzerdefinierte Ressource mit Namespace, mit der Nutzer Kapazität für eine Gruppe von Pods vom Cluster-Autoscaler anfordern können. Dies ist besonders nützlich für Anwendungen mit miteinander verbundenen Pods, die als Einheit geplant werden müssen.

Unterstützte Bereitstellungsklassen

Es gibt drei unterstützte ProvisioningClasses:

  • queued-provisioning.gke.io: Diese GKE-spezifische Klasse lässt sich in den Dynamic Workload Scheduler einbinden. Sie ermöglicht es Ihnen, Anfragen in die Warteschlange zu stellen und sie ausführen zu lassen, wenn Ressourcen verfügbar werden. Dies ist ideal für Batchjobs oder verzögerungstolerante Arbeitslasten. Informationen zum Verwenden der Warteschlangenbereitstellung in GKE Wird ab GKE-Version 1.28.3-gke.1098000 in Standardclustern und ab GKE-Version 1.30.3-gke.1451000 in Autopilot-Clustern unterstützt.

  • check-capacity.autoscaling.x-k8s.io: Diese Open-Source-Klasse prüft die Verfügbarkeit von Ressourcen, bevor versucht wird, Pods zu planen. Unterstützt ab GKE-Version 1.30.2-gke.1468000.

  • best-effort-atomic.autoscaling.x-k8s.io: Diese Open-Source-Klasse versucht, Ressourcen für alle Pods in der Anfrage gemeinsam bereitzustellen. Wenn es nicht möglich ist, genügend Ressourcen für alle Pods bereitzustellen, werden keine Ressourcen bereitgestellt und die gesamte Anfrage schlägt fehl. Unterstützt ab GKE-Version 1.31.27.

Weitere Informationen zu den Klassen „CheckCapacity“ und „BestEffortAtomicScaleUp“ finden Sie in der Open-Source-Dokumentation.

Einschränkungen bei der Verwendung von ProvisioningRequest

  • Das GKE-Cluster-Autoscaling unterstützt nur 1 PodTemplate pro ProvisioningRequest.
  • Der GKE-Cluster-Autoscaler kann jeweils nur einen Knotenpool hochskalieren. Wenn für Ihren ProvisioningRequest Ressourcen aus mehreren Knotenpools erforderlich sind, müssen Sie für jeden Knotenpool separate ProvisioningRequests erstellen.

Best Practices für die Verwendung von ProvisioningRequest

  • Verwenden Sie total-max-nodes: Anstatt die maximale Anzahl von Knoten (--max nodes) zu begrenzen, können Sie mit --total-max-nodes die von Ihrer Anwendung verbrauchten Gesamtresourcen einschränken.
  • location-policy=ANY verwenden: Mit dieser Einstellung können Ihre Pods an einem beliebigen verfügbaren Standort geplant werden. Dies kann die Bereitstellung beschleunigen und die Ressourcennutzung optimieren.
  • Optional: Mit Kueue integrieren: Kueue kann die Erstellung von ProvisioningRequests automatisieren und so Ihren Workflow optimieren. Weitere Informationen finden Sie in der Kueue-Dokumentation.

Backoff-Zeiträume

Ein Hochskalierungsvorgang kann aufgrund von Fehlern beim Erstellen von Knoten fehlschlagen, z. B. aufgrund eines unzureichenden Kontingents oder einer Erschöpfung der IP-Adressen. Wenn diese Fehler auftreten, wiederholt die zugrunde liegende verwaltete Instanzgruppe (Managed Instance Group, MIG) den Vorgang nach einer anfänglichen Backoff-Zeit von fünf Minuten. Wenn weiterhin Fehler auftreten, verlängert sich dieser Backoff-Zeitraum exponentiell auf maximal 30 Minuten. In dieser Zeit kann Cluster Autoscaler weiterhin andere Knotenpools im Cluster hochskalieren, bei denen keine Fehler auftreten.

Weitere Informationen

Mehr über Cluster Autoscaler finden Sie unter FAQs zur automatischen Skalierung im Kubernetes-Open-Source-Projekt.

Beschränkungen

Für Cluster Autoscaler gelten die folgenden Einschränkungen:

  • Lokale PersistentVolumes werden vom Cluster Autoscaler nicht unterstützt.
  • In Versionen der GKE-Steuerungsebene vor 1.24.5-gke.600 unterstützt Cluster Autoscaler das vertikale Skalieren eines Knotenpools ohne Nullknoten, der Lokale SSDs als sitzungsspezifischer Speicher verwendet.
  • Beschränkungen der Clustergröße: bis zu 15.000 Knoten. Berücksichtigen Sie beim Ausführen von Clustern dieser Größe auch andere Clusterlimits und unsere Best Practices.
  • Beim Herunterskalieren unterstützt Cluster Autoscaler eine ordnungsgemäße Beendigung innerhalb einer Stunde. In diesem Zeitraum kann eine Neuplanung der Pods des Knotens auf einem anderen Knoten erfolgen. Nach Ablauf dieses Zeitlimits wird die Beendigung des Knotens erzwungen.
  • Manchmal kann Cluster Autoscaler nicht vollständig herunterskalieren. Dadurch bleibt nach dem Herunterskalieren ein zusätzlicher Pod übrig. Dies kann vorkommen, wenn erforderliche System-Pods auf verschiedenen Knoten geplant sind, da es keinen Trigger gibt, der diese Pods auf einen anderen Knoten verschiebt. Siehe Ich habe einige Knoten mit geringer Auslastung, die jedoch nicht herunterskaliert werden. Warum?. Sie können ein Budget für Pod-Störungen konfigurieren, um diese Einschränkung zu umgehen.
  • Die benutzerdefinierte Planung mit geänderten Filtern wird nicht unterstützt.
  • Cluster Autoscaler berücksichtigt das Standardverhalten von kube-scheduler, wenn entschieden wird, ob neue Knoten für ausstehende Pods bereitgestellt werden sollen. Die Verwendung benutzerdefinierter Scheduler wird nicht unterstützt und kann zu unerwartetem Skalierungsverhalten führen.
  • Knoten werden nicht hochskaliert, wenn Pods einen PriorityClass-Wert unter -10 haben. Weitere Informationen finden Sie unter Wie funktioniert Cluster Autoscaler mit Pod-Priorität und -Präemption?
  • Cluster Autoscaler hat möglicherweise nicht genügend nicht zugewiesenen IP-Adressbereich, um neue Knoten oder Pods hinzuzufügen. Dies führt zu Fehlern beim Hochskalieren, die durch eventResult-Ereignisse mit dem Grund scale.up.error.ip.space.exhausted angezeigt werden. Sie können weitere IP-Adressen für Knoten hinzufügen, indem Sie das primäre Subnetz erweitern. Sie können auch neue IP-Adressen für Pods hinzufügen, indem Sie nicht zusammenhängendes CIDR für mehrere Pods verwenden. Weitere Informationen finden Sie unter Nicht genügend freier IP-Bereich für Pods.
  • GKE Cluster Autoscaler unterscheidet sich vom Cluster Autoscaler des Open-Source-Kubernetes-Projekts. Die Parameter des GKE Cluster Autoscaler hängen von der Clusterkonfiguration ab und können sich ändern. Wenn Sie das Autoscaling-Verhalten genauer steuern möchten, deaktivieren Sie GKE Cluster Autoscaler und verwenden Sie den Cluster Autoscaler der Open-Source-Version von Kubernetes. Die Open-Source-Version von Kubernetes wird jedoch nicht von Google Cloud unterstützt.
  • Wenn Sie einen GKE-Knotenpool löschen, für den die automatische Skalierung aktiviert ist, wird für die Knoten das Flag NoSchedule festgelegt und alle Pods auf diesen Knoten werden sofort entfernt. Um den plötzlichen Rückgang der verfügbaren Ressourcen zu mildern, kann der Autoscaler des Knotenpools neue Knoten im selben Knotenpool bereitstellen. Diese neu erstellten Knoten sind für die Planung verfügbar und entfernte Pods werden wieder auf ihnen geplant. Schließlich wird der gesamte Knotenpool, einschließlich der neu bereitgestellten Knoten und ihrer Pods, gelöscht, was zu potenziellen Dienstunterbrechungen führen kann. Als Behelfslösung können Sie das Autoscaling im Knotenpool deaktivieren, bevor Sie das Löschen starten, um zu verhindern, dass der Autoscaler während des Löschens neue Knoten bereitstellt.
  • Der Cluster Autoscaler muss die Menge der verfügbaren Ressourcen auf neuen Knoten vorhersagen, um Skalierungsentscheidungen treffen zu können. DaemonSet-Pods sind enthalten, was die verfügbaren Ressourcen verringert. Die Vorhersagen sind nicht zu 100% genau und die Menge der verfügbaren Ressourcen kann sich zwischen den GKE-Versionen ändern. Aus diesem Grund empfehlen wir nicht, die Größe von Arbeitslasten so anzupassen und einzuschränken, dass sie zu einem bestimmten Instanztyp passen. Verwenden Sie stattdessen benutzerdefinierte Compute-Klassen. Wenn eine Arbeitslast auf einen bestimmten Instanztyp ausgerichtet sein muss, achten Sie darauf, dass die Größe so bemessen ist, dass auf den Knoten ein Puffer an zuweisbaren Ressourcen verbleibt. In diesem Fall müssen Sie auch dafür sorgen, dass alle relevanten DaemonSet-Pods zusammen mit Ihren Arbeitslast-Pods auf die Knoten passen.
  • Cluster Autoscaler unterstützt keine strengen Pod-Topologie-Verteilungsbeschränkungen, wenn das Feld whenUnsatisfiable auf den Wert DoNotSchedule gesetzt ist. Sie können die Anforderungen an die Streuung lockern, indem Sie das Feld whenUnsatisfiable auf den Wert ScheduleAnyway festlegen.

Bekannte Probleme

  • In Versionen der GKE-Steuerungsebene vor Version 1.22 beendet Cluster Autoscaler von GKE die vertikale Skalierung aller Knotenpools auf leeren Clustern (ohne Knoten). Dieses Verhalten tritt nicht in GKE-Version 1.22 und höher auf.

Fehlerbehebung

Informationen zur Fehlerbehebung finden Sie auf den folgenden Seiten:

Nächste Schritte