Veröffentlicht am

WordPress auf Kubernetes: sicher deployen & betreiben

Teilen:
Authors

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

SchrittKubernetes-RessourceZweck
1ConfigMapKonfiguration der Anwendung
2MySQL als StatefulSetDatenbank mit persistentem Volume
3Service (ClusterIP)Interne Erreichbarkeit der DB
4WordPress-DeploymentDie eigentliche Anwendung
5Service (LoadBalancer)Öffentliche IP-Adresse
6DNS/InstallationDomain zuweisen, WordPress einrichten

Der Ablauf Schritt für Schritt

  1. Cluster provisionieren: Managed Kubernetes, Region nahe am Standort, passende Node-Größen.
  2. Lokale Tools: VSCode, Docker, kubectl.
  3. ConfigMap anwenden: kubectl apply -f configmap
  4. Datenbank starten: MySQL als StatefulSet — provisioniert automatisch ein Volume.
  5. Service für die DB: Interne ClusterIP.
  6. WordPress deployen: Deployment + LoadBalancer → öffentliche IP.
  7. 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:

KriteriumTutorial-DeploymentEnterprise-Betrieb
VerfügbarkeitEin Node, kein FailoverMulti-Zone, Autoscaling, HA-Control-Plane
DatenKein Backup-KonzeptAutomatisierte Backups, Recovery-Tests
SicherheitAdmin-Rechte überallLeast Privilege, Secrets-Management, Network Policies, Image-Scanning
BetriebManuell, einmaligMonitoring, Logging, Updates, Patches, Rollbacks — kontinuierlich
AuditDokumentation, 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:

KostenfaktorSelbstbetriebManaged Service
Senior-EngineeringSchwer zu besetzen, teuerIm Paket enthalten
HA & Multi-ZoneZusätzlicher AufwandTeil des Betriebsmodells
Backups & RecoveryMuss selbst gebaut werdenAutomatisiert, getestet
Security-PflegeLaufende EigenleistungKontinuierlich
Updates & PatchesManuell, schnell veraltetPlanbar, dokumentiert
KostenVersteckter interner AufwandPlanbar, 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

  1. Stateful ist der harte Teil: Stateless Deployments sind einfach, StatefulSets (Datenbanken) sind der Punkt, an dem Kubernetes-Betrieb anspruchsvoll wird.
  2. Admin-Rechte gehören nicht in Produktion: Minimale Permissions und Service Accounts sind Pflicht — die Admin-kubeconfig ist ein Lern-Tool, kein Betriebs-Tool.
  3. Ein Cluster ist keine Produktionsumgebung: Hochverfügbarkeit, Backups und Monitoring sind Pflicht, kein Extra.
  4. Kosten müssen geplant sein: Wer nur Node-Kosten rechnet, übersieht Security, Monitoring, Fachkräfte und Pflege.
  5. 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:

  1. Die Bausteine verstehen: ConfigMap, StatefulSet, Service, Deployment, LoadBalancer.
  2. Stateful ist der Kern: Persistente Volumes und Datenbank-Betrieb sind der anspruchsvolle Teil.
  3. Tutorial ≠ Produktion: HA, Backups, Security, Monitoring und Pflege sind Pflicht.
  4. 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