Kubernetes für die E-Commerce-Skalierung: Von Traffic-Spitzen bis zur globalen Expansion

Verkehrsspitzen am Black Friday können die E-Commerce-Last innerhalb von Minuten um das 10- bis 50-fache erhöhen. Herkömmliche Serverinfrastrukturen können nicht schnell genug reagieren. Kubernetes bietet die Funktionen zur automatischen Skalierung, Selbstheilung und Verkehrsverwaltung, die moderne E-Commerce-Plattformen benötigen, um unvorhersehbare Nachfrage ohne Überbereitstellung in ruhigen Zeiten zu bewältigen.

Dieser Leitfaden behandelt die Kubernetes-Architektur speziell für E-Commerce-Workloads, von der Abwicklung von Flash-Verkäufen bis zum Aufbau von Storefronts mit mehreren Regionen, die Kunden unabhängig vom Standort in weniger als 200 ms bedienen.

Wichtige Erkenntnisse

• Horizontal Pod Autoscaler (HPA) kann E-Commerce-Dienste in weniger als 90 Sekunden von 2 auf 200 Pods skalieren – Ingress-Controller mit Ratenbegrenzung schützen Backend-Dienste bei Datenverkehrsspitzen – Zustandsbehaftete Arbeitslasten (Datenbanken, Suchindizes) erfordern andere Skalierungsstrategien als zustandslose Dienste – Multiregionale Kubernetes-Bereitstellungen reduzieren die Latenz für globale Kundenstämme um 60–80 %

---

Wenn Kubernetes für den E-Commerce Sinn macht

Kubernetes ist nicht immer die richtige Antwort. Es erhöht die betriebliche Komplexität, die durch die Skalierungsanforderungen gerechtfertigt werden muss.

Entscheidungsmatrix

Wenn Ihr Unternehmen in die Spalte „Docker Compose“ fällt, lesen Sie stattdessen unseren Leitfaden zur Docker-Produktionsbereitstellung.

---

Kubernetes-Architektur für E-Commerce

Cluster-Layout

Ein eCommerce-Kubernetes-Cluster enthält normalerweise die folgenden Namespaces:

• storefront: Frontend-Anwendungs-Pods
• api: Backend-API-Dienste
• workers: Hintergrund-Jobprozessoren (Bestellabwicklung, E-Mail-Versand, Bestandssynchronisierung)
• data: Datenbanken, Caches und Suchmaschinen (oder verwaltete externe Dienste)
• ingress: Ingress-Controller und Load Balancer
• monitoring: Prometheus, Grafana, Alarmierung

Bereitstellungskonfiguration

# storefront-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: storefront
  namespace: storefront
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: storefront
  template:
    metadata:
      labels:
        app: storefront
    spec:
      containers:
        - name: storefront
          image: registry.example.com/storefront:v2.1.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 1000m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20
          env:
            - name: API_URL
              value: "http://api-service.api.svc.cluster.local:3001"
            - name: NODE_ENV
              value: "production"

---

Auto-Scaling-Konfiguration

Horizontaler Pod-Autoscaler

# storefront-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: storefront-hpa
  namespace: storefront
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: storefront
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

Die scaleUp-Richtlinie ermöglicht die Verdoppelung von Pods alle 60 Sekunden – entscheidend für die Bewältigung plötzlicher Datenverkehrsspitzen. Die scaleDown-Richtlinie ist konservativ (10 % pro Minute), um Thrashing zu verhindern.

Cluster-Autoscaler

HPA skaliert Pods, aber Pods benötigen Knoten. Der Cluster Autoscaler fügt Knoten basierend auf ausstehenden Pod-Anforderungen hinzu und entfernt sie:

# cluster-autoscaler configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  balance-similar-node-groups: "true"
  skip-nodes-with-local-storage: "false"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"
  max-node-provision-time: "5m"

Konfigurieren Sie für AWS EKS Knotengruppen mit minimalen/maximalen Größen:

eksctl create nodegroup \
  --cluster ecommerce-prod \
  --name workers \
  --node-type t3.large \
  --nodes-min 3 \
  --nodes-max 20 \
  --node-volume-size 50 \
  --managed

---

Ingress- und Traffic-Management

Nginx-Ingress-Controller

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ecommerce-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/rate-limit-window: "1m"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
    - hosts:
        - store.example.com
      secretName: store-tls
  rules:
    - host: store.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 3001
          - path: /
            pathType: Prefix
            backend:
              service:
                name: storefront-service
                port:
                  number: 3000

Abwicklung von Flash-Verkäufen

Flash-Verkäufe erfordern eine Vorskalierung. Verlassen Sie sich bei bekannten Ereignissen mit hohem Datenverkehr nicht allein auf die automatische Skalierung:

# Pre-scale 2 hours before a flash sale
kubectl scale deployment storefront --replicas=20 -n storefront
kubectl scale deployment api --replicas=15 -n api
kubectl scale deployment order-worker --replicas=10 -n workers

# After the sale, let HPA scale down naturally

---

Datenbankskalierung in Kubernetes

Verwaltete vs. selbstgehostete Datenbanken

Empfehlung: Verwenden Sie verwaltete Datenbanken für den Produktions-E-Commerce. Der betriebliche Aufwand für die Ausführung von PostgreSQL in Kubernetes ist für die meisten Unternehmen nicht gerechtfertigt.

Verbindungspooling

