WordPress op Kubernetes: uitdagingen en aanpak

Scope: Single-site als uitgangspunt

We richten ons primair op een single-site WordPress installatie op Kubernetes. Dit is het meest voorkomende scenario en maakt de kernproblemen – state, storage, updates en lifecycle – het duidelijkst zichtbaar. In een single-site setup is één WordPress site geïnstalleerd per Kubernetes deployment, met een eigen database en bestandsopslag. Alle aandacht kan uitgaan naar het hoog beschikbaar en schaalbaar maken van deze ene site, zonder complicaties van gedeelde resources tussen sites.

Multisite (meerdere sites binnen één WordPress installatie) behandelen we kort als een edge-case. Multisite voegt extra complexiteit toe bovenop de single-site uitdagingen. We zullen zien dat multisite een grotere blast radius heeft – één probleem in het platform kan meerdere sites tegelijk raken – en dat beheer (updates, rollbacks, governance) lastiger wordt. Om die redenen houden we multisite buiten de hoofdlijn en bespreken we het apart in een latere sectie.

WordPress en Stateful Uitdagingen op Kubernetes

WordPress is van oorsprong een stateful applicatie. Het heeft twee kernonderdelen die data behouden moeten blijven: een MySQL database en een bestandsdirectory voor uploads (media) en extensies (plugins/themes). Traditioneel draaien deze onderdelen op één server (LAMP-stack), maar in een Kubernetes-omgeving met ephemeral pods moeten we expliciet zorgen voor persistentie. Zonder maatregelen gaat bij elke pod herstart of verplaatsing data verloren.

Persistent storage is dus cruciaal. De database moet bijvoorbeeld op een persistent volume of externe service draaien, anders zouden posts en instellingen verdwijnen bij een pod restart. Evenzo moeten media-uploads en geüploade plugins buiten de container bewaard worden (bijv. via een PersistentVolumeClaim), zodat ze bij herstarts behouden blijven. Kortom, we hebben opslag nodig voor zowel de WordPress-bestanden (wp-content) als de MySQL data.

Daarnaast is er de kwestie van updates en mutaties aan de WordPress code zelf. In een klassieke setup kan een gebruiker via de WP-admin nieuwe plugins of thema’s installeren en updates uitvoeren. In Kubernetes hanteren we echter doorgaans immutable containers – de Docker image bevat de applicatiecode. Als we WordPress in de image "bakken", ontstaat een probleem zodra iemand in WP- admin een plugin toevoegt: die plugin-installer schrijft alleen naar het bestandssysteem van één container, wat niet persistent of gedeeld is. Andere pods krijgen die plugin niet mee, en een herstart wist de installatie weer. We hebben hier twee benaderingen:

• In-app wijzigingen verbieden (immutable image): De meest beheerste aanpak is om WordPress beschouwbaar read-only te maken voor code. Stel in wp-config.php bijvoorbeeld DISALLOW_FILE_MODS=true in, zodat plugins/themes niet via de admin kunnen worden geüpload. Alle code-wijzigingen (nieuwe plugins, updates) gebeuren dan via de CI/CD pipeline: je voegt de plugin toe aan de code of Helm chart en bouwt een nieuwe container image die je uitrolt. Zo komt elke wijziging via een gecontroleerde deployment, en niet ad-hoc via de webinterface. Belangrijk is dan wel dat je tijdens upgrades rekening houdt met de database: als je de image bijwerkt naar een nieuwe WordPress-versie, zorg dat eventuele database migraties compatibel zijn met alle draaiende pods.
• Mutaties toelaten met gedeelde opslag: Als je gebruikers wél de vrijheid wilt geven om via WP-admin plugins te installeren of te uploaden, moet je het WordPress bestandssysteem gedeeld en persistent maken tussen pods. Dit betekent doorgaans een PersistentVolume dat door alle WordPress pods wordt gemount (met een ReadWriteMany volume als je meerdere replica’s tegelijk draait). Bijvoorbeeld: op AWS zou je een EFS share gebruiken die door elke pod gemount is, of in Azure een Azure Files/NetApp Files share. On-premises kun je denken aan NFS, GlusterFS of een bestaande SAN. Zo’n gedeelde volume zorgt ervoor dat een plugin-upload of mediabestand voor alle replicas tegelijk beschikbaar is. Deze aanpak introduceert wel nieuwe aandachtspunten: het opslagmedium moet betrouwbaar en redundant zijn (zodat geen single node of disk failure tot dataverlies leidt) en het moet de performance aankunnen. Ook moet het volume synchroon updates aan kunnen bij gelijktijdige toegang. Technologieën als Portworx of Ceph RWO/RWX volumes kunnen dit faciliteren – Portworx adverteert bijvoorbeeld zijn shared volumes juist om WordPress horizontaal te schalen zonder uploads te verliezen.

