Kubernetes-Autoscaler kollidieren, weil eine einheitliche Steuerungsebene fehlt

Wenn Site Reliability Engineers die korrekte Größe eines Dienstes wie checkout-api anfragen, erhalten sie widersprüchliche Antworten von ihrer eigenen Infrastruktur. Der Horizontal Pod Autoscaler (HPA) fordert möglicherweise elf Replikate aufgrund der CPU-Last, während der Vertical Pod Autoscaler (VPA) behauptet, die Pods seien überdimensioniert. Gleichzeitig verlangt KEDA vierundzwanzig Replikate, um einen Kafka-Rückstau abzuarbeiten, und Karpenter fügt neue Knoten basierend auf aufgeblähten Ressourcenanforderungen hinzu. Dieses Chaos entsteht, weil fünf verschiedene Controller logisch isoliert agieren, aber keiner eine vollständige Sicht auf die tatsächlichen Bedürfnisse des Systems besitzt.

Was passiert ist

Der moderne Kubernetes-Betrieb verlässt sich auf eine Reihe spezialisierter Tools, die nach dem Unix-Prinzip entwickelt wurden: kleine, modulare Komponenten, die einzelne Aufgaben gut erfüllen. HPA verwaltet die horizontale Elastizität, VPA kümmert sich um die vertikale Dimensionierung, KEDA verbindet Ereignisquellen mit der Anzahl der Replikate, und Node-Autoscaler wie Karpenter verwalten die physische Kapazität. GitOps-Tools wie Argo CD erzwingen Baseline-Zustände aus der Versionskontrolle. In traditionellen Unix-Pipelines verarbeiten Tools Daten sequenziell und geben unveränderliche Ausgaben von einer Stufe zur nächsten weiter. Kubernetes-Autoscaler arbeiten jedoch parallel und ändern dieselben API-Felder wie .spec.replicas und .resources.requests, ohne Einsicht in die Aktionen der anderen zu haben.

Diese architektonische Lücke führt dazu, dass die Bestimmung der Arbeitslastkapazität zu einem fragmentierten Prozess wird. Anstatt eine einzige gekoppelte mathematische Gleichung für optimale Leistung und Kosten zu lösen, spaltet das System das Problem auf entkoppelte Controller auf. Jeder Controller geht davon aus, die ausschließliche Kontrolle über seinen spezifischen Bereich zu haben, was zu Flattern statt Effizienz führt. Das Ergebnis ist ein Cluster, in dem keine einzelne Entität die Kompromisse zwischen Latenz, Kosten und Kapazität versteht, was zu operativer Instabilität führt.

Wie es funktioniert

Der Konflikt entsteht, weil unabhängige Regelkreise voneinander abhängige Variablen manipulieren, was vier häufige Fehlermodi erzeugt. Erstens kollidieren HPA und VPA durch den sogenannten „Denominator Collapse“. HPA berechnet die Ziel-Replikate, indem es die tatsächliche Nutzung durch die deklarierten Ressourcenanforderungen teilt. Wenn VPA diese Anforderungen senkt, um Verschwendung zu reduzieren, schrumpft der Nenner. Selbst geringe Traffic-Erhöhungen treiben dann die Nutzungsprozentsätze über die HPA-Schwellenwerte und lösen aggressives Scale-out aus. Da mehr Pods die Last teilen, sinkt die Nutzung pro Pod, was VPA dazu veranlasst, die Anforderungen weiter zu senken – eine Abwärtsspirale hin zu mikroskopisch kleinen Containern.

Zweitens geraten nativer HPA und KEDA in einen Multi-Writer-Race-Condition. Wenn eine Ereignisschlange anschwillt, skaliert KEDA das Deployment hoch, um den Rückstau abzubauen. Wenn die Worker-Pods jedoch I/O-lastig sind und eine niedrige CPU-Nutzung aufweisen, sieht HPA eine geringe Auslastung und skaliert das Deployment wieder herunter. Der API-Server zeichnet abwechselnde Rescale-Ereignisse auf, während der tatsächliche Durchsatz stagniert. Drittens erzeugen GitOps-Engines ein Drift-Ping-Pong. Wenn HPA ein Deployment während einer Lastspitze skaliert, markieren GitOps-Tools die Anwendung als out-of-sync. Wenn Auto-Sync aktiviert ist, setzt das System das Deployment auf seinen Baseline-Wert zurück und entzieht der Anwendung während der Spitzenlast die Kapazität.

