Resilience

Stel je voor dat de disk in je homelab vannacht sterft. Niet corrupt raken, niet eerst een week lang SMART-waarschuwingen geven, gewoon weg. De GitLab met elke repo waar je om geeft, de password vault, vijftien jaar familiefoto’s, de home automation die je huis aanstuurt. Allemaal op een drive die heeft besloten dat hij klaar is. Kun je beantwoorden wat er daarna gebeurt zonder dat je maag samentrekt? Zo niet, dan heb je geen backups. Je hebt hoop, en hoop is geen strategie waarvan je de grenzen om 2 uur ’s nachts wilt ontdekken. ...

Mijn dashboard is een muur van groen. Pods draaien, replicas kloppen, CPU comfortabel, geen alerts. Ik kijk ernaar en voel dat kleine dopamine-shotje van “alles is in orde.” En grotendeels klopt dat ook. De cluster draait al weken. Er is niks omgevallen. Die groene muur is tegelijk het gevaarlijkste in mijn homelab, want hij vertelt me niks over wat er gebeurt als het mis gaat. Hij vertelt me alleen dat er, op dit moment, nog niks mis is gegaan. ...

In mijn vorige post over Prometheus en Thanos zette ik de sidecar architectuur op. Thanos Sidecar draait naast Prometheus, uploadt TSDB blocks naar object storage, en stelt data via gRPC beschikbaar aan de Querier. Voor clusters die in hetzelfde datacenter staan met een dikke, stabiele link naar je centrale infrastructuur is dat heerlijk. Alles pullt. Alles praat met alles. Het leven is goed. Toen begon ik Prometheus op clusters aan de edge te zetten, en werd het leven minder goed. ...

Het eerste cluster dat ik echt in productie draaide had precies één permissiemodel: alles was cluster-admin. Mijn CI pipeline, mijn monitoring stack, het kleine webhook-ontvangertje dat ik op een middag in elkaar zette. Allemaal konden ze elk secret lezen, elke deployment verwijderen en elke namespace aanraken. Het werkte prima, tot ik begon na te denken over wat er gebeurt als één van die pods wordt overgenomen. Kubernetes RBAC (Role-Based Access Control) beantwoordt één vraag: wie mag wat doen met welke resources? Het standaardantwoord op de meeste clusters is “iedereen kan alles doen,” en dat antwoord wordt stilletjes je grootste aansprakelijkheid. ...

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