Kortom, WordPress op Kubernetes vereist dat we expliciet de state buiten de ephemeral containers plaatsen. De gangbare best practice is een externe database te gebruiken en persistente opslag voor wp-content. Veel experts raden aan de database niet in Kubernetes zelf te hosten maar een managed database service te gebruiken, om je de zorgen van uitval, backups en schaalbaarheid te besparen. De bestanden (uploads/plugins) kun je op een gedeelde volume zetten of offloaden naar object storage met behulp van een plugin (bijv. een S3 bucket via WP Offload Media). In beide gevallen geldt dat de kern van WordPress data persistent moet zijn.

Multisite: Extra Complexiteit

Hoewel WordPress Multisite aantrekkelijk kan lijken (meerdere sites draaien op één installatie), brengt het bovenop bovengenoemde uitdagingen nog extra complexiteit. Enkele punten waar multisite het lastiger maakt dan losse sites:

• Grotere blast radius: Alle sites delen dezelfde codebase en infrastructuur. Een foutieve plugin update of een core update met bug kan in één klap álle sites in het netwerk platleggen. In een single-site zou zo’n fout slechts één site raken; multisite verhoogt de inzet. Dit betekent dat updates in een multisite-omgeving voorzichtiger en formeler benaderd moeten worden – denk aan uitgebreide tests en staged rollouts. Rollback-plannen moeten het terugdraaien van een update op het hele netwerk omvatten, niet één site.
• Gedeelde resources & performance: In multisite delen alle sites de server resources en database. Ze draaien wel afzonderlijke tabellen, maar toch in één database en vaak op dezelfde PHP runtime. Dit betekent dat één zware site (bijv. een site met veel verkeer of inefficiënte query’s) de database of cache kan overbelasten en daarmee ook andere sites vertraagt. Er is geen isolatie: een piek bij site A kan latency veroorzaken bij site B, omdat ze uit dezelfde pool van PHP workers en DB-connections putten. Extra maatregelen als object-caching (Redis/Memcached) zijn vrijwel vereist bij grotere multisites om de load te spreiden.
• State en storage delen: Ook op storage-niveau is er meer gedeeld. Uploads worden in een multisite per site gescheiden in subdirectories (/uploads/sites/{id}/), maar uiteindelijk staat alles op hetzelfde volume of bucket. Een fout of corruptie in de shared storage raakt potentieel alle sites. Hetzelfde geldt voor een object cache (één Redis instance voor alle sites) of een gedeelde uploads-NFS: er is één bron die goed moet werken voor alle sites.
• Governance & beheer: Multisite introduceert de Super Admin rol boven de site-admins, zodat centraal beheer mogelijk is. Dit is handig om uniformiteit te bewaren, maar vergt duidelijke governance: wie mag nieuwe plugins/themes netwerkbreed installeren? Hoe voorkom je dat een wijziging voor site X ongewenste impact heeft op site Y? Vaak zijn strengere procedures nodig (RACI-matrices, change approvals) om chaos te voorkomen. Ook zaken als een staging omgeving per site zijn ingewikkelder – je kunt niet eenvoudig één site uit een multisite klonen naar staging zonder de hele database te kopiëren en vervolgens die ene site te isoleren. Migratie van één site uit een multisite naar een eigen installatie is notoir lastig en tijdrovend.

Concluderend is WordPress multisite op Kubernetes nóg uitdagender: alle stateful aspecten gelden in het kwadraat, omdat elke beslissing meerdere sites raakt. Tenzij je specifiek de voordelen van multisite nodig hebt (één codebase, gedeeld beheer voor sterk gelijkende sites, etc.), is het vaak veiliger en flexibeler om sites als separate deployments te behandelen (desnoods met management tools om ze centraal te beheren). In deze post houden we multisite daarom als edge-case; de meeste best practices richten zich op single-sites.

Platformkeuze: Managed Cloud vs. On-Premises Kubernetes

