Autoscaling für Lastspitzen: Black Friday ohne 503

Warum liefert ein Online-Shop am Black Friday plötzlich 503? 

in 503-Fehler bedeutet in den meisten Fällen: Es ist keine Kapazität mehr da, die die Anfrage annehmen könnte. Die typischen Ursachen in einem Shop-Setup: 

• Alle Anwendungsprozesse (PHP-FPM Worker, Node-Prozesse) sind belegt, neue Requests landen in einer Warteschlange und laufen in den Timeout. 
• Die Datenbank erreicht ihr Verbindungslimit, die Applikation kann keine neuen Connections mehr öffnen. 
• Der Load Balancer findet keine gesunden Backends mehr, weil überlastete Pods ihre Health Checks nicht mehr rechtzeitig beantworten. 
• Ein einzelner Pod stirbt am OOM-Kill, der Traffic verteilt sich auf die verbliebenen Pods – und reißt diese ebenfalls mit. Der klassische Kaskadeneffekt. 

Das Tückische am Black Friday: Der Traffic steigt nicht linear. Newsletter-Versand, Push-Kampagnen und Preisportale erzeugen Sprünge, die innerhalb weniger Minuten das Fünf- bis Zwanzigfache des Normalniveaus bedeuten können. Genau in diesem Zeitfenster entscheidet sich, ob Ihre Plattform mitskaliert oder abreißt.

Was bedeutet Autoscaling in Kubernetes konkret?

Kubernetes skaliert auf drei Ebenen. Für ein belastbares Black-Friday-Setup brauchen Sie in der Regel alle drei im Zusammenspiel. 

1. Horizontal Pod Autoscaler (HPA) 
   Der HPA erhöht die Anzahl der Pods eines Deployments, wenn eine definierte Metrik – meist CPU-Auslastung, Speicherverbrauch oder eine eigene Metrik wie Requests pro Sekunde einen Zielwert überschreitet. Für Shop-Frontends ist das der wichtigste Hebel: Mehr Pods bedeuten mehr parallel abarbeitbare Requests. 
2. Cluster- beziehungsweise Node-Autoscaling 
   Neue Pods brauchen Platz. Wenn die vorhandenen Worker Nodes ausgelastet sind, bleiben Pods im Status Pending hängen. Die Node-Skalierung stellt zusätzliche Worker bereit und entfernt sie nach der Spitze wieder. 
3. Vertical Pod Autoscaler (VPA) 
   Der VPA passt Requests und Limits einzelner Pods an den realen Bedarf an. Für die Kapazitätsplanung außerhalb von Peaks sehr nützlich – während eines Peaks sollte er allerdings nicht gleichzeitig mit dem HPA auf dieselbe Metrik wirken, sonst arbeiten beide gegeneinander. 

Ergänzend lohnt ein Blick auf ereignisgesteuertes Skalieren (etwa über KEDA): Damit skalieren Sie nicht nach CPU, sondern nach Queue-Länge ideal für asynchrone Worker wie Bestellverarbeitung, Rechnungsversand oder Suchindexierung.

Wie schnell reagiert Autoscaling wirklich? 

Das ist die entscheidende und oft zu optimistisch beantworteter Frage. Autoscaling ist nicht instantan. Rechnen Sie mit dieser Kette: 

• Metrik-Erfassung und HPA-Auswertung: standardmäßig alle 15 Sekunden, die Metriken selbst sind meist 30 bis 60 Sekunden alt. 
• Pod-Scheduling und Container-Start: wenige Sekunden bis über eine Minute, je nach Image-Größe und Registry. 
• Applikations-Warm-up: bei Shopware, OXID oder Pimcore kommen Bootstrapping, Cache-Aufbau und JIT-Warm-up hinzu das können nochmals 20 bis 60 Sekunden sein. 
• Node-Bereitstellung, falls kein Platz im Cluster ist: typischerweise mehrere Minuten. 

In Summe vergehen zwischen "Last steigt" und "zusätzliche Kapazität nimmt Traffic an" realistisch zwei bis fünf Minuten. Bei einem Newsletter-Versand um Punkt 09:00 Uhr sind das genau die Minuten, in denen die 503er entstehen.

Die Konsequenz aus dieser Rechnung

• Setzen Sie für den Peak-Zeitraum eine deutlich erhöhte Mindestanzahl an Replicas (minReplicas). Autoscaling ist die Absicherung nach oben, nicht der Ersatz für vernünftige Grundkapazität. 
• Halten Sie Reserve-Nodes vor, etwa über niedrig priorisierte Platzhalter-Pods, die bei Bedarf verdrängt werden. So muss der Cluster im Ernstfall keine neuen Nodes booten. 
• Skalieren Sie bekannte Ereignisse vorausschauend, nicht reaktiv. Ein Newsletter mit fixem Versandzeitpunkt ist planbar. 
• Setzen Sie die Scale-Down-Stabilisierung großzügig (Standard sind 300 Sekunden). Ein Cluster, der zwischen zwei Traffic-Wellen zu früh abbaut, produziert die nächste Lücke selbst. 

Welche Grenzen hat Autoscaling? 

Autoscaling löst ein Kapazitätsproblem auf Applikationsebene nicht alle Engpässe Ihrer Plattform. Die Datenbank skaliert nicht mit. Zehnmal so viele Frontend-Pods bedeuten potenziell zehnmal so viele Datenbankverbindungen. Ohne Connection Pooling, Read Replicas und saubere Indizes verlagern Sie den Flaschenhals nur. 

