TL;DR

• Black-Friday-Traffic ist 5x bis 20x hoeher als der Normalbetrieb -- wer nicht automatisch skaliert, verliert Umsatz oder zahlt das ganze Jahr fuer Peak-Kapazitaet
• HPA mit Custom Metrics (Requests/Sekunde) reagiert schneller auf E-Commerce-Lastspitzen als CPU-basiertes Autoscaling
• Scheduled Scaling vor bekannten Events (Black Friday, Cyber Monday) vermeidet den Cold-Start-Engpass beim Hochfahren neuer Pods
• In der Nebensaison 40-60% Kosten sparen durch aggressives Scale-Down, Spot Instances fuer Batch-Jobs und Namespace-Quotas fuer Dev/Test
• Datenbank-Skalierung ist der haeufigste Engpass -- Read Replicas, Connection Pooling und Redis-Caching muessen vor dem Frontend skalieren

Kubernetes fuer E-Commerce: Black Friday ueberleben ohne Nachtschichten

Black Friday, Cyber Monday, Weihnachtsgeschaeft. Drei bis vier Wochen im Jahr entscheiden ueber 30-40% des Jahresumsatzes im E-Commerce. Und genau in diesen Wochen bricht die Infrastruktur zusammen, wenn sie nicht darauf vorbereitet ist.

Das klassische Dilemma: Provisionieren Sie fuer den Peak, zahlen Sie 11 Monate lang fuer ungenutzte Kapazitaet. Provisionieren Sie fuer den Normalbetrieb, gehen bei Lastspitzen Bestellungen verloren. Kubernetes mit intelligentem Autoscaling loest dieses Dilemma -- wenn die Konfiguration stimmt.

Das Lastprofil im E-Commerce verstehen

Bevor Sie Autoscaling konfigurieren, muessen Sie Ihr Lastprofil kennen. E-Commerce-Traffic folgt vorhersagbaren Mustern.

Die Kombination aus vorhersagbaren und unvorhersagbaren Lastspitzen erfordert zwei Strategien: geplantes Pre-Scaling fuer bekannte Events und reaktives Autoscaling fuer alles andere.

HPA-Konfiguration fuer E-Commerce-Workloads

Der Horizontal Pod Autoscaler (HPA) ist das Kernstueck der Skalierungsstrategie. Fuer E-Commerce-Anwendungen reicht CPU-basiertes Autoscaling allein nicht aus. Die Request-Rate ist ein besserer Indikator, weil sie frueher auf steigende Last reagiert.

Frontend und API: Custom-Metric-basiertes Autoscaling

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: shop-frontend-hpa
  namespace: e-commerce-production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: shop-frontend
  minReplicas: 3
  maxReplicas: 50
  metrics:
    # Primaere Metrik: Requests pro Sekunde pro Pod
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"
    # Sekundaere Metrik: CPU als Sicherheitsnetz
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 15
      policies:
        # Schnelles Hochskalieren: Bis 100% mehr Pods in 30 Sekunden
        - type: Percent
          value: 100
          periodSeconds: 30
        # Mindestens 5 Pods auf einmal hinzufuegen
        - type: Pods
          value: 5
          periodSeconds: 30
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        # Langsames Herunterskalieren: Max 10% pro Minute
        - type: Percent
          value: 10
          periodSeconds: 60
      selectPolicy: Min

Die asymmetrische Skalierung ist entscheidend: Schnell hoch, langsam runter. Beim Hochskalieren zaehlt jede Sekunde -- ein langsamer HPA bedeutet Timeouts fuer Kunden. Beim Herunterskalieren ist Vorsicht besser: Zu schnelles Scale-Down fuehrt zu Flapping, wenn die Last schwankt.

Vergleich: Autoscaling-Metriken fuer E-Commerce

Fuer eine detaillierte Anleitung zur HPA-Konfiguration mit Custom Metrics empfehlen wir unseren HPA-Tutorial und den Autoscaling-Guide.

Scheduled Scaling: Vor Black Friday vorheizen

Reaktives Autoscaling hat eine Schwaeche: Neue Pods brauchen Zeit zum Starten. Container-Image-Pull, Anwendungs-Startup, Datenbankverbindungen aufbauen, Readiness-Probe bestehen -- das dauert typischerweise 30 bis 120 Sekunden. Bei einem ploetzlichen Traffic-Anstieg um den Faktor 10 sind die neuen Pods erst bereit, wenn die ersten Kunden bereits Timeouts sehen.

Die Loesung fuer vorhersagbare Events: Geplantes Pre-Scaling.

# CronJob: Pre-Scaling vor Black Friday (Donnerstag 20:00 Uhr)
apiVersion: batch/v1
kind: CronJob
metadata:
  name: black-friday-prescale
  namespace: e-commerce-production
