Black Friday: Die HPA steigt von vier auf zwanzig API-Pods – grüne Grafik, ruhiges Team. Allerdings das Checkout-Timeout: PostgreSQL erreicht max_connections, Redis Single-Thread ist ausgelastet. Die neuen Pods vervielfachen Verbindungen, ohne die Transaktionskapazität zu erhöhen. Autoscaling „erfolgreich“ auf der Kubernetes-Seite, Misserfolg auf der Geschäftsseite.
Durch die Skalierung von Pods werden zustandslose Engpässe behoben. Zustandsbehaftete oder gemeinsame Engpässe werden oft noch schlimmer, wenn niemand die gesamte Kette abgebildet hat. Bevor Sie etwas automatisieren, ermitteln Sie, welche Ressource bei Spitzenzeiten zuerst ausfällt – Basis, Broker, Drittanbieter-API, ausgehende Bandbreite – und wer die Autorität hat, sie zu skalieren.
HPA: die Standardmetrik und ihre blinden Flecken
Der Horizontal Pod Autoscaler vergleicht eine Metrik (CPU, Speicher, benutzerdefinierte Metrik) mit einem Ziel und ändert die Anzahl der Replikate. Auf dem Papier ist es einfach. In der Produktion ist die CPU lediglich ein unvollständiger Stellvertreter für die tatsächliche Last.
| Metrisch | Gutes Signal, wenn | Schlechtes Signal, wenn |
|---|---|---|
| CPU % | Intensives Rechnen (Rendering, Verschlüsselung) | Warten auf Festplatte oder Datenbank |
| Erinnerung | Im Pod verstecken | Leck durch Skala verdeckt |
| Anfragen/s oder Latenz (benutzerdefiniert) | Zustandslose API | Upstream-Sättigung |
| Warteschlangentiefe (KEDA) | Asynchrone Worker | Linie ohne gesunde Verbraucher |
Ohne den Metrikserver und einen Prometheus-Adapter (oder einen gleichwertigen Adapter) bleibt die HPA gegenüber dem Unternehmen blind. Ein Pod kann zwanzig Prozent CPU anzeigen, während er auf eine PostgreSQL-Antwort wartet, die acht Sekunden lang feststeckt. Die Kennzahl steigt zu spät – oder überhaupt nicht.
Das Hinzufügen von Pods auf der Basis einer hundertprozentig genutzten Verbindung führt lediglich zu mehr wartenden Clients.
Um von der Standard-CPU abzuweichen, legen Sie Signale offen, die die Benutzererfahrung widerspiegeln: 95. Perzentil-Latenz bei „/api/checkout“, Redis-Warteschlangenlänge, Anzahl verspäteter Nachrichten bei RabbitMQ. Der HPA wird nur dann nützlich, wenn die gewählte Metrik mit den unter Last beobachteten Timeouts korreliert.
VPA und Größenänderung vor der Multiplikation
Der Vertical Pod Autoscaler empfiehlt oder erzwingt CPU-Speicheranforderungen und -limits. Zu niedrige Anforderungen führen zu einer CPU-Drosselung und drängen den HPA unnötig in die Skalierung. Zu hohe Anfragen füllen die Knoten: Die neuen Pods bleiben ausstehend, der Autoscaling-Cluster wird dringend aktiviert und die Rechnung folgt.
Pragmatischer Arbeitsablauf: Zuerst Anfragen stabilisieren (VPA im „Aus“-Modus, um Empfehlungen zu sammeln), dann HPA für Replikate aktivieren. Überwachen Sie auf einem in Europa verwalteten Cluster die Kosten pro Knoten: Ein Autoscaling-Cluster ohne Budgetwarnung verwandelt eine Traffic-Spitze am Ende des Monats in eine Überraschung.
Cluster-Autoscaler und ausstehende Pods
Wenn die HPA Pods erstellt, für die kein Platz auf vorhandenen Knoten vorhanden ist, bleiben sie „Ausstehend“. Der Autoscaling-Cluster stellt einen Knoten bereit – mit einer Verzögerung von mehreren Minuten (Image-Download, Booten, Speichern). Während dieser Zeit kommt der Verkehr weiterhin über bestehende Pods an, die bereits ausgelastet sind.
Planen Sie mit einem PodDisruptionBudget ein, um eine kritische Bereitstellung während einer Knotenverkleinerung nicht zu belasten. Planen Sie mehrere Knotenpools (allgemeines oder intensives Computing) ein, wenn Ihre Lasten heterogen sind. Legen Sie ein maximales Knotenlimit fest, um eine unkontrollierte Abrechnung während einer schlecht konfigurierten Waagenschleife zu vermeiden.
KEDA für Arbeiter und Dateien
Symfony Messenger-Mitarbeiter, Laravel-Dateien, Kafka-Konsumenten: Das richtige Signal ist Verzögerung oder Warteschlangentiefe, nicht eine CPU bei fünfzehn Prozent, während Tausende von Nachrichten warten. KEDA kann von Null an skaliert werden – praktisch für Batch-Ladungen, aber seien Sie vorsichtig, wenn ein Kaltstart nicht mit einer Verpflichtung zur Echtzeitverfügbarkeit vereinbar ist.
Dokumentieren Sie die Topologie des Austauschs und der Dateien vor der Automatisierung. Ein schlecht verkabelter Skalierer in der falschen Warteschlange skaliert Worker, während die kritische Warteschlange anderswo wächst.
Zustandsbehaftete Dienste: Skalieren Sie nicht blind automatisch
PostgreSQL, Elasticsearch, bestimmte Redis-Bereitstellungen: Horizontale Skalierung ist nicht trivial. Manchmal ist die Antwort ein größerer Knoten (Größenänderung einer virtuellen Maschine), eine Read Replica oder ein Upstream-Cache – nicht mehr API-Pods, die die Verbindungen vervielfachen.
Ordnen Sie die Kette zu: Welche Ressource fällt bei tausend zusätzlichen Anfragen pro Sekunde zuerst aus? Messen Sie im Belastungstest, bevor Sie den falschen Hebel automatisieren. Die automatische Skalierung von Kubernetes ist kein Ersatz für eine durchdachte Datenarchitektur.
Der Gipfel: die Grafik, die fälschlicherweise beruhigt
Die richtige Frage lautet nicht: „Wie viele Hülsen?“ » aber „Welche Ressource geht unter Spitzenlast zuerst – und wer skaliert sie?“
Entscheide dich und gehe ohne blinden Fleck voran
Beginnen Sie mit einem Auslastungstest mit Metriken nach Schicht: Anwendung, Basis, Broker, Netzwerk. Wählen Sie den geeigneten Skalierer (HPA, KEDA, Cluster-Autoscaler) für das Signal aus, das mit Benutzer-Timeouts korreliert, und nicht für die am einfachsten grafisch darzustellende Metrik. Legen Sie maximale Replikate, Unterbrechungsbudgets und 95.-Perzentil-Latenzwarnungen fest.
Vergleichen Sie verwaltete Cluster und Knotenpools über das Verzeichnis und den Vergleich. Die Anleitungen vervollständigen das Cloud-Architektur-Framework. Validierung unter Last: Wenn die Latenz beim 95. Perzentil beim Anstieg der Replikate stabil bleibt, liegt der Engpass woanders – und dort müssen Sie investieren.
Häufig gestellte Fragen
Reicht HPA auf der CPU in der Produktion aus?
Selten allein. Eine stabile CPU kann eine wachsende Redis-Warteschlange oder eine Datenbank mit erschöpften Verbindungen verbergen. Kombinieren Sie Anwendungsmetriken (Warteschlangenverzögerung, Anfragen pro Sekunde, 95. Perzentil-Latenz) über den Prometheus-Adapter oder KEDA, um eine Skalierung entsprechend den Zeitüberschreitungen der Benutzer vorzunehmen.
Was ist der Unterschied zwischen HPA, VPA und Autoscaling-Cluster?
Die HPA passt die Anzahl der Pod-Replikate entsprechend einer Zielmetrik an. Der VPA empfiehlt oder erzwingt CPU-Speicheranforderungen und -limits. Der Autoscaling-Cluster fügt Knoten hinzu, wenn Pods aufgrund fehlender Ressourcen im vorhandenen Cluster ausstehend bleiben.
Was bringt KEDA im Vergleich zum klassischen HPA?
KEDA bietet Skalierer basierend auf Dateitiefe, Cron-Triggern und externen Metriken. Für asynchrone Worker sind diese Signale oft aussagekräftiger als eine niedrige durchschnittliche CPU, während Tausende von Nachrichten warten.
Wie vermeide ich Flattern?
Konfigurieren Sie stabilizationWindowSeconds, Schwellenwerte mit Hysterese, eine Abkühlverzögerung zwischen zwei Skalenereignissen und ein realistisches Minimum an Replikaten. Ohne diese Leitplanken gerät die HPA ins Wanken und destabilisiert dauerhafte Verbindungen.
Die ausgereifte automatische Skalierung skaliert die Ressource, die dem Benutzer ausfällt – nicht die, die bereits in Grafana vorhanden ist.