Stay organized with collectionsSave and categorize content based on your preferences.
Uninstall Cloud Service Mesh
This page explains how to uninstall Cloud Service Mesh.
Uninstall Cloud Service Mesh
Use the following commands to uninstall all Cloud Service Mesh components. These
commands also delete theistio-systemnamespace and all custom resource
definitions (CRDs), including any CRDs that you applied.
To prevent interruption of application traffic:
Downgrade any STRICT mTLS policies to PERMISSIVE.
Remove any AuthorizationPolicy that may block traffic.
Disable Automatic Management on this cluster (whether you applied it
directly or using the fleet-default configuration):
Once all workloads come up and no proxies are observed, then you can safely
delete the in-cluster control plane to stop billing. If you deployed a
managed control plane, then it is automatically deleted with the previous
step.
To remove the in-cluster control plane, run the command below:
istioctlxuninstall--purge
If there are no other control planes, you can delete theistio-systemnamespace 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.
The output should indicate aTerminatingstate and return as shown,
otherwise you might have to manually delete any remaining resources in
the namespaces and try again.
If you will delete your clusters, or have already deleted them, ensure
that each cluster isunregisteredfrom your fleet.
If you have enabled managed Cloud Service Mesh fleet-default configuration and
want to disable it for future clusters, disable it. You can skip this step
if you're only uninstalling from a single cluster.
Upon completion of 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.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Uninstall Cloud Service Mesh\n============================\n\nThis page explains how to uninstall Cloud Service Mesh.\n| **Warning:** Following these instructions to uninstall Cloud Service Mesh removes all configurations regardless of control plane type (in-cluster or managed).\n\nUninstall Cloud Service Mesh\n----------------------------\n\nUse the following commands to uninstall all Cloud Service Mesh components. These\ncommands also delete the `istio-system` namespace and all custom resource\ndefinitions (CRDs), including any CRDs that you applied.\n| **Warning:** If you created CRDs, make sure you have copies of them before proceeding through the following steps.\n\n1. To prevent interruption of application traffic:\n\n - Downgrade any STRICT mTLS policies to PERMISSIVE.\n - Remove any AuthorizationPolicy that may block traffic.\n2. Disable Automatic Management on this cluster (whether you applied it\n directly or using the fleet-default configuration):\n\n gcloud container fleet mesh update --management manual\n\n3. Disable sidecar auto-injection on your namespace(s), if it is enabled. Run\n the following command to display namespace labels:\n\n kubectl get namespace \u003cvar translate=\"no\"\u003eYOUR_NAMESPACE\u003c/var\u003e --show-labels\n\n The output is similar to the following:\n\n \u003cbr /\u003e\n\n ```bash\n NAME STATUS AGE LABELS\n demo Active 4d17h istio.io/rev=asm-181-5\n ```\n\n \u003cbr /\u003e\n\n If you see `istio.io/rev=` in the output under the `LABELS` column,\n remove it: \n\n kubectl label namespace \u003cvar translate=\"no\"\u003eYOUR_NAMESPACE\u003c/var\u003e istio.io/rev-\n\n If you see `istio-injection` in the output under the `LABELS` column,\n remove it: \n\n kubectl label namespace \u003cvar translate=\"no\"\u003eYOUR_NAMESPACE\u003c/var\u003e istio-injection-\n\n If you don't see either the `istio.io/rev` or `istio-injection` labels,\n then auto-injection wasn't enabled on the namespace.\n4. Restart your workloads that have sidecars injected to remove the proxies.\n\n5. If you're using managed Cloud Service Mesh, remove any `controlplanerevision`\n resources in the cluster:\n\n kubectl delete controlplanerevision \u003cvar translate=\"no\"\u003eRELEASE_CHANNEL\u003c/var\u003e -n istio-system\n\n Where \u003cvar translate=\"no\"\u003eRELEASE_CHANNEL\u003c/var\u003e is the\n [release channel](/service-mesh/docs/managed/select-a-release-channel)\n you provisioned, such as `asm-managed`, `asm-managed-rapid`, or\n `asm-managed-stable`.\n6. Delete webhooks from your cluster, if they exist.\n\n ### In-cluster Cloud Service Mesh\n\n Delete the `validatingwebhooksconfiguration` and `mutatingwebhookconfiguration`. \n\n kubectl delete validatingwebhookconfiguration,mutatingwebhookconfiguration -l operator.istio.io/component=Pilot\n\n ### Managed Cloud Service Mesh\n\n A. Delete the `validatingwebhooksconfiguration`. \n\n kubectl delete validatingwebhookconfiguration istiod-istio-system-mcp\n\n B. Delete the `mutatingwebhookconfiguration`.\n **Note:** Use the \u003cvar translate=\"no\"\u003eRELEASE_CHANNEL\u003c/var\u003e according to the [release channel](/service-mesh/docs/managed/release-channels) you provisioned. For example, Regular(`istiod-asm-managed`), Rapid (`istiod-asm-managed-rapid`), and Stable (`istiod-asm-managed-stable`). \n\n kubectl delete mutatingwebhookconfiguration istiod-\u003cvar translate=\"no\"\u003eRELEASE_CHANNEL\u003c/var\u003e\n\n7. Once all workloads come up and no proxies are observed, then you can safely\n delete the in-cluster control plane to stop billing. If you deployed a\n managed control plane, then it is automatically deleted with the previous\n step.\n\n To remove the in-cluster control plane, run the command below: \n\n istioctl x uninstall --purge\n\n If there are no other control planes, you can delete the `istio-system`\n namespace to get rid of all Cloud Service Mesh resources. Otherwise, delete the\n services corresponding to the Cloud Service Mesh revisions. This avoids deleting\n shared resources, such as CRDs.\n8. Delete the `istio-system` and `asm-system` namespaces:\n\n kubectl delete namespace istio-system asm-system --ignore-not-found=true\n\n9. Check if the deletions were successful:\n\n kubectl get ns\n\n The output should indicate a `Terminating` state and return as shown,\n otherwise you might have to manually delete any remaining resources in\n the namespaces and try again. \n\n NAME STATUS AGE\n istio-system Terminating 71m\n asm-system Terminating 71m\n\n 1. If you will delete your clusters, or have already deleted them, ensure that each cluster is [unregistered](/anthos/fleet-management/docs/unregister) from your fleet.\n10. If you have enabled managed Cloud Service Mesh fleet-default configuration and\n want to disable it for future clusters, disable it. You can skip this step\n if you're only uninstalling from a single cluster.\n\n gcloud container hub mesh disable --fleet-default-member-config --project \u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e\n\n Where \u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e is the ID of your Fleet Host project.\n11. If you're using managed Cloud Service Mesh, delete the `mdp-controller` deployment:\n\n kubectl delete deployment mdp-controller -n kube-system\n\n12. Check to see if the `istio-cni-plugin-config` configmap is present:\n\n kubectl get configmap istio-cni-plugin-config -n kube-system\n\n If present, delete the `istio-cni-plugin-config` configmap: \n\n kubectl delete configmap istio-cni-plugin-config -n kube-system\n\n | **Warning:** The network reliability of your GKE cluster may be impacted if you don't delete this configmap.\n13. Delete the `istio-cni-node` daemonset:\n\n kubectl delete daemonset istio-cni-node -n kube-system\n\nUpon completion of these steps, all Cloud Service Mesh components, including proxies,\nin-cluster certificate authorities, and RBAC roles and bindings, are\nsystematically removed from the cluster. During the installation process, a\nGoogle-owned service account is granted the necessary permissions to establish\nthe service mesh resources within the cluster. These uninstall instructions\ndon't revoke these permissions, allowing for a seamless re-activation of\nCloud Service Mesh in the future.\n| **Note:** The `istio-system` namespace and config maps may also continue to be recreated. If you require all of these artifacts to get removed, [contact support](/service-mesh/v1.20/docs/getting-support)."]]
