Vertikales Pod-Autoscaling

Auf dieser Seite wird erläutert, wie Sie Ihre Ressourcenzuweisung analysieren und optimieren können, um die Effizienz Ihrer Arbeitslasten in Google Kubernetes Engine (GKE) mithilfe von vertikalem Pod-Autoscaling zu verbessern. Wenn Sie die Ressourcennutzung Ihrer Arbeitslast im Zeitverlauf analysieren, können Sie Optimierungsempfehlungen erhalten und CPU- und Arbeitsspeicheranfragen sowie Limits für Container in den Pods automatisch anpassen.

Auf dieser Seite erfahren Sie, wie vertikales Pod-Autoscaling funktioniert, welche Vorteile und Einschränkungen es gibt und welche Best Practices für die Verwendung gelten. Außerdem finden Sie API-Referenzen für die benutzerdefinierte VerticalPodAutoscaler-Ressource und zugehörige Typen.

Diese Seite richtet sich an Betreiber und Entwickler, die Cloud-Ressourcen bereitstellen und konfigurieren, Arbeitslasten bereitstellen und die Anwendungsskalierung verwalten. Weitere Informationen zu gängigen Rollen finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Machen Sie sich vor dem Lesen dieser Seite mit Ressourcenanfragen und ‑limits in Kubernetes vertraut.

Für schnelles Skalieren bei plötzlicher Ressourcennutzung verwenden Sie das horizontale Pod-Autoscaling.

Best Practices für Autoscaling finden Sie unter Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE.

Vorteile des vertikalen Pod-Autoscaling

Vertikales Pod-Autoscaling bietet folgende Vorteile:

  • Wenn Sie die richtigen Ressourcenanfragen und -limits für Ihre Arbeitslasten festlegen, verbessern Sie die Stabilität und Kosteneffizienz. Wenn die Pod-Ressourcengrößen kleiner sind als Ihre Arbeitslasten benötigen, kann Ihre Anwendung gedrosselt werden oder infolge von Fehlern aufgrund mangelnden Arbeitsspeichers ausfallen. Sind Ihre Ressourcen zu groß bemessen, müssen Sie Verschwendung und somit höheren Rechnungen in Kauf nehmen.
  • Clusterknoten werden effizient eingesetzt, da Pods die richtigen Ressourcenmengen nutzen.
  • Pods werden auf Knoten geplant, auf denen die benötigten Ressourcen verfügbar sind.
  • Sie müssen kein zeitaufwändiges Benchmarking durchführen, um die richtigen Werte für CPU- und Speicheranforderungen zu ermitteln.
  • Sie können die Wartungszeit reduzieren, da die CPU- und Speicheranforderungen jederzeit automatisch angepasst werden können, ohne dass Sie etwas tun müssen.
  • Vertikales Pod-Autoscaling funktioniert am besten mit homogenen Arbeitslasten mit langer Ausführungszeit.

Vertikales Pod-Autoscaling in GKE bietet gegenüber dem Open-Source-Autoscaler von Kubernetes folgende Vorteile:

  • Bei der Bestimmung des Empfehlungsziels werden die maximalen Knotengrößen und Ressourcenkontingente berücksichtigt.
  • Benachrichtigt den Cluster Autoscaler, um die Clusterkapazität anzupassen.
  • Es werden Verlaufsdaten verwendet, einschließlich Messwerten, die vor der Aktivierung von VerticalPodAutoscaler erfasst wurden.
  • Führt VerticalPodAutoscaler-Pods als Steuerungsebenenprozesse und nicht als Deployments auf Ihren Worker-Knoten aus.

Funktionsweise von vertikalem Pod-Autoscaling

Mit vertikalem Pod-Autoscaling können Sie die für Pods erforderlichen CPU- und Arbeitsspeicherressourcen analysieren und festlegen. Anstatt aktuelle CPU-Anfragen und -Limits sowie Speicheranforderungen und -limits für die Container in Ihren Pods festzulegen, können Sie das vertikale Pod-Autoscaling so konfigurieren, dass sie empfohlene Werte für CPU- und Speicheranfragen sowie Limits bereitstellt, die Sie zur manuellen Aktualisierung Ihrer Pods verwenden können. Sie können das vertikale Pod-Autoscaling auch so konfigurieren, dass die Werte automatisch aktualisiert werden.

