Kubernetes of managed hosting voor je webshop?

Voor de meeste webshops is goede managed hosting de betere keuze: goedkoper, eenvoudiger en met minder bewegende delen. Kubernetes gaat lonen als je meerdere shops of apps op één platform draait, als je verkeer sterk wisselt, als je veel achtergrondwerk hebt of als je organisatie al op Kubernetes draait. Hieronder de eerlijke afweging, met de vragen die je zelf kunt beantwoorden voordat iemand je een cluster verkoopt.

De eerlijke versie: Kubernetes is geen doel

Kubernetes is een platform om containers te draaien, te schalen en te vervangen. Het lost een specifiek probleem op: veel losse onderdelen betrouwbaar laten draaien op een wisselende hoeveelheid machines. Heb je dat probleem niet, dan koop je vooral complexiteit.

Een Magento-shop op één goed ingerichte managed omgeving heeft weinig bewegende delen. De hoster regelt het besturingssysteem, PHP, de database, Varnish, Valkey of Redis en OpenSearch. Jij en je bouwpartner regelen de applicatie. Dat is een overzichtelijke taakverdeling.

Op Kubernetes wordt die taakverdeling anders. Iemand moet het cluster upgraden, de ingress of Gateway beheren, certificaten laten vernieuwen, monitoring inrichten en secrets beheren. Dat werk verdwijnt niet. Het verschuift naar jou of naar de partij die het voor je draait.

Wij zijn Hypernode Silver Partner en bouwen tegelijk Kubernetes-platformen. We hebben dus geen belang bij het ene of het andere antwoord. Wel bij het juiste.

Wanneer managed hosting de betere keuze is

Managed hosting wint in deze situaties:

• Eén shop, voorspelbaar verkeer. Je hebt pieken rond Black Friday en de feestdagen, maar die kun je plannen. Een tijdelijke upgrade van je plan is dan goedkoper dan een autoscaling-platform.
• Geen eigen platformteam. Niemand in je organisatie weet wat een PodDisruptionBudget is, en dat hoeft ook niet.
• De shop is de applicatie. Je hebt geen losse services, geen eigen API-laag, geen zware importstraten naast Magento.
• Budget gaat liever naar features. Elk uur platformbeheer gaat af van je roadmap.

Wat je bij een goede managed Magento-hoster krijgt, en hoe Hypernode dat invult, staat op onze pagina over Hypernode hosting.

Wanneer Kubernetes wel loont

Kubernetes gaat terugverdienen als een of meer van deze punten op jou van toepassing zijn.

Meerdere shops of apps op één platform

Draai je drie Magento-storefronts, een Laravel-API, een PIM-koppeling en een paar workers, dan beheer je anders drie tot zes losse omgevingen. Op Kubernetes deel je de basis: één manier van deployen, één monitoringstack, één set beveiligingsregels. Elke nieuwe app is een extra Helm-release, geen nieuwe server.

Sterk wisselend verkeer

Een shop die met campagnes, tv-spots of flash sales binnen minuten meerdere keren zoveel verkeer krijgt, heeft baat bij autoscaling. Kubernetes schaalt pods op basis van CPU, geheugen of eigen metrics, en een node-autoscaler voegt machines toe als dat nodig is. Meer daarover op onze pagina over autoscaling met HPA, KEDA en Karpenter.

Let op: autoscaling van PHP-pods helpt niet als je database de bottleneck is. Die schaalt niet mee met een paar extra pods.

Veel achtergrondwerk

Productimports, prijsfeeds, ERP-synchronisatie, e-mailqueues, indexers. Op één server concurreert dat werk met je bezoekers om CPU. Op Kubernetes draai je het in aparte pods, eventueel op aparte nodes, en schaal je workers op de lengte van de queue.