Schließlich verstärken Node-Autoscaler diese Ineffizienzen. Tools wie Karpenter provisionieren physische Instanzen streng nach den deklarierten Container-Anforderungen, nicht nach dem tatsächlichen Verbrauch. Wenn ein Container eine CPU-Kern anfordert, aber nur 150 Millicores nutzt, reserviert der Scheduler den gesamten Kern. Dies multipliziert Upstream-Dimensionierungsfehler in massive Cloud-Rechnungen, wobei die durchschnittliche CPU-Auslastung des Clusters trotz hoher Provisionierung bei etwa acht Prozent verharrt.

Wichtige Details

• Fünf verschiedene Controller (HPA, VPA, KEDA, Karpenter, GitOps) liefern oft widersprüchliche Größenempfehlungen für dieselbe Arbeitslast.
• HPA und VPA stehen im Konflikt, weil VPA die Ressourcenanforderungen reduziert, was die von HPA verwendete Nutzungsprozentzahl künstlich erhöht.
• KEDA und HPA konkurrieren beim Schreiben in dieselbe /scale-Subressource, was zu oszillierenden Replikatzahlen führt, wenn die CPU-Nutzung nicht mit der Schlangentiefe übereinstimmt.
• GitOps-Tools können dynamische Skalierungsänderungen von HPA rückgängig machen und Baseline-Konfigurationen wiederherstellen, die den aktuellen Traffic-Lasten nicht gewachsen sind.
• Node-Autoscaler provisionieren Kapazität basierend auf deklarierten Anforderungen statt auf tatsächlicher Nutzung, was zu erheblicher Überprovisionierung und geringer Cluster-Auslastung führt.
• Aktuelle Autoscaler funktionieren wie automatisierte Reflexe, denen ein zentrales Nervensystem zur Koordinierung ihrer Aktionen fehlt.

Warum das wichtig ist

Für Software-Ingenieure und Plattformteams führen diese Konflikte direkt zu unzuverlässigen Diensten und aufgeblähten Kosten. Das durch konkurrierende Controller verursachte Flattern führt zu Latenzspitzen während Nachfrageschwankungen, da reaktive Skalierung wartet, bis Schwellenwerte überschritten werden, bevor sie handelt. Diese reaktive Natur bedeutet, dass neue Compute-Ressourcen erst initialisiert werden, nachdem die Leistung bereits beeinträchtigt wurde, was Service Level Objectives verletzt. Darüber hinaus untergräbt die Unfähigkeit von GitOps, die Produktionsrealität genau abzubilden, die Prinzipien der deklarativ definierten Infrastruktur und macht zukünftige Rollouts riskant und schwer auditierbar.

Die finanziellen Auswirkungen sind ebenso gravierend. Da Node-Autoscaler sich auf deklarierte Anforderungen stützen, die oft aufgebläht sind, um HPA-VPA-Konflikte zu vermeiden, laufen Cluster mit enormen Mengen ungenutzter Kapazität. Ingenieure verbringen viel Zeit damit, Schwellenwerte manuell anzupassen und Git-Diffs abzugleichen, anstatt sich auf die Feature-Entwicklung zu konzentrieren. Das Fehlen einer einheitlichen Steuerungsebene bedeutet, dass jede Skalierungsentscheidung eine lokale Optimierung ist, die den globalen Systemzustand schädigen kann, und verhindert, dass Teams gleichzeitig Kosteneffizienz und hohe Verfügbarkeit erreichen.

Was Sie tun können

• Prüfen Sie Ihren Cluster auf gleichzeitige Controller, die auf dieselben Ressourcen abzielen, insbesondere auf die parallele Verwendung von HPA und VPA in denselben Deployments.
• Bewerten Sie, ob GitOps-Auto-Sync-Richtlinien legitime Skalierungsereignisse rückgängig machen, und erwägen Sie, Unterschiede bei der Replikatzahl sorgfältig zu ignorieren.
• Überwachen Sie das Verhältnis von deklarierten Ressourcenanforderungen zur tatsächlichen Nutzung, um festzustellen, wo Node-Autoscaler überschüssige Kapazität provisionieren.
• Konsolidieren Sie Skalierungssignale, indem Sie ereignisgesteuerte Autoskalierung ausschließlich für schlangenbasierte Arbeitslasten verwenden und CPU-basierte HPA-Skalierung für diese spezifischen Dienste deaktivieren.
• Implementieren Sie prädiktive Skalierungsstrategien, die historische Verbrauchsdaten analysieren, um Kapazität vor Traffic-Spitzen vorzuwärmen.
• Suchen Sie nach Lösungen, die eine einheitliche Steuerungsebene bieten, die mehrere Signale erfassen und gemeinsame Entscheidungen über horizontale und vertikale Dimensionierung treffen kann.