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.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Desinstala Cloud Service Mesh en el clúster

Precaución: El uso de Cloud Service Mesh en el clúster con el plano de control de ISTIOD en GKE en Google Cloud está obsoleto. Cloud Service Mesh con un plano de control en el clúster en Google Distributed Cloud (solo software) sigue siendo compatible, como se describe en Plataformas compatibles.

En esta página, se explica cómo desinstalar Cloud Service Mesh en el clúster si usas las APIs de Istio. Si usas las APIs de Compute Engine, no es necesario que realices 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 en el clúster, se quitarán todas las configuraciones.

Si desinstalas Cloud Service Mesh administrado, sigue la guía de desinstalación administrada.

Si migras de un controlador dentro del clúster a uno administrado, sigue la guía de migración.

Impacto de la eliminación de Cloud Service Mesh

Antes de desinstalar Cloud Service Mesh, ten en cuenta las capacidades que se quitarán de tu clúster y tus cargas de trabajo. Cuando quitas los proxies de Cloud Service Mesh de tus cargas de trabajo y las reinicias, tus aplicaciones vuelven al comportamiento de redes estándar de Kubernetes.

Seguridad

Cuando quitas Cloud Service Mesh, pierdes las siguientes funciones de seguridad:

Encriptación con TLS mutua (mTLS): El tráfico entre los servicios ya no se encripta en tránsito con certificados mTLS administrados por la malla.
Políticas de autorización: Ya no se aplican los recursos personalizados AuthorizationPolicy de la malla. Debes configurar recursos NetworkPolicy de Kubernetes o autenticación y autorización a nivel de la aplicación para restringir el tráfico.

Observabilidad

Cuando quitas Cloud Service Mesh, pierdes las siguientes funciones de observabilidad:

Telemetría y métricas: Se detiene la recopilación automática de métricas de capa 7 (como tasas de solicitudes, tasas de errores y latencia). La telemetría de la malla ya no se transfiere automáticamente a Cloud Monitoring. Las métricas de GKE Standard no se ven afectadas.
Paneles y SLOs: Ya no se completan los paneles preconfigurados de Cloud Service Mesh ni la supervisión de los objetivos de nivel de servicio (SLO) en la consola deGoogle Cloud .
Registro y seguimiento de acceso: Ya no se generan registros de acceso del proxy sidecar con identidades de mTLS del cliente ni seguimientos distribuidos automatizados.

Descubrimiento de servicios y resiliencia de redes

Cuando quitas Cloud Service Mesh, pierdes las siguientes funciones de redes y resiliencia:

Resistencia de la red: Las cargas de trabajo pierden las funciones de resistencia a nivel de sidecar, como los reintentos automáticos, los tiempos de espera de solicitudes configurables, los disyuntores, la detección de valores atípicos y la administración de grupos de conexiones. Las aplicaciones deben administrar las fallas de conexión y los reintentos directamente.
Descubrimiento de servicios de varios clústeres: El descubrimiento de extremos entre clústeres y el enrutamiento en varios clústeres de una flota ya no funcionan a través de la malla. Los servicios solo pueden descubrir extremos dentro de su clúster local con el DNS estándar.

Desinstala Cloud Service Mesh

Usa los siguientes comandos para desinstalar todos los componentes de Cloud Service Mesh.

Para evitar la interrupción del tráfico de la aplicación, haz lo siguiente:
- Cambia las políticas STRICT de mTLS a PERMISSIVE.
- Quita cualquier AuthorizationPolicy que pueda bloquear el tráfico.
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 lo siguiente:
```
 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.

Nota: También debes verificar si hay inyecciones en los recursos, incluidas las implementaciones, los StatefulSets, los ReplicaSets, los DaemonSets, los Jobs y los CronJobs.
Reinicia tus cargas de trabajo que tienen incorporados sidecars para quitar los proxies.

Borra validatingwebhooksconfiguration y mutatingwebhookconfiguration de tu clúster, si existen:

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

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.

De manera opcional, quita los CR de Istio, los CRD de Istio, el mapa de configuración istio-(revisión), el mapa de configuración asm-options, los espacios de nombres istio-system y asm-system para quitar la malla de servicios del clúster o usarlos en otra malla de servicios compatible con la API de Istio.

Quita las CR de Istio:

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

Quita las CRD de Istio:

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

Quita el ConfigMap istio-(revisión). Puedes omitir este paso si borras el espacio de nombres istio-system.
```
kubectl delete configmap istio-RELEASE_CHANNEL -n istio-system
```
Reemplaza RELEASE_CHANNEL por tu canal de versiones

Quita el espacio de nombres istio-system:

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

Quita el espacio de nombres asm-system:

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

Verifica si las eliminaciones se realizaron de forma correcta:

 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
 ```

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 planeas dejar de usar Cloud Service Mesh a nivel de la flota, inhabilita la función de malla de servicios para tu proyecto host de la 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.

Una vez que completes 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 las vinculaciones de RBAC, se quitarán sistemáticamente del clúster. Durante el proceso de instalación, se le otorga a una cuenta de servicio propiedad de Google los permisos necesarios para establecer los recursos de la 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.