Migrazione da Istio su GKE a Cloud Service Mesh

Questa guida mostra come eseguire l'upgrade di un cluster Google Kubernetes Engine (GKE) con Istio su Google Kubernetes Engine (Istio su GKE) versione 1.4 o 1.6 (beta) a Cloud Service Mesh gestito con il piano di controllo gestito da Google e l'autorità di certificazione Cloud Service Mesh.

Prerequisiti

Per completare questa guida sono necessari i seguenti prerequisiti:

  • Un cluster GKE con Istio on GKE abilitato. Se hai più cluster GKE, segui gli stessi passaggi in tutti i cluster.

  • Istio su GKE deve essere la versione 1.4 o 1.6.

  • Assicurati di eseguire GKE versione 1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.19.8-gke.1600+ o versioni successive.

  • Il cluster GKE deve essere in esecuzione in una di queste località.

  • L'utente o l'account di servizio che esegue questo script richiede le autorizzazioni IAM descritte in Configurazione del progetto.

  • Questa guida è stata testata su Cloud Shell, pertanto ti consigliamo di utilizzare Cloud Shell per eseguire i passaggi descritti.

Obiettivi

  • Esegui il deployment del piano di controllo gestito da Google di Cloud Service Mesh nel canale normale. Questa guida è specifica per il canale regolare; i canali stabili o rapidi richiedono istruzioni leggermente modificate. Per scoprire di più sui canali di rilascio, visita questo link.
  • Esegui la migrazione delle configurazioni Istio a Cloud Service Mesh.
  • Configura l'autorità di certificazione Cloud Service Mesh.
  • Eseguire la migrazione delle applicazioni in Cloud Service Mesh.
  • Esegui l'upgrade di istio-ingressgateway da Istio on GKE a Cloud Service Mesh.
  • Completa la migrazione di Cloud Service Mesh o esegui il rollback ad Istio su GKE.

Configura l'ambiente

Per configurare l'ambiente:

  1. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    In fondo alla pagina della console Google Cloud, Cloud Shell di Cloud Shell e mostra un prompt della riga di comando. Cloud Shell è una dell'ambiente shell con Google Cloud CLI e Google Cloud CLI è già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Crea le variabili di ambiente utilizzate in questa guida:

    # Enter your project ID
export PROJECT_ID=PROJECT_ID