Waar je Kubernetes draait, beïnvloedt de implementatie-details van WordPress behoorlijk. We onderscheiden grofweg managed cloud Kubernetes (bijv. AWS EKS, Google GKE, Azure AKS) en on-premises/self-managed clusters (bare-metal of eigen VM’s met Kubernetes).

In cloud omgevingen profiteer je van geïntegreerde services:

• Storage: Elke cloud biedt wel een CSI-driver voor volumes (denk aan Amazon EBS, Azure Disks, Google Persistent Disk) die automatisch provisioning van PersistentVolumes verzorgt. Opslag is vrijwel onbeperkt beschikbaar met hoge betrouwbaarheid. Daarnaast kun je vaak gebruikmaken van managed filesystems (zoals AWS EFS of Azure Files) voor shared storage, of object storage (S3/Blob) voor media. Dit maakt het relatief eenvoudig een PersistentVolumeClaim te koppelen aan cloud storage zonder zelf een storage cluster te beheren.
• Load balancing & networking: In de cloud kan Kubernetes automatisch een externe LoadBalancer resource aanmaken (bijv. AWS ELB/ALB) wanneer je een Service of Ingress exposeert. Dit is "LB as a service" – je hoeft geen eigen load balancer op te zetten. Ook netwerkconfiguratie (subnets, routing) is vaak deels out-of-the-box of via cloud-managed CNI integraties geregeld. Cloud K8s biedt one-click SSL (bijv. via AWS ACM) of integratie met cloud CDN/DNS diensten.
• Managed databases en caches: Je kunt ervoor kiezen de database niet in de cluster te draaien maar een cloud Managed DB service te gebruiken (zoals Amazon RDS, Cloud SQL, Azure Database for MySQL). Zoals eerder genoemd verlaagt dit de operationele hoofdpijn voor backups, upgrades en failover. Hetzelfde geldt voor caching: een managed Redis service kan gebruikt worden in plaats van een container. Via cloud IAM kun je bovendien veilig credentials en toegang regelen (bijv. een Pod IAM role die toegang heeft tot een specifieke database of bucket).
• Upgrades & cluster management: Managed K8s diensten nemen vaak de controleplane upgrades voor hun rekening en bieden gemakkelijke node pool updates. Dit betekent minder onderhoudswerk voor jou en vaak minimale downtime bij versie-upgrades van Kubernetes zelf. De cloud zorgt ook voor node vervanging bij hardware issues: als een VM crasht, spint de autoscaler een nieuwe op.

In on-premises of self-hosted Kubernetes daarentegen moet je deze aspecten zelf invullen:

• Storage: Je moet zelf een storage oplossing implementeren voor persistente volumes. Dat kan variëren van simpele NFS-servers tot geavanceerde SDS (Ceph, GlusterFS) of een SAN integreren. De CSI-driver maturiteit kan een factor zijn – niet alle storage backends zijn even makkelijk of stabiel als de cloudvarianten. Je zult zorgvuldig provisioning en wellicht replicatie moeten inrichten om databeschikbaarheid te garanderen.
• Load balancing & networking: Zonder cloud moet je zelf iets regelen als je van buitenaf bij de cluster wilt. Vaak gebruikt men MetalLB (een load-balancer implementation voor bare metal) of stuurt men verkeer via een externe reverse proxy. Het opzetten van een betrouwbare load balancer is complexer on-prem, en netwerkconfiguratie (subnetten, VLANs, firewall rules) vergt meer handwerk. Er is geen "one-click" ingress: je beheert zelf de ingress controller (NGINX/Traefik) en de onderliggende netwerk infra.
• Availability & schaalbaarheid: In de cloud zijn datacenters redundant en je kunt vrij eenvoudig extra nodes toevoegen. On-premises ben je beperkt tot je eigen hardware. Het risico op downtime is vaak hoger on-prem, omdat grote cloudproviders redundantie beter op orde hebben. Je moet plannen voor capaciteit en schaal: zorg voor voldoende extra compute en storage headroom, want een nieuwe node bijprikken kan weken lead time hebben in plaats van seconden in de cloud. Ook is hardware falen jouw verantwoordelijkheid; je moet monitoring hebben om een kapotte server te detecteren en een vervanger in te zetten.
• Upgrades en beheer: Je voert zelf de upgrades van Kubernetes uit, incl. etcd en control plane. Dit vereist expertise en brengt risico’s met zich mee. Cluster upgrades moeten goed getest worden, meestal via een staging cluster. Backups van etcd, cluster config en persistent data zijn on-prem jouw taak; goede off-site backups zijn een must om bijvoorbeeld een brand of storing te overleven. Niets gebeurt "managed" – je hebt een sterker DevOps team nodig om het platform draaiende te houden.
• Integraties: Functionaliteit die in cloud automatisch of als dienst komt (monitoring, logging, SSL, IAM) moet je on-prem zelf invullen met open-source tools of enterprise oplossingen. Denk aan een eigen Prometheus/Grafana stack voor monitoring, Cert-Manager voor SSL certs, Velero of Stash voor backups, etc. Dit is prima te doen, maar vergt inspanning en onderhoud.

