Smarteres Autoscaling in GKE – jenseits von CPU und Speicher

Autoscaling in Kubernetes basiert in der Regel auf dem Horizontal Pod Autoscaler (HPA). Standardmäßig skaliert der HPA Workloads anhand der Ressourcenauslastung – also CPU oder Speicher. Für viele Workloads funktioniert das gut, doch es spiegelt nicht immer den tatsächlichen Bedarf einer Anwendung wider.

Beispiele:

• Eine Web-API kann unter hoher Anfragelast stehen, ohne dass die CPU-Auslastung ansteigt.
• Ein Queue-Processing-Service braucht mehr Worker, sobald der Backlog wächst.
• KI-Inferenz-Workloads hängen oft stärker von der GPU- als von der CPU-Auslastung ab.
• Streaming-Dienste müssen anhand der Requests pro Sekunde skalieren.

Solche Szenarien verlangen nach Skalierung auf Basis von Anwendungs-Metriken statt Infrastruktur-Metriken.

Kubernetes unterstützt zwar Autoscaling über Custom Metrics, doch in der Vergangenheit waren dafür zusätzliche Komponenten nötig:

• Prometheus-Adapter – ein separates Deployment, das Prometheus-Metriken an die Kubernetes Metrics API anbindet
• Custom-Metric-Pipelines – Ingestion-, Storage- und Query-Schichten zwischen Anwendung und HPA
• Komplexe IAM- und Service-Account-Konfiguration – insbesondere in Managed-Umgebungen wie GKE

Quelle: Gemini Nano Banana Pro

Der operative Aufwand für diese Komponenten war erheblich: Teams mussten die Adapter-Kompatibilität über Kubernetes-Versionen hinweg pflegen, mehrstufige Metrik-Pipelines debuggen und Latenzen aus den Infrastrukturschichten kompensieren. Diese Reibungsverluste bremsten die Adoption – viele Teams kehrten am Ende zur CPU-basierten Skalierung zurück.

GKE bietet jetzt eine native Integration zur Bereitstellung von Custom Metrics und vereinfacht damit, wie Anwendungen Metriken an das Autoscaling-System übergeben. Statt Metriken über externe Adapter und Monitoring-Systeme zu leiten, werden sie nun direkt aus den Pods erfasst und an den HPA weitergegeben.

So kann das Autoscaling-System auf das tatsächliche Anwendungsverhalten reagieren – etwa auf Request-Durchsatz oder Ressourcennutzung. Anwendungs-Metriken in Skalierungsstrategien einzubinden, wird damit deutlich einfacher.

Quelle: Gemini Nano Banana Pro

Das neue Feature basiert auf einer Ressource namens AutoscalingMetric.

Diese Ressource definiert:

• welche Pods die Metriken bereitstellen (über Label-Selektoren)
• wo der Metrik-Endpoint liegt (Port und Pfad)
• welche konkrete Metrik erfasst werden soll
• wie die Metrik an das Autoscaling-System exportiert wird

Sobald sie definiert ist, erfasst GKE die Metriken und stellt sie Komponenten wie dem Load Balancer oder dem Autoscaler zur Verfügung.

Wesentliche Voraussetzungen:

• Metriken müssen über einen HTTP-Endpoint verfügbar sein.
• Das Format muss dem Prometheus-Standard entsprechen.
• Es werden ausschließlich Gauge-Metriken unterstützt.
• Pro Cluster lassen sich maximal 20 eindeutige Metriken bereitstellen.

Gauge vs. andere Metriktypen: Eine Gauge bildet einen Wert ab, der jederzeit steigen oder fallen kann (z. B. aktuelle Queue-Länge = 45). Counter steigen ausschließlich (z. B. insgesamt verarbeitete Requests = 10.432) und eignen sich daher nicht direkt als Autoscaling-Ziel. Wenn Ihre Anwendung aktuell Counter bereitstellt, müssen Sie daraus eine Gauge ableiten (z. B. eine berechnete Request-Rate), bevor Sie sie mit diesem Feature nutzen können.

Sobald die Metrik registriert ist, liest GKE sie kontinuierlich aus und speist den Wert in die Skalierungslogik ein.

Gehen wir ein vollständiges, in sich geschlossenes Beispiel durch.

Szenario: Ein Background-Worker-Service verarbeitet Jobs aus einer Queue. Wir wollen die Anzahl der Worker-Pods anhand der aktuellen Queue-Länge skalieren – nicht anhand der CPU-Auslastung.

Schritt 1: Metrik aus der Anwendung bereitstellen

Deployen Sie Ihre Anwendung so, dass sie am Endpoint /metrics eine Gauge-Metrik im Prometheus-Format bereitstellt:

# HELP job_queue_length Current number of jobs waiting in the queue
# TYPE job_queue_length gauge
job_queue_length 45

Wir gehen davon aus, dass die Metriken unter http://worker-service:9090/metrics verfügbar sind.

Schritt 2: AutoscalingMetric-Ressource anlegen

Definieren Sie eine AutoscalingMetric-Ressource, die GKE mitteilt, wo die Metrik zu finden ist und wie sie exportiert werden soll:

apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: worker-queue-metric
  namespace: default
spec:
  selector:
    matchLabels:
      app: job-worker #The label name and value matching the Pods
  endpoints:
  - port: 9090 #The metrics port number
    path: /metrics #The path to the metric
    metrics:
    - gauge:
      name: job_queue_length #The name of the metric that you are exposing.
      prometheusMetricName: job_queue_length #optional: The Prometheus metric name as exposed by the Pod.

Nach dem Anwenden steht die Metrik dem Autoscaling-System zur Verfügung.

Jetzt legen wir einen HPA an, der die Custom Metric verwendet.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: job-worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: autoscaling.gke.io|worker-queue-metric|queue_utilization
      target:
        type: AverageValue
        averageValue: 20

Diese Konfiguration bedeutet:

• Übersteigt die durchschnittliche Queue-Größe 20 Jobs pro Pod, skaliert das System hoch.
• Schrumpft die Queue, skaliert das System herunter.

Dieses Feature bringt mehrere zentrale Vorteile mit sich.

• Anwendungsorientiertes Skalieren: Skalierungsentscheidungen orientieren sich am tatsächlichen Bedarf statt an Infrastruktur-Hilfsgrößen.
• Geringere operative Komplexität: Keine externen Adapter und keine aufwendigen Metrik-Pipelines mehr.
• Bessere Performance: Anwendungen skalieren präziser und reagieren schneller auf Lastspitzen.
• Effizientere Ressourcennutzung: Die Infrastrukturkosten sinken, weil die Skalierung dem realen Bedarf folgt.
• Flexible Autoscaling-Strategien: Teams können Policies rund um jede Gauge-Metrik bauen, die ihre Anwendung bereitstellt – Queue-Tiefe, aktive Sessions, ausstehende Renderings und vieles mehr.