Wie Kubernetes Container-Skalierung und Lastverteilung verwaltet

Mastering Kubernetes Scaling und Load Balancing

Bei der Bereitstellung containerisierter Anwendungen in der Produktion sind die beiden kritischsten operativen Herausforderungen, sicherzustellen, dass Ihr System schwankende Verkehrsanforderungen bewältigen kann und eine hohe Verfügbarkeit ohne manuelles Eingreifen aufrechterhalten wird. Kubernetes, die De-facto-Container-Orchestrierungsplattform, löst diese Herausforderungen mit einer ausgeklügelten Suite von Steuerungen, die sowohl das Skalieren als auch die Verkehrsverteilung automatisieren, aber viele Teams haben Schwierigkeiten, über grundlegende Konfigurationen hinauszugehen. Durch das Verständnis der zugrunde liegenden Mechanismen, wie Kubernetes das Skalieren von Containern und das Load Balancing verwaltet, können Sie widerstandsfähige Systeme entwerfen, die sich in Echtzeit an die Nachfrage anpassen, während Sie die Ressourcenkosten optimieren und einzelne Ausfallpunkte eliminieren.

Was Sie lernen werden

Sie werden die Kontrollschleifen, Metrikpipelines und Netzwerkproxys verstehen, die das automatische Skalieren und die Serviceerkennung von Kubernetes antreiben, und am Ende werden Sie in der Lage sein, Skalierungsengpässe zu diagnostizieren, die richtige Load-Balancing-Strategie für Ihre Arbeitslast auszuwählen und produktionsreife Konfigurationen zu implementieren, die plötzliche Verkehrsspitzen ohne Ausfallzeiten bewältigen. Die wichtigste Erkenntnis ist, dass effektives Skalieren in Kubernetes eine ganzheitliche Sichtweise erfordert, bei der Horizontal Pod Autoscaler, Cluster Autoscaler und Service-Mesh-Komponenten zusammenarbeiten, nicht als isolierte Funktionen.

Die zwei Säulen: Horizontales Skalieren und Service-Load-Balancing

Kubernetes nähert sich der Elastizität durch zwei komplementäre Mechanismen: Skalieren der Anzahl der Anwendungsreplikate (Pods) und Verteilen des Netzwerkverkehrs auf diese Replikate. Die Steuerungsebene bewertet kontinuierlich Ressourcenmetriken und benutzerdefinierte Indikatoren, um zu entscheiden, wann Pods hinzugefügt oder entfernt werden sollen, während die Datenebene eine virtuelle IP-basierte Serviceabstraktion verwendet, um Anfragen an gesunde Endpunkte weiterzuleiten. Diese Trennung der Belange – Skalierungsentscheidungen, die von Controllern verwaltet werden, und Verkehrsweiterleitung, die von kube-proxy oder Service-Mesh-Seitenwagen verwaltet wird – ermöglicht es jedem Subsystem, sich unabhängig zu entwickeln, obwohl sie in der Praxis tief voneinander abhängig sind.

Wie der Horizontal Pod Autoscaler funktioniert

Der Horizontal Pod Autoscaler (HPA) ist die primäre Engine dafür, wie Kubernetes das Skalieren von Containern und das Load Balancing auf Pod-Ebene verwaltet. Der HPA arbeitet als Kontrollschleife, die regelmäßig den Metrikserver abfragt (typischerweise den Kubernetes Metrics Server für Ressourcenmetriken oder einen benutzerdefinierten Metrikadapter für anwendungsspezifische Signale) und die beobachteten Werte mit den gewünschten Zielen vergleicht. Für CPU-basiertes Skalieren berechnet der Algorithmus die gewünschte Replikatanzahl mit der Formel:

desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))

Diese einfache proportionale Steuerung funktioniert gut für gleichmäßige Arbeitslasten, kann aber zu Oszillationen führen, wenn die Metrik schnell schwankt. Um dies zu mildern, enthält der HPA Stabilisierungsfunktionen – standardmäßig vermeidet er das Herunterskalieren für fünf Minuten und skaliert nur nach einem Fenster von 3-15 Sekunden hoch, abhängig von der Konfiguration – um ein Hin- und Herpendeln zu verhindern. Laut der offiziellen Kubernetes-Dokumentation trifft der HPA-Controller Skalierungsentscheidungen basierend auf dem arithmetischen Mittel der Pod-Metriken, was bedeutet, dass ein einzelner heißer Pod den Durchschnitt verzerren und unnötige Hochskalierungen auslösen kann (Kubernetes SIG-Autoscaling, 2023).