Vertikales Pod-Autoscaling ist in Autopilot-Clustern standardmäßig aktiviert.

Beziehung zu Open-Source-VerticalPodAutoscaler von Kubernetes

Das vertikale Pod-Autoscaling in GKE basiert auf der Open-Source-API VerticalPodAutoscaler von Kubernetes, ist aber eine separate Implementierung, die nur in GKE verfügbar ist. Die GKE-Implementierung ist mit einem eigenen Empfehlungstool auf Skalierbarkeit ausgelegt, behält aber dieselben VerticalPodAutoscaler-API-Arten und -Felder bei, die in der Open-Source-Version definiert sind.

Weitere Informationen finden Sie in der Kubernetes-Dokumentation zum vertikalen Pod-Autoscaling.

Modi für vertikales Pod-Autoscaling

Sie können konfigurieren, wie das vertikale Pod-Autoscaling Ressourcenänderungen anwendet, indem Sie verschiedene Aktualisierungsmodi anwenden.

Auto-Modus (Recreate)

Im Modus Recreate wird ein Pod durch vertikales Pod-Autoscaling entfernt, wenn die Ressourcenanforderungen des Pods geändert werden müssen. Der Ausschluss ist erforderlich, da aufgrund von Kubernetes-Einschränkungen in Versionen vor 1.33 die Ressourcenanforderungen eines aktiven Pods nur geändert werden können, indem der Pod neu erstellt wird.

Sie können ein Budget für Pod-Störungen verwenden, um die Anzahl der Pod-Neuerstellungen zu begrenzen . Mit dem Cluster Autoscaler und der automatischen Knotenbereitstellung können Sie gewährleisten, dass ein Cluster den neuen Umfang Ihrer Arbeitslasten verarbeiten kann.

Vertikales Pod-Autoscaling benachrichtigt vor dem Update den Cluster Autoscaler. Die für die geänderte Arbeitslast erforderlichen Ressourcen werden bereitgestellt, bevor sie neu erstellt wird, um die Unterbrechungszeit zu minimieren.

Initial-Modus

Wenn Initial aktiviert ist, weist vertikales Pod-Autoscaling Ressourcenanforderungen nur bei der Pod-Erstellung zu und ändert sie später nie mehr.

InPlaceOrRecreate-Modus

Im InPlaceOrRecreate-Modus soll die Dienstunterbrechung reduziert werden, indem versucht wird, Pod-Ressourcen zu aktualisieren, ohne den Pod neu zu erstellen.

Wenn Sie den Modus InPlaceOrRecreate verwenden möchten, legen Sie das Feld spec.updatePolicy.updateMode in Ihrem VerticalPodAutoscaler-Objekt auf "InPlaceOrRecreate" fest. In diesem Modus wird anhand des Felds resizePolicy in Ihrem Arbeitslastmanifest ermittelt, ob für eine Ressourcenänderung ein Neustart erforderlich ist. Wenn das Feld resizePolicy nicht definiert ist, wird standardmäßig NotRequired für CPU und Arbeitsspeicher verwendet. Das bedeutet, dass In-Place-Updates versucht werden.

Wenn ein Container aufgrund eines OOM-Ereignisses (Out of Memory) beendet wird, verhält sich das vertikale Pod-Autoscaling im Modus InPlaceOrRecreate ähnlich wie im Modus Auto: Es lernt aus dem Fehler. Beim anschließenden Neuerstellen des Pods, das durch den Absturz ausgelöst wird, wendet das vertikale Pod-Autoscaling eine Empfehlung an, die einen Sicherheitsbuffer enthält (in der Regel 20% zusätzlicher Arbeitsspeicher oder 100 MB, je nachdem, welcher Wert größer ist), um eine sofortige Wiederholung des OOM-Fehlers zu verhindern.

Der InPlaceOrRecreate-Modus ist ab Kubernetes-Version 1.34.0-gke.2201000 verfügbar.

Fallback-Szenarien für den Modus InPlaceOrRecreate

