- Authors

- Name
- Phillip Pham
- @ddppham
WordPress auf Kubernetes: Vom Deployment zum professionellen Betrieb
TL;DR
- WordPress ist der ideale Einstieg in StatefulSets und Datenbank-Betrieb auf Kubernetes — es bringt die typischen Herausforderungen produktiver Systeme mit: Datenbank, persistenten Speicher, Webserver und externe Erreichbarkeit.
- Der Deployment-Weg: ConfigMap → MySQL als StatefulSet → Service (ClusterIP) → WordPress-Deployment → Service (LoadBalancer) → DNS/Installation.
- Die Bausteine sind dieselben, auf denen auch moderne KI-Plattformen laufen — Vektor-Datenbanken, LLM-Inference, Agent-Runtimes.
- Ein funktionierender Cluster ist keine Produktionsumgebung: Der Unterschied liegt in Hochverfügbarkeit, Backups, Security, Monitoring und kontinuierlicher Pflege.
- Stateful ist der harte Teil: Stateless Deployments sind einfach, StatefulSets (Datenbanken) sind der Punkt, an dem Kubernetes-Betrieb anspruchsvoll wird.
Warum WordPress auf Kubernetes?
WordPress ist eine der am weitesten verbreiteten Anwendungen der Welt — und ein hervorragendes Übungsobjekt für Kubernetes. Es erzwingt genau das, was produktive Systeme ausmacht: Die MySQL-Datenbank muss persistent sein, sonst sind alle Daten beim Neustart weg.
Kubernetes ist bekannt für stateless Container — doch produktive Systeme brauchen Zustand: Datenbanken, Dateien, Sessions. WordPress erzwingt genau das. Das Deployment über ein StatefulSet (mit Volume) ist damit eine realistische, alltägliche Übung für eine der wichtigsten Kubernetes-Fähigkeiten.
Der Bezug zu KI-Plattformen
Die gleichen Bausteine — Stateful-Workloads, persistente Volumes, Services, Load-Balancing — tragen auch moderne KI-Plattformen: Vektor-Datenbanken, LLM-Inference, Agent-Runtimes. Wer Kubernetes für WordPress beherrscht, hat das Fundament für den Betrieb anspruchsvoller Systeme.
Der Deployment-Ablauf in der Praxis
Die Architektur in einem Bild
| Schritt | Kubernetes-Ressource | Zweck |
|---|---|---|
| 1 | ConfigMap | Konfiguration der Anwendung |
| 2 | MySQL als StatefulSet | Datenbank mit persistentem Volume |
| 3 | Service (ClusterIP) | Interne Erreichbarkeit der DB |
| 4 | WordPress-Deployment | Die eigentliche Anwendung |
| 5 | Service (LoadBalancer) | Öffentliche IP-Adresse |
| 6 | DNS/Installation | Domain zuweisen, WordPress einrichten |
Der Ablauf Schritt für Schritt
- Cluster provisionieren: Managed Kubernetes, Region nahe am Standort, passende Node-Größen.
- Lokale Tools: VSCode, Docker, kubectl.
- ConfigMap anwenden:
kubectl apply -f configmap - Datenbank starten: MySQL als StatefulSet — provisioniert automatisch ein Volume.
- Service für die DB: Interne ClusterIP.
- WordPress deployen: Deployment + LoadBalancer → öffentliche IP.
- Installation abschließen: WordPress-Assistent, Domain zuweisen.
Die kubeconfig-Verwaltung (der oft übersehene Teil)
Die kubeconfig-Datei sicher ablegen und KUBECONFIG-Umgebungsvariable setzen. Wichtig für Produktion: Die Admin-kubeconfig mit vollen Rechten ist zum Lernen ok, nie für Produktion. Dort minimale Permissions und Service Accounts verwenden.
# kubeconfig sicher ablegen und setzen
export KUBECONFIG=~/.kube/config-prod
# Produktion: minimale Permissions statt Admin-kubeconfig
kubectl auth can-i --list
Das Beispiel: StatefulSet für MySQL
Das Herzstück des Deployments ist die Datenbank als StatefulSet — der Punkt, an dem Kubernetes-Betrieb anspruchsvoll wird:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: mysql
replicas: 1
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:8
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: root-password
volumeMounts:
- name: data
mountPath: /var/lib/mysql
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ['ReadWriteOnce']
resources:
requests:
storage: 10Gi
Der entscheidende Unterschied zum Deployment: das persistente Volume via volumeClaimTemplates. Ohne dieses Volume sind alle WordPress-Daten beim Neustart weg.
Was ein Tutorial zeigt — und was nicht
Ein funktionierender Cluster ist noch keine Produktionsumgebung. Der Unterschied ist der eigentliche Wert:
| Kriterium | Tutorial-Deployment | Enterprise-Betrieb |
|---|---|---|
| Verfügbarkeit | Ein Node, kein Failover | Multi-Zone, Autoscaling, HA-Control-Plane |
| Daten | Kein Backup-Konzept | Automatisierte Backups, Recovery-Tests |
| Sicherheit | Admin-Rechte überall | Least Privilege, Secrets-Management, Network Policies, Image-Scanning |
| Betrieb | Manuell, einmalig | Monitoring, Logging, Updates, Patches, Rollbacks — kontinuierlich |
| Audit | — | Dokumentation, Nachweisbarkeit, Compliance |
Die ehrliche Gegenrechnung
Ein eigener Kubernetes-Betrieb kostet intern schnell das Doppelte eines Managed Service, wenn man Senior-Engineering, HA, Security, Monitoring und laufende Pflege ehrlich einrechnet:
| Kostenfaktor | Selbstbetrieb | Managed Service |
|---|---|---|
| Senior-Engineering | Schwer zu besetzen, teuer | Im Paket enthalten |
| HA & Multi-Zone | Zusätzlicher Aufwand | Teil des Betriebsmodells |
| Backups & Recovery | Muss selbst gebaut werden | Automatisiert, getestet |
| Security-Pflege | Laufende Eigenleistung | Kontinuierlich |
| Updates & Patches | Manuell, schnell veraltet | Planbar, dokumentiert |
| Kosten | Versteckter interner Aufwand | Planbar, transparent |
Ein „billiger" Einstiegs-Cluster wird in der Produktion teuer — durch Nacharbeit, Ausfälle und Sicherheitslücken. Kubernetes veraltet schnell: Wer nicht pflegt, hat nach Monaten einen unsicheren Cluster.
Lessons Learned aus der Praxis
- Stateful ist der harte Teil: Stateless Deployments sind einfach, StatefulSets (Datenbanken) sind der Punkt, an dem Kubernetes-Betrieb anspruchsvoll wird.
- Admin-Rechte gehören nicht in Produktion: Minimale Permissions und Service Accounts sind Pflicht — die Admin-kubeconfig ist ein Lern-Tool, kein Betriebs-Tool.
- Ein Cluster ist keine Produktionsumgebung: Hochverfügbarkeit, Backups und Monitoring sind Pflicht, kein Extra.
- Kosten müssen geplant sein: Wer nur Node-Kosten rechnet, übersieht Security, Monitoring, Fachkräfte und Pflege.
- Betrieb ist kontinuierlich: Ungepflegte Cluster werden zum Haftungsrisiko — das ist der Kern der Betriebsverantwortung.
Fazit
WordPress auf Kubernetes ist der ideale Einstieg in den professionellen Betrieb stateful Workloads — und ein realistisches Bild davon, was produktiven Kubernetes-Betrieb ausmacht:
- Die Bausteine verstehen: ConfigMap, StatefulSet, Service, Deployment, LoadBalancer.
- Stateful ist der Kern: Persistente Volumes und Datenbank-Betrieb sind der anspruchsvolle Teil.
- Tutorial ≠ Produktion: HA, Backups, Security, Monitoring und Pflege sind Pflicht.
- Betrieb ist kontinuierlich: Kubernetes veraltet schnell — ungepflegte Cluster sind ein Haftungsrisiko.
FAQ
Braucht WordPress wirklich Kubernetes? Nein — für eine einzelne kleine Seite reicht gehostetes WordPress. Kubernetes lohnt sich bei Skalierung, Hochverfügbarkeit und vielen Workloads auf einer Plattform. Die ehrliche Einordnung gehört zu einer guten Beratung.
Was kostet professioneller Kubernetes-Betrieb? Mehr als die reinen Node-Kosten. Ein Managed Service mit HA, Security, Backups und Monitoring macht es planbar — im Vergleich zum internen Aufwand (Senior-Engineering, laufende Pflege) meist die günstigere und sicherere Variante.
Wie hängt WordPress mit KI zusammen? KI-Plattformen (Vektor-DBs, LLM-Inference, Agents) laufen auf denselben Kubernetes-Bausteinen: Stateful-Workloads, persistente Volumes, Services, Load-Balancing.
Reicht ein einzelner Node für den Einstieg? Fürs Lernen ja. Für Produktion nein — ohne Multi-Zone, Failover und Backups ist ein einzelner Node ein Single Point of Failure.
Verwandte Artikel
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
Kafka auf Kubernetes: Der Event-Broker für ereignisgesteuerte Architekturen
Kafka auf Kubernetes: Vom Message-Broker zum Rückgrat ereignisgesteuerter Architekturen. Producer, Topics, Partitions & Consumer Groups verstehen — und Kafka richtig betreiben.
NIS2: betroffen oder nicht? Die Schwellenwerte ohne Beratersprech
Die exakten Schwellenwerte aus § 28 BSIG, die Sektorenlisten in verständlich, und der Fall, der die meisten Mittelständler trifft: Betroffenheit über die Lieferkette. Plus was gilt, nachdem die gesetzliche Registrierungsfrist abgelaufen ist.
Kubernetes-Wissen aufbauen trotz Managed Service
Kubernetes-Wissen intern aufbauen, obwohl ein Managed Service den Betrieb übernimmt. Training, Shadowing und Knowledge Transfer als Vertragsbestandteil.
Kubernetes Vendor Lock-in vermeiden: Exit-Strategie 2026
Vendor Lock-in bei Managed Kubernetes vermeiden: Portable Helm-Charts, Exit-Klauseln & Terraform. Anbieterwechsel in 4-8 Wochen statt 6 Monaten.
Kubernetes Backup mit Velero: Praxis-Strategie (2026)
Kubernetes Backup mit Velero: Cluster-Backups, Persistent Volumes sichern, Restore-Tests automatisieren. Solide DR-Strategie aufbauen.
Managed Kubernetes München: Anbieter-Vergleich 2026
Managed Kubernetes in München: 10 Anbieter im Vergleich (EKS, AKS, GKE, EU) – branchenspezifische Empfehlungen für Automotive, Versicherung, Enterprise.
Kubernetes Resilience Patterns für produktive Cluster
Praxisnahe Resilience Patterns für Kubernetes: Pod Anti-Affinity, Circuit Breaker, HPA, PDB und Chaos Engineering mit konkreten YAML-Beispielen.
Managed Kubernetes Anbieter: Kosten & Vergleich (2026)
Managed Kubernetes Anbieter in Deutschland 2026 im ehrlichen Vergleich: echte Preise, SLA-Tabellen und eine Entscheidungsmatrix für KMU und Enterprise.