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.

Esegui la migrazione in-cluster a Istio su un nuovo cluster

Questo tutorial mostra come eseguire la migrazione di un'applicazione da un cluster Google Kubernetes Engine (GKE) esistente che utilizza Cloud Service Mesh in-cluster a un nuovo cluster GKE che utilizza Istio open source. Sfrutterai le funzionalità del mesh edge-to-multi-cluster per una migrazione senza interruzioni.

Nota sulla terminologia: in questo tutorial, Cloud Service Mesh si riferisce a Cloud Service Mesh in-cluster di Google e Istio si riferisce al mesh di servizi Istio open source.

In questo tutorial, imparerai a:

Prepara il cluster esistente con Cloud Service Mesh in-cluster per la migrazione.
Esegui il provisioning di un nuovo cluster GKE con Istio.
Configura l'API Gateway multi-cluster GKE su un cluster dedicato e i servizi multi-cluster per configurare il routing all'ingresso del mesh.
Esegui un deployment canary per dividere il traffico HTTP live tra Cloud Service Mesh e Istio.
Completa il cutover finale a Istio e ritira le risorse Cloud Service Mesh in-cluster.

Deployment canary

"Deployment canary" è una tecnica utilizzata nell'ingegneria del software per testare una nuova versione di software o infrastruttura prima di rilasciarla a tutti gli utenti di produzione. Comporta l'aumento incrementale della percentuale di traffico inviato alla nuova versione di destinazione.

In questo tutorial, configurerai un nuovo cluster con Istio e sposterai gradualmente il traffico utente. Inizierai indirizzando lo 0% del traffico utente al nuovo cluster, poi il 50% e, infine, il 100% al cluster GKE con Istio. Negli ambienti di produzione, puoi utilizzare incrementi più piccoli e granulari (ad esempio, 1%, 5%, 10%, 25%, 50%, 100%). Se in qualsiasi momento noti che il nuovo cluster presenta errori o un degrado delle prestazioni, puoi eseguire un rollback immediato impostando la percentuale di traffico di nuovo sullo 0% per il cluster Istio.

Control plane canary rispetto al cluster canary

Esistono due strategie principali per la migrazione tra i control plane del mesh di servizi:

Migrazione del cluster canary (consigliata): in questa strategia, crei un nuovo cluster nello stesso Google Cloud progetto e nello stesso parco risorse del cluster esistente, installi il control plane del mesh di servizi di destinazione (Istio) e migri i carichi di lavoro e il traffico in entrata nel nuovo cluster.
Migrazione del control plane canary (non supportata): in questa strategia, installi il nuovo control plane side-by-side sullo stesso cluster in cui è installato il control plane iniziale. Questa modalità di migrazione non è supportata.

In questa guida seguirai la strategia di migrazione del cluster canary. Entrambi i cluster devono risiedere nello stesso Google Cloud progetto.

Costi

Questo tutorial utilizza componenti fatturabili di Google Cloud, tra cui:

Al termine di questo tutorial, puoi evitare l'addebito di costi ricorrenti eliminando le risorse create. Per saperne di più, consulta Liberare spazio.

Prima di iniziare

Nella Google Cloud console, nella pagina del selettore di progetti, seleziona il Google Cloud progetto in cui è installato Cloud Service Mesh in-cluster.

Vai al selettore di progetti

Accedi al tuo Google Cloud account. Se non hai mai utilizzato Google Cloud, crea un account per valutare il rendimento dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei carichi di lavoro.

Verify that billing is enabled for your Google Cloud project.

Enable the required APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Verify that billing is enabled for your Google Cloud project.

Enable the required APIs, if any are not already enabled.

Roles required to enable APIs

Enable the APIs

Prepara il cluster utilizzando Cloud Service Mesh in-cluster per la migrazione

In questa sezione, preparerai il cluster GKE esistente che esegue Cloud Service Mesh in-cluster per la migrazione a un cluster GKE con Istio.

Assicurati che il cluster Cloud Service Mesh in-cluster sia in esecuzione e pronto per la migrazione

Assicurati che il cluster Cloud Service Mesh in-cluster GKE_CSM_CLUSTER sia in esecuzione con il control plane istiod in-cluster seguendo la guida all'installazione di Cloud Service Mesh in-cluster.

Esegui il comando seguente per controllare lo stato dell'installazione:
```
kubectl get deployment -A -l app=istiod -L istio.io/rev
```
L'output previsto è simile al seguente:
```
NAMESPACE              NAME                 READY   UP-TO-DATE   AVAILABLE   AGE     REV
ISTIOD_NAMESPACE      istiod-asm-1295-12   2/2     2            2           4d16h   asm-1295-12
```
Verifica che non ci siano errori nel control plane istiod utilizzando il comando seguente:
```
kubectl logs -n ISTIOD_NAMESPACE -l app=istiod
```

Prepara il cluster per la migrazione

Verifica che Workload Identity sia abilitato sul cluster e sul pool di nodi.

Nota:se hai installato Cloud Service Mesh utilizzando asmcli con il flag --enable-workload-identity o --enable-all, Workload Identity è già abilitato automaticamente sul cluster e sul pool di nodi e puoi saltare questo passaggio.