Benutzerdefinierte und externe Metriken für erweitertes automatisches Skalieren

Ressourcenbasiertes Skalieren (CPU und Speicher) ist oft unzureichend für moderne Microservices, die Engpässe in der Nachrichtenwarteschlangentiefe, Datenbankverbindungspools oder Anforderungslatenz aufweisen. Kubernetes adressiert dies durch die Custom Metrics API und External Metrics API, die es dem HPA ermöglichen, Metriken von Prometheus, Datadog oder Cloud-Provider-Überwachungssystemen zu konsumieren. Beispielsweise kann eine Kafka-Consumer-Bereitstellung basierend auf dem Lag der Consumer-Group-Offsets skalieren, sodass die Verarbeitungskapazität dem eingehenden Datenvolumen entspricht, unabhängig von der CPU-Auslastung. Eine Studie von 2022, veröffentlicht in IEEE Transactions on Cloud Computing, ergab, dass benutzerdefiniertes metrikbasiertes automatisches Skalieren die Tail-Latenz um 42 % im Vergleich zu rein CPU-basiertem Skalieren in ereignisgesteuerten Architekturen reduzierte, obwohl eine sorgfältige Abstimmung der Metrik-Erfassungsintervalle erforderlich war (Chen et al., 2022). Wenn Sie benutzerdefinierte Metriken implementieren, stellen Sie sicher, dass Ihr Metrikadapter Daten mit ausreichender Granularität bereitstellt – eine Abtastung alle 30 Sekunden ist eine übliche Baseline, während Hochfrequenzhandelssysteme eine Auflösung von 5 Sekunden erfordern können.

Cluster Autoscaler und Knotenebenen-Skalierung

Während der HPA die Anzahl der Pods anpasst, passt der Cluster Autoscaler die Anzahl der Worker-Knoten in der zugrunde liegenden Cloud-Infrastruktur an. Diese zweistufige Hierarchie erzeugt eine Abhängigkeitskette: Der Cluster Autoscaler löst nur dann Knotenhinzufügungen aus, wenn nicht geplante Pods aufgrund unzureichender Ressourcen ausstehen, und entfernt Knoten, wenn sie nicht ausgelastet sind und alle ihre Pods anderswo neu geplant werden können. Die offizielle Cluster-Autoscaler-FAQ stellt fest, dass Knotenskalierungsentscheidungen mit einem Stabilisierungsfenster von 10 Minuten getroffen werden, um häufige Größenänderungen zu vermeiden, was problematisch für Arbeitslasten mit plötzlichen, anhaltenden Spitzen sein kann, da die kombinierte Verzögerung (HPA-Hochskalieren von Pods + Cluster Autoscaler-Bereitstellung von Knoten + Knoten-Bootstrapping) in vielen Cloud-Umgebungen fünf Minuten überschreiten kann. Für latenzempfindliche Anwendungen sollten Sie die Verwendung von Knotenpools mit vorab bereitgestellter Reservekapazität oder die Implementierung von proaktivem Skalieren basierend auf prognostizierter Nachfrage in Betracht ziehen – eine Technik, die im Forschungspapier „Proactive Autoscaling for Kubernetes“ (arXiv:2301.04567, 2023) untersucht wurde, das eine 30%ige Reduzierung der Skalierungslatenz unter Verwendung von Vorhersagemodellen demonstrierte.

Verkehrsweiterleitung: Die Service-Abstraktion und kube-proxy

Das Skalieren von Pods ist nur die halbe Lösung; Sie müssen auch eingehenden Verkehr auf die richtige Gruppe gesunder Replikate verteilen. Jedes Kubernetes Service-Objekt fungiert als stabiler interner Load Balancer und bietet eine feste IP-Adresse und einen DNS-Namen, der die dynamischen Pod-Endpunkte abstrahiert. Die Standardimplementierung verwendet kube-proxy, das auf jedem Knoten läuft und iptables- oder IPVS-Regeln verwaltet, die Service-IPs in tatsächliche Pod-IPs übersetzen. Im iptables-Modus erstellt jeder Service eine probabilistische Kette von Regeln – die Wahrscheinlichkeitsverteilung ist proportional zum Gewicht jedes Pods, was effektiv ein Round-Robin-Load-Balancing bewirkt. Der iptables-Ansatz kann jedoch bei großen Skalierungen unter Leistungseinbußen leiden: Ein Cluster mit 5.000 Services und 50.000 Endpunkten kann Latenzen von 10-15 Sekunden bei Regelaktualisierungen erfahren, wie in den Kubernetes-Leistungsbenchmarks dokumentiert. Der IPVS-Modus, basierend auf dem Linux Virtual Server-Kernelmodul, bietet eine bessere Skalierbarkeit für große Cluster und unterstützt mehrere Load-Balancing-Algorithmen (Round-Robin, Least Connections, Source Hashing), die über das Flag --ipvs-scheduler ausgewählt werden können.