Wenn beim vertikalen Pod-Autoscaling festgestellt wird, dass eine direkte Aktualisierung nicht möglich ist, wird auf das Verhalten des Modus Recreate zurückgegriffen. Dabei wird der Pod entfernt und neu erstellt, um die Änderungen zu übernehmen. Einige häufige Szenarien, in denen vertikales Pod-Autoscaling auf das Neuerstellen zurückgreift:

  • Unzureichende Knotenkapazität:Die aktualisierte Ressourcenanfrage überschreitet die zuweisbare Kapazität des aktuellen Knotens und das Update kann nicht direkt geplant werden (Status „nicht möglich“ oder „aufgeschoben“ für länger als ein Zeitlimit).
  • Änderung der QoS-Klasse:Durch die Ressourcenaktualisierung würde sich die QoS-Klasse (Quality of Service) des Pods ändern, z. B. von Burstable zu Guaranteed.
  • RestartContainer-Richtlinie:Das Feld resizePolicy des Pods ist für eine Ressource, die durch vertikales Pod-Autoscaling geändert werden soll, auf RestartContainer gesetzt.
  • Zeitüberschreitungen:Eine In-Place-Updateanfrage bleibt zu lange im Status „Ausstehend“.

Off-Modus

Im Modus Off wendet das vertikale Pod-Autoscaling keine Änderungen automatisch auf einen Pod an. Sie können weiterhin empfohlene Werte für die Anforderungen und Limits von CPU und Arbeitsspeicher basierend auf der bisherigen Nutzung ansehen, diese Empfehlungen werden jedoch nicht automatisch angewendet. Sie können die empfohlenen Werte bei Bedarf manuell auf Ihre Pods anwenden.

Ressourcenrichtlinien

Mit ContainerResourcePolicy können Sie anpassen, wie das vertikale Pod-Autoscaling Empfehlungen für bestimmte Container generiert. Mit dieser Richtlinie können Sie Einschränkungen festlegen und steuern, welche Ressourcen skaliert werden.

Mindest- und Höchstlimits

Sie können die minimalen (minAllowed) und maximalen (maxAllowed) Ressourcenwerte für einen Container angeben.

  • minAllowed: Das vertikale Pod-Autoscaling empfiehlt keinen Wert, der unter diesem Grenzwert liegt. Dieses Limit ist nützlich, um ein Mindestleistungsniveau zu gewährleisten oder anwendungsspezifische Anforderungen zu erfüllen.
  • maxAllowed: Das vertikale Pod-Autoscaling empfiehlt keinen Wert, der höher als dieses Limit ist. Dieses Limit ist nützlich, um die Kosten zu kontrollieren oder zu verhindern, dass ein einzelner Container zu viele Knotenressourcen verbraucht.

Kontrollierte Ressourcen

Standardmäßig werden beim vertikalen Pod-Autoscaling Empfehlungen für CPU und Arbeitsspeicher berechnet. Mit dem Feld controlledResources können Sie angeben, welche Ressourcen automatisch skaliert werden sollen. Sie können den Autoscaler beispielsweise so konfigurieren, dass er nur Empfehlungen für den Arbeitsspeicher gibt und CPU-Anforderungen unverändert lässt.

