Kubernetes (Web)

Definition: Kubernetes (K8s) ist ein 2014 von Google als Open Source veröffentlichtes Container-Orchestrierungssystem, das Deployment, Skalierung, Load Balancing und Self-Healing von containerisierten Webanwendungen automatisiert. Kubernetes gruppiert Container in Pods, verteilt sie auf Cluster-Nodes und verwaltet deren Lebenszyklus über deklarative YAML-Konfigurationen. Managed Kubernetes-Dienste wie Google Kubernetes Engine (GKE), Amazon EKS und Azure AKS nehmen den Betrieb des Control Planes ab. Im Web-Marketing-Kontext ist Kubernetes primär relevant als Infrastruktur für High-Traffic-Websites, Server-Side Tagging (sGTM), API-Services und Microservices-Architekturen die automatisch bei Kampagnen-Peaks skalieren müssen.

Erläuterung

Kubernetes ist für die meisten kleinen und mittleren Websites überdimensioniert – Docker Compose oder serverlose Plattformen wie Vercel oder Cloud Run sind einfacher und günstiger. Kubernetes wird relevant wenn: (1) hoher Traffic mit Lastspitzen (Kampagnenstarts, Black Friday), (2) viele verschiedene Services parallel betrieben werden, (3) Zero-Downtime-Deployments absolut kritisch sind, oder (4) das Team bereits Container-Expertise aufgebaut hat. Die Lernkurve ist steil, der Operational Overhead hoch.

Kubernetes-Kernkonzepte

Pod: Kleinste deploybare Einheit; 1+ Container die sich Netzwerk und Storage teilen; ephemeral (nach Ausfall neuer Pod statt Restart); typischerweise 1 Container pro Pod für Webanwendungen; Sidecar-Pattern: zweiter Container für Logging/Monitoring im gleichen Pod
Deployment: Verwaltet Anzahl gewünschter Pod-Replicas; Rolling Update: neue Version schrittweise ausrollen während alte läuft; Rollback: kubectl rollout undo deployment/my-app; ReplicaSet sichert dass immer N Pods laufen; Basis für Zero-Downtime-Deployments
Service: Stabile Netzwerk-Adresse für eine Gruppe von Pods; ClusterIP (intern), NodePort (extern via Node-Port), LoadBalancer (Cloud-Load-Balancer); Pods kommen und gehen – Service-IP bleibt konstant; Grundlage für Service-to-Service-Kommunikation
ConfigMap und Secret: Konfigurationen (URLs, Feature Flags) und Secrets (API-Keys, DB-Passwörter) getrennt vom Image; Secrets Base64-encodiert (nicht verschlüsselt – externe Secret-Manager wie AWS Secrets Manager empfohlen); Änderungen ohne Image-Rebuild möglich

Skalierung und Verfügbarkeit

Horizontal Pod Autoscaler (HPA): Skaliert Pod-Anzahl automatisch basierend auf CPU/Memory-Nutzung oder Custom Metrics; kubectl autoscale deployment web --min=3 --max=20 --cpu-percent=60; bei Kampagnen-Traffic: automatisch von 3 auf 20 Pods; nach Peak: zurück auf 3; spart Kosten gegenüber permanent hoher Pod-Anzahl
Vertical Pod Autoscaler (VPA): Passt CPU/Memory-Requests pro Pod an; empfiehlt optimale Resource-Requests basierend auf historischem Verbrauch; nicht zusammen mit HPA auf gleiche Metrik anwenden
Cluster Autoscaler: Skaliert Anzahl der Nodes (Server) im Cluster; wenn HPA mehr Pods will aber kein Node Kapazität hat: neuer Node wird automatisch provisioniert (Cloud-VMs); bei GKE und EKS standardmäßig verfügbar; Cluster-Scaling dauert 1–3 Minuten
Pod Disruption Budget (PDB): Garantiert Minimum-Verfügbarkeit während Cluster-Updates und Wartung; minAvailable: 2 bedeutet immer mindestens 2 Pods laufen; verhindert vollständige Downtime bei Node-Draining; für Produktions-Deployments obligatorisch

Managed Kubernetes und Alternativen

Google Kubernetes Engine (GKE): Vollständig managed Control Plane (kostenlos); Autopilot-Modus: kein Node-Management, nur Pod-Konfiguration; beste Integration mit Google Cloud (Cloud Build, Artifact Registry, Cloud SQL); empfohlen für Teams die bereits Google Cloud nutzen
Amazon EKS: AWS-managed Kubernetes; gute Integration mit AWS-Diensten (ALB Ingress Controller, ECR, RDS); Fargate für serverless Pods (kein Node-Management); Control Plane: 72 USD/Monat pro Cluster; höherer Konfigurationsaufwand als GKE Autopilot
Google Cloud Run (Alternative): Serverless Container ohne Kubernetes-Komplexität; automatische Skalierung auf 0 (kostenlos wenn idle); ideal für sGTM, APIs, Event-driven Workloads; empfohlen wenn Kubernetes-Overhead nicht gerechtfertigt ist; bis 2 Mio. Requests/Monat kostenlos
Helm: Package Manager für Kubernetes; Chart = vorkonfiguriertes Kubernetes-Deployment; helm install nginx-ingress ingress-nginx/ingress-nginx; wiederverwendbare Konfigurationen; Werte (Values) für Umgebungsunterschiede (staging vs. production)

Marketing-Infrastruktur-Anwendungsfälle

Server-Side Tagging (sGTM): Google Tag Manager Server-Side als Container auf Kubernetes oder Cloud Run; Skalierung bei Traffic-Spitzen automatisch; eigene Domain für First-Party-Tracking; Kubernetes ermöglicht feingranularere Ressourcenkontrolle als Cloud Run bei hohem Traffic
Kampagnen-Peak-Management: Produktlaunch-Traffic von 10× normalem Niveau; HPA skaliert Web-App-Pods automatisch; Cluster Autoscaler provisioniert neue Nodes; kein manuelles «mehr Server bitte»; nach Peak automatische Skalierung nach unten (Kosteneinsparung)
Blue-Green und Canary Deployments: Kubernetes Ingress oder Service Mesh (Istio) für Traffic-Splitting; Canary: 5 % Traffic auf neue Version, 95 % auf alte; Metriken beobachten; bei Problemen Traffic zurückswitchen in Sekunden; besonders wertvoll für Checkout-Deploys

Praxistipp: Für die meisten Marketing-Websites ist Kubernetes überdimensioniert – evaluieren Sie zuerst Google Cloud Run oder AWS Fargate für containerisierte Workloads. Cloud Run für Server-Side GTM (sGTM) ist der häufigste Marketing-relevante Kubernetes-Alternative-Anwendungsfall: Ein sGTM-Container auf Cloud Run kostet unter 5 €/Monat bei kleinem Traffic, skaliert automatisch und erfordert keine Kubernetes-Kenntnisse. Kubernetes lohnt sich wenn Ihr Team bereits Container-Erfahrung hat, Sie mehrere Services parallel betreiben und Peak-Traffic-Skalierung automatisch erfolgen muss – dann ist GKE Autopilot der einfachste Einstieg.