Migration overview
This document explains what changes between Alauda Service Mesh v1 (Mesh v1) and Alauda Service Mesh v2 (Mesh v2), how the migration is phased, and the conventions used throughout this section. Read it before you start.
On Alauda Container Platform 4.1, update the platform to 4.2 or 4.3 first: Mesh v2.2 is not supported on 4.1.
Run the whole migration end to end in a test environment that matches your production mesh — same topology, same gateways, same observability stack — before you migrate a production mesh. Decommissioning Mesh v1 cannot be undone: after that point, going back means reinstalling Mesh v1 from your backups.
TOC
Why migrateWhat changesFeature mappingMigration phasesWhy running both control planes is safeConventionsWhy migrate
Mesh v1 is built on the upstream istio-operator project, which is no longer maintained. Alauda Container Platform 4.4 does not ship Mesh v1, so every Mesh v1 mesh must be migrated while the platform is on 4.2 or 4.3. Mesh v2 is built on the Sail Operator and tracks current Istio releases.
What changes
Istio resources — Gateway, VirtualService, DestinationRule, ServiceEntry, Sidecar, PeerAuthentication, Telemetry and the rest — are reused as they are. The migration changes which control plane programs them, not the resources themselves.
Feature mapping
Migration phases
The migration runs in seven phases. Each phase ends with checks that must pass before you start the next one.
For a mesh that spans several clusters, follow the single-cluster phases and add the steps in Migrating a multi-cluster mesh. See Rolling back the migration for what each phase can be rolled back to.
Why running both control planes is safe
During Phase 2 to Phase 5 the two control planes share one cluster. Four properties keep them apart:
- One certificate authority. Mesh v1 stores its intermediate certificate in the
cacertssecret of theistio-systemnamespace, in the formatistiodexpects. The Mesh v2istiodruns in the same namespace and loads the same secret, so both sides issue workload certificates from the same root and mutual TLS keeps working across them. - Revision isolation. Mesh v1 is itself a revisioned deployment (
1-22). Mesh v2 uses theRevisionBasedupdate strategy, so its injection and validation webhooks carry its own revision suffix. Theistio.io/revlabel selects exactly one control plane per namespace. - No shared default. Mesh v1 owns the
defaultwebhook slot. Mesh v2 does not create anIstioRevisionTagnameddefaultuntil Mesh v1 is gone. - Separate traffic capture. Mesh v1 captures traffic with the
istio-initcontainer, Mesh v2 withIstioCNI. The CNI plugin skips pods that already carryistio-init, so pods of both generations run on the same node without interfering.
After you create the Mesh v2 Istio resource, never delete the Mesh v1 service mesh from the platform UI, and never delete a ServiceMesh resource and leave the cleanup to the Mesh v1 controllers. The Mesh v1 deletion flow deletes the whole istio-system namespace, including the Mesh v2 control plane that runs in it. Remove Mesh v1 only by following Decommissioning Mesh v1. This rule takes effect in Phase 2.
Conventions
Commands run against the cluster that hosts the mesh. Commands that act on the global cluster pass --context "${GLOBAL_CONTEXT}" explicitly.
Environment-specific values are shell variables. Every page that uses a variable either sets it with a discovery command or points back to the page that does.