Twee control planes zijn geen luxe

De belangrijkste vraag bij een mesh-upgrade is niet hoe je vooruitkomt. Maar hoe je terugkomt als de eerste golf knarst.

De in-place upgrade beantwoordt die vraag zo: één control plane wordt vervangen, alle workloads hangen meteen aan de nieuwe versie. Als er iets klemt, heet de terugweg restore. Dat is minder een plan dan een gebed met een back-up.

Het canary-patroon met revisions beantwoordt haar anders. De nieuwe control-plane-revision wordt parallel aan de oude geïnstalleerd, beide draaien tegelijk. Welke workload bij welke revision hoort, bepaalt een namespace-label, en de wissel gebeurt pas bij de volgende sidecar-restart. Er kantelt niets in één keer.

De volgorde maakt er een geordend proces van: eerst een niet-kritieke namespace, daarna golf voor golf richting klantnabije services. Na elke golf controleren in plaats van hopen. istioctl proxy-status laat op elk moment zien welke proxy aan welke control plane hangt, hetzelfde commando dat in report #8 het diagnosepad opende. En de oude revision blijft staan tot de laatste golf erdoor is. De terugweg: label terug, restart, klaar.

Ja, twee control planes kosten een tijdlang dubbele resources. Vergeleken met één nacht waarin de hele mesh aan een net vervangen control plane hangt, is dat simpelweg de prijs voor een terugweg die de naam verdient.

Voor beslissers wordt hier meer beslist dan een technische nuance: of er bij de belangrijkste ingreep in het netwerk een geordende terugtocht bestaat of alleen de vlucht naar voren. En de upgrade-schuld uit report #19 bouwt niemand af zolang elke upgrade een moedproef is.

Daarom de vraag aan de groep: hoe lopen control-plane-upgrades bij jullie vandaag, in-place, in golven, of wacht het ticket nog? Eerlijke antwoorden uitdrukkelijk welkom.