Kubernetes

Lange tijd vernieuwde ik mijn certificaten zoals de meeste mensen dat doen: een agenda-reminder, een handmatige certbot-run en de stille hoop dat ik er op tijd aan zou denken. Dat werkte. Het werkte precies tot de ochtend waarop een service me om de oren sloeg met certfouten en ik geen idee had waarom, omdat de renewal-cron al weken stilletjes faalde. Dat is het stuk dat niemand je vertelt over handmatige TLS. De fout kondigt zichzelf niet aan. Het certificaat verloopt gewoon, meestal op het slechtst denkbare moment, en je komt erachter omdat een browser tegen iemand staat te schreeuwen. De kennis over vernieuwing eindigt in het hoofd van één persoon. Teams slaan HTTPS over op interne services omdat het handmatig optuigen vervelend genoeg is om uit te stellen. ...

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

Je metrics zeggen dat iets traag is. Je logs zeggen dat er errors waren. Prima. Beantwoord dan dit: welke request faalde nou eigenlijk, waar kwam die latency vandaan, en welke service in de keten vrat die timeout op? Metrics en logs halen daar allebei hun schouders bij op. Ik liep tegen die muur aan toen een checkout flow onder load begon te timeouten. Tien services in het pad, elk van ze groen op zijn eigen dashboard, en geen enkele manier om één gedoemde request te volgen van voordeur tot fout. Precies dat gat vult distributed tracing op. Het volgt één request terwijl die door je services beweegt en toont je precies wat er gebeurde en waar het vastliep. ...

Je hebt Prometheus voor metrics, dus je kunt al zien wat er gebeurt in je clusters. Metrics vertellen je dat de latency van een request om 14:32 piekte. Ze vertellen je niet dat de payment service een null pointer gooide omdat iemand een config-wijziging met een typefout uitrolde. Daarvoor heb je logs nodig. Het standaardantwoord was jarenlang Elasticsearch. Krachtig en flexibel, en het indexeert elke token in elke logregel. Die full-text index is geweldig totdat je naar de rekening kijkt. Je betaalt ervoor in CPU bij ingest, in RAM om de index warm te houden, en in opslag die sneller groeit dan je daadwerkelijke logvolume. Ik draaide ooit een ELK stack in een vorige baan en was meer tijd kwijt aan het tunen van JVM heap sizes dan aan het lezen van logs. ...

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