Beschränkungen

  • Wenn Sie vertikales Pod-Autoscaling mit horizontalem Pod-Autoscaling verwenden möchten, verwenden Sie das multidimensionale Pod-Autoscaling. Sie können auch vertikales Pod-Autoscaling mit horizontalem Pod-Autoscaling für benutzerdefinierte und externe Messwerte verwenden.
  • Vertikales Pod-Autoscaling ist aufgrund der eingeschränkten Sichtbarkeit der tatsächlichen Arbeitsspeichernutzung der Arbeitslast noch nicht bereit für die Verwendung mit JVM-Arbeitslasten.
  • Vertikales Pod-Autoscaling hat eine Standardeinstellung von mindestens zwei Replikaten für Deployments, um Pods durch überarbeitete Ressourcenwerte zu ersetzen. In GKE-Version 1.22 und höher können Sie diese Einstellung überschreiben. Geben Sie dazu im Feld PodUpdatePolicy einen Wert für das Feld minReplicas an.
  • Wenn Sie den InPlaceOrRecreate-Aktualisierungsmodus des vertikalen Pod-Autoscalings verwenden und eine In-Place-Aktualisierung nicht möglich ist (z. B. wenn der Pod über die Knotenkapazität hinaus skaliert wird), wird der Pod durch das vertikale Pod-Autoscaling entfernt und neu erstellt, um die Empfehlung anzuwenden. Das Entfernen und Neuerstellen erfolgt auch für Pods, für die in der Spezifikation das Feld resizePolicy festgelegt ist, um Neuerstellungen zu vermeiden. Dieses Verhalten tritt bei Autopilot-Größenänderungsanfragen auf, auch wenn Mindestressourcen und Einschränkungen für das CPU:Arbeitsspeicherverhältnis angewendet werden.
  • Für das vertikale Pod-Autoscaling ist ein Arbeitslastobjekt erforderlich, das die Pods verwaltet, z. B. ein Deployment, StatefulSet, ReplicaSet oder ReplicationController. Sie können vertikales Pod-Autoscaling nicht mit eigenständigen Pods verwenden, da ein Arbeitslastcontroller zum Verwalten des Prozesses zum Neuerstellen von Pods erforderlich ist.

Best Practices

  • Anzahl der VerticalPodAutoscaler-Objekte begrenzen: Um Unterbrechungen bei der Clusteraktualisierung zu vermeiden, sollten Sie die Anzahl der VerticalPodAutoscaler-Objekte pro Cluster unter 1.000 halten.
  • Vertikales Pod-Autoscaling funktioniert am besten mit homogenen Arbeitslasten mit langer Ausführungszeit.
    • Lang andauernd:Arbeitslasten, die mindestens 24 Stunden lang ausgeführt werden. Für vertikales Pod-Autoscaling ist eine erhebliche Menge an Verlaufsdaten erforderlich, um Empfehlungen mit hoher Zuverlässigkeit zu generieren. Im Modus Auto oder Recreate erfolgen Updates in der Regel, nachdem ein Pod mindestens 24 Stunden alt ist. So werden häufige Pod-Neustarts und ‑Churn vermieden.
    • Homogen:Pods, die auf ein einzelnes VerticalPodAutoscaler-Objekt ausgerichtet sind (z. B. alle Replikate in einem Deployment), sollten ähnliche Ressourcenverbrauchsmuster aufweisen. Der vertikale Pod-Autoscaler generiert Empfehlungen, indem er Nutzungsdaten für alle Ziel-Pods zusammenfasst. Wenn Ihre Replikate eine heterogene Nutzung aufweisen, z. B. einige Pods im Leerlauf sind und andere stark ausgelastet sind, kann das vertikale Pod-Autoscaling eine Empfehlung ausgeben, die die Leerlauf-Pods über- oder die ausgelasteten Pods unterprovisioniert.
  • Horizontales Pod-Autoscaling für Arbeitslasten mit plötzlichen Nachfragespitzen verwenden: Vertikales Pod-Autoscaling ist für die Größenanpassung im stabilen Zustand konzipiert und ist keine Lösung für plötzliche, kurzzeitige Ressourcenspitzen. Verwenden Sie für Arbeitslasten mit schnellen Schwankungen bei Traffic oder Bedarf an CPU oder Arbeitsspeicher stattdessen das horizontale Pod-Autoscaling.
  • OOM-Schutz nutzen: Der vertikale Pod-Autoscaler reagiert zwar, bietet aber automatischen Schutz vor Ereignissen, bei denen der Arbeitsspeicher nicht ausreicht (Out-of-Memory, OOM). Wenn ein Pod OOMKilled ist, beobachtet das vertikale Pod-Autoscaling das Ereignis sofort und erhöht die Arbeitsspeicherempfehlung um etwa 20% (oder 100 MB, je nachdem, welcher Wert größer ist), um die Stabilität zu verbessern, wenn der Pod neu erstellt wird. Weitere Informationen zu OOM-Ereignissen finden Sie unter OOM-Ereignisse beheben.

API-Referenz

Dies ist die Referenz zur API v1. Wir empfehlen dringend, diese Version der API zu verwenden.

VerticalPodAutoscaler v1 autoscaling.k8s.io

Felder

TypeMeta

API-Gruppe, Version und Art.
metadata

