Aggiornamenti della configurazione per la modernizzazione

Questo documento descrive gli aggiornamenti di configurazione che potresti dover apportare a Cloud Service Mesh gestito prima di eseguire la modernizzazione del tuo mesh al piano di controllo TRAFFIC_DIRECTOR dal piano di controllo ISTIOD.

Per ulteriori informazioni sul flusso di lavoro di modernizzazione, consulta la pagina Modernizzazione del piano di controllo gestito.

Esegui la migrazione dai secret Istio a multicluster_mode

I secret multi-cluster non sono supportati quando un cluster utilizza il control planeTRAFFIC_DIRECTOR. Questo documento descrive come puoi eseguire la modernizzazione passando dall'utilizzo dei secret multi-cluster di Istio all'utilizzo di multicluster_mode.

Panoramica dei secret Istio rispetto alle API dichiarative

Il rilevamento degli endpoint di Istio multi-cluster open source funziona utilizzando istioctl o altri strumenti per creare un secret di Kubernetes in un cluster. Questo secret consente a un cluster di bilanciare il carico del traffico su un altro cluster nel mesh. Il piano di controllo ISTIOD legge quindi questo segreto e inizia a instradare il traffico verso l'altro cluster.

Cloud Service Mesh dispone di un'API dichiarativa per controllare il traffico multi-cluster anziché creare direttamente i secret Istio. Questa API considera i secret Istio come un dettaglio di implementazione ed è più affidabile della creazione manuale dei secret Istio. Le future funzionalità di Cloud Service Mesh dipenderanno dall'API dichiarativa e non potrai utilizzarle direttamente con i secret Istio. L'API dichiarativa è l'unico percorso supportato per il futuro.

Se utilizzi Istio Secrets, esegui la migrazione all'API dichiarativa il prima possibile. Tieni presente che l'impostazione multicluster_mode indica a ciascun cluster di indirizzare il traffico a tutti gli altri cluster del mesh. L'utilizzo dei secret consente una configurazione più flessibile, in quanto ti consente di configurare per ogni cluster a quale altro cluster deve indirizzare il traffico nel mesh. Per un elenco completo delle differenze tra le funzionalità supportate dell'API dichiarativa e i secret Istio, consulta Funzionalità supportate mediante le API Istio.

Esegui la migrazione dagli API secret di Istio all'API dichiarativa

Se hai eseguito il provisioning di Cloud Service Mesh utilizzando la gestione automatica con l'API di funzionalità di flotta, non devi seguire queste istruzioni. Questi passaggi si applicano solo se hai eseguito l'onboarding utilizzando asmcli --managed.

Tieni presente che questa procedura modifica i secret che rimandano a un cluster. Durante questa procedura, gli endpoint vengono rimossi e poi aggiunti di nuovo. Tra la rimozione e l'aggiunta degli endpoint, il traffico tornerà brevemente al routing locale anziché al bilanciamento del carico verso altri cluster. Per ulteriori informazioni, consulta il problema di GitHub.

Per passare dall'utilizzo dei secret Istio all'API dichiarativa, segui questi passaggi. Esegui questi passaggi contemporaneamente o in rapida successione:

Attiva l'API dichiarativa per ogni cluster nel parco risorse in cui vuoi attivare il rilevamento di endpoint multi cluster impostando multicluster_mode=connected. Tieni presente che devi impostare esplicitamente multicluster_mode=disconnected se non vuoi che il cluster sia rilevabile.

Utilizza il seguente comando per attivare la scoperta degli endpoint su più cluster in un cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Utilizza il seguente comando per disattivare il rilevamento degli endpoint per un cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Elimina i vecchi secret.

Dopo aver impostato multicluster_mode=connected sui cluster, per ogni cluster verrà generato un nuovo segreto per ogni altro cluster su cui è impostato multicluster_mode=connected. Il secret viene inserito nello spazio dei nomi istio-system e ha il seguente formato:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
A ogni segreto verrà applicata anche l'etichetta istio.io/owned-by: mesh.googleapis.com.

Una volta creati i nuovi secret, puoi eliminare i secret creati manualmente con istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Una volta eseguita la migrazione, controlla le metriche delle richieste per assicurarti che vengano inoltrate come previsto.