Platform

Stel je dit voor: een aanvaller kraakt één pod in je cluster, via een kwetsbare image of een gelekte token. Vanuit dat ene bruggenhoofd kan deze elke database, elke interne API en elke secret-ophalende sidecar bereiken die je draait. Niets houdt hem tegen, want standaard probeert niets dat. Network Policies zijn precies het ding dat hem tegenhoudt. Ze maken van “één gecompromitteerde pod” gewoon “één gecompromitteerde pod, en daar blijft het bij.” Iedereen weet dat ze ze zouden moeten gebruiken. Bijna niemand doet het echt, want de YAML ziet er eng uit en het gedrag is raar tot het mentale model klikt. ...

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

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