Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Desinstala Cloud Service Mesh

En esta página, se explica cómo desinstalar Cloud Service Mesh si usas las APIs de Istio. Si usas las APIs de Compute Engine, no es necesario que sigas ningún paso. Consulta la descripción general de Cloud Service Mesh para comprender las diferencias.

Si sigues estas instrucciones para desinstalar Cloud Service Mesh, se quitarán todas las configuraciones, sin importar el tipo del plano de control (en el clúster o administrado). Si vas a migrar de un controlador dentro del clúster a uno administrado, sigue la guía de migración.

Desinstala Cloud Service Mesh

Usa los siguientes comandos para desinstalar todos los componentes de Cloud Service Mesh. Por medio de estos comandos, también se borran el espacio de nombres istio-system y todas las definiciones de los recursos personalizados (CRD), incluidas las CRD que aplicaste.

Para evitar la interrupción del tráfico de la aplicación:
- Cambia las políticas STRICT de mTLS a PERMISSIVE.
- Quita cualquier AuthorizationPolicy que pueda bloquear el tráfico.
Inhabilita la administración automática en este clúster (ya sea que la hayas aplicado directamente o con la configuración predeterminada de la flota):
```
  gcloud container fleet mesh update \
     --management manual \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION
```
Reemplaza lo siguiente:
- MEMBERSHIP_NAME es el nombre de membresía que aparece cuando verificaste que tu clúster estaba registrado en la flota.
- MEMBERSHIP_LOCATION es la ubicación de tu membresía (una región o global).
Inhabilita la inserción automática de sidecar en tus espacios de nombres, si está habilitada. Ejecuta el siguiente comando para mostrar las etiquetas del espacio de nombres:
```
 kubectl get namespace YOUR_NAMESPACE --show-labels
```
El resultado es similar a este:
```
 NAME   STATUS   AGE     LABELS
 demo   Active   4d17h   istio.io/rev=asm-181-5
```
Si ves istio.io/rev= en el resultado en la columna LABELS, quítalo:
```
 kubectl label namespace YOUR_NAMESPACE istio.io/rev-
```
Si ves istio-injection en el resultado en la columna LABELS, quítalo:
```
 kubectl label namespace YOUR_NAMESPACE istio-injection-
```
Si no ves las etiquetas istio.io/rev o istio-injection, la inyección automática no se habilitó en el espacio de nombres.
Reinicia tus cargas de trabajo que tienen incorporados sidecars para quitar los proxies.
Si usas Cloud Service Mesh administrado, verifica qué implementación del plano de control tienes en tu clúster. Esto te ayudará a borrar los recursos pertinentes en los pasos posteriores.

Si usas Cloud Service Mesh administrado, quita todos los recursos controlplanerevision del clúster:

kubectl delete controlplanerevision asm-managed asm-managed-rapid asm-managed-stable -n istio-system --ignore-not-found=true

Borra los webhooks del clúster, si existen.
Cloud Service Mesh en el clúster
Borra la validatingwebhooksconfiguration y la mutatingwebhookconfiguration.
```
kubectl delete validatingwebhookconfiguration,mutatingwebhookconfiguration -l operator.istio.io/component=Pilot,istio.io/owned-by!=mesh.googleapis.com
```
Cloud Service Mesh administrada
A. Borra la validatingwebhooksconfiguration.
```
kubectl delete validatingwebhookconfiguration istiod-istio-system-mcp
```
B. Borra todos los mutatingwebhookconfiguration.

Nota: Usa RELEASE_CHANNEL de acuerdo con el canal de versiones que aprovisionaste. Por ejemplo, Regular(istiod-asm-managed), Rápido (istiod-asm-managed-rapid) y Estable (istiod-asm-managed-stable).
```
kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL
```
Una vez que aparezcan todas las cargas de trabajo y no se vean proxies, puedes borrar de forma segura el plano de control en el clúster para detener la facturación.

Para quitar el plano de control en el clúster, ejecuta el siguiente comando:
```
istioctl uninstall --purge
```
Si no hay otros planos de control, puedes borrar el espacio de nombres istio-system para deshacerte de todos los recursos de Cloud Service Mesh. De lo contrario, borra los servicios correspondientes a las revisiones de Cloud Service Mesh. Esto evita borrar recursos compartidos, como CRD.

Borra los espacios de nombres istio-system y asm-system:

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

