Resilience

Je homelab draait je GitLab, je wachtwoorden, je foto’s, je home automation. Wat gebeurt er als de disk faalt? Als je die vraag niet met vertrouwen kunt beantwoorden, heb je geen backups. Je hebt hoop. De 3-2-1 regel bestaat al decennia omdat hij werkt. Drie kopieën, twee verschillende media, één offsite. Hier is hoe je het daadwerkelijk implementeert. De 3-2-1 Regel Uitgelegd flowchart TD subgraph rule["3-2-1 Backup Regel"] Data["Originele Data"] subgraph three["3 Kopieën"] C1["Kopie 1<br/>(Origineel)"] C2["Kopie 2<br/>(Lokale Backup)"] C3["Kopie 3<br/>(Offsite)"] end subgraph two["2 Media Types"] M1["NVMe/SSD"] M2["HDD/NAS"] end subgraph one["1 Offsite"] Off["Cloud/Remote"] end end Data --> C1 Data --> C2 Data --> C3 C1 --> M1 C2 --> M2 C3 --> Off Waarom Drie Kopieën? Kopie 1: Je live data (origineel) Kopie 2: Lokale backup (snelle restore) Kopie 3: Offsite backup (disaster recovery) Eén kopie is geen backup. Twee kopieën kunnen allebei falen in dezelfde ramp (brand, overstroming, ransomware). Drie kopieën met separatie geeft je echte resilience. ...

Je cluster ziet er gezond uit. Pods draaien. Metrics zijn groen. Alles werkt. Tot een node faalt tijdens piekverkeer. Of de database connection pool uitgeput raakt. Of die ene service die niemand zich herinnert gedeployed te hebben al het beschikbare geheugen begint op te eten. Je kunt wachten tot deze dingen gebeuren in productie om 3 uur ’s nachts. Of je kunt opzettelijk dingen kapot maken, op jouw voorwaarden, en de zwakheden fixen voor ze storingen worden. ...

In mijn vorige post over Prometheus en Thanos behandelde ik de sidecar architectuur — Thanos Sidecar draait naast Prometheus, uploadt TSDB blocks naar object storage, en stelt data beschikbaar aan de Querier. Het werkt uitstekend voor clusters met stabiele connectiviteit naar je centrale infrastructuur. Maar wat als je clusters aan de edge staan? Als ze uren of dagen connectiviteit kunnen verliezen? Als je tientallen of honderden kleine clusters draait en geen sidecar complexiteit op elk daarvan wilt? ...

Wanneer alles cluster-admin heeft, is niets veilig. Kubernetes RBAC (Role-Based Access Control) bestaat om één vraag te beantwoorden: wie kan wat doen met welke resources? De meeste clusters antwoorden verkeerd: “iedereen kan alles doen.” Dit is niet alleen een security probleem — het is een resilience probleem. Wanneer een service account wordt gecompromitteerd, hoeveel schade kan het aanrichten? Wanneer iemand het verkeerde commando uitvoert, wat is de blast radius? Least privilege beperkt die radius. ...

Elke deployment is een risico. De vraag is niet óf er iets fout gaat — maar hoeveel schade het veroorzaakt wanneer het gebeurt. Traditionele Kubernetes deployments zijn alles-of-niets. Je pusht een nieuwe versie, en binnen seconden raakt 100% van je traffic de nieuwe code. Als er een bug is, ziet iedereen het. Als de service crasht, zijn alle gebruikers getroffen. Progressive delivery verandert deze vergelijking. In plaats van naar iedereen tegelijk te deployen, verschuif je geleidelijk traffic naar de nieuwe versie, en valideer je bij elke stap. Als er iets misgaat, is slechts een fractie van de gebruikers getroffen. ...