Kubernetes: de overkill die je waarschijnlijk niet nodig hebt

Het is 2026 en toch zie ik het nog steeds gebeuren: kleine bedrijven met een paar developers, een relatief eenvoudige webapplicatie en voorspelbare, beperkte traffic die besluiten Kubernetes te implementeren. Niet omdat hun product het nodig heeft, maar omdat "Netflix het ook gebruikt", omdat het zogenaamd de standaard is, of simpelweg omdat een Kubernetes-implementatie als prestigeproject wordt gezien. In deze opinie ontleed ik waarom Kubernetes voor het overgrote deel van de bedrijven vooral extra complexiteit toevoegt — en zelden echte waarde oplevert.

Het probleem dat je niet hebt

Kubernetes is ontworpen voor een specifiek probleem: het orkestreren van duizenden containers over honderden servers, met automatische scaling, self-healing en zero-downtime deployments op enorme schaal. Google bouwde het omdat zij dit probleem daadwerkelijk hadden.

Heb jij dit probleem? Waarschijnlijk niet. Als je load voorspelbaar is — wat bij de meeste applicaties gewoon het geval is — als er geen fulltime DevOps-team beschikbaar is, en als je applicatie prima draait op een paar servers, dan ben je een probleem aan het oplossen dat je in de praktijk helemaal niet hebt.

De verborgen kosten

Wat ik in de praktijk zie:

• 1. Kennisconcentratie: In een klein team is er vaak maar een persoon die Kubernetes echt snapt. Als die persoon ziek is of vertrekt, heb je een serieus probleem. De leercurve is zo steil dat niet iedereen het zomaar oppakt.
• 2. Operationele overhead: Kubernetes clusters moeten onderhouden worden. Updates, security patches, monitoring, logging — het vraagt continue aandacht. Aandacht die je developers hadden kunnen besteden aan features.
• 3. Debugging complexiteit: Iets werkt niet? Succes met het uitzoeken of het aan je applicatie ligt, aan je container configuratie, aan je pod specs, aan je service mesh, aan je ingress controller, of aan een van de tientallen andere bewegende onderdelen.
• 4. Cloud kosten: Een managed Kubernetes cluster (EKS, GKE, AKS) kost al snel honderden euro's per maand, los van de compute resources. Voor wat? Om een handvol containers te draaien die ook prima op een betaalbare VPS hadden gekund?

Performance overhead

Wat ook vaak vergeten wordt: Kubernetes kan applicaties in kleine omgevingen juist trager maken. In plaats van een krachtige server die tijdens piekmomenten tijdelijk meer CPU of RAM kan gebruiken, wordt capaciteit opgesplitst in tientallen kleine pods met strakke resource limits.

In theorie is dat efficient. In de praktijk betekent het extra network hops tussen services, meer latency door de overlay networking van Kubernetes, en minder flexibiliteit tijdens piekbelasting. Vooral databases en stateful services kunnen hier merkbaar last van hebben — juist de componenten waar performance het meest telt.

De resource-realiteit

Laten we het concreet maken. Stel: je hebt een budget waarmee je ongeveer 32 GB RAM aan compute kunt draaien. Hoe ziet dat er in de praktijk uit?

En wordt je server te klein? Bij de meeste hosters schaal je met een paar klikken op naar meer CPU en RAM. Downtime: vaak een paar minuten. Geen migratie naar een complex cluster nodig, geen autoscaling policies, geen extra observability tooling. Vertical scaling is voor 9/10 omgevingen verrassend lang toereikend.

Je applicatie moet ook mee

Wat vaak onderschat wordt: het is niet alleen je infrastructuur die verandert als je naar Kubernetes gaat. Je applicatiecode zelf moet er ook klaar voor zijn. Dingen die op een normale server vanzelfsprekend zijn, worden in een Kubernetes-omgeving ineens engineering challenges die dev-cycles kosten.

• ✗ File storage: Op een server schrijf je een upload naar disk en klaar. In Kubernetes heeft iedere pod zijn eigen ephemeral storage. Pod A schrijft een bestand, pod B kan het niet lezen. Je moet shared storage opzetten (PersistentVolumeClaims met ReadWriteMany — complex en duur) of alles migreren naar object storage zoals S3. Code die Storage::put() doet, moet ineens herschreven worden.
• ✗ Sessions en cache: File-based sessions en cache werken niet meer als requests over meerdere pods verdeeld worden. Je hebt Redis of een database-backed session driver nodig — extra infrastructuur die je anders niet had gehad.
• ✗ Configuratie: Op een server drop je een .env bestand en je bent klaar. In Kubernetes wordt dit ConfigMaps voor niet-gevoelige waarden en Secrets voor credentials, eventueel met tools als Sealed Secrets of External Secrets Operator om ze veilig te beheren. Een simpele configuratiewijziging gaat van "bestand aanpassen, service herstarten" naar "Secret updaten, rollout restart triggeren, controleren of alle pods de nieuwe config hebben opgepikt."
• ✗ Cron jobs: Op een server voeg je een regel toe aan crontab en het werkt. In Kubernetes heb je CronJob resources nodig met eigen concurrency policies, history limits en failure handling. Meer YAML, meer bewegende onderdelen, meer dat fout kan gaan.
• ✗ Database migraties: Op een server draai je php artisan migrate en klaar. Met meerdere pods moet je garanderen dat slechts een pod tegelijk migraties draait — via init containers of Kubernetes Jobs. Anders krijg je race conditions op je database schema.

Kortom: een Kubernetes-migratie is niet alleen een infrastructuur-beslissing. Het is een applicatie-refactor die dev-cycles kost, extra complexiteit introduceert en je team opzadelt met problemen die op een normale server simpelweg niet bestaan. Problemen waar je business geen enkel voordeel uit haalt.

Wanneer het WEL zin heeft

Even voor de duidelijkheid: Kubernetes is geen slechte technologie. Het is geweldige technologie, voor de juiste use case. Overweeg Kubernetes als:

• ✓ Je daadwerkelijk moet schalen naar honderden of duizenden containers
• ✓ Je een dedicated platform/DevOps team hebt dat zich hierop kan focussen
• ✓ Je load onvoorspelbaar is en je echt auto-scaling nodig hebt
• ✓ Je meerdere teams hebt die onafhankelijk van elkaar moeten kunnen deployen

Wat je ook zou kunnen doen

Voor de meeste kleine tot middelgrote bedrijven is dit een veel betere setup:

• ✓ Een managed platform: Laravel Forge, Ploi, of zelfs gewoon Heroku. Zero-downtime deployments, SSL, monitoring — zonder de complexiteit.
• ✓ Simpele VPS'en: DigitalOcean, Hetzner, of OVH. Betaalbaar, betrouwbaar, en iedereen in je team kan ermee overweg.
• ✓ Docker Compose voor development: Consistent tussen development en productie, zonder de orkestratie overhead.
• ✓ Serverless voor specifieke workloads: AWS Lambda of Cloudflare Workers voor die ene functie die wel moet schalen.

Herken je dit? Zit je vast met een te complexe setup? Laat het me weten — ik help graag om dingen weer simpel te maken.