Anthos Service Mesh and Traffic Director are now Cloud Service Mesh. For more information, see the Cloud Service Mesh overview.

Uninstall in-cluster Cloud Service Mesh

This page explains how to uninstall in-cluster Cloud Service Mesh if you are using the Istio APIs. If you are using Compute Engine APIs, no steps are necessary. See the Cloud Service Mesh overview to understand the differences.

Following these instructions to uninstall in-cluster Cloud Service Mesh removes all configurations.

If you are uninstalling managed Cloud Service Mesh, follow the managed uninstallation guide instead.

If you are migrating from in-cluster to managed, follow the Migration guide instead.

Uninstall Cloud Service Mesh

Use the following commands to uninstall all Cloud Service Mesh components.

To prevent interrupting application traffic:
- Downgrade any STRICT mTLS policies to PERMISSIVE.
- Remove any AuthorizationPolicy that may block traffic.
Disable sidecar auto-injection on your namespace(s), if it is enabled. Run the following command to display namespace labels:
```
 kubectl get namespace YOUR_NAMESPACE --show-labels
```
The output is similar to the following:
```
 NAME   STATUS   AGE     LABELS
 demo   Active   4d17h   istio.io/rev=asm-181-5
```
If you see istio.io/rev= in the output under the LABELS column, remove it:
```
 kubectl label namespace YOUR_NAMESPACE istio.io/rev-
```
If you see istio-injection in the output under the LABELS column, remove it:
```
 kubectl label namespace YOUR_NAMESPACE istio-injection-
```
If you don't see either the istio.io/rev or istio-injection labels, then auto-injection wasn't enabled on the namespace.

Note: You should also check resources including Deployments, StatefulSets, ReplicaSets, DaemonSets, Jobs and CronJobs also for injection.
Restart your workloads that have sidecars injected to remove the proxies.

Delete the validatingwebhooksconfiguration and mutatingwebhookconfiguration from your cluster, if they exist:

  kubectl delete validatingwebhookconfiguration,mutatingwebhookconfiguration -l operator.istio.io/component=Pilot,istio.io/owned-by!=mesh.googleapis.com

Once all workloads come up and no proxies are observed, then you can safely delete the in-cluster control plane to stop billing.

To remove the in-cluster control plane, run the following command:
```
istioctl uninstall --purge
```
If there are no other control planes, you can delete the istio-system namespace to get rid of all Cloud Service Mesh resources. Otherwise, delete the services corresponding to the Cloud Service Mesh revisions. This avoids deleting shared resources, such as CRDs.

Optionally, Remove Istio CRs, Isto CRDs, istio-(revision) configmap, asm-options configmap, istio-system and asm-system namespaces to remove service mesh from the cluster or use them in another Istio API compatible service mesh.

Remove Istio CRs:

kubectl delete gateways,virtualservices,destinationrules,serviceentries,envoyfilters,sidecars,peerauthentications,requestauthentications,authorizationpolicies,telemetries,wasmplugins,proxyconfigs --all --all-namespaces

Remove Istio CRDs:

kubectl get crds -o name | grep --color=never 'istio.io' | xargs kubectl delete

Remove istio-(revision) configmap. You can skip this step if you delete the istio-system namespace.
```
kubectl delete configmap istio-RELEASE_CHANNEL -n istio-system
```
Replace RELEASE_CHANNEL with your release channel

Remove istio-system namespace:

kubectl delete namespace istio-system --ignore-not-found=true

Remove asm-system namespace:

kubectl delete namespace asm-system --ignore-not-found=true

Check if the deletions were successful:

 kubectl get ns
 ```

The output should indicate a `Terminating` state and return as shown,
otherwise you might have to manually delete any remaining resources in
the namespaces and try again.

```sh
 NAME                 STATUS       AGE
 istio-system         Terminating  71m
 asm-system           Terminating  71m
 ```

If you will delete your clusters, or have already deleted them, ensure that each cluster is unregistered from your fleet.
If you plan to stop using Cloud Service Mesh at the fleet level, disable the service mesh feature for your fleet host project.
```
 gcloud container hub mesh disable --project FLEET_PROJECT_ID
```
Where FLEET_PROJECT_ID is the ID of your Fleet Host project.

Once you've completed these steps, all Cloud Service Mesh components, including proxies, in-cluster certificate authorities, and RBAC roles and bindings, are systematically removed from the cluster. During the installation process, a Google-owned service account is granted the necessary permissions to establish the service mesh resources within the cluster. These uninstall instructions don't revoke these permissions, allowing for a seamless re-activation of Cloud Service Mesh in the future.