ObjectMeta

Standard-Objektmetadaten.
spec

VerticalPodAutoscalerSpec

Das Verhalten von VerticalPodAutoscaler.
status

VerticalPodAutoscalerStatus

Zuletzt beobachteter Status des VerticalPodAutoscaler.

VerticalPodAutoscalerSpec v1 autoscaling.k8s.io

Felder
targetRef

CrossVersionObjectReference

Verweist auf den Controller, der die Pods für den Autoscaler verwaltet, um beispielsweise ein Deployment oder ein StatefulSet zu steuern. Sie können einen VerticalPodAutoscaler auf jeden Controller mit einer Unterressource vom Typ Scale verweisen. Normalerweise ruft der VerticalPodAutoscaler den Pod-Satz vom ScaleStatus des Controllers ab. Bei einigen bekannten Controllern, zum Beispiel DaemonSet, ruft der VerticalPodAutoscaler den Pod-Satz von der Controller-Spezifikation ab.
updatePolicy

PodUpdatePolicy

Gibt an, ob empfohlene Aktualisierungen beim Start eines Pods angewendet werden und ob empfohlene Aktualisierungen während der Lebensdauer eines Pods angewendet werden.
resourcePolicy

PodResourcePolicy

Legt Richtlinien für das Anpassen der CPU- und Speicheranforderungen für einzelne Container fest. Mit der Ressourcenrichtlinie können Sie Einschränkungen für die Empfehlungen für einzelne Container festlegen. Wenn nicht angegeben, berechnet das Autoscaling empfohlene Ressourcen für alle Container im Pod ohne zusätzliche Beschränkungen.

recommenders

VerticalPodAutoscalerRecommenderSelector array

Der Recommender, der für das Generieren von Empfehlungen für dieses VPA-Objekt verantwortlich ist. Lassen Sie das Feld leer, um den von GKE bereitgestellten Standard-Recommender zu verwenden. Andernfalls kann die Liste genau einen Eintrag für einen vom Nutzer bereitgestellten alternativen Recommender enthalten. Unterstützt ab GKE 1.22.

VerticalPodAutoscalerList v1 autoscaling.k8s.io

Felder

TypeMeta

API-Gruppe, Version und Art.
metadata

ObjectMeta

Standard-Objektmetadaten.
items

VerticalPodAutoscaler array

Eine Liste mit VerticalPodAutoscaler-Objekten.

PodUpdatePolicy v1 autoscaling.k8s.io

Felder
updateMode

string

Gibt an, ob empfohlene Aktualisierungen beim Start eines Pods angewendet werden und ob empfohlene Aktualisierungen während der Lebensdauer eines Pods angewendet werden. Folgende Werte sind möglich:

  • "Off": Es werden empfohlene Updates generiert, die aber nicht automatisch auf den Pod angewendet werden.
  • "Initial": Empfohlene Aktualisierungen werden nur beim ersten Start eines Pods angewendet. Aktualisierungen, die erfolgen, während der Pod bereits ausgeführt wird, werden nicht automatisch angewendet.
  • "Recreate": Empfohlene Updates werden angewendet, indem der Pod neu erstellt wird. Der vorhandene Pod wird beendet und ein neuer Pod mit der aktualisierten Konfiguration wird erstellt.
  • "Auto": Der Standardwert, der im Wesentlichen den "Recreate"-Modus erzwingt.
  • "InPlaceOrRecreate": Empfohlene Aktualisierungen werden, sofern möglich, angewendet, ohne den Pod neu zu erstellen.
minReplicas

int32

Die Mindestanzahl von Replikaten, die aktiv sein müssen, um die Pod-Bereinigung auszuführen (ausstehende Prüfungen wie Budget für Pod-Störungen). Nur positive Werte sind zulässig. Die Standardeinstellung ist 2. Unterstützt ab GKE 1.22.

PodResourcePolicy v1 autoscaling.k8s.io

Felder
containerPolicies

ContainerResourcePolicy array

Eine Reihe von Ressourcenrichtlinien für einzelne Container. Es kann höchstens einen Eintrag für jeden benannten Container und optional einen einzelnen Platzhaltereintrag mit "containerName = '*'" geben, der alle Container abdeckt, die keine spezifischen Richtlinien haben.