Een voorbeeld met KEDA, dat queue-consumers schaalt op basis van een RabbitMQ-queue:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: magento-consumer-product-import
spec:
  scaleTargetRef:
    name: magento-consumer-product-import
  minReplicaCount: 0
  maxReplicaCount: 6
  triggers:
    - type: rabbitmq
      metadata:
        queueName: product_import
        mode: QueueLength
        value: "100"
      authenticationRef:
        name: rabbitmq-auth

Staat de queue leeg, dan draaien er nul consumers. Komt er een import binnen, dan schaalt KEDA op. Dat soort gedrag is op een klassieke server lastig na te bouwen.

Portabiliteit of multi-cloud

Moet je kunnen verhuizen tussen cloudaanbieders, of eisen je klanten of je compliance dat je niet aan één leverancier vastzit? Kubernetes is dan een gemeenschappelijke laag. Je manifests en Helm-charts werken grotendeels op elk conform cluster. Grotendeels: load balancers, storage classes en identity verschillen per aanbieder.

Je organisatie draait al op Kubernetes

Heeft je IT-afdeling al clusters, monitoring en een security-beleid, dan is een webshop erbij zetten logischer dan een losse hostingomgeving naast die standaard. De platformkosten zijn dan grotendeels al gemaakt.

Wat niemand je vertelt over Kubernetes voor een webshop

Een paar punten die in verkooppraatjes vaak ontbreken.

Je database blijft het lastige deel. MySQL of MariaDB in een cluster draaien kan, met een operator. Maar back-ups, failover, upgrades en performance-tuning blijven specialistisch werk. Wij adviseren bijna altijd een managed database buiten het cluster.

Magento is niet out-of-the-box stateless. Media, sessies, cron, de maintenance-flag en gegenereerde code moeten allemaal bewust een plek krijgen. Hoe dat per component werkt, lees je in Magento 2 op Kubernetes: de architectuur per component.

Componenten veranderen onder je voeten. Twee voorbeelden uit de afgelopen periode:

• Het community-project ingress-nginx is in maart 2026 met pensioen gegaan. Sindsdien komen er geen releases, bugfixes of securitypatches meer. Wie daar nog op draait, moet migreren naar de Gateway API of een andere ingress-controller.
• Bitnami heeft in 2025 het gratis aanbod van containerimages sterk ingeperkt. Oude tags staan in een legacy-repository die geen updates meer krijgt; actuele, onderhouden images zitten grotendeels achter het betaalde Bitnami Secure Images. Veel Helm-charts voor MySQL, Redis en RabbitMQ leunden op die images.

Op managed hosting merk je zulke verschuivingen nauwelijks. Op Kubernetes is het jouw werk, of dat van je partner.

Kubernetes zelf heeft een releasetempo. Er verschijnen ongeveer drie minor-versies per jaar, en elke versie krijgt ongeveer veertien maanden patches. Een cluster bijhouden is dus doorlopend werk, geen eenmalige klus.

Signalen dat je huidige hosting knelt

Niet elk probleem is een platformprobleem. Maar deze signalen wijzen wel die kant op:

• Imports en indexers vertragen de frontend. Elke nacht, of erger: overdag tijdens een prijsupdate.
• Je zet steeds vaker een extra server neer voor een koppeling, een API of een tool, elk met eigen beheer en eigen patchmomenten.
• Opschalen kost dagen in plaats van minuten, omdat er een ticket, een migratie of een herstart bij komt kijken.
• Deploys zijn spannend. Niemand weet precies wat er op de server staat, en terugdraaien is handwerk.

Het laatste punt los je overigens ook zonder Kubernetes op, met een nette CI/CD-straat naar managed hosting. De eerste drie zijn structureler.

Een beslisschema in vijf vragen

Beantwoord deze vragen eerlijk. Twee of meer keer "ja" bij vraag 1 tot en met 4 is een signaal om Kubernetes serieus te onderzoeken.