Service-Typen und externer Zugriff

Für externen Verkehr, der in den Cluster eintritt, bietet Kubernetes drei Service-Typen: NodePort, LoadBalancer und Ingress. NodePort legt einen statischen Port auf der IP-Adresse jedes Knotens offen, geeignet für Entwicklungs- oder On-Premise-Umgebungen, in denen kein separater externer Load Balancer verfügbar ist. Der LoadBalancer-Typ integriert sich mit Cloud-Provider-APIs (AWS ELB, Azure Load Balancer, GCP Cloud Load Balancing), um einen dedizierten externen Load Balancer bereitzustellen, der Verkehr an NodePorts auf allen Knoten weiterleitet. Dieser Ansatz lagert Health Checks und SSL-Terminierung an den Cloud-Provider aus, verursacht jedoch Kosten pro Ressource – AWS Application Load Balancer kosten beispielsweise etwa 0,0225 USD pro Stunde zuzüglich Datenverarbeitungsgebühren (AWS Pricing, 2024). Ingress hingegen arbeitet auf der HTTP/HTTPS-Ebene und ermöglicht pfad- und hostbasiertes Routing, sodass ein einzelner Load Balancer mehrere Services bedienen kann. Der Ingress-Controller (NGINX, Traefik oder AWS ALB Ingress Controller) implementiert die eigentlichen Routing-Regeln und führt TLS-Terminierung, Caching und Ratenbegrenzung durch.

Erweitertes Load Balancing mit Service Meshes

Für Teams, die eine feinkörnige Kontrolle über das Verkehrsverhalten benötigen – wie Canary-Deployments, Circuit Breaking oder Fault Injection – bietet ein Service Mesh wie Istio oder Linkerd eine leistungsfähigere Alternative zu kube-proxy. Diese Meshes setzen Sidecar-Proxys (Envoy oder Linkerd2-proxy) neben jedem Pod ein und bilden eine dedizierte Datenebene, die den gesamten ein- und ausgehenden Verkehr abfängt. Die Steuerungsebene verwaltet die Konfigurationsverteilung und Telemetrieerfassung und ermöglicht so ausgefeilte Load-Balancing-Richtlinien auf der Anwendungsebene. Basierend auf einer Analyse der Endbenutzer-Community der Cloud Native Computing Foundation aus dem Jahr 2023 korreliert die Einführung von Service Meshes mit einer 45%igen Reduzierung der Zeit bis zur Wiederherstellung bei Teilausfällen, was auf automatische Wiederholungsversuche und Ausreißererkennung zurückgeführt wird. Der Overhead ist jedoch nicht trivial: Istios Envoy-Proxy fügt etwa 5-10 ms Latenz pro Hop hinzu und verbraucht 0,5-1 vCPU pro Pod in moderaten Verkehrsszenarien. Bei der Entscheidung zwischen kube-proxy und einem Service Mesh sollten Sie abwägen, ob Ihre Anforderungen über die grundlegende Round-Robin-Verteilung hinausgehen – wenn Sie Traffic Mirroring, JWT-Authentifizierung oder gewichtetes Routing basierend auf HTTP-Headern benötigen, ist ein Service Mesh gerechtfertigt; andernfalls sind die nativen Service- und Ingress-Ressourcen ausreichend.

Horizontales Pod-Autoskalieren in der Praxis: Konfiguration und Abstimmung

Um zu veranschaulichen, wie Kubernetes das Skalieren von Containern und das Load Balancing in einer realen Bereitstellung verwaltet, betrachten Sie eine typische Webanwendung mit der folgenden HPA-Konfiguration:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "500"
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 2
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Pods
        value: 5
        periodSeconds: 30
      - type: Percent
        value: 100
        periodSeconds: 30
      selectPolicy: Max

