Advanced

Elke vendor pitch deck heeft op dit moment dezelfde slide. “Autonomous cluster management.” Een AI bewaakt je Kubernetes cluster, ziet problemen, diagnosticeert ze, en fixt ze terwijl jij slaapt. Platform engineers stoppen met brandjes blussen en het cluster geneest zichzelf. Ik draai een homelab juist omdat ik wil begrijpen wat er echt gebeurt, in plaats van een black box te vertrouwen. Dus als ik zo’n claim zie, is mijn eerste reflex om het zelf te testen in plaats van de slide te geloven. ...

Ik scande mijn images met Trivy. Ik dwong policies af met Kyverno. Mijn workloads kregen cryptografische identiteit via SPIFFE. Drie lagen preventie, allemaal groen, en een tijd lang voelde dat als genoeg. Toen begon ik de ongemakkelijke vraag te stellen. Wat gebeurt er nadat een pod draait? Mijn scanners controleerden de image die erin ging. Mijn admission controller controleerde de spec bij deployment. Geen van beide kijkt nog mee zodra het proces daadwerkelijk draait. Als een container om 3 uur ’s nachts wordt gepakt door een zero-day, hebben al die controls hun werk al gedaan en zijn ze naar huis. ...

Hoe weet Service A dat Service B echt Service B is? Ik blijf bij die vraag terugkomen, want het gangbare antwoord is ongemakkelijk. Jarenlang vertrouwden we op netwerklocatie. Traffic van het juiste IP was legitiem, klaar. Zero trust nam die aanname mee naar buiten en schoot hem dood. Nu moet elke service bewijzen wie hij is, bij elk request, ongeacht waar hij op het netwerk zit. Dat klinkt prima op een slide. Het lastige is het bewijs. Hoe laat een pod werkelijk zijn identiteit zien aan een andere pod, zonder dat ik overal met de hand secrets uitdeel en daarna eindeloos hun rotatie zit te bewaken? ...

Ik had ooit een wiki-pagina met de titel “Cluster conventies”. Resource limits op alles. Geen :latest tags. Geen deploys in de default namespace. Het was een prima pagina. Niemand las hem. Na een half jaar overtrad de helft van het cluster die regels, en ik kwam er pas achter toen er iets omviel. Een regel die in een doc leeft is een suggestie. Een regel die de API server weigert te accepteren is governance. Dat gat is precies waarom deze post bestaat. ...

Een standaard Kubernetes Deployment heeft me lang prima gediend. Push een nieuwe image tag, kijk hoe de pods rollen, klaar. Simpel, declaratief, en meestal ging er niks mis. De rolling update gaf me zelfs een warm gevoel van veiligheid: oude pods verdwijnen pas als de nieuwe ready zijn. Dat gevoel is een leugen. Een rolling update beschermt je tegen pods die niet opstarten. Hij doet niks tegen pods die perfect opstarten en vervolgens kapotte responses serveren. De container is gezond, de readiness probe is groen, en je nieuwe code stuurt stilletjes 500’s naar elke gebruiker. Binnen seconden raakt 100% van je traffic code die niemand onder echte load heeft gevalideerd. ...