Architecture

Ik schrijf veel over Kubernetes. Ik draai het dagelijks. Ik vind het oprecht een mooi stuk techniek. Dus het verbaast je misschien dat ik regelmatig mensen ervan afpraat. Dit is het scenario waar ik steeds opnieuw inloop. Een klein team, één product, een roadmap vol echte features om te bouwen, en iemand heeft besloten dat de eerste mijlpaal een Kubernetes cluster is. Minimaal drie nodes, etcd, een CNI, een ingress controller, cert-manager, een monitoring stack. Weken werk voordat één klant iets ziet. Iedereen knikt mee, want zo ziet serieuze infrastructuur er nu eenmaal uit in 2026. ...

Mijn homelab begon met één ArgoCD Application. Daarna een handvol. Toen ik mezelf voor de vijftiende keer kubectl apply -f zag draaien om weer een Application te registreren, wist ik dat ik precies had gebouwd wat ik wilde vermijden: handmatige stappen die ik moest onthouden, in een volgorde die ik moest onthouden, zonder enige administratie van wat er zou moeten bestaan. Het App-of-Apps pattern lost dat op met één idee. Je maakt met de hand een enkele root Application, en die maakt de rest aan. Na een gewist cluster bouw ik het geheel terug met één kubectl apply. Die eigenschap is de hele reden dat ik het draai, en het is dezelfde reden dat ik überhaupt self-host: ik wil dat de repository de waarheid is, niet mijn geheugen. ...

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. ...

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? ...

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. ...