Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Disinstalla Cloud Service Mesh in-cluster

Attenzione:Cloud Service Mesh in-cluster che utilizza il control plane ISTIOD su GKE su Google Cloud è deprecato. Cloud Service Mesh con un control plane in-cluster su Google Distributed Cloud (solo software) continua a essere supportato come descritto in Piattaforme supportate.

Questa pagina spiega come disinstallare Cloud Service Mesh in-cluster se utilizzi le API Istio. Se utilizzi le API Compute Engine, non sono necessari passaggi. Per comprendere le differenze, consulta la panoramica di Cloud Service Mesh.

Se segui queste istruzioni per disinstallare Cloud Service Mesh in-cluster, tutte le configurazioni vengono rimosse.

Se stai disinstallando Cloud Service Mesh gestito, segui la guida alla disinstallazione gestita.

Se esegui la migrazione da in-cluster a gestito, segui la guida alla migrazione.

Impatto della rimozione di Cloud Service Mesh

Prima di disinstallare Cloud Service Mesh, considera le funzionalità che vengono rimosse dal cluster e dai carichi di lavoro. Quando rimuovi i proxy Cloud Service Mesh dai tuoi carichi di lavoro e li riavvii, le tue applicazioni tornano al comportamento di networking Kubernetes standard.

Sicurezza

Quando rimuovi Cloud Service Mesh, perdi le seguenti funzionalità di sicurezza:

Crittografia TLS reciproca (mTLS): il traffico tra i servizi non viene più criptato in transito con i certificati mTLS gestiti dal mesh.
Policy di autorizzazione: le risorse personalizzate AuthorizationPolicy di Mesh non vengono più applicate. Devi configurare le risorse NetworkPolicy di Kubernetes o l'autenticazione e l'autorizzazione a livello di applicazione per limitare il traffico.

Osservabilità

Quando rimuovi Cloud Service Mesh, perdi le seguenti funzionalità di osservabilità:

Telemetria e metriche: la raccolta automatica delle metriche di livello 7 (come tassi di richieste, tassi di errore e latenza) si interrompe. La telemetria del mesh non viene più inserita automaticamente in Cloud Monitoring. Le metriche GKE standard non sono interessate.
Dashboard e SLO: le dashboard preconfigurate di Cloud Service Mesh e il monitoraggio degli obiettivi del livello di servizio (SLO) nella consoleGoogle Cloud non vengono più compilati.
Registrazione e tracciamento degli accessi: i log di accesso del proxy sidecar con identità mTLS client e tracce distribuite automatizzate non vengono più generati.

Service Discovery e resilienza del networking

Quando rimuovi Cloud Service Mesh, perdi le seguenti funzionalità di rete e resilienza:

Resilienza di rete: i carichi di lavoro perdono le funzionalità di resilienza a livello di sidecar, inclusi i tentativi automatici, i timeout delle richieste configurabili, gli interruttori di circuito, il rilevamento di outlier e la gestione del pool di connessioni. Le applicazioni devono gestire direttamente gli errori di connessione e i tentativi.
Service Discovery multi-cluster: il rilevamento degli endpoint cross-cluster e il routing tra più cluster in un parco risorse non funzionano più tramite la mesh. I servizi possono rilevare gli endpoint solo all'interno del cluster locale utilizzando il DNS standard.

Disinstalla Cloud Service Mesh

Utilizza i seguenti comandi per disinstallare tutti i componenti di Cloud Service Mesh.

Per evitare di interrompere il traffico dell'applicazione:
- Esegui il downgrade di tutte le policy mTLS STRICT a PERMISSIVE.
- Rimuovi eventuali AuthorizationPolicy che potrebbero bloccare il traffico.
Disattiva l'inserimento automatico di sidecar nei tuoi spazi dei nomi, se è abilitato. Esegui questo comando per visualizzare le etichette dello spazio dei nomi:
```
 kubectl get namespace YOUR_NAMESPACE --show-labels
```
L'output è simile al seguente:
```
 NAME   STATUS   AGE     LABELS
 demo   Active   4d17h   istio.io/rev=asm-181-5
```
Se nell'output visualizzi istio.io/rev= nella colonna LABELS, rimuovilo:
```
 kubectl label namespace YOUR_NAMESPACE istio.io/rev-
```
Se nell'output visualizzi istio-injection nella colonna LABELS, rimuovilo:
```
 kubectl label namespace YOUR_NAMESPACE istio-injection-
```
Se non vedi le etichette istio.io/rev o istio-injection, l'inserimento automatico non è stato abilitato nello spazio dei nomi.

Nota :devi controllare anche le risorse, inclusi deployment, StatefulSet, ReplicaSet, DaemonSet, Job e CronJob, per verificare la presenza di iniezioni.
Riavvia i workload a cui sono stati inseriti i sidecar per rimuovere i proxy.

Elimina validatingwebhooksconfiguration e mutatingwebhookconfiguration dal cluster, se esistenti:

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

Una volta che tutti i workload sono attivi e non vengono osservati proxy, puoi eliminare in sicurezza il control plane in-cluster per interrompere la fatturazione.

Per rimuovere il control plane in-cluster, esegui questo comando:
```
istioctl uninstall --purge
```
Se non sono presenti altri control plane, puoi eliminare lo spazio dei nomi istio-system per eliminare tutte le risorse Cloud Service Mesh. In caso contrario, elimina i servizi corrispondenti alle revisioni di Cloud Service Mesh. In questo modo si evita l'eliminazione di risorse condivise, come i CRD.

(Facoltativo) Rimuovi le CR Istio, le CRD Istio, la configmap istio-(revisione), la configmap asm-options, gli spazi dei nomi istio-system e asm-system per rimuovere mesh di servizi dal cluster o utilizzarli in un altro mesh di servizi compatibile con l'API Istio.

Rimuovi CR Istio:

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

Rimuovi i CRD di Istio:

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

Rimuovi il configmap istio-(revisione). Puoi saltare questo passaggio se elimini lo spazio dei nomi istio-system.
```
kubectl delete configmap istio-RELEASE_CHANNEL -n istio-system
```
Sostituisci RELEASE_CHANNEL con il tuo canale di rilascio

Rimuovi lo spazio dei nomi istio-system:

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

Rimuovi lo spazio dei nomi asm-system:

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

Controlla se le eliminazioni sono andate a buon fine:

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

Se eliminerai i cluster o li hai già eliminati, assicurati che ogni cluster sia annullato dal tuo parco risorse.
Se prevedi di interrompere l'utilizzo di Cloud Service Mesh a livello di parco risorse, disabilita la funzionalità mesh di servizi per il progetto host del parco risorse.
```
 gcloud container hub mesh disable --project FLEET_PROJECT_ID
```
Dove FLEET_PROJECT_ID è l'ID del progetto host del parco risorse.

Una volta completati questi passaggi, tutti i componenti di Cloud Service Mesh, inclusi proxy, autorità di certificazione in-cluster e ruoli e binding RBAC, vengono rimossi sistematicamente dal cluster. Durante il processo di installazione, a un account di servizio di proprietà di Google vengono concesse le autorizzazioni necessarie per stabilire le risorse del mesh di servizi all'interno del cluster. Queste istruzioni di disinstallazione non revocano queste autorizzazioni, consentendo una riattivazione senza problemi di Cloud Service Mesh in futuro.