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 hat und welche Best Practices für die Verwendung gelten. Außerdem erhalten Sie Zugriff auf die API-Referenzen für die benutzerdefinierte Ressource „VerticalPodAutoscaler“ 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.

Wenn Sie eine schnelle Skalierung als Reaktion auf eine plötzliche Ressourcennutzung benötigen, 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-Autoscalings

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.
• Die Wartungszeit wird reduziert, 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 Google Kubernetes Engine (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 zum Open-Source-VerticalPodAutoscaler von Kubernetes

Das vertikale Pod-Autoscaling in GKE basiert auf der Open-Source-Kubernetes-API VerticalPodAutoscaler, ist aber eine separate Implementierung, die nur in GKE verfügbar ist. Die GKE-Implementierung ist mit einem eigenen Recommender auf Skalierbarkeit ausgelegt, behält aber die gleichen 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 entfernt das vertikale Pod-Autoscaling einen Pod, wenn die Ressourcenanfragen des Pods geändert werden müssen. Die Bereinigung ist erforderlich, da die Ressourcenanfragen eines aktiven Pods aufgrund von Kubernetes-Einschränkungen in Versionen vor 1.33 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 Ressourcenanfragen nur bei der Pod-Erstellung zu und ändert sie später nie mehr.

InPlaceOrRecreate-Modus

Der Modus InPlaceOrRecreate soll Dienstunterbrechungen reduzieren, indem versucht wird, Pod-Ressourcen zu aktualisieren, ohne den Pod neu zu erstellen.

Wenn Sie den InPlaceOrRecreate-Modus verwenden möchten, setzen Sie das Feld spec.updatePolicy.updateMode in Ihrem VerticalPodAutoscaler-Objekt auf "InPlaceOrRecreate". In diesem Modus wird anhand des Felds resizePolicy in Ihrem Arbeitslastmanifest ermittelt, ob eine Ressourcenänderung einen Neustart erfordert. Wenn das Feld resizePolicy nicht definiert ist, wird standardmäßig NotRequired für CPU und Arbeitsspeicher verwendet. Das bedeutet, dass direkte 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. Bei der anschließenden Neuerstellung des Pods, die durch den Absturz ausgelöst wird, wendet das vertikale Pod-Autoscaling eine Empfehlung an, die einen Sicherheitspuffer enthält (normalerweise 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 InPlaceOrRecreate-Modus

Wenn das vertikale Pod-Autoscaling feststellt, dass ein direktes Update nicht möglich ist, wird auf das Verhalten des Recreate-Modus zurückgegriffen. Dabei wird der Pod entfernt und neu erstellt, um die Änderungen anzuwenden. Häufige Szenarien, in denen das vertikale Pod-Autoscaling auf die Neuerstellung zurückgreift:

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

Off-Modus

Im Modus Off werden durch vertikales Pod-Autoscaling keine Änderungen automatisch auf einen Pod angewendet. Sie können weiterhin empfohlene Werte für die Anfragen und Limits für CPU und Arbeitsspeicher basierend auf der bisherigen Nutzung aufrufen. Diese Empfehlungen werden jedoch nicht für Sie angewendet. Sie können die empfohlenen Werte bei Bedarf manuell auf Ihre Pods anwenden.

CPU-Boost beim Starten

Der CPU-Boost beim Start beschleunigt den Start von Anwendungen und verbessert die Kosteneffizienz, indem die CPU-Anfragen während der Initialisierung vorübergehend erhöht und dann direkt wieder auf das Ausgangsniveau zurückgesetzt werden.

Weitere Informationen zum Konfigurieren des CPU-Boosts beim Starten finden Sie unter Anwendungsstart mit CPU-Boost beim Starten beschleunigen.

Funktionsweise des CPU-Boosts beim Starten

Beim CPU-Start-Boost wird eine temporäre Ressourcenerhöhung basierend auf der CPU-Anfrage des Containers berechnet. Der Pod kehrt nach der Startphase zu diesem Baseline-Anforderungsniveau zurück.

Durch die Erhöhung wird diese Baseline-Anfrage entweder um einen Multiplikator oder um eine feste Menge erhöht. Diese erhöhte Anfrage bleibt aktiv, bis der Pod bereit ist. Danach setzt GKE die CPU-Anfrage auf den ursprünglichen Wert zurück.

Informationen zum Lebenszyklus von Boosts

Der Start-Boost-Prozess besteht aus drei Phasen:

1. Zulassungsphase: Während der Pod-Zulassung fängt der VPA-Zulassungs-Webhook die Anfrage ab und fügt die erhöhten CPU-Werte ein, bevor GKE den Pod plant.
2. Startphase: Die Anwendung wird mit der vorübergehend erhöhten CPU-Zuweisung initialisiert, um eine Drosselung der Initialisierung zu vermeiden.
3. Unboosting-Phase: Nachdem der Pod den Status Ready erreicht hat und der Zeitraum durationSeconds abgelaufen ist, skaliert VPA die CPU-Anfrage direkt auf den Basiswert herunter.

Aktualisierungsmodus für optimierte Arbeitslasten auswählen

Sie können den CPU-Boost beim Start mit oder ohne kontinuierliche Ressourcenverwaltung des VPA konfigurieren. Durch die kontinuierliche Ressourcenverwaltung des VPA werden Ihre Pod-Ressourcenanfragen nach dem Ende der Startphase automatisch angepasst. Legen Sie dazu das Feld updateMode im VPA-Objekt fest. Weitere Informationen zu VPA-Aktualisierungsmodi finden Sie unter Modi für vertikales Pod-Autoscaling.

• updateMode: "Off": Der VPA verwaltet nur den anfänglichen Boost während der Pod-Zulassung (eine Phase bei der Pod-Erstellung) und die anschließende Herunterskalierung nach dem Start. Die Ressourcenanfragen des Containers im stabilen Zustand werden nicht geändert.
• updateMode: "Auto", "Recreate" oder "InPlaceOrRecreate": VPA verwaltet den Start-Boost und passt die Ressourcenanfragen Ihres Pods weiterhin automatisch basierend auf der laufenden Nutzung an.

So wird die Ressourcenzuweisung für den CPU-Boost berechnet

Die GKE berechnet die vorübergehend erhöhte CPU-Anfrage so:

1. Basis-CPU ermitteln: Die CPU-Basisanfrage hängt vom VPA-Feld updateMode ab:

   • Auto, Recreate oder InPlaceOrRecreate: Die Baseline-CPU-Anfrage ist die VPA-Empfehlung. Wenn keine Empfehlung vorhanden ist, greift GKE auf die in der Pod-Spezifikation definierte CPU-Anfrage zurück.
   • Off: Die CPU-Anfrage-Baseline ist der Anfragewert aus der Pod-Spezifikation.

2. Berechnen Sie die erhöhte CPU: Die Berechnung hängt von der Berechnungsmethode ab, die Sie im Feld type der Boost-Konfiguration angeben:

   • Factor: Wendet einen Multiplikator auf die CPU-Basisanfrage an:

     Geboostete CPU  =  Basis-CPU × factor

   • Quantity: Fügt der CPU-Basisanfrage eine absolute CPU-Menge hinzu:

     Geboostete CPU  =  Basis-CPU + quantity

Die endgültige CPU-Anfrage hängt vom Clustermodus ab:

• Standardcluster: Die endgültige CPU-Anfrage ist der optimierte CPU-Wert.
• Autopilot-Cluster: Die endgültige CPU-Anfrage ist der erhöhte CPU-Wert, der durch die maximal zulässige CPU für den zugewiesenen Pod-Arbeitsspeicher begrenzt ist.

Verhalten des CPU-Limits während eines Boosts

Wie GKE CPU-Limits verarbeitet, hängt von der Einstellung controlledValues in Ihrer containerResourcePolicy ab:

• RequestsAndLimits (Standard): GKE erhöht sowohl die CPU-Anfrage als auch das CPU-Limit und behält das ursprüngliche Verhältnis bei, um die Quality of Service (QoS)-Klasse des Containers beizubehalten.
• RequestsOnly: GKE erhöht nur die CPU-Anfrage. Die GKE begrenzt die hochgestufte Anfrage knapp unter dem definierten CPU-Limit, um die Dienstqualität aufrechtzuerhalten.

Hinweise zu Autopilot-Clustern

Da GKE Autopilot bestimmte CPU-zu-Arbeitsspeicher-Verhältnisse und Mindest-Pod-Größen erzwingt, prüft GKE die Boosts während der Pod-Zulassung, um die Compliance sicherzustellen. In den folgenden Szenarien kann ein Boost geändert oder ignoriert werden:

• Autopilot-Mindestwerte: Wenn die hochgestufte Anfrage unter den Mindest-CPU-Anforderungen für Autopilot-Arbeitslasten liegt (z. B. 50 m für Pods für allgemeine Zwecke), wendet GKE die Hochstufung nicht an und erzwingt die Standardmindestwerte.
• Verhältnisbegrenzung (teilweise oder übersprungene Boosts): Wenn die geboostete CPU-Anfrage den erforderlichen CPU-zu-Arbeitsspeicher-Verhältnisbereich überschreiten würde, begrenzt GKE den Boost auf den höchsten Wert, der den zugewiesenen Arbeitsspeicher berücksichtigt. Wenn die ursprüngliche Pod-Anfrage bereits das maximal zulässige CPU-zu-Arbeitsspeicher-Verhältnis verwendet, überspringt GKE den Boost, um eine Größenänderung des Arbeitsspeichers zu vermeiden.
• Scale-Out-ComputeClass: Die Scale-Out-ComputeClass erzwingt ein striktes Verhältnis von 1:4 (CPU:Arbeitsspeicher). Wenn Sie versuchen, die CPU eines Pods mit horizontaler Skalierung zu erhöhen, ohne den Arbeitsspeicher zu erhöhen, kann es sein, dass GKE die Erhöhung ignoriert.

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 Limit liegt. Dieses Limit ist nützlich, da es dazu beiträgt, ein grundlegendes Leistungsniveau zu gewährleisten oder anwendungsspezifische Anforderungen zu erfüllen.
• maxAllowed: Das vertikale Pod-Autoscaling empfiehlt keinen Wert, der über diesem Limit liegt. 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. Im Feld controlledResources können Sie angeben, welche Ressourcen automatisch skaliert werden sollen. Sie können das Autoscaling beispielsweise so konfigurieren, dass nur Empfehlungen für den Arbeitsspeicher bereitgestellt werden und CPU-Anfragen unverändert bleiben.

Beschränkungen

• Wenn Sie vertikales Pod-Autoscaling mit horizontalem Pod-Autoscaling für die CPU verwenden möchten, verwenden Sie die HPA-Größenanpassung mit VPA (Vorabversion) oder 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.
• In GKE-Version 1.35.1 und früher hat das vertikale Pod-Autoscaling eine Standardeinstellung von mindestens zwei Replikaten für Deployments, um Pods durch überarbeitete Ressourcenwerte zu ersetzen. In Version 1.35.2 und höher ist die Standardeinstellung ein Mindestreplikat. In 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 Aktualisierungsmodus InPlaceOrRecreate des vertikalen Pod-Autoscalings verwenden und eine direkte 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. Die Bereinigung und Neuerstellung erfolgt auch für Pods, für die in ihrer Spezifikation ein resizePolicy-Feld festgelegt ist, um Neuerstellungen zu vermeiden. Dieses Verhalten tritt bei Autopilot-Anfragen zur Größenanpassung auf, einschließlich bei der Anwendung von Mindestressourcen und Einschränkungen des CPU:Arbeitsspeicher-Verhältnisses.
• 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 das vertikale Pod-Autoscaling nicht mit eigenständigen Pods verwenden, da ein Arbeitslast-Controller erforderlich ist, um den Prozess der Pod-Neuerstellung zu verwalten.
• Vertikales Pod-Autoscaling generiert Empfehlungen für Ressourcenanfragen und -limits auf Containerebene (spec.containers[].resources) und wendet Aktualisierungen darauf an. Vertikales Pod-Autoscaling unterstützt keine Ressourcenspezifikationen auf Pod-Ebene (spec.resources).

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 laufend: Arbeitslasten, die mindestens 24 Stunden lang ausgeführt werden. Für das vertikale Pod-Autoscaling ist eine erhebliche Menge an Verlaufsdaten erforderlich, um Empfehlungen mit hoher Konfidenz zu generieren. Im Modus Auto oder Recreate erfolgen Aktualisierungen in der Regel, wenn ein Pod mindestens 24 Stunden alt ist. Dadurch werden häufige Pod-Neustarts und Abwanderung verhindert.
  • Homogen: Pods, die von einem einzelnen VerticalPodAutoscaler-Objekt (z. B. alle Replikate in einem Deployment) angesprochen werden, sollten ähnliche Ressourcenverbrauchsmuster aufweisen. Der vertikale Pod-Autoscaler generiert Empfehlungen, indem er Nutzungsdaten aller Ziel-Pods aggregiert. Wenn Ihre Replikate eine heterogene Nutzung haben, z. B. wenn einige Pods inaktiv sind und andere stark ausgelastet sind, kann das vertikale Pod-Autoscaling eine Empfehlung geben, die die inaktiven Pods überdimensioniert oder die ausgelasteten Pods unterdimensioniert.
• Verwenden Sie horizontales Pod-Autoscaling für Arbeitslasten mit plötzlichen Nachfragespitzen. Vertikales Pod-Autoscaling ist für die Größenanpassung im stabilen Zustand konzipiert und keine Lösung für plötzliche, kurzlebige Ressourcenspitzen. Verwenden Sie für Arbeitslasten mit schnellen Schwankungen beim Traffic oder bei der Nachfrage nach CPU oder Arbeitsspeicher stattdessen das horizontale Pod-Autoscaling.
• OOM-Schutz nutzen. Obwohl der vertikale Pod-Autoscaler reaktiv ist, bietet er automatisierten Schutz vor Out-of-Memory-Ereignissen (OOM). Wenn ein Pod OOMKilled ist, beobachtet das vertikale Pod-Autoscaling das Ereignis sofort und erhöht die Speicherempfehlung 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 v1-API-Referenz. 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 des 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 die Generierung 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": Empfohlene Updates werden generiert, aber nicht automatisch auf den Pod angewendet. "Initial": Empfohlene Updates werden nur angewendet, wenn ein Pod zum ersten Mal gestartet wird. Updates, die während der Ausführung des Pods erfolgen, werden nicht automatisch angewendet. "Recreate": Empfohlene Updates werden durch Neuerstellen des Pods angewendet. 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 Updates werden nach Möglichkeit 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. Der Standardwert ist 1 in GKE-Version 1.35.2 und höher und 2 in Version 1.35.1 und niedriger. 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
containerRecommendations	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

• Vertikales Pod-Autoscaling konfigurieren
• HPA-Arbeitslasten mit VPA optimieren
• Anwendungsstart mit CPU-Start-Boost beschleunigen
• Weitere Informationen zum horizontalen Pod-Autoscaling
• Weitere Informationen zu Cluster Autoscaler