Conclusie: Een managed cloud Kubernetes platform neemt veel infrastructuurzorgen uit handen, wat het eenvoudiger maakt om WordPress’ stateful onderdelen in te passen. On-prem kan zeker, maar vraagt om zorgvuldig design en extra tooling voor storage, networking en reliability. De keuze cloud vs on-prem hangt af van je situatie (compliance, kosten, expertise). In beide gevallen geldt dat de fundamentele uitdagingen (persistente data, schaalbaarheid van WP, etc.) opgelost moeten worden, maar de middelen waarmee je dat doet verschillen.

Tooling voor Deployment en Lifecycle: Helm, GitOps, Operators

Helm charts

Er bestaan kant-en-klare Helm charts (pakketjes) voor WordPress, zoals de populaire Bitnami/Bitpoke WordPress chart. Hiermee kun je in enkele commando’s een werkende WP + database in je cluster deployen. Dit is een geweldige kickstart – de chart maakt de Deployments, Services, PVC’s etc. automatisch aan. Bitnami’s chart configureert bijvoorbeeld een MariaDB database en een volume voor WordPress data out-of-the-box. Echter, Helm neemt je slechts tot aan een draaiende installatie. De fundamentele kwesties blijven: de chart zal een PersistentVolumeClaim aanmaken voor /bitnami/wordpress directory, maar jíj moet zorgen dat die storage class betrouwbaar is. Upgraden van WordPress via Helm betekent de chart versie bumpen of image tag bijwerken; maar als een gebruiker intussen via de admin een plugin toevoegt, staat die op de PVC en niet in je Helm manifest. Zulke drift tussen de cluster state en je chart is een aandachtspunt. Helm zelf biedt geen oplossing voor file-level changes of database migrations – dat is aan jouw procedures. Kortom, beschouw Helm als één handige deployment template; het maakt installatie reproduceerbaar en parameteriseerbaar, maar Day-2 operaties (back-ups, updates, recoveries) moet je nog steeds zelf inregelen.

GitOps (bijv. Argo CD, Flux)

GitOps brengt het principe dat je clusterconfiguratie in Git als bron van waarheid houdt. Dit werkt uitstekend voor Kubernetes resources: je Deployment-, Service- en Ingress-definities staan in een Git repo, en een tool als ArgoCD zorgt dat de cluster altijd overeenkomt met Git. Voor WordPress op K8s is dit erg nuttig om bijvoorbeeld je Helm release en config te versioneren, zodat je wijzigingen (nieuwe env vars, scaling, chart updates) gecontroleerd via pull requests doet. De beperking zit echter in WordPress’ interne state. Zaken als de database-inhoud of geüploade bestanden kún je niet in Git versioneren – dat zijn runtime data. GitOps dekt dus de infrastructuur kant (containers, ConfigMaps, PVC claims), maar WP-specifieke veranderingen via de UI vallen buiten Git. Als je bijv. een plugin via CI toevoegt (nieuwe image), is dat GitOps-gecontroleerd; maar als een beheerder via WP-Admin een instelling verandert of een afbeelding uploadt, gebeurt dat in de database en PV, niet via Git manifest. GitOps zal hoogstens signaleren dat een Kubernetes object is veranderd (bijv. een PVC status), maar het synchroniseert die data natuurlijk niet. In de praktijk gebruik je GitOps voor alle declareerbare aspecten (infrastructure-as-code), maar je hebt daarnaast reguliere WordPress backup/restore procedures nodig voor de inhoud. Een best practice is wel om WordPress configuratie (wp-config.php instellingen, welke plugins actief, etc.) zoveel mogelijk te automatiseren/versiebeheer (bv. via environment variables of config files), zodat herstel eenvoudiger is en handmatige drifts beperkt blijven.

