O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Desinstalar o Cloud Service Mesh gerenciado

Nesta página, explicamos como desinstalar o Cloud Service Mesh gerenciado. Se você estiver desinstalando o Cloud Service Mesh no cluster, siga o guia de desinstalação no cluster.

Se você estiver usando uma configuração legada com vários planos de controle provisionados, seguir estas instruções vai remover todos eles.

Os planos de controle gerenciados pelo asmcli não são compatíveis com a desinstalação, mas os clusters que têm planos de controle gerenciados por asmcli --managed ou pela API de malha são compatíveis. Se você não tiver certeza sobre o plano de controle, execute o seguinte comando:

kubectl get controlplanerevisions -n istio-system -l 'app.kubernetes.io/created-by!=asmcli'

A desinstalação é compatível se algum item estiver listado na saída.

Impacto da remoção do Cloud Service Mesh

Antes de desinstalar o Cloud Service Mesh, considere os recursos que serão removidos do cluster e das cargas de trabalho. Quando você remove proxies do Cloud Service Mesh das suas cargas de trabalho e as reinicia, os aplicativos voltam ao comportamento padrão de rede do Kubernetes.

Segurança

Ao remover o Cloud Service Mesh, você perde os seguintes recursos de segurança:

Criptografia TLS mútua (mTLS): o tráfego entre serviços não é mais criptografado em trânsito com certificados mTLS gerenciados pela malha.
Políticas de autorização: os recursos personalizados do Mesh AuthorizationPolicy não são mais aplicados. É necessário configurar recursos NetworkPolicy do Kubernetes ou autenticação e autorização no nível do aplicativo para restringir o tráfego.

Observabilidade

Ao remover o Cloud Service Mesh, você perde os seguintes recursos de observabilidade:

Telemetria e métricas: a coleta automática de métricas da camada 7 (como taxas de solicitação, taxas de erro e latência) é interrompida. A telemetria da malha não é mais ingerida automaticamente no Cloud Monitoring. As métricas padrão do GKE não foram afetadas.
Painéis e SLOs: os painéis pré-configurados do Cloud Service Mesh e o monitoramento de objetivo de nível de serviço (SLO) no consoleGoogle Cloud não são mais preenchidos.
Registro e rastreamento de acesso: os registros de acesso do proxy sidecar com identidades mTLS do cliente e rastreamentos distribuídos automatizados não são mais gerados.

Descoberta de serviços e resiliência de rede

Ao remover o Cloud Service Mesh, você perde os seguintes recursos de rede e resiliência:

Resiliência de rede: as cargas de trabalho perdem recursos de resiliência no nível do sidecar, incluindo novas tentativas automáticas, tempos limite de solicitação configuráveis, disjuntores, detecção de outliers e gerenciamento de pool de conexões. Os aplicativos precisam gerenciar falhas de conexão e novas tentativas diretamente.
Descoberta de serviços multicluster: a descoberta de endpoints entre clusters e o roteamento em vários clusters em uma frota não funcionam mais pela malha. Os serviços só podem descobrir endpoints no cluster local usando o DNS padrão.

Desinstalar o Cloud Service Mesh

Use os comandos a seguir para desinstalar todos os componentes do Cloud Service Mesh.

Para evitar a interrupção do tráfego de aplicativos:
- Faça o downgrade de qualquer política STRICT mTLS para PERMISSIVE.
- Remova qualquer AuthorizationPolicy que possa bloquear o tráfego.
Desative o recurso de vários clusters se houver outros clusters executando a descoberta de endpoints no cluster que você está desinstalando.
```
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'
```
Encontre e exclua os secrets que precisam de limpeza:
```
kubectl get secrets -n istio-system -l istio/multiCluster=true
```
```
kubectl delete secret SECRET_NAME
```
Em que SECRET_NAME é o nome do secret. Repita essa etapa para cada secret listado.
Desative a injeção automática de sidecar nos namespaces, se estiver ativada. Execute o seguinte comando para mostrar os rótulos de namespace:
```
 kubectl get namespace YOUR_NAMESPACE --show-labels
```
O resultado será o seguinte:
```
 NAME   STATUS   AGE     LABELS
 demo   Active   4d17h   istio.io/rev=asm-181-5
```
1. Se você vir istio.io/rev= na saída da coluna LABELS, remova-o:
```
 kubectl label namespace YOUR_NAMESPACE istio.io/rev-
```
2. Se você vir istio-injection na saída da coluna LABELS, remova-o:
```
 kubectl label namespace YOUR_NAMESPACE istio-injection-
```
3. Se você não vir os rótulos istio.io/rev ou istio-injection, a injeção automática não foi ativada no namespace.
Observação: verifique também recursos como implantações, StatefulSets, ReplicaSets, DaemonSets, jobs e CronJobs para injeção.
Reinicie as cargas de trabalho que tenham arquivos secundários injetados para remover os proxies.

