The migration goes namespace by namespace, or not at all
During the migration to Ambient, traffic can vanish from the dashboard without being gone. A staged plan with checkpoints catches that.
- Date
- Topic
- Ambient
- Sources
- 8
- Reading time
- 2 min
- Version
- Translation
Sidecar and Ambient coexist in the same mesh. That makes the migration plannable, because the switch happens per namespace, in a fixed order: deploy the waypoint, enable Ambient on the namespace, only then remove the injection label, and finally roll out the workloads again. If you reverse the order, Istio’s guide says you end up with pods served by neither sidecar nor ztunnel. That is a stage, and you take stages one at a time. Before that comes stage zero: moving the routing rules to the Gateway API, still in the sidecar model (report #26).
Figure as text
Staged plan for the migration from sidecar to Ambient: on the left, three stages in sidecar mode (low-risk namespaces, standard workloads, critical paths), in the middle, the gate per stage with four checkpoints (mTLS old versus new, waypoint inventory as in report #25, telemetry comparison with istio_requests_total and the changing reporter label, acceptance with evidence in the migration log), on the right, the Ambient side with the status per stage (accepted, in progress, planned). Below, two boxes: the order per namespace according to Istio's guide (waypoint ready, enable Ambient, injection label out, roll out workloads again) and stage zero (routing rules to the Gateway API, still in the sidecar model, report #26). Punchline: Migrate every namespace at once and you have no plan. You have a bet running.
But plannable doesn’t mean risk-free. Every stage needs a gate with checkpoints.
mTLS: Do migrated and old workloads still talk to each other over encrypted connections? During the migration, mixed operation is the normal state, so it gets tested.
Policies: Which L7 rules now need a waypoint? Report #25 applies here word for word: an L7 policy without a waypoint becomes a DENY policy. Two more traps from the guide: sidecar clients bypass waypoints entirely, and old selector-based L7 policies block traffic as soon as the sidecars are gone. According to Istio, there is currently no zero-downtime migration path for L7 policies, so a maintenance window goes into the plan.
Telemetry: istio_requests_total before versus after (report #9). After the migration, you only get the HTTP view where a waypoint sits in the path, and the rest becomes an L4 view. On top of that, the label changes: waypoints report with reporter=”waypoint”, ztunnel with reporter=”source”. Dashboards and alerts that filter on reporter=”destination” run empty, even with a waypoint. When traffic vanishes from the dashboard, it isn’t gone. You just don’t see it anymore, and that’s better sorted out before the next incident.
The acceptance logic is the same as for the App Mesh migration in report #13: every stage ends with evidence. No namespace counts as migrated just because nobody complained for a week. The evidence goes into the migration log, with a date.
Migrate every namespace at once and you have no migration plan. You have a bet running.
Next week closes the arc: how to tell which mode fits which setup. As a decision grid, without a creed.