spec:
  schedule: "0 20 * 11 4"  # Jeden 4. Donnerstag im November um 20:00
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: autoscaler-admin
          containers:
            - name: prescale
              image: bitnami/kubectl:1.29
              command:
                - /bin/sh
                - -c
                - |
                  echo "Pre-Scaling fuer Black Friday gestartet"
                  kubectl scale deployment shop-frontend \
                    --replicas=25 -n e-commerce-production
                  kubectl scale deployment product-api \
                    --replicas=15 -n e-commerce-production
                  kubectl scale deployment checkout-service \
                    --replicas=12 -n e-commerce-production
                  kubectl scale deployment search-service \
                    --replicas=10 -n e-commerce-production
                  echo "Pre-Scaling abgeschlossen"
          restartPolicy: OnFailure
---
# CronJob: Scale-Down nach Cyber Monday (Dienstag 06:00 Uhr)
apiVersion: batch/v1
kind: CronJob
metadata:
  name: post-cyber-monday-scaledown
  namespace: e-commerce-production
spec:
  schedule: "0 6 * 12 2"  # Ersten Dienstag im Dezember um 06:00
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: autoscaler-admin
          containers:
            - name: scaledown
              image: bitnami/kubectl:1.29
              command:
                - /bin/sh
                - -c
                - |
                  echo "Post-Event Scale-Down gestartet"
                  kubectl scale deployment shop-frontend \
                    --replicas=5 -n e-commerce-production
                  kubectl scale deployment product-api \
                    --replicas=4 -n e-commerce-production
                  kubectl scale deployment checkout-service \
                    --replicas=3 -n e-commerce-production
                  kubectl scale deployment search-service \
                    --replicas=3 -n e-commerce-production
                  echo "Scale-Down abgeschlossen, HPA uebernimmt"
          restartPolicy: OnFailure

Der HPA laeuft weiterhin parallel. Nach dem Pre-Scaling uebernimmt er die Feinsteuerung: Wenn die tatsaechliche Last hoeher ist als die Pre-Scaled-Kapazitaet, skaliert er weiter hoch. In ruhigeren Phasen skaliert er zurueck -- aber nie unter das Minimum aus der HPA-Konfiguration.

Kosten-Optimierung in der Nebensaison

Die Kehrseite der Peak-Skalierung: 10 Monate im Jahr brauchen Sie nur einen Bruchteil der Kapazitaet. Hier liegt das groesste Einsparpotenzial.

Einsparpotenziale im Ueberblick

Detaillierte Anleitungen zur Kostenoptimierung finden Sie in unserem Praxis-Guide fuer Kubernetes-Kosten.

Dev/Test-Umgebungen zeitgesteuert abschalten

# CronJob: Dev-Umgebung um 20:00 Uhr herunterfahren
apiVersion: batch/v1
kind: CronJob
metadata:
  name: dev-shutdown
  namespace: e-commerce-dev
spec:
  schedule: "0 20 * * 1-5"  # Mo-Fr um 20:00
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: namespace-admin
          containers:
            - name: shutdown
              image: bitnami/kubectl:1.29
              command:
                - /bin/sh
                - -c
                - |
                  kubectl scale deployment --all \
                    --replicas=0 -n e-commerce-dev
                  kubectl scale deployment --all \
                    --replicas=0 -n e-commerce-staging
          restartPolicy: OnFailure
---
# CronJob: Dev-Umgebung um 07:00 Uhr hochfahren
apiVersion: batch/v1
kind: CronJob
metadata:
  name: dev-startup
  namespace: e-commerce-dev
spec:
  schedule: "0 7 * * 1-5"  # Mo-Fr um 07:00
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: namespace-admin
          containers:
            - name: startup
              image: bitnami/kubectl:1.29
              command:
                - /bin/sh
                - -c
                - |
                  kubectl scale deployment shop-frontend \
                    --replicas=1 -n e-commerce-dev
                  kubectl scale deployment product-api \
                    --replicas=1 -n e-commerce-dev
                  kubectl scale deployment shop-frontend \
                    --replicas=1 -n e-commerce-staging
                  kubectl scale deployment product-api \
                    --replicas=1 -n e-commerce-staging
          restartPolicy: OnFailure

Datenbank-Skalierung: Der vergessene Engpass

Die meisten E-Commerce-Teams konzentrieren sich auf die Frontend- und API-Skalierung. Aber wenn 50 Frontend-Pods gleichzeitig auf eine einzelne PostgreSQL-Instanz zugreifen, wird die Datenbank zum Flaschenhals. Und eine Datenbank laesst sich nicht so einfach horizontal skalieren wie ein stateless Service.

Skalierungsstrategien fuer E-Commerce-Datenbanken

Die effektivste Kombination fuer die meisten E-Commerce-Shops: Redis als Cache-Layer vor der Datenbank, PgBouncer als Connection Pooler und Read Replicas fuer leseintensive Workloads wie Produktsuche und Katalogseiten.

CDN-Integration: Statische Assets aus dem Cluster raushalten