Verifique se não há proxies conectados ao plano de controle gerenciado:

  kubectl get pods --all-namespaces -o json | jq -r '
  .items[] |
  select(
     .spec.containers[].env[]? |
     select(.name == "PROXY_CONFIG" and (.value | contains("\"discoveryAddress\":\"meshconfig.googleapis.com:443\"")))
  ) |
  "\(.metadata.namespace)\t\(.metadata.name)"
  '

Atualize o gerenciamento de especificação de associação de recurso de malha para not-installed:
```
 gcloud alpha container fleet mesh update \
   --project FLEET_PROJECT_ID \
   --memberships MEMBERSHIP_NAME \
   --location MEMBERSHIP_LOCATION \
   --management not-installed
```
Substitua:
- MEMBERSHIP_NAME é o nome da assinatura listado quando você verificou que o cluster estava registrado na frota.
- MEMBERSHIP_LOCATION é o local da assinatura (uma região ou global).

Verifique se o estado da associação do recurso de malha para o estado do plano de controle é DISABLED.

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

A saída é semelhante a:

 servicemesh:
   controlPlaneManagement:
     details:
     - code: DISABLED
       details: Control Plane Management is not enabled.
     state: DISABLED
   dataPlaneManagement:
     details:
     - code: DISABLED
       details: Data Plane Management is not enabled.
     state: DISABLED
 state:
   description: 'Please see https://cloud.google.com/service-mesh/docs/install for instructions to onboard to Anthos Service Mesh.'
...

Se o estado do plano de controle for DEPROVISIONING, verifique novamente após alguns minutos.

Se o estado do plano de controle for STALLED, a desinstalação será bloqueada devido a uma condição de erro interno. Se o problema persistir, entre em contato com o suporte.

Opcionalmente, remova as CRs do Istio, as CRDs do Istio, o ConfigMap istio-(revision), o ConfigMap asm-options e o namespace istio-system para remover a malha de serviço do cluster ou usá-los em outra malha de serviço compatível com a API do Istio.
1. Remova os CRs do Istio:
```
kubectl delete gateways,virtualservices,destinationrules,serviceentries,envoyfilters,sidecars,peerauthentications,requestauthentications,authorizationpolicies,telemetries,wasmplugins,proxyconfigs --all --all-namespaces
```
2. Remova os CRDs do Istio:
```
kubectl get crds -o name | grep --color=never 'istio.io' | xargs kubectl delete
```
3. Remova o configmap istio-(revision). Pule esta etapa se você excluir o namespace istio-system.
```
kubectl delete configmap istio-RELEASE_CHANNEL -n istio-system
```
  Substitua RELEASE_CHANNEL pelo seu canal de lançamento (asm-managed, asm-managed-stable ou asm-managed-rapid).
4. Remova o configmap asm-options:
```
kubectl delete configmap asm-options -n istio-system
```
5. Remova o namespace istio-system:
```
kubectl delete namespace istio-system --ignore-not-found=true
```
6. Verifique se as exclusões foram feitas:
```
kubectl get ns
```
  A saída indicará um estado Terminating e retornará conforme mostrado. Caso contrário, talvez seja necessário excluir manualmente os recursos restantes nos namespaces e tentar novamente.
```
NAME                 STATUS       AGE
istio-system         Terminating  71m
```
Se você estiver usando o Certificate Authority Service, limpe as permissões e o pool de ACs criados ao configurar o Certificate Authority Service para o Managed Cloud Service Mesh.
Se você ativou a configuração padrão da frota do Cloud Service Mesh gerenciado e quer desativá-la para clusters futuros, faça isso. Você pode pular esta etapa se estiver desinstalando apenas de um cluster.
```
 gcloud container hub mesh disable --fleet-default-member-config --project FLEET_PROJECT_ID
```
FLEET_PROJECT_ID é o ID do projeto host da frota.
Se você planeja parar de usar o Cloud Service Mesh no nível da frota, desative o recurso de malha de serviço no projeto host da frota.
```
 gcloud container hub mesh disable --project FLEET_PROJECT_ID
```
FLEET_PROJECT_ID é o ID do projeto host da frota.

Após a conclusão dessas etapas, todos os componentes do Cloud Service Mesh, incluindo proxies, autoridades certificadoras e funções e vinculações de RBAC, serão removidos sistematicamente do cluster. Durante o processo de instalação, uma conta de serviço do Google recebe as permissões necessárias para estabelecer os recursos da malha de serviço no cluster. Essas instruções de desinstalação não revogam essas permissões, permitindo uma reativação perfeita do Cloud Service Mesh no futuro.