# Copy and paste the following
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_1=GKE_CLUSTER_NAME
export CLUSTER_1_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export SHELL_IP=$(curl ifconfig.me) # This is required for private clusters with `master-authorized-networks` enabled.

  3. Crea una cartella WORKDIR. Tutti i file associati a questa guida vengono inseriti in WORKDIR, quindi puoi eliminare WORKDIR al termine.

    mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`

  4. Crea un file KUBECONFIG per questa guida. Puoi utilizzare anche file KUBECONFIG esistente contenente il contesto del cluster per Eseguire la migrazione del cluster GKE a Cloud Service Mesh.

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig

  5. Recupera le credenziali per il cluster GKE e memorizza il contesto in una variabile:

    Cluster di zona

    gcloud container clusters get-credentials ${CLUSTER_1} \
  --zone=${CLUSTER_1_LOCATION}

export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}

    Cluster a livello di regione

    gcloud container clusters get-credentials ${CLUSTER_1} \
  --region=${CLUSTER_1_LOCATION}

export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}

  6. I cluster devono essere registrati in un parco risorse. Questo passaggio può essere eseguito separatamente prima dell'installazione o come parte dell'installazione, passando il flag --fleet-id e uno dei flag --enable-all o --enable-signup.

  7. Nel progetto deve essere abilitata la funzionalità Service Mesh. Potresti attivare nell'ambito dell'installazione, passando uno dei flag --enable-all o --enable-signup esegui questo comando prima dell'installazione:

      gcloud container hub mesh enable --project=FLEET_PROJECT_ID

    dove FLEET_PROJECT_ID è l'ID progetto del progetto host del parco risorse.

Passaggio facoltativo

Se il cluster è privato (con master-authorized-networks abilitato), aggiungi il tuo $SHELL_IP alla lista consentita di master-authorized-networks. Se hai già accesso al tuo cluster, questo passaggio potrebbe non essere necessario.

Cluster di zona

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --zone=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

Cluster a livello di regione

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --region=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

Installa Cloud Service Mesh

In questa sezione eseguirai il deployment di Cloud Service Mesh con il piano di controllo gestito da Google del canale regolare sul cluster GKE. Questo piano di controllo viene inizialmente implementato come secondo piano di controllo (o canary).

  1. Scarica l'ultima versione dello script che installa Cloud Service Mesh alla directory di lavoro corrente e rendi eseguibile lo script:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
chmod +x asmcli

  2. Per configurare il cluster GKE, esegui lo script di installazione per installare Cloud Service Mesh con il piano di controllo del canale normale gestito da Google:

    ./asmcli install \
-p ${PROJECT_ID} \
-l ${CLUSTER_1_LOCATION} \
-n ${CLUSTER_1} \
--fleet_id ${FLEET_PROJECT_ID} \
--managed \
--verbose \
--output_dir ${CLUSTER_1} \
--enable-all \
--channel regular

    Il completamento di questo passaggio può richiedere alcuni minuti.

  3. Verifica il piano di controllo gestito da Google

  4. Copia istioctl nella cartella WORKDIR:

    cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.

Nella sezione successiva, scaricherai ed eseguirai lo script migrate_addon per della migrazione a Cloud Service Mesh. Utilità a riga di comando istioctl deve trovarsi nella stessa cartella dello script migrate_addon. Utilizza la WORKDIR sia per l'utilità a riga di comando istioctl sia per lo script migrate_addon.

Esegui la migrazione delle configurazioni a Cloud Service Mesh

In questa sezione esegui la migrazione delle configurazioni di Istio on GKE a Cloud Service Mesh. Lo script guidato identifica le configurazioni di cui è possibile eseguire la migrazione e quelle di cui non è possibile eseguire la migrazione.

  1. Scarica lo strumento di migrazione e rendilo eseguibile:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
chmod +x ${WORKDIR}/migrate_addon

  2. Disattiva il webhook di convalida della galleria. Questo passaggio è necessario per eseguire la migrazione delle configurazioni 1.4 a Cloud Service Mesh. Rispondi Y a entrambe le domande:

    ${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhook

    L'output è simile al seguente:

    tmpdir directory not present. Create directory? Continue? [Y/n] Y

Disabling the Istio validation webhook... Continue? [Y/n] Y
Running: kubectl get clusterrole istio-galley-istio-system -n istio-system -o yaml
Running: kubectl patch clusterrole -n istio-system istio-galley-istio-system --type=json -p=[{"op": "replace", "path": "/rules/2/verbs/0", "value": "get"}]
clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system patched
Running: kubectl get ValidatingWebhookConfiguration istio-galley --ignore-not-found
Running: kubectl delete ValidatingWebhookConfiguration istio-galley --ignore-not-found
validatingwebhookconfiguration.admissionregistration.k8s.io "istio-galley" deleted

  3. Verifica ed esegui la migrazione manuale della configurazione. Questo passaggio consente di identificare alcune delle configurazioni di cui è necessaria la migrazione manuale prima di eseguire la migrazione dei carichi di lavoro al piano di controllo gestito da Google.

    ${WORKDIR}/migrate_addon -d tmpdir --command config-check

    L'output è simile al seguente:

    Installing the authentication CR migration tool...
OK

Checking for configurations that will need to be explicitly migrated...
No resources found

Esegui la migrazione delle configurazioni personalizzate

Potrebbe essere necessario eseguire manualmente la migrazione delle configurazioni personalizzate prima di Cloud Service Mesh. Lo script precedente identifica le configurazioni personalizzate e stampa le informazioni su ciò che è richiesto. Queste personalizzazioni sono che segue:

  • I filtri di Envoy personalizzati rilevati non sono supportati da Cloud Service Mesh. Rimuovili, se possibile. I filtri Envoy non sono attualmente supportati nel piano di controllo gestito da Google.

  • È stato rilevato un certificato plug-in personalizzato. La migrazione dei certificati dei plug-in a Cloud Service Mesh non verrà eseguita. Se certificati plug-in vengono utilizzati con Istio su GKE, questi certificati non vengono utilizzati dopo la migrazione dei carichi di lavoro al piano di controllo gestito da Google. Tutti i carichi di lavoro utilizzano certificati firmati dall'autorità di certificazione di Google Cloud Service Mesh. I certificati dei plug-in non sono supportati dall'autorità di certificazione Cloud Service Mesh. Questo messaggio è informativo e non è necessaria un'azione.

  • Sono stati rilevati criteri di sicurezza di cui non è stato possibile eseguire la migrazione. <Error reason>. In genere l'operazione non riesce a causa di criteri AuthZ alpha di cui è necessaria la migrazione manuale. Per ulteriore contesto e informazioni su come eseguire la migrazione i criteri, consulta Esegui la migrazione dei criteri di sicurezza alpha pre-Istio 1.4 alle API attuali. Per ulteriori informazioni sul messaggio di errore, consulta security-policy-migrate.

  • È stata rilevata una configurazione VirtualService potenzialmente incompatibile. <Specific deprecated config>. Devi aggiornare le seguenti configurazioni VirtualService:

    • L'utilizzo di appendHeaders non è supportato. Usa invece il criterio spec.http.headers.
    • L'utilizzo di websocketUpgrade non è necessario. L'opzione è attiva per impostazione predefinita.
    • Sostituisci il campo abort.percent con abort.percentage.

  • È stata rilevata un'installazione personalizzata di risorse del mixer che non è stato possibile di cui è stata eseguita la migrazione. Richiede la migrazione manuale a telemetryv2. Se mixer personalizzato i criteri sono configurati in aggiunta Per l'installazione di Istio on GKE devi eseguire manualmente la migrazione ai criteri di telemetria v2. Per ulteriori informazioni su come fare, vedi Personalizzazione delle metriche Istio.

  • Deployment <deploymentName> potrebbe essere un gateway personalizzato. Esegui la migrazione manualmente. Devi eseguire manualmente la migrazione di tutti i deployment del gateway diversi da istio-ingressgateway (installato per impostazione predefinita). Per informazioni su come eseguire l'upgrade dei gateway per il piano di controllo gestito da Google, consulta Configurazione del piano di controllo gestito da Google.

Per eseguire la migrazione delle configurazioni, segui questi passaggi:

  1. Esegui la migrazione manuale di tutte le configurazioni personalizzate (tranne l'ultima configurazione) elencato) prima di andare al passaggio 2.

  2. Utilizza lo strumento di migrazione per eseguire la migrazione delle configurazioni che possono essere eseguite automaticamente (o ignorate).

    ${WORKDIR}/migrate_addon -d tmpdir --command migrate-configs

    L'output è simile al seguente:

    Converting authentication CRs...
2021/06/25 20:44:58 found root namespace: istio-system
2021/06/25 20:44:59 SUCCESS converting policy /default
Running: kubectl apply --dry-run=client -f beta-policy.yaml
peerauthentication.security.istio.io/default created (dry run)

Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y
Running: kubectl apply -f beta-policy.yaml
peerauthentication.security.istio.io/default created
OK

  3. Applica il trust radice dell'autorità di certificazione Cloud Service Mesh. In questo modo puoi eseguire la migrazione dall'attuale CA Citadel all'autorità di certificazione Cloud Service Mesh senza tempi di riposo delle tue applicazioni.

    ${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-ca

    L'output è simile al seguente:

    Configuring Istio on GKE to trust Anthos Service Mesh... Continue? [Y/n] Y
Running: kubectl get cm -n istio-system istio-asm-managed -oyaml
Running: kubectl -n istio-system apply -f -
secret/meshca-root created
Running: kubectl get cm istio -n istio-system -o yaml
Running: kubectl get cm istio -n istio-system -o yaml
Running: kubectl replace -f -
configmap/istio replaced
Running: kubectl get deploy istio-pilot -n istio-system -o yaml
Running: kubectl patch deploy istio-pilot -n istio-system -p={"spec":{"template":{"spec":{"containers":[{
    "name":"discovery",
    "image":"gcr.io/gke-release/istio/pilot:1.4.10-gke.12",
    "env":[{"name":"PILOT_SKIP_VALIDATE_TRUST_DOMAIN","value":"true"}]
  }]}}}}
deployment.apps/istio-pilot patched
Running: kubectl get deploy istio-citadel -n istio-system -o yaml
Running: kubectl patch deploy istio-citadel -n istio-system -p={"spec":{"template":{"spec":{
    "containers":[{
      "name":"citadel",
      "args": ["--append-dns-names=true", "--grpc-port=8060", "--citadel-storage-namespace=istio-system", "--custom-dns-names=istio-pilot-service-account.istio-system:istio-pilot.istio-system", "--monitoring-port=15014", "--self-signed-ca=true", "--workload-cert-ttl=2160h", "--root-cert=/var/run/root-certs/meshca-root.pem"],
      "volumeMounts": [{"mountPath": "/var/run/root-certs", "name": "meshca-root", "readOnly": true}]
    }],
    "volumes": [{"name": "meshca-root", "secret":{"secretName": "meshca-root"}}]
  }}}}
deployment.apps/istio-citadel patched
OK

Waiting for root certificate to distribute to all pods. This will take a few minutes...
ASM root certificate not distributed to asm-system, trying again later
ASM root certificate not distributed to asm-system, trying again later
ASM root certificate distributed to namespace asm-system
ASM root certificate distributed to namespace default
ASM root certificate distributed to namespace istio-operator
ASM root certificate not distributed to istio-system, trying again later
ASM root certificate not distributed to istio-system, trying again later
ASM root certificate distributed to namespace istio-system
ASM root certificate distributed to namespace kube-node-lease
ASM root certificate distributed to namespace kube-public
ASM root certificate distributed to namespace kube-system
ASM root certificate distributed to namespace online-boutique
Waiting for proxies to pick up the new root certificate...
OK

Configuring Istio Addon 1.6 to trust Anthos Service Mesh...
Running: kubectl get cm -n istio-system env-asm-managed -ojsonpath={.data.TRUST_DOMAIN} --ignore-not-found
Running: kubectl get cm istio-istio-1611 -n istio-system -o yaml
Running: kubectl replace -f -
configmap/istio-istio-1611 replaced
Running: kubectl patch -n istio-system istiooperators.install.istio.io istio-1-6-11-gke-0 --type=merge
istiooperator.install.istio.io/istio-1-6-11-gke-0 patched
Running: kubectl -n istio-system get secret istio-ca-secret -ojsonpath={.data.ca-cert\.pem}
Running: kubectl -n istio-system patch secret istio-ca-secret
secret/istio-ca-secret patched
Running: kubectl patch deploy istiod-istio-1611 -n istio-system
deployment.apps/istiod-istio-1611 patched
Running: kubectl rollout status -w deployment/istiod-istio-1611 -n istio-system
Waiting for deployment "istiod-istio-1611" rollout to finish: 1 old replicas are pending termination...
deployment "istiod-istio-1611" successfully rolled out
Running: kubectl apply -f - -n istio-system
envoyfilter.networking.istio.io/trigger-root-cert created
Waiting for proxies to pick up the new root certificate...
Running: kubectl delete envoyfilter trigger-root-cert -n istio-system
OK

    Questo passaggio richiede alcuni minuti per la distribuzione del certificato radice di Cloud Service Mesh a tutti gli spazi dei nomi. Attendi il termine dello script con un OK messaggio.

Il passaggio precedente esegue quanto segue:

  • Installa l'autorità di certificazione root of trust di Cloud Service Mesh per tutti i carichi di lavoro nel cluster.

  • Modifica le configurazioni dei deployment del piano di controllo istio-pilot, istiod e istio-citadel. Le modifiche includono quanto segue:

    • È in corso l'upgrade delle immagini alle build più recenti.
    • Disattivare la verifica di trust-domain impostando PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true.
    • Aggiunta della radice di attendibilità dell'autorità di certificazione Cloud Service Mesh a istio-citadel per la distribuzione ConfigMap a tutti gli spazi dei nomi.
    • Aggiunta dell'autorità di certificazione radice di Cloud Service Mesh a istio-ca-secret per distribuire il certificato radice.

  • Memorizza i manifest di configurazione precedenti in tmpdir.

  • Fornisce i passaggi per la funzione di rollback (documentata di seguito).

Migrazione dei carichi di lavoro in Cloud Service Mesh

In questa sezione esegui la migrazione dei carichi di lavoro in esecuzione su Istio on GKE a Cloud Service Mesh. Dopo la migrazione, verificherai che il file collaterale corretto (Cloud Service Mesh) vengono inseriti in ogni pod e che l'applicazione funziona come previsto.

Se stai eseguendo questa procedura su un cluster esistente, seleziona uno spazio dei nomi di cui eseguire la migrazione.

  1. Definisci lo spazio dei nomi come variabile. viene eseguita la migrazione di questo spazio dei nomi Cloud Service Mesh:

    export NAMESPACE=NAMESPACE_NAME

  2. Per eseguire la migrazione dei carichi di lavoro a Cloud Service Mesh, devi rinominare il nome del nominato per Cloud Service Mesh. L'etichettatura dello spazio dei nomi consente a Cloud Service Mesh per inserire automaticamente i file collaterali in tutti i carichi di lavoro. Per etichettare lo spazio dei nomi, Esegui questo comando, impostando l'etichetta su asm-managed:

    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite

  3. Esegui un riavvio graduale di tutti i deployment nello spazio dei nomi:

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}

    L'output è simile al seguente:

    deployment.apps/deploymentName1 restarted
deployment.apps/deploymentName2 restarted
...

  4. Assicurati che tutti i pod vengano riavviati e siano in esecuzione con due container per Pod:

    kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods

    L'output è simile al seguente:

    NAME                        READY   STATUS    RESTARTS   AGE
deploymentName1-PodName     2/2     Running   0          101s
deploymentName2-PodName     2/2     Running   2          100s
...

    Un buon modo per verificare questo passaggio è esaminare il AGE dei pod. Ensure che il valore sia breve, ad esempio qualche minuto.

  5. Controlla la versione del proxy Envoy del file collaterale da uno qualsiasi dei pod di qualsiasi Esegui il deployment nello spazio dei nomi per verificare che sia stato eseguito il deployment dei proxy Envoy di Cloud Service Mesh:

    export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'

    L'output è simile al seguente:

    "gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3"
"appContainerImage"

  6. Verifica e testa le applicazioni dopo il riavvio.

    kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

  7. (Facoltativo) Se vuoi che Google gestisca gli upgrade dei proxy, attiva il piano dati gestito da Google

Visualizza stato migrazione

Esegui questo comando per visualizzare lo stato della migrazione:

kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}

L'output indica se le migrazioni sono complete, in attesa o non riuscite:

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Se migrationStatus restituisce SUCCESS, l'upgrade del piano di controllo a Cloud Service Mesh è andato a buon fine. Per aggiornare manualmente il piano dati, completa i passaggi descritti in Eseguire la migrazione dei carichi di lavoro.

Se migrationStatus restituisce uno stato diverso da SUCCESS, puoi scegliere tra:

  • Non intraprendere alcuna azione aggiuntiva se l'errore di migrazione non interessa la tua organizzazione Istio per i carichi di lavoro GKE. Altrimenti, esegui il rollback, se necessario.
  • Aggiornare le configurazioni personalizzate nel cluster ed eseguire di nuovo la migrazione manualmente se viene visualizzato migrationStatus MIGRATION_CONFIG_ERROR.

Puoi visualizzare le metriche del piano di controllo in Metrics Explorer dopo la riuscita della migrazione. Consulta verify_control_plane_metrics

Accedere alle dashboard di Cloud Service Mesh

In questa sezione, vai alle dashboard di Cloud Service Mesh e assicurati di ricevere gli indicatori ideali per tutti i servizi. Dovresti anche essere in grado di visualizzare la topologia dell'applicazione.

  1. Nella console Google Cloud, vai alla pagina Cloud Service Mesh.

    Vai a Cloud Service Mesh

  2. Dovresti essere in grado di visualizzare le metriche e la topologia dei tuoi servizi.

Per saperne di più sulle dashboard di Cloud Service Mesh, consulta Esplorazione di Cloud Service Mesh nella console Google Cloud.

Completare una migrazione riuscita

In questa sezione finalizzi la migrazione di Istio on GKE a Cloud Service Mesh. Prima di procedere con questa sezione, assicurati di voler procedere con Cloud Service Mesh. Questa sezione ti aiuta anche a eliminare gli elementi di Istio su GKE. Se vuoi eseguire il rollback a Istio su GKE, vai alla sezione successiva.

  1. Sostituisci istio-ingressgateway (parte della configurazione standard Istio su GKE) con il controllo delle versioni del piano di controllo gestito da Google gateway:

    ${WORKDIR}/migrate_addon -d tmpdir --command replace-gateway

    L'output è simile al seguente:

    Replacing the ingress gateway with an Anthos Service Mesh gateway... Continue? [Y/n] Y
Running: kubectl label namespace istio-system istio-injection- istio.io/rev- --overwrite
label "istio.io/rev" not found.
namespace/istio-system labeled
Running: kubectl apply -f -
serviceaccount/asm-ingressgateway created
deployment.apps/asm-ingressgateway created
role.rbac.authorization.k8s.io/asm-ingressgateway created
rolebinding.rbac.authorization.k8s.io/asm-ingressgateway created
Running: kubectl wait --for=condition=available --timeout=600s deployment/asm-ingressgateway -n istio-system
deployment.apps/asm-ingressgateway condition met

Scaling the Istio ingress gateway to zero replicas... Continue? [Y/n] Y
Running: kubectl -n istio-system patch hpa istio-ingressgateway --patch {"spec":{"minReplicas":1}}
horizontalpodautoscaler.autoscaling/istio-ingressgateway patched (no change)
Running: kubectl -n istio-system scale deployment istio-ingressgateway --replicas=0
deployment.apps/istio-ingressgateway scaled
OK

  2. Riconfigura il webhook in modo che utilizzi il piano di controllo gestito da Google. Tutti i carichi di lavoro iniziano utilizzando il piano di controllo gestito da Google:

    ${WORKDIR}/migrate_addon -d tmpdir --command replace-webhook

    L'output è simile al seguente:

    Configuring sidecar injection to use Anthos Service Mesh by default... Continue? [Y/n] Y
Running: kubectl patch mutatingwebhookconfigurations istio-sidecar-injector --type=json -p=[{"op": "replace", "path": "/webhooks"}]
mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector patched
Revision tag "default" created, referencing control plane revision "asm-managed". To enable injection using this
revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=default'
OK

  3. Rinomina tutti gli spazi dei nomi con l'etichetta Cloud Service Mesh ed esegui un riavvio graduale di tutti i carichi di lavoro per inserirli nel piano di controllo gestito da Google:

    export NAMESPACE=NAMESPACE_NAME \
    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE}
    istio.io/rev=asm-managed istio-injection- --overwrite`

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
${NAMESPACE}

    Puoi ignorare il messaggio "istio-injection not found" nel come output. Ciò significa che in precedenza lo spazio dei nomi non aveva Etichetta istio-injection, prevista nelle nuove di Cloud Service Mesh o di nuovi deployment. Poiché l'inserimento automatico non riesce se uno spazio dei nomi contiene sia istio-injection sia dell'etichetta di revisione, tutti i comandi kubectl label nella La documentazione di Istio su GKE include la rimozione Etichetta istio-injection.

  4. Finalizza la migrazione eseguendo questo comando:

    ${WORKDIR}/migrate_addon -d tmpdir --command write-marker

    L'output è simile al seguente:

    Current migration state: SUCCESS