Dieser HPA verwendet sowohl die CPU-Auslastung als auch benutzerdefinierte HTTP-Anforderungsratenmetriken mit separaten Stabilisierungsfenstern und Skalierungsrichtlinien. Die scaleUp-Richtlinie priorisiert die aggressivste Option (entweder 5 Pods hinzufügen oder die aktuelle Anzahl verdoppeln) alle 30 Sekunden, was eine schnelle Reaktion auf Verkehrsspitzen ermöglicht. Die scaleDown-Richtlinie beschränkt Entfernungen auf 2 Pods pro Minute nach einer Abkühlphase von 5 Minuten, um ein Flackern beim Herunterskalieren bei variablen Arbeitslasten zu verhindern. Die Stabilisierungsfenster – 300 Sekunden für das Herunterskalieren und 30 Sekunden für das Hochskalieren – sind von den Standardempfehlungen im Kubernetes-HPA-Walkthrough abgeleitet, angepasst für eine Webanwendung mit vorhersagbaren täglichen Verkehrsmustern.

Häufige Fallstricke und Minderungsstrategien

Selbst bei richtiger Konfiguration treten Teams häufig auf Probleme mit dem Skalieren und Load Balancing von Kubernetes. Ein häufiges Problem ist der „Thundering-Herd“-Effekt, bei dem eine plötzliche Verkehrsspitze dazu führt, dass der HPA viele Replikate gleichzeitig skaliert, was den Scheduler und den API-Server überlastet. Um dies zu vermeiden, implementieren Sie spec.behavior.scaleUp.selectPolicy: Max mit einem niedrigeren periodSeconds-Wert, um Hochskalierungsereignisse über mehrere Zyklen zu verteilen. Ein weiterer Fallstrick ist das alleinige Verlassen auf CPU-Metriken für speicherintensive Anwendungen – Java-Anwendungen mit großen Heaps können eine hohe Speichernutzung aufweisen, während die CPU niedrig bleibt, was verhindert, dass der HPA das Skalieren auslöst. Die Lösung besteht darin, speicherbasierte Metriken oder benutzerdefinierte Metriken zu verwenden, die den anwendungsspezifischen Durchsatz widerspiegeln. Stellen Sie außerdem sicher, dass Ihr Load Balancer (ob kube-proxy oder Service Mesh) Health Checks mit angemessenen Schwellenwerten durchführt – der Standard-Readiness-Probe-Fehlerschwellenwert (3 Fehler in 10 Sekunden) kann für Java-Anwendungen mit Kaltstartlatenz zu aggressiv sein; erwägen Sie, initialDelaySeconds auf 60-120 Sekunden basierend auf der Startzeit Ihrer Anwendung zu erhöhen.

Überwachung und Beobachtbarkeit für Skalierungsentscheidungen

Effektives Skalieren erfordert Sichtbarkeit sowohl auf Systemebene als auch auf Geschäftsebene. Das Prometheus-Ökosystem in Kombination mit Grafana-Dashboards ist der De-facto-Standard für die Beobachtbarkeit von Kubernetes. Zu den wichtigsten zu überwachenden Metriken gehören:

• HPA-Status: kube_horizontalpodautoscaler_status_desired_replicas und kube_horizontalpodautoscaler_status_current_replicas, um Skalierungsverzögerungen zu erkennen
• Planungslatenz: kube_scheduler_e2e_scheduling_duration_seconds, um Engpässe bei der Pod-Platzierung zu identifizieren
• Load-Balancer-Health: kube_service_status_load_balancer_ingress für cloudverwaltete Load Balancer
• Anforderungslatenz und Fehlerraten: abgeleitet von Istio- oder NGINX-Ingress-Metriken, um Skalierungsaktionen mit der Benutzererfahrung zu korrelieren

Laut dem „State of Kubernetes Observability 2024“-Bericht von D2iQ erleben Teams, die benutzerdefinierte Geschäftsmetriken instrumentieren (z. B. aktive Sitzungen, Warteschlangentiefe, Zahlungstransaktionsraten), 38 % weniger Überbereitstellungsvorfälle im Vergleich zu Teams, die nur CPU-/Speichermetriken verwenden. Dies deckt sich mit der Empfehlung des Google Cloud Architecture Center, Service Level Objectives (SLOs) zu definieren, die Skalierungsaktionen antreiben – zum Beispiel Skalieren, wenn die 99. Perzentil-Latenz 200 ms für mehr als 2 Minuten überschreitet, anstatt nur auf Ressourcenmetriken zu reagieren.

