Service Mesh (ASM) automatically records the version of each Istio resource before you update fields in its spec section. If a configuration change causes unexpected behavior, you can roll back to any recorded version from the ASM console.
ASM stores up to five versions per resource. When a sixth spec update occurs, the oldest version is automatically removed.
Only changes to fields in the spec section trigger version recording. Updates to other fields do not create a version record.
The following procedure uses a virtual service as an example. The same steps apply to all supported Istio resources.
Prerequisites
| Requirement | Details |
|---|---|
| ASM instance version | 1.9.7.92 or later. See Create an ASM instance or Update an ASM instance. |
| Virtual service | At least one virtual service exists. See Manage virtual services. |
Supported Istio resources
Version control and rollback apply to the following Istio resources:
| Category | Resources |
|---|---|
| Traffic management | Virtual services, destination rules, Istio gateways, service entries, Envoy filters, workload groups, workload entries, and sidecar resources |
| Zero-trust security | Request authentication policies, peer authentication policies, and authorization policies |
Step 1: Enable Istio resource version control
You can enable version control during instance creation or on an existing instance.
During instance creation: Select Enable Istio custom resource version control in the creation wizard.
On an existing instance:
Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose ASM Instance > Base Information.
On the Base Information page, click Settings. In the Settings Update panel, select Enable Istio custom resource version control and click OK.
Step 2: Update a virtual service to generate a version record
After you enable version control, ASM automatically saves the current spec before each update.
Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Traffic Management Center > VirtualService.
On the VirtualService page, find the target virtual service and click YAML in the Actions column.
In the Edit dialog box, modify a field in the
specsection. For example, change thenumberfield from9080to9081, then click OK. ASM saves the previousspecas a new version entry.
Step 3: Roll back to an earlier version
Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Traffic Management Center > VirtualService.
On the VirtualService page, find the target virtual service and click Version in the Actions column.
In the Version dialog box, find the target version (for example, v2) and click View in the Actions column to inspect the
speccontent.Confirm the version is correct, then click Rollback.
Verify the rollback
After the rollback, confirm that the resource reflects the expected version:
On the VirtualService page, find the virtual service and click YAML in the Actions column.
In the Edit dialog box, verify that the
speccontent matches the version you selected.
FAQ
Why is the Version button missing for my Istio resource?
Make sure your ASM instance is version 1.9.7.92 or later and that Enable Istio custom resource version control is turned on. See Step 1.
Does ASM record versions for changes made outside the console?
Yes. Once version control is enabled, ASM records spec changes regardless of the method used to update Istio resources.
How many versions does ASM keep?
ASM stores up to five versions per Istio resource. When a sixth spec update occurs, the oldest version is removed.
Why does a recorded version look different from the original YAML?
ASM omits redundant fields from version records. For example, if an Istio gateway's servers.tls field in the spec section uses the default value PASSTHROUGH, ASM excludes it from the recorded version. This does not affect rollback behavior -- the restored configuration works as expected.