# pgbouncer-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pgbouncer
  namespace: data
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: pgbouncer
          image: edoburu/pgbouncer:1.21.0
          ports:
            - containerPort: 5432
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
            - name: MAX_CLIENT_CONN
              value: "1000"
            - name: DEFAULT_POOL_SIZE
              value: "25"
            - name: POOL_MODE
              value: "transaction"

PgBouncer ermöglicht im Transaktionspooling-Modus Hunderten von Anwendungs-Pods die gemeinsame Nutzung eines begrenzten Pools von Datenbankverbindungen. Ohne Verbindungspooling würde die Skalierung auf 50 API-Pods 50 x 20 = 1.000 Datenbankverbindungen erfordern, was die meisten PostgreSQL-Instanzen überfordern würde.

Weitere Strategien zur Datenbankskalierung finden Sie in unserem Leitfaden zur Datenbankskalierung.

---

Bereitstellung in mehreren Regionen

Architektur

Eine multiregionale E-Commerce-Kubernetes-Bereitstellung verwendet Folgendes:

1. Regionale Cluster: Unabhängige Kubernetes-Cluster in jeder Region
2. Globaler Load Balancer: Leitet Benutzer zur nächstgelegenen Region weiter (AWS Global Accelerator, Cloudflare)
3. Datenbankreplikation: Primär in einer Region, Lesereplikate in anderen
4. CDN: Statische Assets, die von Edge-Standorten weltweit bereitgestellt werden

Auswirkung auf die Latenz

Durch die Bereitstellung in mehreren Regionen wird die Latenz für internationale Kunden um 60–90 % reduziert, was die Konversionsraten direkt verbessert. Studien zeigen, dass alle 100 ms Latenzreduzierung die E-Commerce-Conversion um 1,1 % steigert.

---

Überwachung des Kubernetes-E-Commerce

Wichtige Dashboards

1. Geschäftskennzahlen: Bestellungen pro Minute, Warenkorb-Conversion-Rate, Umsatz pro Stunde
2. Anwendungsmetriken: Anforderungslatenz (P50, P95, P99), Fehlerrate, aktive Sitzungen
3. Infrastrukturmetriken: Pod-CPU/Speicher, Knotenauslastung, HPA-Aktivität
4. Datenbankmetriken: Verbindungsanzahl, Abfragelatenz, Replikationsverzögerung

# prometheus-servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: api
  endpoints:
    - port: metrics
      interval: 15s
      path: /metrics

---

Häufig gestellte Fragen

Wie viel kostet Kubernetes im Vergleich zu herkömmlichem Hosting?

Die Kubernetes-Infrastruktur kostet aufgrund der Control-Plane-Kosten, Load-Balancer-Gebühren und des Knoten-Overheads 20–40 % mehr als entsprechende Bare-Metal- oder einfache Cloud-Instanzen. Durch die automatische Skalierung werden die Gesamtausgaben jedoch in der Regel um 30–50 % reduziert, da Sie nicht für die Spitzenkapazität außerhalb der Spitzenzeiten zahlen. Der Nettoeffekt für die meisten E-Commerce-Unternehmen mit variablem Datenverkehr ist eine Kostenreduzierung von 10–25 %.

Können wir Odoo auf Kubernetes ausführen?

Ja, aber mit Vorbehalten. Der Dateispeicher von Odoo erfordert gemeinsam genutzten dauerhaften Speicher (EFS, NFS), wenn mehrere Replikate ausgeführt werden. Sitzungsaffinität ist erforderlich, es sei denn, Sie externalisieren Sitzungen an Redis. Datenbankverbindungen müssen über PgBouncer gepoolt werden. Für die meisten Odoo-Bereitstellungen ist Docker Compose oder ECS einfacher und ausreichend. Kubernetes ist für große Odoo-Bereitstellungen mit mehr als 200 gleichzeitigen Benutzern sinnvoll.

Wie gehen wir mit Kubernetes-Upgrades ohne Ausfallzeiten um?

Verwenden Sie einen verwalteten Kubernetes-Dienst (EKS, GKE, AKS), der Upgrades der Steuerungsebene abwickelt. Verwenden Sie für Knoten-Upgrades eine fortlaufende Strategie: Einen Knoten absperren, seine Pods entleeren (sie werden auf andere Knoten umgeplant), den Knoten aktualisieren und die Absperrung aufheben. Mit den entsprechenden Budgets für die Pod-Unterbrechung erfolgt dies vollständig automatisiert und ohne Ausfallzeiten.

Was ist die Mindestclustergröße für Produktions-E-Commerce?

Ein minimaler Produktionscluster für eine mittelgroße E-Commerce-Plattform: 3 Knoten (t3.large oder gleichwertig) für Anwendungs-Workloads sowie eine verwaltete Datenbankinstanz. Dies ist für etwa 500 gleichzeitige Benutzer geeignet und bietet Platz für die automatische Skalierung bei Spitzenzeiten. Gesamtkosten für die Infrastruktur: ca. 500–800 US-Dollar pro Monat.

---

Was als nächstes kommt

Kubernetes bietet die Skalierungsgrundlage, ist jedoch nur ein Teil des Infrastrukturpuzzles. Kombinieren Sie es mit CI/CD-Best Practices, CDN-Optimierung und Lasttests für eine vollständige E-Commerce-Betriebsplattform.

Kontaktieren Sie ECOSIRE für Kubernetes-Beratung und E-Commerce-Skalierungsstrategie oder erkunden Sie unsere Shopify-Integrationsdienste für Managed Headless Commerce auf Kubernetes.

---

Herausgegeben von ECOSIRE – unterstützt Unternehmen bei der weltweiten Skalierung ihrer E-Commerce-Infrastruktur.