Häufig gestellte Fragen

Skaliert Kubernetes Container automatisch basierend auf Verkehr oder CPU?
Ja, Kubernetes kann Container automatisch mit dem Horizontal Pod Autoscaler skalieren, der die Replikatanzahl basierend auf der beobachteten CPU-Auslastung, dem Speicherverbrauch oder benutzerdefinierten Metriken wie der Anforderungsrate anpasst. Das automatische Skalieren ist jedoch nicht standardmäßig aktiviert – Sie müssen explizit eine HPA-Ressource mit Skalierungsrichtlinien und Metrikschwellenwerten für Ihre Bereitstellung definieren.

Wie verteilt Kubernetes den Verkehr auf Pods?
Kubernetes Services bieten internes Load Balancing mit kube-proxy, das Netzwerkregeln verwaltet, die Verkehr über iptables oder IPVS auf Pod-Endpunkte verteilen. Für externen Verkehr übernehmen Ingress-Controller oder Cloud-LoadBalancer-Services das Routing. Das Load Balancing erfolgt typischerweise im Round-Robin-Verfahren, aber Service Meshes bieten fortgeschrittenere Algorithmen wie Least-Requests oder Consistent Hashing.

Was ist der Unterschied zwischen Horizontal Pod Autoscaler und Cluster Autoscaler?
Der Horizontal Pod Autoscaler passt die Anzahl der Pod-Replikate innerhalb einer Bereitstellung basierend auf Nachfragemetriken an, während der Cluster Autoscaler die Anzahl der Worker-Knoten im Cluster anpasst, wenn Pods aufgrund unzureichender Ressourcen nicht geplant werden können. Sie arbeiten komplementär: Der HPA reagiert auf Arbeitslaständerungen, und der Cluster Autoscaler stellt die zugrunde liegende Infrastruktur bereit, um die erhöhte Pod-Anzahl zu unterstützen.

Kann ich Kubernetes-Pods basierend auf benutzerdefinierten Anwendungsmetriken skalieren?
Absolut. Kubernetes unterstützt benutzerdefinierte und externe Metriken über die Custom Metrics API und External Metrics API. Sie müssen einen Metrikadapter wie den Prometheus Adapter oder den Datadog Cluster Agent bereitstellen, der Ihre anwendungsspezifischen Metriken für den HPA-Controller bereitstellt. Häufige benutzerdefinierte Metriken sind Warteschlangenlänge, aktive Verbindungen oder Auftragsverarbeitungsrate.

Welche Load-Balancing-Algorithmen unterstützt Kubernetes?
Der native Service (kube-proxy) unterstützt Round-Robin und im IPVS-Modus zusätzliche Algorithmen wie Least Connections, Source Hashing und Weighted Round-Robin. Ingress-Controller und Service Meshes erweitern dies um HTTP-basiertes Routing, Canary-Deployments und Circuit-Breaking-Muster. Die Wahl hängt von den Verkehrsmustern Ihrer Anwendung ab – einfache zustandslose Dienste funktionieren gut mit Round-Robin, während zustandsbehaftete oder Sticky-Session-Szenarien Sitzungsaffinität oder Consistent Hashing erfordern.

Quellen

1. Kubernetes SIG-Autoscaling. (2023). Horizontal Pod Autoscaler Walkthrough. Kubernetes Documentation. https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
2. Chen, L., et al. (2022). „Custom-Metric Autoscaling for Microservices: A Comparative Study.“ IEEE Transactions on Cloud Computing, 10(4): 2891-2905.
3. Kubernetes Cluster Autoscaler. (2024). FAQ and Best Practices. https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
4. Zhao, W., & Zhang, Y. (2023). „Proactive Autoscaling for Kubernetes Using Predictive Models.“ arXiv:2301.04567.
5. Cloud Native Computing Foundation. (2023). Service Mesh End-User Survey Report. CNCF Technical Advisory Group.
6. AWS Pricing. (2024). Elastic Load Balancing Pricing. https://aws.amazon.com/elasticloadbalancing/pricing/
7. D2iQ. (2024). State of Kubernetes Observability 2024. Industry Report.
8. Google Cloud Architecture Center. (2023). Scaling Microservices with Kubernetes. https://cloud.google.com/architecture/scaling-microservices

— Editorial Team