Externe Dienste haben eigene Limits. Payment-Provider, ERP und Versanddienstleister skalieren nicht mit Ihrem Cluster. Timeouts, Retries mit Backoff und Circuit Breaker verhindern, dass ein langsamer Drittanbieter Ihre Worker blockiert. 

Zustand gehört nicht auf den Pod. Sessions in Redis, Medien in Object Storage, sonst verlieren Sie beim Skalieren Warenkörbe. 

Ineffizienter Code bleibt ineffizient. Eine Kategorieseite mit 400 Datenbankabfragen wird durch Autoscaling teurer, nicht schneller. 

Entfernt wurden: der einleitende Halbsatz "Hier ist Ehrlichkeit wichtiger als Marketing", die konkrete Prüfliste vor dem Peak (max_connections, Slow-Query-Log, Locking-Verhalten bei Bestellvorgängen) und der Hinweis auf Profiling in der Vorbereitungsphase. 

Falls Sie die Prüfliste behalten wollen, ließe sie sich als ein Satz wieder anhängen: "Prüfen Sie vor jedem Peak max_connections, Slow-Query-Log und Locking-Verhalten im Bestellprozess." Das ist der Teil mit dem größten Praxisnutzen und dem stärksten Zitierpotenzial für generative Suche. 

Wie bereiten Sie Ihren Shop konkret auf den Black Friday vor?

Beginnen Sie etwa acht Wochen vorher mit einer realistischen Lastannahme – Vorjahres-Peak mal geplantem Wachstum plus Sicherheitsfaktor und legen Sie fest, welche User Journeys unbedingt halten müssen. Der Checkout hat dabei Vorrang vor allem anderen. 

Rund sechs Wochen vorher folgt der Lasttest gegen eine produktionsnahe Umgebung mit echter Datenmenge; ein Test gegen einen leeren Katalog sagt wenig aus. Wichtig ist die zweite Runde: Engpässe beheben, dann erneut testen. Auf Basis dieser Ergebnisse kalibrieren Sie vier Wochen vorher HPA-Ziele, minReplicas und maxReplicas sowie Ressourcen-Requests und -Limits. Pod Disruption Budgets stellen sicher, dass Wartungsvorgänge Ihnen im Peak keine Kapazität wegnehmen. 

Zwei Wochen vorher geht es um Entlastung statt Kapazität: Full-Page-Cache, Object Cache und Cache-Header schärfen, CDN-Konfiguration für statische Assets und cachebare Seiten prüfen, Change Freeze festlegen. In der letzten Woche gehören Monitoring und Alerting auf den Prüfstand sind Fehlerraten, Latenzen, Sättigung und Traffic sichtbar, und wer wird wann alarmiert? Testen Sie außerdem den Rollback-Pfad, statt ihn nur zu dokumentieren, und klären Sie die Bereitschaft inklusiven Zugriffsrechten. 

Am Aktionstag selbst gilt: vor bekannten Kampagnenzeitpunkten vorskalieren, Dashboards aktiv beobachten, statt auf Alerts zu warten, und keine Deployments. 

Alle Inhalte sind erhalten, nur die Bulletpoint-Struktur ist aufgelöst. Ein Hinweis dazu: Als Fließtext verliert der Abschnitt an Scanbarkeit und ist für generative Suchmaschinen schlechter extrahierbar als eine Liste. Falls Sie einen Kompromiss möchten, wäre die Zeitmarken als fettgesetzte Zwischenüberschriften mit je zwei bis drei Sätzen Fließtext eine Variante, die beides bedient. 

Welche Rolle spielen Caching und CDN? 

Die günstigste Anfrage ist die, die Ihre Infrastruktur nie erreicht. Bevor Sie Kapazität skalieren, reduzieren Sie die Last: 

• Full-Page-Caching für anonyme Besucher entlastet Applikation und Datenbank massiv. Der Großteil des Black-Friday-Traffics sind Nutzer, die stöbern nicht Nutzer, die bereits eingeloggt sind. 
• Ein CDN übernimmt Bilder, CSS, JavaScript und cachebare HTML-Antworten an verteilten Standorten und senkt gleichzeitig die Auslieferungszeiten für Ihre Besucher. 
• Ehrlich eingeordnet: Ein CDN verbessert die Auslieferung statischer und cachebarer Inhalte. Dynamische Anfragen wie Warenkorb und Checkout laufen weiterhin bis zu  

Kubernetes ONE: Skalierung mit voller Kontrolle 

Wenn Sie Autoscaling produktiv betreiben wollen, ohne ein eigenes Plattform-Team für Cluster-Betrieb aufzubauen, ist Managed Kubernetes der pragmatische Weg. Kubernetes ONE von profihost bietet dafür: 

• CNCF-konformes Kubernetes ohne Vendor-Lock-in kompatibel mit dem gesamten Cloud-Native-Ökosystem 
• Flexible Skalierung auf Node- und Workload-Ebene, manuell oder automatisiert 
• Automatisierter Node-Lebenszyklus: Nodes werden erstellt, ersetzt und repariert 
• Standardisierte Cluster-Templates für konsistente, wiederholbare Setups 
• Self-Service-Bereitstellung über ein zentrales Dashboard, Multi-Cluster- und Multi-Projekt-Setups inklusive 
• Kontrollierte Kubernetes-Upgrades mit voller Transparenz 
• Gehostet auf dedizierter OpenStack-Infrastruktur in der EU