이 페이지에서는 Istio API를 사용하는 경우 Cloud Service Mesh를 제거하는 방법을 설명합니다. Compute Engine API를 사용하는 경우 별도의 단계가 필요하지 않습니다. 차이점을 알아보려면 Cloud Service Mesh 개요를 참고하세요.
다음 안내에 따라 Cloud Service Mesh를 제거하면 컨트롤 플레인 유형(클러스터 내 또는 관리형)에 관계없이 모든 구성이 삭제됩니다.
클러스터 내에서 관리형으로 이전하는 경우 이전 가이드를 따르세요.
Cloud Service Mesh 제거
다음 명령어를 사용하여 모든 Cloud Service Mesh 구성요소를 제거합니다. 이러한 명령어는 적용한 CRD를 포함하여 istio-system 네임스페이스와 모든 커스텀 리소스 정의(CRD)도 삭제합니다.
애플리케이션 트래픽이 중단되지 않도록 하려면 다음 안내를 따르세요.
STRICT mTLS 정책을 PERMISSIVE로 다운그레이드합니다.
트래픽을 차단할 수 있는 AuthorizationPolicy를 삭제합니다.
이 클러스터에서 자동 관리를 사용 중지합니다(직접 사용하거나 Fleet 기본 구성 사용).
모든 워크로드가 시작되고 프록시가 관찰되지 않으면 클러스터 내 컨트롤 플레인을 안전하게 삭제하여 청구를 중단할 수 있습니다.
클러스터 내 컨트롤 플레인을 삭제하려면 다음 명령어를 실행합니다.
istioctluninstall--purge
다른 컨트롤 플레인이 없으면 istio-system 네임스페이스를 삭제하여 모든 Cloud Service Mesh 리소스를 삭제할 수 있습니다. 그렇지 않으면 Cloud Service Mesh 버전에 해당하는 서비스를 삭제합니다. 이렇게 하면 CRD와 같은 공유 리소스를 삭제할 수 없습니다.
관리형 Cloud Service Mesh를 제거하는 경우 지원팀에 문의하여 모든Google Cloud 리소스가 삭제되었는지 확인하세요. 이 단계를 따르지 않으면 istio-system 네임스페이스 및 구성 맵도 계속 다시 만들어질 수 있습니다.
이 단계가 완료되면 프록시, 클러스터 내 인증 기관, RBAC 역할 및 바인딩을 포함한 모든 Cloud Service Mesh 구성요소가 클러스터에서 체계적으로 삭제됩니다. 설치 프로세스 중 클러스터 내에서 서비스 메시 리소스를 설정하는 데 필요한 권한이 Google 소유 서비스 계정에 부여됩니다. 이러한 삭제 안내는 이러한 권한을 취소하지 않으며 이후에 Cloud Service Mesh를 다시 쉽게 활성화할 수 있게 해줍니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Uninstall Cloud Service Mesh\n============================\n\n| **Note:** This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nThis page explains how to uninstall Cloud Service Mesh if you are using\nthe Istio APIs. If you are using Compute Engine APIs, no steps are\nnecessary. See the [Cloud Service Mesh overview](/service-mesh/docs/overview)\nto understand the differences.\n\nFollowing these instructions to uninstall Cloud Service Mesh removes\nall configurations regardless of control plane type (in-cluster or managed).\nIf you are doing a migration from in-cluster to managed, follow the\n[Migration guide](/service-mesh/docs/tutorials/migrate-in-cluster-to-managed-on-new-cluster)\ninstead.\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 \\\n --management manual \\\n --memberships \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e \\\n --project \u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e \\\n --location \u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e is the membership name listed when you verified that your cluster was registered to the fleet.\n - \u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e is the location of your membership (either a region, or `global`).\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, check which\n [control plane implementation](/service-mesh/docs/supported-features-managed#identify_control_plane_implementation)\n you have in your cluster, this will help delete relevant resources in further\n steps.\n\n6. If you're using managed Cloud Service Mesh, remove all `controlplanerevision`\n resources in the cluster:\n\n kubectl delete controlplanerevision asm-managed asm-managed-rapid asm-managed-stable -n istio-system --ignore-not-found=true\n\n7. 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,istio.io/owned-by!=mesh.googleapis.com\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 all `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\n8. Once all workloads come up and no proxies are observed, then you can safely\n delete the in-cluster control plane to stop billing.\n\n To remove the in-cluster control plane, run the following command: \n\n istioctl 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.\n9. Delete the `istio-system` and `asm-system` namespaces:\n\n kubectl delete namespace istio-system asm-system --ignore-not-found=true\n\n10. 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\n11. If you will delete your clusters, or have already deleted them, ensure\n that each cluster is\n [unregistered](/anthos/fleet-management/docs/unregister) from your fleet.\n\n12. If you 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.\n13. If you plan to stop using Cloud Service Mesh at the fleet level, disable the service mesh feature for your fleet host project.\n\n gcloud container hub mesh disable --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.\n14. If you enabled managed Cloud Service Mesh, check and delete managed resources if they present:\n\n | **Note:** If your cluster is an `Autopilot` cluster, you cannot delete resources from the `kube-system` namespace. If you're uninstalling managed Cloud Service Mesh and you're keeping your cluster, [contact Support](/service-mesh/docs/getting-support) to ensure that these resources are deleted.\n 1. Delete the `mdp-controller` deployment:\n\n kubectl delete deployment mdp-controller -n kube-system\n\n 2. If you have the `TRAFFIC_DIRECTOR` control plane implementation, clean up Transparent Health Check resources. Normally these are removed automatically, but you can make sure they are cleaned up by doing the following:\n\n 1. Delete the `snk` daemonset.\n\n kubectl delete daemonset snk -n kube-system\n\n 2. Delete the firewall rule.\n\n gcloud compute firewall-rules delete gke-csm-thc-\u003cvar translate=\"no\"\u003eFIRST_8_CHARS_OF_CLUSTER_ID\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eFIRST_8_CHARS_OF_CLUSTER_ID\u003c/var\u003e is the first 8 characters of the Cluster ID for your specific cluster.\n 3. 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.\n 4. Delete the `istio-cni-node` daemonset:\n\n kubectl delete daemonset istio-cni-node -n kube-system\n\n15. If you're uninstalling managed Cloud Service Mesh, [contact Support](/service-mesh/docs/getting-support) to ensure that all\n Google Cloud resources are cleaned up. The `istio-system` namespace and config\n maps may also continue to be recreated if you don't follow this step.\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:** Some resources (e.g. Network Endpoint Groups or NEGs) will be orphaned after the systematic removal of these components. To err on the side of caution, Cloud Service Mesh must *fail open* during clean up. This is to ensure that the uninstallation of managed Cloud Service Mesh never has a negative impact other networking resources in your project or on the workloads. To have these orphaned resources removed for the purposes of hygiene or \"house cleaning\", contact [Google Cloud Support](/service-mesh/docs/getting-support)"]]
