Der Umzug geht Namespace für Namespace, oder gar nicht
Beim Umzug auf Ambient kann Traffic aus dem Dashboard verschwinden, ohne weg zu sein. Ein Stufenplan mit Prüfpunkten fängt das ab.
- Datum
- Thema
- Ambient
- Quellen
- 8
- Lesezeit
- 2 Min.
Sidecar und Ambient koexistieren im selben Mesh. Das macht den Umzug planbar, denn umgestellt wird pro Namespace, in fester Reihenfolge: Waypoint bereitstellen, Ambient am Namespace aktivieren, erst dann das Injection-Label entfernen, zuletzt die Workloads neu ausrollen. Wer die Reihenfolge dreht, hat laut Istio-Leitfaden Pods, die weder Sidecar noch ztunnel bedient. Das ist eine Stufe, und Stufen nimmt man eine nach der anderen. Davor liegt Stufe null: die Routing-Regeln auf die Gateway API bringen, noch im Sidecar-Modell (Post 26).
Abbildung als Text
Stufenplan für den Umzug von Sidecar zu Ambient: links drei Stufen im Sidecar-Modus (risikoarme Namespaces, Standard-Workloads, kritische Pfade), in der Mitte das Prüf-Gate je Stufe mit vier Prüfpunkten (mTLS alt gegen neu, Waypoint-Inventur nach Post 25, Telemetrie-Vergleich mit istio_requests_total und wechselndem reporter-Label, Abnahme mit Nachweis im Migrationsprotokoll), rechts die Ambient-Seite mit dem Status je Stufe (abgenommen, läuft, geplant). Darunter zwei Kästen: die Reihenfolge je Namespace nach Istio-Leitfaden (Waypoint bereit, Ambient aktivieren, Injection-Label raus, Workloads neu ausrollen) und Stufe null (Routing-Regeln auf die Gateway API, noch im Sidecar-Modell, Post 26). Pointe: Wer alle Namespaces auf einmal umzieht, hat keinen Plan. Der hat eine Wette laufen.
Planbar heißt aber nicht risikolos. An jede Stufe gehört ein Gate mit Prüfpunkten.
mTLS: Sprechen umgezogene und alte Workloads weiter verschlüsselt miteinander? Der Mischbetrieb ist während des Umzugs der Normalzustand, also wird er getestet.
Policies: Welche L7-Regeln brauchen jetzt einen Waypoint? Post 25 gilt hier wörtlich, eine L7-Policy ohne Waypoint wird zur DENY-Policy. Zwei Fallen aus dem Leitfaden dazu: Sidecar-Clients gehen am Waypoint vorbei, und alte selector-basierte L7-Policies sperren den Verkehr, sobald die Sidecars weg sind. Für L7-Policies gibt es laut Istio derzeit keinen Umzug ohne Unterbrechung, also kommt ein Wartungsfenster in den Plan.
Telemetrie: istio_requests_total vorher gegen nachher (Post 9). Die HTTP-Sicht liefert nach dem Umzug nur noch dort, wo ein Waypoint im Pfad steht, der Rest wird zur L4-Sicht. Dazu wechselt das Label: Waypoints melden reporter=“waypoint“, ztunnel reporter=“source“. Dashboards und Alerts, die auf reporter=“destination“ filtern, laufen leer, auch mit Waypoint. Wenn Traffic aus dem Dashboard verschwindet, ist er nicht weg. Ihr seht ihn nur nicht mehr, und das klärt man besser vor dem nächsten Incident.
Die Abnahme-Logik ist dieselbe wie beim App-Mesh-Umzug in Post 13: Jede Stufe endet mit einem Nachweis. Kein Namespace gilt als migriert, weil sich eine Woche lang niemand beschwert hat. Der Nachweis wandert ins Migrationsprotokoll, mit Datum.
Wer alle Namespaces auf einmal umzieht, hat keinen Migrationsplan. Der hat eine Wette laufen.
Nächste Woche schließt der Bogen: woran man festmacht, welcher Modus zu welchem Setup passt. Als Raster, ohne Glaubensbekenntnis.
