Kubernetes in production on Tom Meurs

Simulatie, emulatie, virtualisatie en containers: de restaurant-metafoor

Mon, 23 Feb 2026 20:18:00 +0100

TL;DR Simulatie modelleert iets zonder het te draaien. Emulatie draait het door de hardware in software na te bouwen. Virtualisatie draait meerdere complete besturingssystemen op één machine. Containers draaien meerdere apps op één kernel. Hieronder per term een restaurant, een tabel, en de vier verwarringen die ik het vaakst hoor.

“Dus wat is nou het verschil tussen een container en een virtual machine?”

Die vraag krijg ik vaak. Meestal van iemand die slim genoeg is om in vergaderingen mee te knikken en niet zo goed wil toegeven dat het vaag is. Eerlijk? De meeste uitleg maakt het erger. Die begint met “hypervisor”, “kernel sharing” en “hardware-abstractie”, en nu heeft die persoon vier nieuwe termen om over in de war te zijn in plaats van één.

Wanneer je Kubernetes niet moet gebruiken

Sat, 17 Jan 2026 10:00:00 +0100

Ik schrijf veel over Kubernetes en ik draai het thuis elke dag. Ik vind het mooi spul.

Dus het verbaast je misschien dat ik een flink deel van m’n tijd besteed aan mensen ervan afpraten.

Het gaat steeds zo. Een klein team, één product, een roadmap vol features waar klanten op wachten, en iemand heeft besloten dat de eerste mijlpaal een Kubernetes-cluster is. Minimaal drie nodes, etcd, een CNI , een ingress controller, cert-manager, een monitoringstack. Weken werk voordat één klant iets ziet. Iedereen knikt mee, want zo hoort een serieuze setup er nu eenmaal uit te zien.

Data-driven Kubernetes migratie: waarom je metrics nodig hebt voordat je beweegt

Sun, 08 Feb 2026 14:00:00 +0100

TL;DR Een e-commerceklant verhuisde een PHP-monoliet in oktober naar EKS, twee weken voor Black Friday, met resource-limits die gegokt waren op de oude serverspecs. Halverwege de ochtend liepen de pods tegen hun memory-limit aan, gingen vier uur lang in een loop dood, en de schatting was €240.000 aan gemiste omzet. De tweede helft gaat over hoe je die getallen uit loadtests en VPA-aanbevelingen haalt in plaats van ze te gokken.

Kubernetes high availability: stacked vs external etcd uitgelegd

Wed, 15 Jan 2025 20:23:00 +0100

Het eerste “productie” Kubernetes cluster dat ik draaide had één control plane node. Het tikte weken vrolijk door, totdat een disk kapotging en het hele ding meenam. Elke pod, elke service, weg. Die storing leerde me hoe “single point of failure” echt voelt, en duwde me naar een vraag die ik mensen steeds zie struikelen: als je een cluster bouwt dat node-verlies overleeft, draai je etcd dan op je control plane nodes, of op aparte nodes?

Hoe etcd echt werkt: het hart van je Kubernetes cluster

Mon, 27 Jan 2025 21:47:00 +0100

Als er iets misgaat in Kubernetes, leidt het spoor meestal terug naar etcd. API server timeout? Check etcd. Pods stuck in pending? Misschien etcd. Cluster voelt traag? Waarschijnlijk etcd.

Ik behandelde etcd lang zoals de meeste operators dat doen: als een black box die naast het control plane meedraait. “De database.” Je maakt er een backup van en laat het verder met rust. Maar black boxes voelen voor mij als splinters, en de eerste keer dat een etcd cluster om 2 uur ’s nachts omviel besefte ik dat ik geen idee had waar ik naar keek. Dus heb ik het uitgezocht. En het blijkt te draaien op een handjevol ideeën die, zodra ze landen, de meeste etcd problemen diagnoseerbaar maken in plaats van eng.

Graceful degradation in Kubernetes: wat gebeurt er als componenten falen

Thu, 20 Feb 2025 14:22:00 +0100

Iedereen herhaalt de zin dat Kubernetes zelf-herstellend is. Pods sterven, ze komen terug. Nodes vallen weg, workloads herschedulen. Het systeem reconcilieert zichzelf naar de staat die je hebt gedeclareerd, en de meeste dagen denk je er nooit over na.

Dan is op een dag het ding dat het herstel doet juist het ding dat kapot ging. De API server is down. etcd reageert niet. De scheduler zit vast. En nu?

Onkapotbaar - mijn fascinatie.

Tue, 23 Dec 2025 20:00:00 +0100

Als kind noemde ik de dingen die me fascineerden onkapotbaar. Onverwoestbaar klopte nooit, want onverwoestbaar is iets dat nooit kapotgaat. Onkapotbaar is iets dat blijft werken nadat het kapot is.

Ik weet nog precies waar het begon. Een foto van een A-10 Thunderbolt II, terug van een missie met een halve vleugel weg, de staart aan flarden en de romp vol gaten. Dat ding bracht zijn piloot gewoon thuis.

Geluk had daar niks mee te maken. Iemand heeft jaren voor die missie aan een tekentafel besloten dat dat vliegtuig er zo uit mocht zien en toch thuis moest komen.

Chaos engineering: je cluster kapot maken om het sterker te maken

Tue, 28 Apr 2026 19:45:00 +0100

TL;DR Chaos engineering is je eigen cluster expres kapot maken, met de hypothese vooraf op papier en een rollback binnen handbereik. Ik draai het op de homelab met Litmus: een wekelijkse pod-delete, een maandelijkse node drain, elk kwartaal een game day. Tot nu toe heeft het vier dingen gevonden die het dashboard me nooit had laten zien.

M’n dashboard is een muur van groen. Pods draaien, replicas kloppen, CPU rustig, geen alert te bekennen. Ik kijk ernaar en krijg dat kleine shotje “alles is in orde.” En grotendeels klopt dat ook. Het cluster draait al weken en er is niks omgevallen.

Kubernetes offline draaien: edge computing zonder internet

Tue, 04 Mar 2025 20:47:00 +0100

Wat gebeurt er als je Kubernetes cluster geen internet kan bereiken? Ik bedoel geen trage verbinding. Ik bedoel helemaal geen verbinding. Schepen op zee. Afgelegen mijnbouwlocaties. Fabrieksvloeren met air-gapped netwerken. Militaire deployments.

Voor veel mensen klinkt dat exotisch, alsof het een probleem van iemand anders is. Ik behandel het als een basis-ontwerpeis, en ik leg uit waarom het mijn homelab beter maakt terwijl ik de kabel bijna nooit echt eruit trek.