1. Draai je meer dan één shop of applicatie die je samen wilt beheren?
2. Schommelt je verkeer onvoorspelbaar, met pieken die je plan regelmatig overschrijden?
3. Heb je zware achtergrondprocessen die nu je frontend vertragen?
4. Heb je een harde eis voor portabiliteit, of draait je organisatie al op Kubernetes?
5. Is er iemand, intern of extern, die het platform structureel beheert, ook in het weekend?

Is het antwoord op vraag 5 "nee", dan is Kubernetes geen optie. Hoe goed de argumenten bij 1 tot en met 4 ook zijn.

De tussenvormen

Het is geen zwart-witkeuze. Er zitten varianten tussen.

• Managed hosting plus losse containers. De shop blijft op managed hosting. Een Laravel-koppeling of importservice draait als container elders. Prima startpunt.
• Managed Kubernetes. Het control plane wordt beheerd door de aanbieder, zoals EKS, GKE, AKS of Europese aanbieders als Scaleway, OVHcloud en DigitalOcean. Jij beheert nodes, workloads en add-ons. Hetzner biedt zelf geen managed Kubernetes; daar draai je k3s of Talos zelf, of via een derde partij. Meer in managed Kubernetes kiezen.
• Volledig door een partner gedraaid. Iemand anders bouwt de images, de Helm-charts, de GitOps-straat en de monitoring, en blijft het platform beheren. Dat is wat wij doen. Zie ons overzicht Kubernetes voor webshops en Laravel-platformen.

Hoe een migratie eruitziet als het wel past

Komt Kubernetes uit de vragen als goede keuze, dan migreren we stapsgewijs. Niet in één big bang.

1. Container-image bouwen. De shop draait eerst lokaal en in CI als image, met DI-compilatie en static content in het image.
2. Externe diensten loskoppelen. Database, sessies, cache en media gaan naar diensten die meerdere pods kunnen delen.
3. Staging op het cluster. Een volledige kopie draait op Kubernetes, inclusief cron, consumers en Varnish.
4. Loadtest. Pas als staging zich onder belasting gedraagt zoals verwacht, plannen we de overstap.
5. DNS-switch. Productie verhuist met een korte freeze op de database-sync.

De configuratie zit vanaf dag één in Git. Een minimale Argo CD Application voor de shop ziet er zo uit:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: shop-productie
  namespace: argocd
spec:
  project: webshops
  source:
    repoURL: https://git.example.nl/platform/shop-deploy.git
    targetRevision: main
    path: overlays/productie
  destination:
    server: https://kubernetes.default.svc
    namespace: shop-productie
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Daarmee is elke wijziging aan het platform een commit, met reviewer en geschiedenis. Hoe wij Magento specifiek inrichten, staat op Magento 2 op Kubernetes.

Kosten: waar je op moet letten

We noemen hier bewust geen bedragen. Prijzen van cloudaanbieders veranderen en hangen sterk af van je opzet. Wel de kostenposten die je naast elkaar moet zetten:

• Managed hosting: een vast maandbedrag per plan, plus eventueel tijdelijk opschalen.
• Kubernetes: control plane (bij sommige aanbieders), nodes, load balancers, storage, dataverkeer, managed database, logging en monitoring, en vooral: de uren voor beheer en upgrades.

De volledige lijst, met een rekenstap die je zelf kunt invullen, staat in wat kost Kubernetes voor een webshop?.

De rekenstap in het kort: Kubernetes is pas goedkoper als de besparing op losse omgevingen en overcapaciteit groter is dan de extra beheeruren. Bij één shop is dat zelden zo.

Ons advies

Begin bij je probleem, niet bij de technologie. Is je shop traag, dan los je dat meestal op in de applicatie en de caching, niet in het platform. Heb je meerdere apps, wisselend verkeer en zwaar achtergrondwerk, dan is Kubernetes een serieuze optie.

Twijfel je? Leg je situatie aan ons voor via contact. We zeggen het ook als je beter op managed hosting kunt blijven.