Schluss mit Over-Provisioning für den Start: GKEs neuer CPU Startup Boost

Der Zielkonflikt: Startgeschwindigkeit vs. ungenutzte Ressourcen

Jedes Team, das schwergewichtige, latenzkritische Workloads auf Kubernetes betreibt, muss sich zwischen zwei frustrierenden Kompromissen entscheiden:

Für den Start dimensionieren – und dauerhaft dafür zahlen. Sie setzen den CPU-Request hoch genug an, um die Initialisierung schnell zu durchlaufen, obwohl die App im warmen Zustand nur minimale CPU benötigt. Dieser Request bleibt rund um die Uhr bestehen. Anhand dieses Werts platziert der Scheduler den Pod, entscheidet der Cluster Autoscaler, ob neue Nodes hinzukommen – und danach richtet sich Ihre Rechnung. Über einige hundert Replicas hinweg summiert sich der Kompromiss zwischen schnellerem Start und dauerhafter Verschwendung schnell.

Für den Steady State dimensionieren – und beim Start leiden. Sie setzen den Request passend zur tatsächlichen Laufzeitnutzung und nehmen in Kauf, dass jeder Neustart, jedes Rolling Deployment und jedes Node-Upgrade eine zähe Angelegenheit bis zur Readiness bedeutet. Unter CPU-Throttling kann sich ein JVM-Warm-up, das eigentlich 5 Sekunden dauern sollte, auf 30 Sekunden oder mehr ziehen. Das heißt: langsamere Rollouts, langsameres Scale-out bei HPA-Events und potenzielle Latenzspitzen für Ihre Nutzer.

Keine der beiden Optionen ist wirklich akzeptabel. CPU Startup Boost wurde entwickelt, um genau diese Lücke zu schließen.

Welches Problem CPU Startup Boost tatsächlich löst

CPU Startup Boost ist eine neue Funktion des Vertical Pod Autoscaler (VPA) von GKE, die sich derzeit in der Preview befindet. Sie ermöglicht es, den CPU-Request eines Containers während der Pod-Initialisierung temporär zu erhöhen und ihn anschließend automatisch auf die Baseline zurückzusetzen – ohne den Container neu zu starten.

Ressourcenhungrige Laufzeitumgebungen (Java, Node.js und Python mit umfangreichen Imports) erhalten den nötigen CPU-Spielraum nur dann, wenn sie ihn wirklich brauchen: während der Initialisierung. Ihr Baseline-Request kann so die tatsächliche Steady-State-Nutzung widerspiegeln, statt ein Kompromiss zu sein, der für die ersten Sekunden im Leben eines Pods aufgebläht wurde. Da das Herunterskalieren vom Boost auf die Baseline über Kubernetes' In-Place Pod Resize (IPPR) erfolgt statt über Eviction und Neuerstellung des Pods, läuft der Container die ganze Zeit weiter.

Das funktioniert parallel zur üblichen Aufgabe des VPA, langfristige Ressourcendimensionierungen zu empfehlen und anzuwenden. Der Startup Boost ist letztlich nur ein kurzlebiges Override, das auf der Baseline aufsetzt, die der VPA (oder Sie selbst) bereits festgelegt hat.

So funktioniert es – und so konfigurieren Sie es

Die vollständige Anleitung finden Sie hier: Accelerate application startup with CPU startup boost.

CPU Startup Boost wird definiert, indem Sie Ihrem VerticalPodAutoscaler-Objekt einen startupBoost-Block hinzufügen. Sie können ihn auf Pod-Ebene anwenden, sodass jeder Container denselben Boost erhält, oder auf Container-Ebene, um gezielt einzelne Container zu boosten oder sie von einem Pod-weiten Boost auszunehmen.

Der Boost greift ausschließlich bei der Pod-Erstellung. Startet ein Container später neu – etwa nach einem OOMKill, während der Pod selbst weiterläuft –, wird der Boost nicht erneut angewendet. Der Admission Webhook, der den Boost injiziert, läuft nur bei der initialen Pod-Admission.

Der Boost-Typ kann ein Multiplikator oder eine feste Menge sein. type: "Factor" skaliert den Baseline-CPU-Request mit einem Multiplikator (factor: 2 verdoppelt ihn); type: "Quantity" addiert eine feste CPU-Menge zur Baseline.

Der Boost funktioniert gemeinsam mit den Update-Modi des VPA, nicht anstelle davon. Führen Sie ihn mit updateMode: "Off" aus, wenn Sie nur das Boost-Verhalten und nichts weiter möchten, oder kombinieren Sie ihn mit updateMode: "InPlaceOrRecreate", wenn der VPA die Ressourcen zusätzlich auf Basis der laufenden Nutzung anpassen soll.

Für einen Boost auf Pod-Ebene nutzen Sie eine der folgenden Optionen.

Boost auf Pod-Ebene, VPA-Anpassungen deaktiviert

Verwenden Sie diese Variante, wenn Sie ausschließlich den Boost möchten – der VPA wendet keine weiteren Ressourcenempfehlungen an.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Jeder Container im Pod erhält für die ersten 10 Sekunden nach Erreichen von Ready das Doppelte seines Baseline-CPU-Requests; anschließend skaliert GKE ihn in-place wieder herunter.

Boost auf Pod-Ebene mit laufendem VPA-Management

Verwenden Sie diese Variante, wenn Sie sowohl den Startup Boost als auch anschließend kontinuierliches In-Place-Right-Sizing der Ressourcen möchten.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Gleiches Boost-Verhalten, aber mit updateMode: "InPlaceOrRecreate" empfiehlt und wendet der VPA über die gesamte Lebensdauer des Pods weiterhin Ressourcenänderungen an – zunächst per In-Place-Resize und erst als Fallback per Neuerstellung.

Boost auf Container-Ebene, gezielt für einen Container

Nützlich, wenn ein Deployment einen Sidecar- oder Utility-Container enthält, der den CPU-Schub beim Start nicht benötigt. Über resourcePolicy.containerPolicies beschränken Sie den Boost auf genau den Container, der ihn braucht.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

Hier erhält boosted-container-name während des Starts 2 zusätzliche vCPUs auf seinen Baseline-Request – eine feste Menge statt eines Multiplikators.

Einen Container von einem Pod-weiten Boost ausnehmen

Der umgekehrte Fall: Ein Boost auf Pod-Ebene ist gesetzt, aber ein Container soll nicht mit geboostet werden.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

Der Pod-weite Boost wendet standardmäßig einen Faktor von 2 auf alle Container an, aber die Container-Policy überschreibt das für den genannten Container mit einem Faktor von 1.