Kubernetes Operators

Een operator is een stuk controller software dat domeinspecifieke kennis in de cluster brengt. Voor WordPress bestaan er operators (bijv. de open-source Presslabs/Bitpoke WordPress Operator) die beloven om WordPress sites als first-class citizen te beheren. Zo’n operator kan bijvoorbeeld een custom resource WordPressSite introduceren, waarna je alleen hoeft te declareren "ik wil een WP site met deze naam, zoveel replicas, deze version", en de operator regelt het aanmaken van Deployment, PVC, Service, database etc. In theorie kunnen operators ook day-2 taken automatiseren, zoals backups maken, updates coördineren, scaling op basis van metrics, enz. Het klinkt als een panacee, maar er zijn kanttekeningen:

• Abstractie lekken: Veel operators dekken niet alle aspecten. Bijvoorbeeld, een WP operator kan de app deployment automatiseren, maar de specifieke storage backend of tuning van MySQL zijn nog steeds jouw zorg. Een operator neemt complexiteit weg bij standaardhandelingen, maar complexe scenario’s of storingen vereisen alsnog kennis van Kubernetes en WordPress. Je blijft verantwoordelijk voor performance optimalisatie en troubleshooting als dingen misgaan.
• Volwassenheid en support: Operators variëren in kwaliteit en maturity. De Presslabs WordPress operator werd een paar jaar geleden geïntroduceerd en bood indrukwekkende mogelijkheden, maar gebruikers gaven aan dat hij destijds nog in pre-alpha fase was voor hun eisen. Sommige operators zijn community-driven met beperkt support. Je bent dus enigszins afhankelijk van de ontwikkelaars voor updates en bugfixes. Als je hier bedrijfskritisch op leunt, beoordeel dan de levensvatbaarheid (aantal maintainers, updates).
• Lock-in door CRD’s: Wanneer je een operator gebruikt, introduceer je Custom Resource Definitions die specifiek zijn voor die operator. Stel je bouwt je hele workflow rond een WordPress CRD, dan zit je vast aan die operator voor beheer. Wisselen van approach later kan migratie betekenen van die CRD naar een andere (of terug naar "plain" Helm). Dit is niet onoverkomelijk, maar wel iets om rekening mee te houden. Je legt een deel van je platform vast in de logica van een derden-tool.

Desalniettemin kunnen operators waardevol zijn, zeker in grotere hostingplatforms. In de praktijk zie je vaak een combinatie: bijvoorbeeld een WordPress operator in tandem met een MySQL operator (bijv. van Presslabs) zodat zowel app als database gemanaged worden. Aanvullend Cert-Manager operator voor SSL, enzovoort. Dit vormt een ecosysteem van operators die samen veel werk automatiseren. Presslabs (tegenwoordig Bitpoke) heeft zo’n volledige stack open-source samengesteld. Het komt neer op investeren in een Kubernetes-native manier van WordPress beheren. Als je die investering kunt maken en de voordelen (snellere opschaling, self-healing, standaardisatie) nodig hebt, is het zeker het onderzoeken waard. Voor veel teams is echter een eenvoudiger setup met Helm charts en goede CI/CD pipelines al voldoende om WordPress betrouwbaar op Kubernetes te draaien, zonder direct de complexiteit van custom operators.

Aanbevolen Basisopzet voor WordPress op Kubernetes

Samenvattend vertalen we de bovenstaande inzichten naar een praktische standaardaanpak voor WordPress op Kubernetes:

