Kubernetes voor Magento en Laravel: alleen als het loont
Kubernetes is geen doel. Voor de meeste webshops is goede managed hosting goedkoper en eenvoudiger. Het loont wel bij meerdere shops of apps op één platform, sterk wisselend verkeer, veel queues en imports, of een organisatie die al op Kubernetes draait. Dit is de hub voor alles wat wij weten over Magento en Laravel op Kubernetes.
Kubernetes lost schaal- en platformproblemen op. Heb je die niet, dan koop je vooral extra complexiteit.
Pods komen en gaan. Media, sessies en database horen buiten de pod. Magento en Laravel moeten daarop ingericht worden.
Met GitOps staat elke wijziging aan het cluster in Git. Terugdraaien is een revert, geen nachtelijke zoektocht.
De Kubernetes-community stopte het onderhoud aan ingress-nginx. Geen updates en securityfixes meer. Tijd voor de Gateway API.
Kubernetes voor webshops, per onderwerp
Elk onderwerp heeft een eigen pagina met onze aanpak, wat je krijgt en de gidsen die erbij horen.
Magento op Kubernetes
Magento 2 per component op Kubernetes: PHP-FPM, Varnish, Valkey, OpenSearch, cron en consumers, met deploys zonder downtime. En eerlijk wanneer het niet loont.
Bekijk →Laravel op Kubernetes
Laravel-apps op Kubernetes: php-fpm of Octane met FrankenPHP, Horizon en queue workers die schalen op de wachtrij, migraties als Job en Reverb voor websockets.
Bekijk →GitOps met Argo CD
Argo CD als enige weg naar productie: Applications en ApplicationSets per omgeving, migraties via sync waves, drift-detectie, rollbacks en canary-releases.
Bekijk →Helm-charts en Kustomize
Eigen Helm charts voor Magento en Laravel, values per omgeving, Kustomize-overlays en een eerlijke kijk op Bitnami-charts na de wijziging van 2025.
Bekijk →Managed Kubernetes kiezen
EKS, GKE, AKS of een Europese aanbieder: vergeleken op datalocatie, AVG, kostenposten, upgrades en beheerlast. Plus wanneer self-managed met k3s of Talos past.
Bekijk →Kubernetes monitoring
Prometheus, Grafana, Loki en OpenTelemetry ingericht op wat je shop doet: PHP-FPM, queues, cron en checkout-latency, met alerts die ertoe doen.
Bekijk →Kubernetes autoscaling
Pods en nodes die meegroeien met verkeer en queues: HPA, KEDA, Karpenter, en de requests en limits waar het meestal misgaat.
Bekijk →Ingress, Gateway API en TLS
ingress-nginx is met pensioen. De route naar de Gateway API, de keuze voor een implementatie en TLS met cert-manager, Cloudflare en Varnish.
Bekijk →Kubernetes security
Secrets buiten Git, RBAC met minimale rechten, Pod Security Standards, NetworkPolicies, Kyverno en Trivy: een cluster dat standaard dicht staat.
Bekijk →Kubernetes CI/CD
Images bouwen en scannen in CI, uitrollen via Git en Argo CD, canary of blue-green met Argo Rollouts en een preview-omgeving per pull request.
Bekijk →Plan een half uur over Kubernetes voor je platform
Een half uur via video met de mensen die het werk ook echt doen. Kies hieronder een moment dat jou past.
- Direct met het vaste team, geen tussenlagen
- Concrete feedback op je huidige situatie of plannen
- Eerlijk advies, ook als het antwoord "niet doen" is
- Indicatie van kosten en tijdlijn
Plan een gratis Tech Check
Vrijblijvend jouw uitdagingen bespreken
Of bel direct: 0591-239 299
Waar Kubernetes voor webshops misgaat
Kubernetes zelf is zelden het probleem. Het gaat mis op de plekken waar een PHP-applicatie aanneemt dat er één vaste server is.
Magento die bij het opstarten nog compileert
Een pod draait setup:di:compile of static-content:deploy bij elke start. Opstarten duurt minuten, autoscaling komt te laat en elke pod kan net iets anders opleveren.
Queues en scheduler als bijzaak
De scheduler draait in elke webpod en jobs lopen dubbel. Of er draait één worker die bij een import uren achterloopt, terwijl de webpods niets te doen hebben.
Handmatige kubectl apply
Iemand past iets aan in het cluster en niemand weet nog wat er draait. Een tweede omgeving opbouwen lukt niet meer, terugdraaien wordt gokken.
Een ingress-controller zonder onderhoud
ingress-nginx krijgt sinds maart 2026 geen updates en securityfixes meer. Wie er nog op draait, heeft een onbeheerde component direct aan internet.
Schalen op het verkeerde signaal
Een HPA op CPU reageert niet op een volle queue. En zonder node-autoscaling blijven nieuwe pods op Pending staan, net op het moment dat je ze nodig hebt.
Secrets in Git en images vol kwetsbaarheden
Databasewachtwoorden in een values-bestand, iedereen cluster-admin, images die maanden niet zijn herbouwd. Eén gelekte token en het hele platform ligt open.
Twijfel je of Kubernetes je iets oplevert?
Plan een half uur met ons. We kijken naar je verkeer, je achtergrondwerk en je huidige hosting, en zeggen eerlijk of Kubernetes loont of dat managed hosting de betere keuze is.
Waar wij je mee helpen
Magento 2 op Kubernetes
Images met gebouwde static content, Varnish, Valkey of Redis, OpenSearch, cron en consumers als losse workloads, en deploys zonder downtime.
Magento op Kubernetes →Laravel op Kubernetes
PHP-FPM of Octane, Horizon en queue workers met autoscaling, scheduler als CronJob, migraties als Job en storage op S3.
Laravel op Kubernetes →GitOps met Argo CD
Eén Git-repo als bron van waarheid, automatische sync, sync waves voor migraties en ApplicationSets voor meerdere shops of omgevingen.
GitOps met Argo CD →Managed Kubernetes kiezen
EKS, GKE, AKS of een Europese aanbieder: wat elk regelt, waar je data staat en welke kostenposten erbij horen.
Managed Kubernetes →Autoscaling
HPA voor web, KEDA voor queues en imports, cluster-autoscaler of Karpenter voor nodes. Schalen op het signaal dat ertoe doet.
Autoscaling →Monitoring en logging
Prometheus, Grafana en Loki met alerts op foutpercentage en latency, zodat je een storing ziet voordat je klant hem ziet.
Monitoring →Je praat met de mensen die het werk doen
Wij leveren geen architectuurplaat die een ander moet bouwen. Het vaste team dat je Magento- of Laravel-platform kent, bouwt de images, charts en GitOps-repo, migreert je verkeer en draait het cluster daarna mee. Korte lijnen, geen tussenlagen. En als Kubernetes niet nodig is, zeggen we dat ook.
- RuthgerEigenaar & developer
- HaimantiDeveloper
- WouterDeveloper
Van scan tot beheer
Eerst de vraag of Kubernetes past. Daarna bouwen, migreren en meedraaien, met hetzelfde team van begin tot eind.
- 1
Scan
We kijken naar je verkeer, je achtergrondwerk, je huidige hosting en je team. Uitkomst: Kubernetes, managed hosting, of eerst containers en CI/CD. Met de kostenposten erbij.
- 2
Architectuur
Keuze voor managed Kubernetes en regio, wat in het cluster draait en wat erbuiten (database, object storage), netwerk, secrets en de indeling in namespaces en omgevingen.
- 3
Bouwen
Container-images met alles vooraf gebouwd, Helm-charts of Kustomize per omgeving, een GitOps-repo met Argo CD, CI die images bouwt, scant en naar een registry pusht.
- 4
Migreren
Staging eerst, loadtests, data en media overzetten, DNS met een lage TTL en een terugvalplan. Livegang op een moment dat jouw omzet het minst raakt.
- 5
Beheren
Monitoring en alerts, Kubernetes- en image-updates, capaciteit en kosten bijsturen. Wij draaien het mee, met dezelfde mensen die het gebouwd hebben.
Waar we op letten, per laag
Een cluster is zo sterk als zijn zwakste laag. Dit controleren we bij elke inrichting en elke review.
Workloads & images
- DI-compilatie en static content in het image, niet bij opstarten
- Kleine images met een vaste tag of digest, nooit latest
- Readiness- en liveness-probes die echt iets zeggen
- Cron, queue-consumers en workers als eigen workloads
- Requests en limits gebaseerd op metingen
Deploy & GitOps
- Alle manifests in Git, geen handmatige wijzigingen
- Argo CD met automatische sync en drift-detectie
- Migraties als Job of PreSync-hook in de juiste sync wave
- Rollback getest, niet alleen bedacht
- Canary of blue-green waar het risico het rechtvaardigt
Data & opslag
- Database bij voorkeur managed, buiten het cluster
- Media op object storage of een RWX-volume
- Sessies en cache in Valkey of Redis, niet op schijf
- Backups getest met een echte restore
- Helm-charts voor stateful diensten kritisch gekozen
Netwerk & TLS
- Gateway API of een onderhouden ingress-controller
- Certificaten automatisch via cert-manager
- Varnish als eigen Deployment voor Magento
- NetworkPolicies tussen namespaces
- Echte client-IP en headers doorgegeven aan de applicatie
Schalen & kosten
- HPA voor web, KEDA voor queues en pieken
- Node-autoscaling met cluster-autoscaler of Karpenter
- PodDisruptionBudgets zodat onderhoud geen downtime geeft
- Inzicht in kosten per namespace of app
- Nodes die 's nachts niet onnodig doordraaien
Observability & security
- Metrics, logs en alerts met Prometheus, Grafana en Loki
- Alerts op symptomen als foutpercentage en latency
- Secrets via External Secrets, niet in Git
- RBAC volgens least privilege
- Images gescand met Trivy, policies afgedwongen met Kyverno
Managed hosting, managed Kubernetes of zelf doen?
Drie routes, elk met een eerlijke plek. Voor veel webshops is de eerste kolom de beste keuze.
| Onderdeel | Managed hosting (bv. Hypernode) | Managed Kubernetes + ons | Zelf Kubernetes beheren |
|---|---|---|---|
| Server en platform | Geregeld door de hostingpartij, geoptimaliseerd voor Magento | Control plane bij de cloudaanbieder, de rest richten wij in | Alles zelf, inclusief upgrades van Kubernetes |
| Meerdere shops en apps op één platform | Per shop een eigen omgeving | Sterk punt: gedeeld platform, gescheiden per namespace | Kan, als je team het kan dragen |
| Pieken en achtergrondwerk | Binnen de grenzen van je pakket | Autoscaling op verkeer en queue-lengte | Afhankelijk van je eigen inrichting |
| Deploys en rollback | Via de tooling van de host of je eigen pipeline | GitOps met Argo CD, rollback via Git | Zelf bouwen en onderhouden |
| Monitoring en storingen | Basismonitoring door de host | Prometheus, Grafana en Loki, alerts naar ons | Jouw eigen piketdienst |
| Benodigde kennis in huis | Weinig | Weinig: wij beheren, jij houdt inzicht | Veel, en op meer dan één persoon |
Wij zijn Hypernode Silver Partner en adviseren managed hosting als dat beter past. Kubernetes kiezen we alleen als het iets oplevert dat je met managed hosting niet krijgt.
Waar je nu mee te maken krijgt
Drie onderwerpen die nu spelen bij iedereen die Kubernetes overweegt of er al op draait.
ingress-nginx stopt: zo migreer je naar de Gateway API
ingress-nginx krijgt geen updates en securityfixes meer. Wat de Gateway API anders doet en hoe je migreert zonder downtime.
Lees verder →Kubernetes of managed hosting voor je webshop?
Wanneer Kubernetes loont voor een webshop, en wanneer managed hosting goedkoper en eenvoudiger is.
Lees verder →Wat kost Kubernetes voor een webshop? De kostenposten
De kostenposten die je vooraf moet kennen: nodes, load balancers, opslag, verkeer, monitoring en de uren voor beheer.
Lees verder →Zes Kubernetes-fouten die je geld en uptime kosten
Deze fouten zijn snel gemaakt en lastig te zien, tot het misgaat op een drukke dag.
- 1
setup:upgrade bij het starten van elke pod
Tien pods starten tegelijk en draaien allemaal de migraties. Dat geeft locks en halve schema-updates. Eén Job of PreSync-hook, één keer per release.
- 2
Media op een lokaal volume
Een upload komt op één pod terecht en de andere pods zien hem niet. Bij een herstart is hij weg. pub/media en storage horen op object storage of een RWX-volume.
- 3
De database in het cluster zonder reden
Een StatefulSet met MySQL lijkt goedkoop, tot je backups, upgrades en failover zelf moet regelen. Een managed database buiten het cluster is meestal de betere keuze.
- 4
Geen resource requests
Zonder requests plant de scheduler pods op volle nodes, valt de HPA terug op niets en kan één import de webpods verdringen. Meten, dan instellen.
- 5
Image-tag latest
Je weet niet welke code draait, een herstart kan ineens nieuwe code ophalen en terugdraaien kan niet. Vaste tags of digests, door de pipeline gezet.
- 6
Helm-charts van derden blind installeren
Charts en images veranderen van licentie, locatie of onderhouder, zoals bij Bitnami in 2025. Pin versies, controleer de bron en kies bewust wat je in productie zet.
Heb je Kubernetes nodig, en ben je er klaar voor?
Acht vragen. Antwoord je op meer dan twee met “nee” of “weet ik niet”, dan is managed hosting waarschijnlijk de betere stap.
- 1Draai je meerdere shops, apps of services die je op één platform wilt beheren?
- 2Heb je verkeerspieken die je huidige hosting niet goed opvangt?
- 3Heb je veel achtergrondwerk, zoals imports, exports en queues, dat los van de webserver moet schalen?
- 4Draait je applicatie al in containers, lokaal en in CI?
- 5Staan media, sessies en cache al buiten de webserver?
- 6Heb je een geautomatiseerde pipeline die bij elke release hetzelfde doet?
- 7Is er iemand, intern of extern, die het cluster structureel beheert en updates bijhoudt?
- 8Ken je de kostenposten van een cluster, ook de uren voor beheer en monitoring?
Kubernetes-begrippen, kort uitgelegd
De termen die je tegenkomt zodra je over Kubernetes voor je platform praat.
- Pod
- De kleinste eenheid in Kubernetes: één of meer containers die samen draaien, bijvoorbeeld PHP-FPM met nginx. Pods zijn tijdelijk en kunnen elk moment vervangen worden.
- Deployment
- Beschrijft hoeveel identieke pods er draaien en hoe ze bij een release worden vervangen. Webpods, queue-consumers en workers draaien als Deployment.
- StatefulSet
- Voor workloads met vaste identiteit en eigen opslag, zoals een database of zoekcluster. Kan, maar vraagt veel meer beheer dan een stateless Deployment.
- Namespace
- Een logische afscheiding binnen een cluster. Handig om shops, apps of omgevingen te scheiden, met eigen rechten, quota en policies.
- Service
- Een vast netwerkadres voor een groep pods. Pods komen en gaan, de Service blijft en verdeelt het verkeer.
- Ingress
- De oudere Kubernetes-API om HTTP-verkeer van buiten naar Services te routeren. De API bestaat nog, maar de populaire controller ingress-nginx wordt sinds maart 2026 niet meer onderhouden.
- Gateway API
- De opvolger van Ingress: rijkere routering en een duidelijke scheiding tussen wie het platform beheert en wie routes aanmaakt. Werkt met implementaties als Envoy Gateway, Traefik of Cilium.
- Helm
- Package manager voor Kubernetes. Een chart is een sjabloon voor alle manifests van een applicatie, ingevuld met values per omgeving.
- Kustomize
- Manifests aanpassen per omgeving met overlays in plaats van sjablonen. Ingebouwd in kubectl en goed te combineren met Helm.
- GitOps
- Werkwijze waarbij de gewenste staat van het cluster in Git staat en een tool het cluster daarmee gelijk houdt. Elke wijziging is een commit, elke rollback een revert.
- Argo CD
- GitOps-tool die Git en cluster vergelijkt en synchroniseert. Met sync waves en hooks bepaal je de volgorde, bijvoorbeeld eerst migraties, dan de nieuwe pods.
- HPA
- Horizontal Pod Autoscaler: schaalt het aantal pods op basis van metrics als CPU, geheugen of eigen metrics. Goed voor webverkeer.
- KEDA
- Event-driven autoscaling voor Kubernetes, een CNCF-project. Schaalt workers op bijvoorbeeld de lengte van een Redis-queue en kan terug naar nul.
- Operator
- Software die een applicatie in het cluster beheert via eigen resources (CRD's), zoals cert-manager voor certificaten of External Secrets voor secrets uit een vault.
Alle gidsen
14 praktische artikelen, geordend per onderwerp.
Keuze & kosten
Magento & Laravel op Kubernetes
- ›Magento 2 op Kubernetes: de architectuur per component
- ›Magento deployen op Kubernetes zonder downtime
- ›Laravel op Kubernetes: Horizon, queues en scheduler inrichten
- ›Laravel-queues automatisch schalen met KEDA
- ›Helm-chart voor je Laravel-app: structuur, values en valkuilen
- ›Magento 2 en Docker — lokale development setup die werkt
Deploy, GitOps & CI/CD
Veelgestelde vragen
Gerelateerde pagina’s
Kubernetes als het loont, managed hosting als dat beter is
We kijken naar je platform, zeggen eerlijk welke route past en bouwen en beheren het daarna zelf. Plan een gesprek met het team dat het doet.