WordPress auf Kubernetes: Sieben Fallen zwischen Chart und erster Seite
WordPress läuft auf Kubernetes gut, wenn ein paar Dinge von Anfang an stimmen. Sieben Fallen, die beim ersten Setup fast jeder einmal erlebt, und wie Sie sie umgehen.
WordPress ist nicht für Kubernetes geschrieben worden. Es erwartet einen Server mit Festplatte, eine Datenbank nebenan und einen Administrator, der sich um den Rest kümmert. Trotzdem läuft es auf Kubernetes sehr gut, wenn ein paar Dinge von Anfang an stimmen. Die folgenden sieben Fallen erlebt fast jeder einmal, meistens in den ersten Stunden nach dem ersten helm install.
1. Der offene Installer
Eine frische WordPress-Installation zeigt unter ihrer Adresse den Installer: Seitentitel, Admin-Nutzer, Passwort. Wer ihn zuerst ausfüllt, besitzt die Seite. Das klingt theoretisch, ist es aber nicht. Automatisierte Scanner suchen gezielt nach frischen Installationen, und zwischen dem ersten Deployment und dem Moment, in dem Sie den Installer selbst aufrufen, vergehen oft Minuten, manchmal Stunden, etwa während das Zertifikat ausgestellt wird. Wer in dieser Zeit zuerst kommt, hat einen Admin-Zugang und die Datenbank.
Die Abhilfe ist einfach: Bis der Installer durchlaufen ist, steht die Seite hinter einem Passwort, etwa per Basic Auth am Ingress. Danach wird der Schutz entfernt. Wichtig ist nur, dass es von Anfang an so ist, nicht nachträglich.
2. WP-Cron, der nur bei Besuchern läuft
WordPress plant Aufgaben mit WP-Cron: geplante Beiträge, Update-Prüfungen, Aufgaben von Plugins. Ausgeführt werden sie aber nur, wenn jemand die Seite aufruft. Eine Seite mit wenig Besuchern veröffentlicht einen geplanten Beitrag deshalb Stunden zu spät, eine Seite mit vielen Besuchern startet bei jedem Aufruf unnötige Prüfungen.
Auf Kubernetes gibt es die bessere Lösung eingebaut: einen CronJob, der alle paar Minuten wp-cron.php aufruft, und DISABLE_WP_CRON in der Konfiguration, damit Besucheraufrufe nicht mehr zählen.
3. Eine Festplatte, eine Instanz
WordPress schreibt Uploads, Themes und Plugins in sein Verzeichnis wp-content. Auf Kubernetes liegt es auf einem PersistentVolume, bei Scaleway auf Block Storage, und Block Storage hängt an genau einem Node. Zwei Pods auf zwei Nodes können dieselbe Festplatte nicht gleichzeitig nutzen.
Die Folgen: WordPress läuft mit einer Instanz. Ein Rollout muss die alte Instanz stoppen, bevor die neue startet, sonst wartet die neue ewig auf die Festplatte. Und horizontales Skalieren braucht einen anderen Weg: Uploads in Object Storage auslagern, etwa mit einem Plugin, und den Rest ins Image. Für die meisten Seiten reicht eine Instanz mit ausreichend Ressourcen und einem Cache davor völlig aus.
4. Die Redirect-Schleife hinter dem Ingress
Hinter einem Ingress-Controller spricht WordPress intern HTTP, der Besucher HTTPS. Weiß WordPress nicht, dass die ursprüngliche Anfrage verschlüsselt war, leitet es auf HTTPS um, der Ingress reicht wieder HTTP durch, und der Browser meldet zu viele Umleitungen. Das offizielle WordPress-Image wertet den Header X-Forwarded-Proto aus, den ingress-nginx setzt. Probleme entstehen meist erst durch eine zweite Schicht: Cloudflare im SSL-Modus „Flexible“ spricht mit dem Ursprung unverschlüsselt. Mit „Full (strict)“ und einem gültigen Zertifikat am Ingress ist die Schleife weg.
5. Das Datenbank-Passwort im Klartext
Helm-Charts erwarten das Datenbank-Passwort meist in den Values. Dort liegt es im Git-Repository, im Helm-Release im Namespace und in jedem Ticket, in das jemand die Values kopiert. Besser: Das Passwort wird erzeugt, liegt verschlüsselt und wird in den Values nur referenziert. Und WordPress bekommt eine eigene Datenbank mit eigenem Nutzer, nicht den Admin der Instanz.
6. Uploads, die an der Grenze scheitern
Ein Upload durchläuft mehrere Grenzen: die maximale Anfragegröße des Ingress-Controllers, die Grenzen von PHP und gegebenenfalls die eines Proxys davor. ingress-nginx lässt ohne weitere Einstellung nur ein Megabyte durch, und das Theme-Paket oder das Video scheitert mit einem knappen Fehler 413. Wer Uploads erwartet, setzt die Grenze am Ingress bewusst und prüft die von PHP dazu.
7. Backups von nur einer Hälfte
Eine WordPress-Seite besteht aus zwei Hälften: der Datenbank mit Beiträgen und Einstellungen und der Festplatte mit Uploads, Themes und Plugins. Ein Backup nur der Datenbank bringt Beiträge ohne Bilder zurück, eines nur der Festplatte Bilder ohne Beiträge. Beide gehören gesichert, zeitlich nah beieinander, und beide gehören einmal zurückgespielt, bevor man sich darauf verlässt. Was dabei mit Festplatten aus Helm-Charts passiert, beschreibt Helm-Charts und ihre Festplatten.
Was tun, wenn die WordPress-Seite wächst?
Eine Seite mit einer Instanz trägt mehr, als viele denken. Die Engpässe liegen fast immer in der Datenbank und bei PHP, nicht in der Zahl der Pods. Drei Schritte helfen, bevor man über mehrere Instanzen nachdenkt: ein Seiten-Cache als Plugin oder vor der Seite, ein Objekt-Cache für die Datenbankabfragen und ausreichend CPU und Speicher für den einen Pod. Erst wenn das nicht mehr reicht, lohnt der Umbau auf mehrere Instanzen mit Uploads in Object Storage und einem Image, das WordPress und Plugins enthält, statt sie auf der Festplatte zu pflegen.
Was gehört vor den Start der ersten Seite?
- Installer bis zur Einrichtung hinter einem Passwort
- Echter Cron-Job, WP-Cron abgeschaltet
- Eine Instanz, Rollout mit Stoppen vor dem Start
- Cloudflare, falls davor, im Modus „Full (strict)“
- Eigene Datenbank, Passwort nicht im Klartext
- Upload-Grenzen am Ingress und in PHP geprüft
- Snapshots der Festplatte und Backups der Datenbank, einmal getestet
Wie löst der App-Katalog diese Fallen?
Im App-Katalog von Clusterward ist WordPress die erste Vorlage, und sie nimmt die meisten Punkte dieser Liste ab: Sie geben Namen, Domain, Cluster und MySQL-Instanz an, Clusterward legt eine eigene Datenbank mit erzeugtem Passwort an, das in den Values nur referenziert wird, dazu eine Festplatte mit täglichen Snapshots, einen Cron-Job alle fünf Minuten, das Zertifikat und bei registrierter Zone den DNS-Record. WordPress läuft mit genau einer Instanz und wird beim Update erst gestoppt, dann neu gestartet. Die Festplatte ist so markiert, dass sie ein Undeploy übersteht. Bis Sie den Installer durchlaufen haben, fragt die Seite nach einem Einrichtungs-Passwort; „Open to everyone“ entfernt es. Ingress-Anfragen dürfen standardmäßig 64 MB groß sein. Danach ist die Seite eine normale Anwendung mit Logs, Auslastung und Uptime-Checks. Zwei Dinge bleiben bei Ihnen: DISABLE_WP_CRON nach der Einrichtung in der wp-config.php setzen, damit nur noch der Cron-Job zählt, und bei Cloudflare den SSL-Modus prüfen. Mehr unter WordPress auf Kubernetes; wie die Festplatte gesichert wird, unter Volumes & Snapshots, die Datenbank-Instanz unter Managed Datenbanken.
Fazit
WordPress auf Kubernetes scheitert selten an Kubernetes, sondern an den Annahmen, die WordPress über seinen Server macht. Schützen Sie den Installer, ersetzen Sie WP-Cron, planen Sie die Festplatte für eine Instanz und sichern Sie beide Hälften. Dann läuft die Seite so ruhig wie auf jedem anderen Server, nur mit Snapshots, Logs und Rollbacks dazu.
WordPress-Seiten auf Kubernetes geplant? Erzählen Sie uns, wie viele Seiten Sie betreiben. Wir zeigen, wie der App-Katalog sie anlegt und sichert. Frage stellen →
Quellen und weiterführende Links
Häufige Fragen
- Stellen Sie die Seite hinter ein Passwort, etwa per Basic Auth am Ingress, bis der Installer durchlaufen ist, und entfernen Sie den Schutz danach. Sonst kann jemand anderes den Installer zuerst ausfüllen und hat Admin-Zugang und Datenbank. Automatisierte Scanner suchen gezielt nach frischen Installationen.