BYTEHERDER"Wanneer hebben jullie dit cluster voor het laatst geüpgrade?"
Het antwoord was een datum van veertien maanden eerder, daarna een stilte, en toen: "we zijn het steeds van plan."
Vier mensen in de kamer, allemaal vakbekwaam, allemaal een beetje ongemakkelijk, en niemand die kon zeggen wat er stuk zou gaan. Dat laatste is het hele verhaal.
Hoe een cluster hier terechtkomt
Even terug, want niemand besluit twee minor versies achter te gaan lopen.
Het cluster was netjes gebouwd. Declaratief, versies vastgezet, geleverd via Flux, met een stagingcluster uit dezelfde manifesten. Wie het had opgezet wist wat hij deed.
Toen vertrok degene die het had opgezet. Toen ging er een release mis op een ander systeem en was iedereen een kwartaal lang voorzichtig. Toen stond in de release notes van de volgende versie dat een API die het team gebruikte zou verdwijnen, en had niemand tijd om uit te zoeken hoevéél ze hem gebruikten. Toen waren ze vier versies verder en was het gat op zichzelf al angstaanjagend.
Elk van die stappen is redelijk. De uitkomst niet.
Meten in plaats van schatten
Dus hielden we op met erover praten en zochten we het in een dag uit. Drie dingen, in deze volgorde.
Wat gebruiken we werkelijk dat verdwijnt? Niet wat de release notes als vervallen aanmerken. Wat dít cluster aanroept.
# verwijderde en verouderde API's in live objecten én in de manifesten
kubectl-pluto detect-all-in-cluster -o wide
kubectl-pluto detect-files -d ./clusters/prod
Over negen namespaces kwamen hier vier treffers uit. Twee zaten in een Helm-chart die we een jaar niet hadden bijgewerkt, en de chart upgraden loste ze allebei op. Eén was een PodDisruptionBudget op een oude API-versie, een wijziging van één regel. Eén zat in een CRD van een leverancier, de enige categorie die echt vervelend is, en die leverancier bleek vijf maanden eerder al een compatibele versie te hebben uitgebracht.
Vier bevindingen. Een halve dag werk. Dit was het punt waar iedereen het bangst voor was geweest.
Komt de control plane terug? Bouw het cluster opnieuw uit dezelfde manifesten, op wegwerpinfrastructuur, op de doelversie.
Dat is de hele test, en hij zegt alleen iets als de manifesten werkelijk de bron van waarheid zijn. Dit is waar veel teams ontdekken dat dat niet zo is, en die ontdekking is de dag op zichzelf al waard. De onze waren het, grotendeels. Twee secrets waren in 2024 met de hand aangemaakt en stonden nergens in git. We vonden ze doordat het herbouwde cluster met twee pods in CreateContainerConfigError opkwam, wat een aanzienlijk prettiger manier is om daarachter te komen dan tijdens een echte upgrade.
Overleeft de data het? Zet de back-up van vannacht terug in het herbouwde cluster en kijk of de applicatie start.
Niet "meldt de back-upjob succes". Terugzetten. De back-upjob meldde al veertien maanden succes. Het terugzetten mislukte de eerste keer, omdat de back-up de PVC's vastlegde maar niet de CSI volume snapshot class waar ze naar verwezen, dus niets kon binden. Dat is een oplossing van een kwartier zodra je het weet, en het had daar stilletjes gelegen gedurende de hele periode dat het cluster te riskant was om te upgraden.
De upgrade
Veertig minuten, op een dinsdagmiddag, geen weekend.
Eén nodegroep tegelijk, kubectl drain met een PodDisruptionBudget die echt zijn werk deed, de workload in de gaten houden, door naar de volgende. Geen incident. Geen hap uit het errorbudget. Het spannendste moment was een monitoringalert dat afging omdat een node NotReady werd tijdens zijn eigen geplande drain, en dat is een afstemprobleem voor een andere keer.
Veertig minuten, tegenover veertien maanden het niet doen.
Wat die dag werkelijk waard was
De upgrade was het minst waardevolle dat er gebeurde.
De waardevolle uitkomsten waren een restore die werkt, twee secrets die nu in git staan, en een opgeschreven procedure met die vier commando's erin. De volgende upgrade is nu een ingeplande taak in plaats van een doorlopend gesprek, en dat blijft ook zo, want wat het eng maakte was nooit de upgrade.
Er bestaat een versie van dit stuk die eindigt met "test je back-ups", en dat is waar en dat heb je al eens gelezen. Deze manier van kijken is bruikbaarder: een ongemeten risico staat in iemands hoofd niet op zijn werkelijke waarde. Het staat op het ergste dat iemand in de kamer zich kan voorstellen, en het blijft klimmen, want een versiegat dat groeit laat het voorgestelde rampscenario meegroeien.
Meten kost een dag. Het komt bijna altijd kleiner terug dan de kamer verwachtte. En op de keren dat het groter terugkomt, ben je daar op een dinsdag met een wegwerpcluster achter gekomen in plaats van om twee uur 's nachts met het echte.
Vraag wanneer het cluster voor het laatst geüpgrade is. Zit er een stilte in het antwoord, dan is de versie niet het probleem.