De migratie gaat namespace voor namespace, of helemaal niet
Bij de migratie naar Ambient kan verkeer uit het dashboard verdwijnen zonder weg te zijn. Een stappenplan met controlepunten vangt dat op.
- Datum
- Onderwerp
- Ambient
- Bronnen
- 8
- Leestijd
- 2 min
- Versie
- Vertaling
Sidecar en Ambient bestaan naast elkaar in dezelfde mesh. Dat maakt de migratie planbaar, want er wordt per namespace omgeschakeld, in een vaste volgorde: waypoint klaarzetten, Ambient voor de namespace activeren, pas dan het injection-label verwijderen, als laatste de workloads opnieuw uitrollen. Wie de volgorde omdraait, heeft volgens Istio’s migratiegids pods die door sidecar noch ztunnel worden bediend. Dat is één stap, en stappen zet je één voor één. Daar gaat stap nul aan vooraf: de routingregels naar de Gateway API overzetten, nog in het sidecar-model (report #26).
Afbeelding als tekst
Stappenplan voor de migratie van sidecar naar Ambient: links drie stappen in sidecar-modus (risicoarme namespaces, standaardworkloads, kritieke paden), in het midden de gate per stap met vier controlepunten (mTLS oud tegenover nieuw, waypoint-inventarisatie volgens report #25, telemetrievergelijking met istio_requests_total en het wisselende reporter-label, acceptatie met bewijs in het migratielogboek), rechts de Ambient-kant met de status per stap (geaccepteerd, loopt, gepland). Daaronder twee vakken: de volgorde per namespace volgens Istio's migratiegids (waypoint klaar, Ambient activeren, injection-label eruit, workloads opnieuw uitrollen) en stap nul (routingregels naar de Gateway API, nog in het sidecar-model, report #26). Pointe: Wie alle namespaces tegelijk migreert, heeft geen plan. Die heeft een weddenschap lopen.
Planbaar betekent echter niet risicoloos. Bij elke stap hoort een gate met controlepunten.
mTLS: blijven gemigreerde en oude workloads versleuteld met elkaar praten? Die mix is tijdens de migratie de normale toestand, dus wordt hij getest.
Policies: welke L7-regels hebben nu een waypoint nodig? Report #25 geldt hier letterlijk, een L7-policy zonder waypoint wordt een DENY-policy. Daar komen twee valkuilen uit de gids bij: sidecar-clients gaan volledig om waypoints heen, en oude, op selector gebaseerde L7-policies blokkeren het verkeer zodra de sidecars weg zijn. Voor L7-policies is er volgens Istio momenteel geen zero-downtime-migratie, dus komt er een onderhoudsvenster in het plan.
Telemetrie: istio_requests_total vooraf tegenover achteraf (report #9). Na de migratie is er alleen nog een HTTP-beeld waar een waypoint in het pad staat, de rest wordt een L4-beeld. Daarnaast wisselt het label: waypoints melden reporter=”waypoint”, ztunnel reporter=”source”. Dashboards en alerts die op reporter=”destination” filteren, lopen leeg, ook met een waypoint. Als verkeer uit het dashboard verdwijnt, is het niet weg. Jullie zien het alleen niet meer, en dat zoek je beter uit vóór het volgende incident.
De acceptatielogica is dezelfde als bij de App Mesh-migratie in report #13: elke stap eindigt met een bewijs. Een namespace geldt niet als gemigreerd omdat er een week lang niemand heeft geklaagd. Het bewijs gaat het migratielogboek in, met datum.
Wie alle namespaces tegelijk migreert, heeft geen migratieplan. Die heeft een weddenschap lopen.
Volgende week sluit de verhaallijn af: waaraan je afmeet welke modus bij welke setup past. Als raster, zonder geloofsbelijdenis.