• Single-site deployment: Begin met één WordPress site per namespace of deployment. Dit minimaliseert overlappende impact. Gebruik een Kubernetes Deployment voor de WordPress PHP applicatie, zodat je makkelijk kunt schalen en updates via rolling updates kunt uitrollen.
• 1-3 replicas voor webpods: Draai de WordPress pods in replicatie (bijv. 2 pods) voor hoge beschikbaarheid en om leesverkeer te verdelen. Zet een Kubernetes Ingress of Service (LoadBalancer) op om verkeer naar de pods te balanceren. Denk eraan dat bij >1 replica de sessie-affiniteit geen groot probleem is (WordPress gebruikt standaard geen server-side sessies voor logged-in users), maar als je plugins hebt die sessies/local cache gebruiken, overweeg een externe store of sticky sessions.
• Externe database: Gebruik een aparte MySQL/MariaDB instance buiten de cluster. Ideaal is een managed cloud database service voor betrouwbaarheid. Als dat niet kan, draai de database in een dedicated VM of zelfs als single K8s StatefulSet met een persistent volume – maar zorg altijd voor een backupstrategie. De kern is dat DB data niet verloren mag gaan bij cluster events; extern houden maakt updates en scaling van de app los van de data-laag.
• Persistente opslag voor uploads (of object storage): Voor mediabestanden en andere uploads configureer je een PersistentVolumeClaim gebonden aan een duurzame storageclass. In de cloud kun je een gedeelde filesystem service kiezen (bv. AWS EFS, Azure Files) zodat meerdere pods tegelijk bij de files kunnen. Dit laat je toe om horizontaal te schalen zonder uploads te dupliceren. Alternatief is een plugin die media direct in object storage opslaat (S3, GCS) – dan hoeven de WordPress pods geen gedeeld filesystem voor media te hebben, wat de architectuur eenvoudiger maakt. In beide gevallen blijft wp-content/uploads durably opgeslagen buiten de container.
• Immutable applicatie-image: Maak een Docker image met WordPress en de benodigde plugins/themes vooraf geïnstalleerd (via Composer of WP-CLI tijdens build, bijvoorbeeld). Hanteer de policy dat containers niet beschrijfbaar zijn voor code (set DISALLOW_FILE_MODS). Plugin updates gaan dan via een nieuwe image build + deploy. Dit voorkomt configuratiedrift en maakt rollback eenvoudiger (je weet exact welke code er draait in een gegeven image).
• Helm en GitOps voor deployments: Gebruik een Helm chart (desnoods de Bitnami WordPress chart als basis) om alle Kubernetes resources declaratief vast te leggen. Parameteriseer zaken als de database-credentials, storageclass naam, replica-aantal, etc. Check deze Helm release in bij Git (bijv. helm values YAML). Zet vervolgens een GitOps tool als Argo CD/Flux in om de cluster consistent met Git te houden. Hiermee worden veranderingen (bijv. een update naar een nieuwe WordPress versie via image tag) traceerbaar en gecontroleerd doorgevoerd.
• Caching en performance: Overweeg een Redis (of Memcached) deployment voor object caching, zeker als de site veel queries aan de DB doet. Dit kan in Kubernetes draaien of extern. Een caching layer komt alle replicas ten goede en is bij multisite of zware sites bijna noodzakelijk. Evenzo is een CDN voor statische assets aanbevolen in productie om de load op de pods te verminderen.
• Monitoring & backups: Implementeer monitoring op zowel de Kubernetes cluster (node/pod metrics) als op WordPress-niveau (uptime en performance checks). Tools als Prometheus/Grafana kunnen geïntegreerd worden (sommige Helm charts hebben hooks voor Prometheus metrics). Zorg dat backups geregeld zijn: database backups (automated snapshots of export via tools als mysqldump of a MySQL operator’s backup feature) en file backups (e.g. sync the uploads PV to cloud storage of use a backup operator like Stash). Test herstelprocedures om zeker te zijn dat je bij een calamiteit een site kunt restoren.
• Voorzichtig met multisite: Indien je toch WordPress Multisite op Kubernetes wilt draaien, pas alle bovenstaande punten nog strikter toe. Gebruik één gedeelde DB met backups, een RWX storage voor alles onder /wp-content/uploads/sites/, en intensieve testen voor updates. Hou er rekening mee dat schaalbaarheidsvoordelen beperkt zijn – uiteindelijk blijft één WP installatie die je opschaalt, niet meerdere onafhankelijke apps. Multisite op K8s is vooral nuttig als de sites inhoudelijk sterk verwant zijn en je centrale controle boven maximale isolatie plaatst.

Met deze aanpak hebben we een robuuste basis neergezet: we combineren het beste van Kubernetes (self-healing, schaalbaarheid, declarative config) met respect voor de aard van WordPress (stateful data die we extern/persistent borgen). Het resultaat is een WordPress die voor de eindgebruiker "gewoon" werkt zoals altijd, maar achter de schermen profiteren we van container orchestratie. Zolang we de beperkingen (complexiteit, kosten) in gedachten houden en de juiste tools inzetten, kan WordPress op Kubernetes een succesvolle en beheersbare keuze zijn voor moderne hosting behoeften.