Desinstalar o Cloud Service Mesh no cluster

Nesta página, explicamos como desinstalar o Cloud Service Mesh no cluster se você estiver usando as APIs do Istio. Se você estiver usando as APIs do Compute Engine, não será necessário realizar nenhuma etapa. Consulte a visão geral do Cloud Service Mesh para entender as diferenças.

Seguir estas instruções para desinstalar o Cloud Service Mesh no cluster remove todas as configurações.

Se você estiver desinstalando o Cloud Service Mesh gerenciado, siga o guia de desinstalação gerenciada.

Se você estiver migrando do controlador no cluster para o gerenciado, siga o guia de migração.

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.

1. 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.

2. 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

   Se você vir istio.io/rev= na saída na coluna LABELS, remova-a:

    kubectl label namespace YOUR_NAMESPACE istio.io/rev-
   

   Se você vir istio-injection na saída na coluna LABELS, remova-a:

    kubectl label namespace YOUR_NAMESPACE istio-injection-
   

   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.

3. Reinicie as cargas de trabalho que tenham arquivos secundários injetados para remover os proxies.

4. Exclua os pods validatingwebhooksconfiguration e mutatingwebhookconfiguration do cluster, se eles existirem:

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

5. Depois que todas as cargas de trabalho aparecerem e nenhum proxy for observado, será possível excluir com segurança o plano de controle no clusterpara interromper o faturamento.

   Para remover o plano de controle no cluster, execute o seguinte comando:

   istioctl uninstall --purge
   

   Se não houver outros planos de controle, exclua o namespace istio-system para eliminar todos os recursos do Cloud Service Mesh. Caso contrário, exclua os serviços correspondentes às revisões do Cloud Service Mesh. Isso evita a exclusão de recursos compartilhados, como CRDs.

6. Se quiser, remova os CRs do Istio, os CRDs do Istio, o configmap istio-(revision), o configmap asm-options e os namespaces istio-system e asm-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.

   4. Remova o namespace istio-system:

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

   5. Remova o namespace asm-system:

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

      1. Verifique se as exclusões foram feitas:

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

7. Se você vai excluir ou já excluiu os clusters, verifique se cada um deles está cancelado da sua frota.

8. 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.

Depois de concluir essas etapas, todos os componentes do Cloud Service Mesh, incluindo proxies, autoridades certificadoras no cluster e funções e vinculações do 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.