ContainerResourcePolicy v1 autoscaling.k8s.io

Felder
containerName

string

Der Name des Containers, für den die Richtlinie gilt. Wenn keine Angabe erfolgt, dient die Richtlinie als Standardrichtlinie.
mode

ContainerScalingMode

Gibt an, ob empfohlene Aktualisierungen beim Start eines Containers angewendet werden und ob empfohlene Aktualisierungen während der Lebensdauer eines Containers angewendet werden. Mögliche Werte sind "Off" (Aus) und "Auto" (Automatisch). Der Standardwert ist „Automatisch“, wenn Sie keinen Wert angeben.
minAllowed

ResourceList

Gibt die minimalen CPU- und Speicheranforderungen an, die für den Container zulässig sind. Standardmäßig gilt kein Minimum.
maxAllowed

ResourceList

Gibt die maximalen CPU- und Speicheranforderungen an, die für den Container zulässig sind. Standardmäßig gibt es keine Obergrenze.
ControlledResources

[]ResourceName

Gibt den Typ der Empfehlungen an, die vom VerticalPodAutoscaler berechnet und gegebenenfalls angewendet werden. Wenn leer, wird der Standardwert [ResourceCPU, ResourceMemory] verwendet.

VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io

Felder
name

string

Name des Recommenders, der für die Generierung der Empfehlung für dieses Objekt verantwortlich ist.

VerticalPodAutoscalerStatus v1 autoscaling.k8s.io

Felder
recommendation

RecommendedPodResources

Die zuletzt empfohlenen CPU- und Speicheranforderungen.
conditions

VerticalPodAutoscalerCondition array

Beschreibt den aktuellen Status des VerticalPodAutoscaler.

RecommendedPodResources v1 autoscaling.k8s.io

Felder
containerRecommendation

RecommendedContainerResources array

Eine Reihe von Ressourcenempfehlungen für einzelne Container.

RecommendedContainerResources v1 autoscaling.k8s.io

Felder
containerName

string

Der Name des Containers, für den die Empfehlung gilt.
target

ResourceList

Die empfohlene CPU- und Speicheranforderung für den Container.
lowerBound

ResourceList

Die empfohlenen minimalen CPU- und Speicheranforderungen für den Container. Die angegebenen Ressourcenmengen gewährleisten keine stabile Ausführung der Anwendung. Die Ausführung mit geringeren CPU- und Speicheranforderungen hat wahrscheinliche erhebliche Auswirkungen auf Leistung oder Verfügbarkeit.
upperBound

ResourceList

Die empfohlenen maximalen CPU- und Speicheranforderungen für den Container. CPU- und Speicheranforderungen, die über diesen Werten liegen, führen wahrscheinlich zu einer Verschwendung von Ressourcen.
uncappedTarget

ResourceList

Die zuletzt vom Autoscaling berechnete Ressourcenempfehlung, die auf der tatsächlichen Ressourcennutzung basiert und die ContainerResourcePolicy nicht berücksichtigt. Wenn die tatsächliche Ressourcennutzung dazu führt, dass das Ziel gegen die ContainerResourcePolicy verstößt, kann dieser Wert von der begrenzten Empfehlung abweichen. Dieses Feld hat keinen Einfluss auf die tatsächliche Ressourcenzuweisung. Es wird nur als Statusangabe verwendet.

VerticalPodAutoscalerCondition v1 autoscaling.k8s.io

Felder
type

VerticalPodAutoscalerConditionType

Die Art des beschriebenen Zustands. Mögliche Werte sind "RecommendationProvided" (Empfehlung bereitgestellt), "LowConfidence" (Geringe Konfidenz), "NoPodsMatched" (Keine übereinstimmenden Pods) und "FetchingHistory" (Verlauf wird abgerufen).
status

ConditionStatus

Der Status des Zustands. Mögliche Werte sind "True" (Wahr), "False" (Falsch) und "Unknown" (Nicht bekannt).
lastTransitionTime

Time

Die letzte Statusänderung des Zustands.
reason

string

Der Grund für die letzte Statusänderung.
message

string

Ein menschenlesbarer String mit Details zur letzten Statusänderung.

Nächste Schritte