Kubernetes

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

De eerste keer dat ik kubectl get secret myapp -o yaml draaide en de waarde base64-decodeerde, zakte mijn maag. Daar stond mijn database-wachtwoord, gewoon in etcd, leesbaar voor iedereen die met de juiste RBAC bij de API kon. Kubernetes Secrets zijn geen secrets. Het is base64-gecodeerde platte tekst met een mooie naam. Dat is de default, en het is precies het ding waar niemand je op dag één voor waarschuwt. ...

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

Lange tijd draaide mijn CI op de servers van iemand anders. Push code, wacht op een hosted runner, kijk hoe de minuten aftikken tegen een maandelijks quotum, hoop dat de provider de regels niet verandert volgend kwartaal. Het werkte, tot ik me begon af te vragen waar mijn broncode eigenlijk stond terwijl hij gebouwd werd, en wie er nog meer bij kon. Dus haalde ik GitLab in huis. Ik draai hem nu self-hosted, op eigen hardware, naast de clusters waarnaar hij deployt. Dat is soevereiniteit toegepast op CI/CD: mijn code, mijn builds, mijn artifacts, geen vendor die prijzen kan veranderen, een feature kan deprecaten waar ik van afhankelijk ben, of mijn repositories kan lezen zonder dat ik het weet. ...