Running: kubectl apply -f -
configmap/asm-addon-migration-state created
OK

  5. Disabilita Istio su GKE eseguendo il seguente comando:

    Cluster di zona

    gcloud beta container clusters update ${CLUSTER_1} \
    --project=$PROJECT_ID \
    --zone=${CLUSTER_1_LOCATION} \
    --update-addons=Istio=DISABLED

    Cluster a livello di regione

    gcloud beta container clusters update ${CLUSTER_1} \
    --project=$PROJECT_ID \
    --region=${CLUSTER_1_LOCATION} \
    --update-addons=Istio=DISABLED

  6. Ripulisci le configurazioni eseguendo il seguente comando:

    ${WORKDIR}/migrate_addon -d tmpdir --command cleanup

    L'output è simile al seguente:

    Cleaning up old resources...
Running: kubectl get cm -n istio-system asm-addon-migration-state -ojsonpath={.data.migrationStatus}
Will delete IstioOperator/istio-1-6-11-gke-0.istio-system
Will delete ServiceAccount/istio-citadel-service-account.istio-system
...
Will delete DestinationRule/istio-policy.istio-system
Will delete DestinationRule/istio-telemetry.istio-system
Will delete Secret/istio-ca-secret.istio-system

Deleting resources previously listed... Continue? [Y/n] Y
Running: kubectl delete IstioOperator istio-1-6-11-gke-0 -n istio-system --ignore-not-found
istiooperator.install.istio.io "istio-1-6-11-gke-0" deleted
Running: kubectl delete ServiceAccount istio-citadel-service-account -n istio-system --ignore-not-found
serviceaccount "istio-citadel-service-account" deleted-ingressgateway -n istio-system --ignore-not-found
...
Running: kubectl delete Secret istio-ca-secret -n istio-system --ignore-not-found
secret "istio-ca-secret" deleted
Running: kubectl delete -n istio-system jobs -lk8s-app=istio,app=security
job.batch "istio-security-post-install-1.4.10-gke.8" deleted

  7. Assicurati che i deployment e i servizi Istio su GKE siano stati rimossi correttamente dal cluster:

    kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,services

    L'output è simile al seguente:

    NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/asm-ingressgateway   1/1     1            1           10m

