Advanced

Elk platform team stelt uiteindelijk dezelfde vraag: moeten we een Internal Developer Platform bouwen? Het eerlijke antwoord is meestal ja. Het deel dat teams sloopt is de hoe. Ik heb platforms gezien die een klein fortuin kostten en daarna stilletjes verlaten werden omdat niemand ze wilde gebruiken. Ik heb ook een paar Helm charts en een Kyverno policy een heel team van manier zien veranderen waarop ze software shippen. Het gat tussen die twee uitkomsten heeft bijna niets met budget te maken, of met welke modieuze tool je koos. Het komt neer op de vraag of je begon met een echt probleem oplossen of met het platform bouwen dat jij dacht dat developers zouden moeten willen. ...

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

De eerste keer dat je een stateful workload op een self-hosted cluster draait, loop je tegen een muur. Geen cloud provider storage class om op te leunen. Alleen je nodes, hun disks, en een Postgres pod die weigert te schedulen omdat niets hem een PersistentVolume kan geven. Dus je gaat lezen, en binnen een uur heb je het teruggebracht tot twee namen die steeds terugkomen: Longhorn en Rook-Ceph. Ik heb beide in productie gedraaid. Dus laat me mijn bias meteen op tafel leggen: op kleine clusters kies ik standaard Longhorn, en waarom precies leg ik verderop uit. Houd dat in je achterhoofd terwijl je leest, want het kleurt hoe ik dingen weeg. Beide zijn CNCF projecten, beide geven je gerepliceerde block storage die overleeft als een node sterft, en beide zijn goede software. Ze zijn het alleen oneens over hoeveel complexiteit je zou moeten tekenen. ...

Een tijdlang werkte mijn alerting prima. Een handvol regels, pages waren zeldzaam, en als er een binnenkwam betekende het iets. Toen groeide de cluster, schroefde ik de Prometheus Operator defaults erop, en veranderde “prima” stilletjes in ruis. Het kantelpunt was een page om 3 uur ’s nachts. Mijn telefoon trilde, ik checkte slaperig: “High CPU usage on node-worker-3.” Ik keek naar de grafiek, zag dat hij al tien minuten op 75% stond, en ging weer slapen. Volgende nacht, dezelfde alert. Een week later checkte ik niet eens meer. ...

De eerste keer dat een service niet meer resolvede in een van mijn clusters, zat ik een avond iptables chains te lezen. Honderden regels, gegenereerd door kube-proxy, van boven naar beneden geëvalueerd. Ik heb het echte probleem nooit gevonden. Ik herstartte een node en het was weg. Dat zat me meer dwars dan de outage zelf. Ik draaide iets dat ik niet kon lezen. Dat gevoel is waarom ik naar Cilium ben overgestapt. Het gebruikt eBPF om networking logica naar beneden te duwen, de Linux kernel in, en slaat iptables volledig over. Je krijgt betere performance, je kunt daadwerkelijk zien wat je verkeer doet, en network policies worden geen giswerk meer. ...