Per verificare Workload Identity sul cluster, esegui il comando seguente:
```
gcloud container clusters describe "GKE_CSM_CLUSTER" \
    --location="LOCATION" \
    --project="PROJECT_ID" \
    --format="value(workloadIdentityConfig.workloadPool)"
```
Sostituisci GKE_CSM_CLUSTER con il nome del cluster esistente, LOCATION con la località del cluster e PROJECT_ID con l'ID progetto.

Output previsto:
```
PROJECT_ID.svc.id.goog
```
Se Workload Identity non è presente, consulta la guida a Workload Identity per aggiornare il cluster.

Verifica che il cluster sia registrato nel parco risorse:

gcloud container clusters describe "GKE_CSM_CLUSTER" \
    --location="LOCATION" \
    --project="PROJECT_ID" \
    --format="yaml(fleet)"

Output previsto per un cluster registrato:

fleet:
  membership: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/memberships/MEMBERSHIP_NAME

Se i dettagli del parco risorse sono vuoti, consulta la guida alla registrazione dell'appartenenza al parco risorse per registrare il cluster nel parco risorse.

Esporre l'applicazione utilizzando un gateway Ingress seguendo la guida all'installazione e all'upgrade del gateway.

Installa Istio su un nuovo cluster GKE

In questa sezione, eseguirai il provisioning di un nuovo cluster GKE che esegue Istio open source per la strategia di migrazione del cluster canary.

Crea un nuovo cluster GKE GKE_ISTIO_CLUSTER nello stesso Google Cloud progetto (PROJECT_ID) del cluster Cloud Service Mesh in-cluster esistente.

Nota: entrambi i cluster devono risiedere nello stesso Google Cloud progetto ed essere registrati nello stesso parco risorse. Il gateway multi-cluster e i servizi multi-cluster (MCS) si basano su un parco risorse condiviso nello stesso progetto per scoprire gli endpoint di servizio (ServiceImport) e instradare il traffico in tempo reale su entrambi i cluster durante la migrazione. Questa configurazione dello stesso progetto è l'approccio ufficialmente supportato per questa migrazione.

Quando crei il cluster, assicurati di specificare --project e di abilitare Workload Identity utilizzando --workload-pool=PROJECT_ID.svc.id.goog:
```
gcloud container clusters create GKE_ISTIO_CLUSTER \
    --project=PROJECT_ID \
    --location=LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog
```
Se hai già creato un cluster, utilizza la guida a Workload Identity per abilitare Workload Identity.

Registra il cluster Istio nel parco risorse:

gcloud container fleet memberships register \
    GKE_ISTIO_CLUSTER \
    --gke-cluster=LOCATION/GKE_ISTIO_CLUSTER \
    --enable-workload-identity \
    --location=LOCATION \
    --project=PROJECT_ID

Installa Istio seguendo la guida all'installazione ufficiale di Istio con i gateway in entrata di cui è stato eseguito il deployment per il traffico in entrata. Per una migrazione più fluida, ti consigliamo di installare la stessa versione di Istio open source. Se decidi di eseguire l'upgrade di Istio open source, consulta le note di rilascio di Istio per eventuali modifiche del comportamento.

Configura questo cluster installando le applicazioni nello stesso modo del cluster GKE utilizzando Cloud Service Mesh in-cluster. Questa guida fa riferimento allo spazio dei nomi che ospita i gateway in entrata come ISTIO_INGRESS_NAMESPACE.
Assicurati che il cluster sia in stato integro e pronto a gestire il traffico. I team delle applicazioni sono responsabili della conferma che tutti i microservizi siano in esecuzione correttamente e superino i controlli di integrità prima di instradare il traffico utente live.

Configura l'API Gateway multi-cluster su un cluster dedicato

In questa sezione, configurerai un bilanciatore del carico delle applicazioni esterno (L7XLB) tramite il controller Gateway GKE per abilitare il traffico in entrata nel mesh. Durante la migrazione, ti consigliamo di eseguire il deployment delle risorse dell'API Gateway su un cluster di configurazione GKE dedicato per gestire il bilanciatore del carico. Questa guida fa riferimento a questo cluster di configurazione dedicato come GKE_CONFIG_CLUSTER.

Prepara il cluster di configurazione

Prepara il cluster di configurazione per ospitare le API Gateway e HTTPRoute seguendo la guida al gateway multi-cluster.

Esporta i servizi utilizzando i servizi multi-cluster

Esporta il servizio istio-ingressgateway su entrambi i cluster mesh utilizzando ServiceExport come indicato nella guida ai servizi multi-cluster (MCS):

Nota: l'applicazione di ServiceExport fa sì che il controller MCS GKE esegua automaticamente il provisioning dei Google Cloud gruppi di endpoint di rete (NEG) per i pod del gateway in entrata.

apiVersion: net.gke.io/v1
kind: ServiceExport
metadata:
  namespace: NAMESPACE
  name: SERVICE_EXPORT_NAME

Esegui il provisioning delle risorse dell'API Gateway sul cluster di configurazione