Verifica si las eliminaciones se realizaron de forma correcta:
```
 kubectl get ns
```
El resultado debe indicar un estado Terminating y mostrarlo como se indica a continuación. De lo contrario, es posible que debas borrar de forma manual los recursos restantes en el espacio de nombres y volver a intentarlo.
```
 NAME                 STATUS       AGE
 istio-system         Terminating  71m
 asm-system           Terminating  71m
```
Si borrarás tus clústeres o ya los borraste, asegúrate de que cada clúster esté dado de baja de tu flota.
Si habilitaste la configuración predeterminada de la flota de Cloud Service Mesh administrado y quieres inhabilitarla para los clústeres futuros, inhabilítala. Puedes omitir este paso si solo desinstalas desde un solo clúster.
```
 gcloud container hub mesh disable --fleet-default-member-config --project FLEET_PROJECT_ID
```
En el ejemplo anterior, FLEET_PROJECT_ID es el ID de tu proyecto host de la flota.
Si planeas dejar de usar Cloud Service Mesh a nivel de la flota, inhabilita la función de malla de servicios para el proyecto host de tu flota.
```
 gcloud container hub mesh disable --project FLEET_PROJECT_ID
```
En el ejemplo anterior, FLEET_PROJECT_ID es el ID de tu proyecto host de la flota.
Si habilitaste Cloud Service Mesh administrado, verifica y borra los recursos administrados si están presentes:

Nota: Si tu clúster es un clúster de Autopilot, no puedes borrar recursos del espacio de nombres kube-system. Si desinstalas Cloud Service Mesh administrado y conservas tu clúster, comunícate con el equipo de asistencia para asegurarte de que se borren estos recursos.
1. Borra la implementación mdp-controller:
```
  kubectl delete deployment mdp-controller -n kube-system
```
2. Obtén y, luego, borra el recurso personalizado de control del plano de datos:
  1. Obtén el CR de control del plano de datos:
```
kubectl get dataplanecontrol
```
  2. Borra el CR de control del plano de datos:
```
kubectl delete dataplanecontrol DATA_PLANE_CONTROL_CR_NAME
```
    Reemplaza DATA_PLANE_CONTROL_CR_NAME por el resultado del comando anterior.
  3. Borra los CRD de controlplanerevision y dataplanecontrol:
```
kubectl delete crd controlplanerevisions.mesh.cloud.google.com dataplanecontrols.mesh.cloud.google.com
```
3. Si tienes la implementación del plano de control TRAFFIC_DIRECTOR, limpia los recursos de la verificación de estado transparente. Normalmente, estos archivos se quitan de forma automática, pero puedes asegurarte de que se limpien siguiendo estos pasos:
  1. Borra el daemonset snk.
```
   kubectl delete daemonset snk -n kube-system
```
  2. Borra la regla de firewall.
```
   gcloud compute firewall-rules delete gke-csm-thc-FIRST_8_CHARS_OF_CLUSTER_ID
```
    Reemplaza lo siguiente:
    - FIRST_8_CHARS_OF_CLUSTER_ID son los primeros 8 caracteres del ID del clúster específico.
4. Comprueba si el configmap istio-cni-plugin-config está presente:
```
  kubectl get configmap istio-cni-plugin-config -n kube-system
```
  Si está presente, borra el configmap de istio-cni-plugin-config:
```
  kubectl delete configmap istio-cni-plugin-config -n kube-system
```
  Advertencia: La confiabilidad de la red de tu clúster de GKE puede verse afectada si no borras este ConfigMap.
5. Borra el daemonset istio-cni-node:
```
  kubectl delete daemonset istio-cni-node -n kube-system
```
Si desinstalas Cloud Service Mesh administrado, comunícate con el equipo de asistencia para asegurarte de que se limpien todos los recursos deGoogle Cloud . Es posible que el espacio de nombres istio-system y los mapas de configuración también se sigan recreando si no sigues este paso.

Cuando se completan estos pasos, todos los componentes de Cloud Service Mesh, incluidos los proxies, las autoridades de certificación en el clúster y los roles y vinculaciones de RBAC, se quitan sistemáticamente del clúster. Durante el proceso de instalación, se le otorgan a una cuenta de servicio propiedad de Google los permisos necesarios para establecer los recursos de malla de servicios dentro del clúster. Estas instrucciones de desinstalación no revocan estos permisos, lo que permite una reactivación sin problemas de Cloud Service Mesh en el futuro.

Desinstala Cloud Service Mesh

Desinstala Cloud Service Mesh

Cloud Service Mesh en el clúster

Cloud Service Mesh administrada