Jeder Request, der nicht bis zu Ihren Kubernetes-Pods durchkommt, ist ein Request weniger, den Sie skalieren muessen. Ein CDN (Content Delivery Network) liefert statische Assets -- Produktbilder, CSS, JavaScript -- direkt vom Edge aus.

Die Kombination aus CDN und Kubernetes-Autoscaling bedeutet: Das CDN faengt den groessten Teil der Lastspitze ab. Nur die dynamischen Requests (Checkout, Warenkorb, Login) muessen tatsaechlich von Ihren Pods bearbeitet werden. Das reduziert die Anzahl der benoetigten Pods bei Peak-Traffic erheblich.

Checkliste: 8 Wochen bis Black Friday

Woche 1-2: Analyse

• Letztjaehrige Traffic-Daten auswerten (Peak-Request-Rate, Peak-DB-Connections)
• Aktuelle Resource Requests und Limits aller Deployments pruefen
• Engpaesse identifizieren: Wo sind die Limits zuerst erreicht?
• Monitoring-Stack pruefen: Sind alle relevanten Metriken erfasst?

Woche 3-4: Infrastruktur vorbereiten

• HPA-Konfigurationen ueberpruefen und maxReplicas erhoehen
• Cluster Autoscaler Limits anpassen (genug Headroom fuer neue Nodes)
• Pre-Scaling CronJobs fuer Black Friday anlegen
• CDN-Konfiguration pruefen: Cache-Hit-Rate fuer statische Assets optimieren

Woche 5-6: Datenbank und Cache

• Read Replicas fuer Produktkatalog-Datenbank einrichten
• PgBouncer oder Connection Pooling konfigurieren
• Redis-Cache aufwaermen: Produktdaten, Kategorien, Preise vorladen
• Datenbank-Monitoring: Slow-Query-Logs aktivieren, Connection-Limits pruefen

Woche 7-8: Lasttests und Notfallplaene

• Lasttest mit realistischem Black-Friday-Profil (nicht nur gleichmaessige Last)
• Autoscaling unter Last beobachten: Skaliert der HPA schnell genug?
• Notfallplan dokumentieren: Was passiert bei Datenbankausfall, CDN-Ausfall, Cloud-Region-Stoerung?
• 24/7-On-Call-Rotation fuer die Event-Woche planen

Was schiefgehen kann: Lehren aus der Praxis

1. Cluster-Autoscaler zu langsam

Neue Nodes brauchen 2-5 Minuten, bis sie bereit sind. Wenn der Traffic in Sekunden ansteigt, reicht reaktives Node-Scaling nicht. Die Loesung: Pre-Scaling der Nodes vor dem Event oder Karpenter statt des klassischen Cluster Autoscalers (30-60 Sekunden statt 2-5 Minuten).

2. Connection Limits der Datenbank erreicht

50 neue Pods oeffnen jeweils 10 Datenbankverbindungen -- das sind 500 neue Connections in wenigen Sekunden. PostgreSQL hat standardmaessig ein Limit von 100 Connections. Ohne PgBouncer oder ProxySQL bricht die Datenbank ein, obwohl die Pods healthy sind.

3. Image Pull bei Peak

Wenn 30 neue Pods gleichzeitig starten, muessen alle das Container-Image pullen. Bei grossen Images (500 MB+) und begrenzter Registry-Bandbreite dauert das. Die Loesung: Image Pre-Pulling auf allen Nodes vor dem Event oder kleinere Images durch Multi-Stage Builds.

4. DNS-Throttling

Kubernetes-interne DNS-Aufloesung ueber CoreDNS wird bei hoher Pod-Anzahl zum Engpass. NodeLocal DNSCache reduziert die Last auf CoreDNS erheblich und verbessert die DNS-Latenz.

Kosten: Peak vs. Normalbetrieb

Die Gesamtkosten liegen mit Autoscaling typischerweise 40-60% unter einer statischen Provisionierung fuer Peak-Last. Der groesste Hebel ist das automatische Scale-Down in den 10 Monaten Normalbetrieb.

Fazit

Black Friday muss kein Albtraum fuer Ihr Operations-Team sein. Mit der richtigen Kubernetes-Konfiguration skaliert die Infrastruktur automatisch mit der Last -- und faehrt danach wieder runter.

Die drei wichtigsten Massnahmen:

1. HPA mit Custom Metrics (Requests/Sekunde) statt nur CPU-basiertem Autoscaling. Reagiert schneller auf Traffic-Spitzen.
2. Pre-Scaling vor bekannten Events. Reaktives Autoscaling allein ist zu langsam fuer den initialen Traffic-Anstieg.
3. Datenbank-Skalierung nicht vergessen. Read Replicas, Connection Pooling und Redis-Caching muessen vor dem Peak stehen.

Weiterführende Guides: Der Autoscaling-Guide erklaert die Zusammenarbeit von HPA, VPA und Cluster Autoscaler im Detail. Der Kosten-Optimierung Praxis-Guide zeigt weitere Einsparpotenziale fuer den Normalbetrieb.