Magento op Kubernetes, per component goed ingericht

De meest gemaakte fout bij Magento op Kubernetes is een container die bij het opstarten nog setup:di:compile en setup:static-content:deploy draait. Dan duurt een nieuwe pod minuten in plaats van seconden. Autoscaling wordt daarmee waardeloos: tegen de tijd dat de extra pod klaar is, is de piek voorbij.

Wij bouwen alles in het image. De Dockerfile is een multi-stage build. In de eerste stage draait composer install met --no-dev en een geoptimaliseerde autoloader. Daarna volgen bin/magento setup:di:compile en setup:static-content:deploy voor de talen en thema's die je echt gebruikt. Met Hyvä bouwen we ook de Tailwind-CSS in die stage. De laatste stage kopieert alleen het resultaat naar een slank PHP-FPM-image.

Om static content zonder database te kunnen bouwen, zetten we de configuratie van scopes, thema's en talen vast in app/etc/config.php via bin/magento app:config:dump. Gevoelige instellingen staan niet in config.php maar in env.php, en die vullen we pas in de cluster in vanuit environment-variabelen en Secrets. Zo is één image bruikbaar voor test, acceptatie en productie.

Elk image krijgt een unieke tag, gekoppeld aan de commit. Nooit latest. Daardoor weet je altijd precies welke code er draait, en is terugrollen een kwestie van de vorige tag weer uitrollen. Het image wordt in de pipeline gescand op kwetsbaarheden, bijvoorbeeld met Trivy, voordat het naar de registry gaat.

Magento heeft cron nodig voor indexers, e-mails, sitemaps, prijsregels en opruimtaken. Op één server is dat één regel in de crontab. Op Kubernetes moet je kiezen. Een CronJob die elke minuut bin/magento cron:run start is eenvoudig, maar maakt elke minuut een nieuwe pod aan. Met concurrencyPolicy Forbid voorkom je dat runs elkaar overlappen. Bij veel cronwerk kiezen we vaak een Deployment met één replica die cron:run in een lus draait. Dan blijft het proces warm en zie je in de logs één doorlopend verhaal.

Belangrijk is dat er altijd maar één cron-runner actief is. Twee runners betekent dubbele e-mails, dubbele exports en locks die elkaar in de weg zitten. Lees ook waarom cron in Magento vaak het eerste is dat 's nachts vastloopt.

Queue-consumers verwerken asynchroon werk, zoals bulk-acties, export van producten en voorraad-updates. Standaard start Magento consumers vanuit cron. Op Kubernetes zetten we dat uit in env.php, via de instelling cron_consumers_runner met cron_run op false. Daarna draait elke belangrijke consumer als eigen Deployment met bin/magento queue:consumers:start en een limiet op het aantal berichten, zodat het proces regelmatig netjes herstart en geen geheugen lekt.

Gebruik je RabbitMQ als message broker, dan kun je consumers laten schalen op de lengte van de wachtrij met KEDA. Bij een grote import komen er automatisch extra consumers bij, en daarna schaalt het terug. De webpods merken daar niets van, want ze delen geen CPU met het achtergrondwerk.

Veel Magento-handleidingen voor Kubernetes gebruiken nog de community-controller ingress-nginx. Die is door de Kubernetes-community met pensioen gestuurd. De aankondiging kwam in november 2025, het onderhoud liep op best-effort-basis tot maart 2026. Sindsdien verschijnen er geen releases en geen securityfixes meer. Bestaande installaties werken nog, maar zijn een risico.

Voor nieuwe clusters gebruiken we de Gateway API, met een implementatie zoals Envoy Gateway, NGINX Gateway Fabric, Traefik of Cilium. De keten wordt dan: Gateway met TLS via cert-manager, daarna Varnish, daarna Nginx en PHP-FPM. Een CDN of WAF zoals Cloudflare staat daar meestal nog voor. Meer over de keuze tussen controllers staat op onze pagina over ingress, Gateway API en TLS.