Zwei Control Planes sind kein Luxus

Die wichtigste Frage bei einem Mesh-Upgrade ist nicht, wie ihr vorwärtskommt. Sondern wie ihr zurückkommt, wenn die erste Welle knirscht.

Das In-Place-Upgrade beantwortet sie so: Eine Control Plane wird ersetzt, alle Workloads hängen sofort an der neuen Version. Wenn etwas klemmt, heißt der Rückweg Restore. Das ist weniger ein Plan als ein Gebet mit Backup.

Das Canary-Muster mit Revisionen beantwortet sie anders. Die neue Control-Plane-Revision wird parallel zur alten installiert, beide laufen gleichzeitig. Welcher Workload zu welcher Revision gehört, entscheidet ein Namespace-Label, und der Wechsel passiert erst beim nächsten Sidecar-Restart. Nichts kippt auf einmal.

Die Reihenfolge macht daraus einen geordneten Prozess: erst ein unkritischer Namespace, dann Welle für Welle Richtung kundennaher Services. Nach jeder Welle prüfen statt hoffen. istioctl proxy-status zeigt jederzeit, welcher Proxy an welcher Control Plane hängt, derselbe Befehl, der in Post 8 den Diagnose-Pfad eröffnet hat. Und die alte Revision bleibt stehen, bis die letzte Welle durch ist. Der Rückweg: Label zurück, Restart, fertig.

Ja, zwei Control Planes kosten eine Zeit lang doppelte Ressourcen. Verglichen mit einer Nacht, in der das ganze Mesh an einer frisch ersetzten Control Plane hängt, ist das schlicht der Preis für einen Rückweg, der den Namen verdient.

Für Entscheider entscheidet sich hier mehr als eine Technik-Nuance: ob es beim wichtigsten Eingriff ins Netz einen geordneten Rückzug gibt oder nur die Flucht nach vorn. Und die Upgrade-Schulden aus Post 19 baut niemand ab, solange jedes Upgrade eine Mutprobe ist.

Deshalb die Frage in die Runde: Wie laufen Control-Plane-Upgrades bei euch heute, in-place, in Wellen, oder wartet das Ticket noch? Ehrliche Antworten ausdrücklich willkommen.