NAME                           TYPE           CLUSTER-IP    EXTERNAL-IP      AGE   PORT(S)
service/istio-ingressgateway   LoadBalancer   10.64.5.208   34.139.100.237   95m   15020:31959/TCP,80:30971/TCP,443:31688/TCP,31400:31664/TCP,15029:32493/TCP,15030:31722/TCP,15031:30198/TCP,15032:31910/TCP,15443:31222/TCP

    Vedrai solo il servizio e il deployment del gateway di ingresso Cloud Service Mesh.

Complimenti. Hai eseguito correttamente la migrazione da Istio su GKE in Cloud Service Mesh con il piano di controllo gestito da Google Autorità di certificazione Cloud Service Mesh senza tempi di inattività per le applicazioni.

Esegui il rollback delle modifiche

In questa sezione, se non vuoi procedere con Cloud Service Mesh, puoi eseguire il rollback delle modifiche apportate a Cloud Service Mesh. Dopo aver completato questa sezione, i carichi di lavoro tornano a Istio su GKE.

  1. Esegui il rollback delle modifiche al webhook mutante: 

    ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook

  2. Rinomina i namespace per utilizzare l'iniezione di sidecar Istio su GKE invece di Cloud Service Mesh eseguendo il seguente comando:

    per gli spazi dei nomi con carichi di lavoro versione 1.4: 

    export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite

    per gli spazi dei nomi con carichi di lavoro versione 1.6: 

    export NAMESPACE=NAMESPACE_NAME
kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite

  3. Esegui un riavvio in sequenza di tutti i deployment nello spazio dei nomi:

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}

  4. Attendi qualche minuto e assicurati che tutti i pod siano in esecuzione:

    kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods

    L'output è simile al seguente:

    NAME                       READY   STATUS    RESTARTS   AGE
deploymentName1-PodName    2/2     Running   0          101s
deploymentName2-PodName    2/2     Running   2          100s
...

  5. Verifica la versione del proxy Envoy del file collaterale da uno qualsiasi dei pod per confermare per il deployment dei proxy Envoy su GKE v1.4:

    export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'

    L'output è simile al seguente:

    "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
"appContainerImage"

    o

    "gke.gcr.io/istio/proxyv2:1.6.14-gke.4"
"appContainerImage"

  6. Verifica e testa le applicazioni dopo il riavvio.

  7. Esegui il rollback delle modifiche dell'autorità di certificazione Cloud Service Mesh:

    ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca

  8. Riattiva l'webhook Istio Galley:

    ${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook

Hai eseguito il rollback delle modifiche a Istio su GKE.

Deployment di Boutique online

In questa sezione esegui il deployment nel cluster GKE di un'applicazione di microservizi di esempio denominata Online Boutique. È stato eseguito il deployment di Online Boutique in uno spazio dei nomi abilitato per Istio. Verifica che l'applicazione funzioni e che Istio su GKE iniezioni i proxy sidecar in ogni pod.

Se disponi già di cluster con applicazioni, puoi saltare la creazione un nuovo spazio dei nomi e l'implementazione di Online Boutique. Puoi seguire la stessa procedura per tutti gli spazi dei nomi Sezione Migrazione dei carichi di lavoro in Cloud Service Mesh.

  1. Esegui il deployment di Online Boutique nel cluster GKE:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
online-boutique

kubectl --context=${CLUSTER_1_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_1_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_1_CTX} -n online-boutique apply -f online-boutique

  2. Attendi che tutti i deployment siano pronti:

    kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

  3. Assicurati che ci siano due container per pod: il container dell'applicazione e il proxy sidecar Istio che Istio su GKE esegue automaticamente esegue l'injection nel pod:

    kubectl --context=${CLUSTER_1_CTX} -n online-boutique get pods

    L'output è simile al seguente:

    NAME                                     READY   STATUS    RESTARTS   AGE
adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s

  4. Puoi anche controllare la versione del proxy Envoy sidecar da uno dei pod per verificare di aver eseguito il deployment dei proxy Envoy di Istio su GKE v1.4:

    export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_1_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_1_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

    L'output è simile al seguente:

    "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

  5. Accedi all'applicazione passando all'indirizzo IP del istio-ingressgateway Indirizzo IP del servizio:

    kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Domande frequenti

Questa sezione descrive le domande frequenti e le risposte correlate su la migrazione da Istio su GKE a Cloud Service Mesh.

Perché sto eseguendo la migrazione da Istio su GKE a Cloud Service Mesh?

Istio su Google Kubernetes Engine è una funzionalità beta che esegue il deployment di Istio gestiti da Google nel cluster Google Kubernetes Engine (GKE). Istio on GKE esegue il deployment di una versione non supportata (Istio 1.4). Per fornirti le funzionalità di service mesh più recenti e un'implementazione di service mesh supportata, stiamo eseguendo l'upgrade di tutti gli utenti di Istio su GKE a Cloud Service Mesh.

Cloud Service Mesh è il prodotto mesh di servizi gestito e supportato da Google basate sulle API Istio. Cloud Service Mesh è per Istio, ciò che GKE è Kubernetes. Poiché Cloud Service Mesh si basa sulle API Istio, puoi continuerà a utilizzare le configurazioni Istio durante la migrazione Cloud Service Mesh. Inoltre, non ci sono vincoli al fornitore proprietario.

Cloud Service Mesh offre i seguenti vantaggi:

  • Un mesh di servizi gestito e supportato da Google.
  • API Istio senza vincoli al fornitore.
  • Dashboard di telemetria e gestione degli SLO pronti all'uso senza dover gestire ulteriori soluzioni di terze parti.
  • Opzioni di autorità di certificazione ospitate da Google.
  • Integrazione con il networking Google Cloud e Identity-Aware Proxy (IAP).
  • Supporto di piattaforme ibride e multi-cloud.

Per scoprire di più sulle funzionalità e sulle capacità di Cloud Service Mesh, consulta Funzionalità supportate del control plane gestito da Google.

Sono previsti tempi di inattività associati a questa migrazione?

Lo script di migrazione è progettato per evitare tempi di inattività. Lo script viene installato Cloud Service Mesh come piano di controllo canary insieme al piano di controllo Istio esistente. Viene eseguito l'upgrade di istio-ingressgateway in loco. Quindi etichetti nuovamente gli spazi dei nomi abilitati per Istio per iniziare utilizzando Cloud Service Mesh con l'autorità di certificazione Cloud Service Mesh.

Assicurati di avere PodDisruptionBudgets configurato correttamente per le applicazioni, in modo da con i tempi di inattività delle applicazioni. Anche se è possibile evitare tempi di inattività, se la migrazione viene eseguita autonomamente, ti consigliamo di eseguirla durante un periodo di manutenzione pianificata. Le migrazioni guidate da Google eseguita durante un Periodo di manutenzione di GKE. Assicurati che nei cluster GKE siano configurati periodi di manutenzione.

L'utilizzo di Cloud Service Mesh comporta dei costi?

Esistono due modi per utilizzare Cloud Service Mesh su GKE:

Esistono funzionalità o configurazioni non supportate nell'ultima versione di Cloud Service Mesh?

Lo script controlla tutte le configurazioni di Istio ed esegue la migrazione alla versione più recente di Cloud Service Mesh. Esistono alcune configurazioni che potrebbero richiedere passaggi aggiuntivi per la migrazione da Istio versione 1.4 a Cloud Service Mesh Versione 1.10. Lo script esegue un controllo di configurazione e ti informa se alcune configurazioni richiedono passaggi aggiuntivi.

La migrazione modifica le mie attuali configurazioni di Istio?

No, le configurazioni di Istio funzionano su Cloud Service Mesh senza richiedere modifiche.

Dopo la migrazione a Cloud Service Mesh, posso eseguire la migrazione inversa a Istio?

Sì, non è previsto alcun impegno a utilizzare Cloud Service Mesh. Puoi disinstallare Cloud Service Mesh e reinstallare Istio in qualsiasi momento.

Se la migrazione non riesce, è possibile eseguire il rollback?

Sì, lo script ti consente di eseguire il rollback al precedente Istio su GKE completamente gestita.

Quale versione di Istio posso eseguire la migrazione utilizzando questo script?

Lo script ti assiste nella migrazione da Istio su GKE versione 1.4 a Cloud Service Mesh versione 1.10. Lo script convalida la versione di Istio durante la fase di pre-migrazione e ti informa se la tua versione di Istio può eseguire la migrazione.

Come posso ricevere ulteriore assistenza per questa migrazione?

Il nostro team di assistenza è felice di aiutarti. Puoi aprire una richiesta di assistenza dalla console Google Cloud. Per saperne di più, vedi Gestione delle richieste di assistenza.

Che cosa succede se non eseguo la migrazione a Cloud Service Mesh?

I componenti Istio continuano a funzionare, ma Google non gestisce più il tuo Istio dell'installazione. Non ricevi più aggiornamenti automatici e l'installazione viene il suo funzionamento durante l'aggiornamento della versione del cluster Kubernetes.

Per ulteriori informazioni, vedi Assistenza di Istio.