Laravel op Kubernetes: web, queues en scheduler elk op hun eigen plek

Elke release begint met een image. Wij bouwen dat in een multi-stage Dockerfile. De eerste stage draait composer install met --no-dev en --optimize-autoloader. Een tweede stage bouwt de frontend met npm ci en vite build. De laatste stage start vanaf een slank PHP-image, kopieert alleen vendor, de gebouwde assets en de applicatiecode, en draait als niet-root gebruiker.

Wat niet in het image hoort: een .env-bestand, API-sleutels of databasewachtwoorden. Die komen in de cluster binnen als environment-variabelen. Daardoor draait exact hetzelfde image op test, acceptatie en productie. Wat je op acceptatie hebt goedgekeurd, is bit voor bit wat er live gaat.

Elk image krijgt een tag die naar de commit verwijst, nooit latest. In de pipeline scannen we het image op kwetsbaarheden, bijvoorbeeld met Trivy, voordat het naar de registry gaat. Een kritieke kwetsbaarheid in een basis-image houdt de release tegen in plaats van dat je hem achteraf in productie ontdekt.

Het startcommando bepaalt de rol. In de Helm-chart krijgt elke Deployment hetzelfde image met een eigen command: php-fpm voor web, horizon voor queues, schedule:work voor de scheduler. Eén build, één versie, geen verschillen tussen rollen die later voor verrassingen zorgen.

Horizon is het dashboard en de procesmanager voor Redis-queues. Op Kubernetes draait Horizon als Deployment. Binnen een pod start Horizon zelf meerdere workerprocessen per supervisor, en met de balance-strategie auto verdeelt het die over de queues. Dat is één laag van autoscaling.

KEDA is de andere laag. KEDA is een CNCF graduated project dat pods schaalt op externe signalen, zoals de lengte van een Redis-lijst. Laravel zet wachtende jobs in een lijst met de naam queues: plus de queuenaam, voorafgegaan door de Redis-prefix uit config/database.php. Een KEDA ScaledObject met de redis-trigger leest die lijst en voegt pods toe zodra er meer jobs wachten dan je drempel.

Combineer die twee lagen niet blind. Als Horizon binnen een pod opschaalt en KEDA tegelijk pods toevoegt, krijg je meer workers dan je database aankan. Wij kiezen per applicatie één leidende laag. Vaak is dat Horizon met vaste pods voor het dashboard en de kleine queues, en losse queue:work-Deployments met KEDA voor de queues met grote pieken, zoals imports.

Belangrijk bij elke worker is een nette shutdown. Kubernetes stuurt bij een deploy of schaalactie een SIGTERM. queue:work en Horizon maken dan de lopende job af en stoppen. Zet terminationGracePeriodSeconds daarom ruimer dan de timeout van je langste job. Anders breekt Kubernetes jobs halverwege af en worden ze opnieuw uitgevoerd.

Een pod heeft geen vaste schijf. Uploads, gegenereerde PDF's en exports gaan daarom naar S3 of een S3-compatibele object storage via de s3-disk van Laravel. Bij een EU-provider kan dat de object storage van dezelfde aanbieder zijn, zodat data in de EU blijft. storage:link heb je dan niet meer nodig voor publieke bestanden; je serveert ze via de URL van de bucket of een CDN.

Sessies en cache gaan naar Redis of Valkey. De database-driver werkt ook, maar legt extra last op je database. Logs stuur je met LOG_CHANNEL op stderr naar de output van de container. Loki, of de logdienst van je cloudprovider, haalt ze daar op. Zo verdwijnen logs niet als een pod wordt vervangen.

Laravel heeft vanaf versie 11 een standaard health-route op /up. Die gebruiken we voor de readiness- en liveness-probes. Voor workers en de scheduler, die geen HTTP spreken, controleren we via metrics of ze werk oppakken. Een worker die draait maar niets verwerkt, is erger dan een worker die crasht.