Zalando verkoopt sokken en schoenen. En nog wat andere zaken, aan 250 miljoen bezoekers per maand. Daarvoor heeft het bedrijf 380 AWS accounts, 118 clusters en rond de 1.000 ontwikkelaars die Kubernetes gebruiken. De clusters zelf zijn redelijk complex, in totaal bestaan ze uit 47 componenten (alhoewel die natuurlijk niet in ieder cluster in gebruik zijn).
Zalando heeft veel ervaring met het at-scale draaien van Kubernetes clusters en presenteert een achttal incidenten, aan de hand van de postmortems (een verslag van wat er fout ging).
Rode draad bij die incidenten: veel start op de ingress (het koppelvlak van de applicatie met de buitenwereld) en manifesteert zich als 404 of 501 errors, die vervolgens zijn terug te leiden tot memory leaks, configuratiefouten en menselijk dwalen. Het verschil tussen fouten maken en dwalen wordt wel scherp gesteld: “human error is never the root cause” en “junior programmers are a feature, not a bug” – want het is bijvoorbeeld de fixed memory limit in een of ander component die voor een crash zorgt na een memory leak, niet de configuratiefout die daaraan voorafging. Fouten maken mag. Vaak leidt een gemaakte fout zelfs tot het ontdekken van een bug in een ander component, zelfs in de infrastructuur van AWS – hoewel dat zelden voorkomt.
Maar in de configuratie een proces killen en dan wachten tot het weer opkomt (pkill en dan wait), dat is dwalen. Zeker met het begeleidende commentaar van de ontwikkelaar, “We simply kill the process when there is a failure, but wait a while until the process is back up to prevent a crash loop”. Of een “sleep 120” in de installatie-configuratie van Flannel, dat is ook niet handig. Daar werd tijdens de presentatie dan ook – met naam en toenaam van de schuldige – gehakt van gemaakt. Fouten maken mag, maar schandpalen komen in deze wereld gewoon voor. Kubernetes heeft veel memory leaks en fixed memory limits, en “Docker is always a topic”. En Containerlinux “stable” – dat woord stable, dat heeft ook aan betekenis ingeboet.
Zalando onderzoekt elk incident uitvoerig, voorziet het van de al eerder genoemde postmortem en plaatst dat resultaat op Github, inclusief eventueel de aanpassingen die nodig waren om het systeem weer in de lucht te krijgen. Volledige transparantie, een mooi initiatief. Een lijst van failures is terug te vinden op https://k8s.af/.
Zalando refereert nog aan andere manieren om hoge beschikbaarheid te garanderen, bijvoorbeeld zoals Amazon doet (met een SLA-garantie van 99,9%). Die garantie is echter alleen op de API-server van Kubernetes, en daar zijn weinig incidenten op. Kijk dus goed uit met welke garantie op welk component wordt geboden, is de boodschap. En die andere componenten van Kubernetes, die zijn met de standaard configuratie niet gereed voor productie. Daar is nog behoorlijk wat gesleutel voor nodig. Een voorbeeld is de configuratie van kube-dns, waarvan de scale parameter fixed op 1 staat. Dat schaalt dan niet echt.
Zalando sluit af met de opmerking ”I haven’t heard any Istio failure story yet and that makes me wonder”. Een open uitnodiging aan de vorige spreker, misschien.