Segui la guida al gateway edge-to-mesh per creare le risorse Gateway e HTTPRoute sul cluster di configurazione dedicato. Una configurazione di esempio è simile alla seguente:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: global-gateway
  namespace: CSM_INGRESS_NAMESPACE
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: edge-to-mesh-route
  namespace: CSM_INGRESS_NAMESPACE
spec:
  parentRefs:
  - name: global-gateway
  rules:
  - backendRefs:
    # Backend 1: Cloud Service Mesh Cluster (CSM_INGRESS_NAMESPACE namespace)
    - group: net.gke.io
      kind: ServiceImport
      name: istio-ingressgateway
      namespace: CSM_INGRESS_NAMESPACE
      port: 80
      weight: 100

Se le risorse ServiceImport risiedono in uno spazio dei nomi diverso da HTTPRoute, utilizza ReferenceGrant per abilitare il routing del traffico tra spazi dei nomi:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-csm-ingress-to-ISTIO_INGRESS_NAMESPACE
  namespace: ISTIO_INGRESS_NAMESPACE
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: CSM_INGRESS_NAMESPACE
  to:
  - group: net.gke.io
    kind: ServiceImport

Esegui la migrazione del traffico utilizzando il deployment canary

In questa sezione, sposterai il traffico nel nuovo cluster e completerai la migrazione.

Shift il 50% del traffico su Istio

In questa sezione, eseguirai un deployment canary per eseguire la migrazione del traffico lentamente. Per ulteriori informazioni, consulta la guida alla suddivisione del traffico.

Applica la risorsa personalizzata HTTPRoute nel cluster di configurazione per dividere il traffico canary nel cluster Istio:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: edge-to-mesh-route
  namespace: CSM_INGRESS_NAMESPACE
spec:
  parentRefs:
  - name: global-gateway
  rules:
  - backendRefs:
    # Backend 1: CSM Cluster (CSM_INGRESS_NAMESPACE namespace)
    - group: net.gke.io
      kind: ServiceImport
      name: istio-ingressgateway
      namespace: CSM_INGRESS_NAMESPACE
      port: 80
      weight: 50
    # Backend 2: Istio Cluster (ISTIO_INGRESS_NAMESPACE namespace)
    - group: net.gke.io
      kind: ServiceImport
      name: istio-ingressgateway
      namespace: ISTIO_INGRESS_NAMESPACE
      port: 80
      weight: 50

Convalida la distribuzione del traffico in tempo reale eseguendo richieste parallele all'indirizzo IP pubblico del gateway.

Output previsto: le risposte sono bilanciate del carico tra GKE_CSM_CLUSTER e GKE_ISTIO_CLUSTER.

In produzione, come indicato in precedenza, esegui la migrazione del traffico in incrementi più piccoli (ad esempio, 1%, 5%, 10%, 25%, 50%, 100%). Potrebbe essere necessario del tempo prima che questi incrementi di peso si propaghino completamente al bilanciatore del carico, quindi verifica che il traffico sia suddiviso correttamente prima di aumentare ulteriormente.

Completa la migrazione al cluster Istio

Verifica che l'applicazione sul cluster Istio funzioni correttamente con il traffico canary e che tutto il traffico sia stato spostato verso di essa. Dopo aver verificato che il routing del traffico funzioni correttamente, completa la migrazione eliminando la risorsa ServiceExport sul cluster Cloud Service Mesh in-cluster:

kubectl --context="GKE_CSM_CLUSTER_CONTEXT" delete serviceexport.net.gke.io istio-ingressgateway -n CSM_INGRESS_NAMESPACE

Il controller Gateway GKE scollega automaticamente il gruppo di endpoint di rete (NEG) del cluster Cloud Service Mesh dal Google Cloud servizio di backend del bilanciatore del carico. Tutto il traffico client in entrata passa senza problemi al cluster Istio senza tempi di inattività.

Libera spazio

Per evitare che al tuo Google Cloud account vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, libera spazio dai componenti di cui è stato eseguito il deployment.

Elimina le risorse ServiceExport sul cluster Istio:

kubectl --context="GKE_ISTIO_CLUSTER_CONTEXT" delete serviceexport.net.gke.io istio-ingressgateway -n ISTIO_INGRESS_NAMESPACE

Annulla la registrazione delle appartenenze al parco risorse:

gcloud container fleet memberships unregister \
    GKE_CSM_CLUSTER \
    --gke-cluster="LOCATION/GKE_CSM_CLUSTER" \
    --project="PROJECT_ID"

Elimina il cluster Cloud Service Mesh in-cluster:

gcloud container clusters delete GKE_CSM_CLUSTER \
    --location="LOCATION" \
    --project="PROJECT_ID"

Passaggi successivi

Leggi la guida all'architettura di base: Dal perimetro al mesh multi-cluster: esegui il deployment di applicazioni distribuite a livello globale tramite GKE Gateway e Cloud Service Mesh.
Scopri di più sui pattern dell'API Gateway multi-cluster.
Scopri di più sul bilanciamento del carico multi-cluster.
Esplora la documentazione sulla gestione del traffico del mesh di Istio.