Migrazione da Istio su GKE ad Anthos 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) alla gestione di Anthos Service Mesh con il piano di controllo gestito da Google e l'autorità di certificazione Anthos Service Mesh (Mesh CA).
Prerequisiti
Per completare questa guida sono necessari i seguenti prerequisiti:
Un cluster GKE con Istio su GKE abilitato. Se hai più cluster GKE, segui gli stessi passaggi per tutti i cluster.
Istio su GKE deve essere in 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 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 documentate in Configurazione del progetto.
Questa guida è stata testata su Cloud Shell, quindi ti consigliamo di utilizzare Cloud Shell per eseguire i passaggi descritti in questa guida.
Obiettivi
- Esegui il deployment del piano di controllo gestito da Google di Anthos Service Mesh nel canale normale. Questa guida è specifica per il canale normale e i canali stabili o rapidi richiedono istruzioni leggermente modificate. Per ulteriori informazioni sui canali di rilascio, visita questo link.
- Esegui la migrazione delle configurazioni di Istio ad Anthos Service Mesh.
- Configura Mesh CA.
- Esegui la migrazione delle applicazioni ad Anthos Service Mesh.
- Esegui l'upgrade di
istio-ingressgateway
da Istio su GKE ad Anthos Service Mesh. - Finalizza la migrazione di Anthos Service Mesh o esegui il rollback a Istio su GKE.
Configura l'ambiente
Per configurare l'ambiente, segui questi passaggi:
Nella console Google Cloud, attiva Cloud Shell.
Nella parte inferiore della pagina della console Google Cloud, viene avviata una sessione Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI e Google Cloud CLI già installati e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.
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.
Crea una cartella
WORKDIR
. Tutti i file associati a questa guida finiranno inWORKDIR
, così potrai eliminareWORKDIR
al termine.mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
Crea un file
KUBECONFIG
per questa guida. Puoi anche utilizzare il tuo fileKUBECONFIG
esistente che contiene il contesto del cluster GKE di cui eseguire la migrazione ad Anthos Service Mesh.touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
Ottieni le credenziali per il cluster GKE e archivia 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}
I cluster devono essere registrati in un parco risorse. Questo passaggio può essere eseguito separatamente prima dell'installazione oppure nell'ambito dell'installazione, passando il --fleet-id e uno dei flag --enable-all o --enable-registration.
Nel progetto deve essere abilitata la funzionalità Mesh di servizi. Puoi abilitarlo come parte dell'installazione passando uno dei flag --enable-all o --enable-registration o eseguendo il seguente 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 è cluster privato (con master-authorized-networks
abilitato),
aggiungi $SHELL_IP
alla lista consentita di master-authorized-networks
.
Se hai già accesso al 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
Installazione di Anthos Service Mesh
In questa sezione eseguirai il deployment di Anthos Service Mesh con il piano di controllo del canale normale gestito da Google sul cluster GKE. Il deployment di questo piano di controllo viene inizialmente eseguito insieme a un secondo piano di controllo (o canary).
Scarica la versione più recente dello script che installa Anthos Service Mesh nella directory di lavoro attuale e rendi eseguibile lo script:
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli chmod +x asmcli
Per configurare il cluster GKE, esegui lo script di installazione per installare Anthos Service Mesh con il piano di controllo del canale regolare 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.
Copia
istioctl
nella cartellaWORKDIR
:cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
Nella sezione successiva scaricherai ed eseguirai lo script migrate_addon
per facilitare la migrazione ad Anthos Service Mesh. L'utilità a riga di comando istioctl
deve trovarsi nella stessa cartella dello script migrate_addon
. Utilizza la cartella WORKDIR
sia per l'utilità da riga di comando istioctl
sia per lo script migrate_addon
.
Esegui la migrazione delle configurazioni ad Anthos Service Mesh
In questa sezione, eseguirai la migrazione di Istio sulle configurazioni GKE ad Anthos Service Mesh. Lo script guidato identifica le configurazioni di cui è possibile o meno eseguire la migrazione.
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
Disattiva il webhook di convalida della galleria. Questo passaggio è necessario per eseguire la migrazione di alcune configurazioni 1.4 ad Anthos 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
Verifica ed esegui la migrazione manuale della configurazione. Questo passaggio consente di identificare alcune delle configurazioni di cui è necessario eseguire 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 la migrazione manuale delle configurazioni personalizzate prima di eseguire la migrazione ad Anthos Service Mesh. Lo script precedente identifica le configurazioni personalizzate e stampa le informazioni sui requisiti. Queste personalizzazioni sono le seguenti:
I filtri envoy personalizzati rilevati non sono supportati da Anthos Service Mesh. Se possibile, rimuovili. I filtri Envoy non sono attualmente supportati nel piano di controllo gestito da Google.
Certificato plug-in personalizzato rilevato. Non verrà eseguita la migrazione dei certificati dei plug-in ad Anthos Service Mesh. Se vengono utilizzati i certificati dei plug-in con Istio su GKE, questi 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 da Google Mesh CA. I certificati dei plug-in non sono supportati da Mesh CA. Questo messaggio è informativo e non è richiesta alcuna azione da parte tua.
Sono stati rilevati criteri di sicurezza di cui non è stato possibile eseguire la migrazione. <Motivo dell'errore>. In genere questa operazione non riesce a causa di criteri di autorizzazione alpha che devono essere migrati manualmente. Per ulteriori informazioni e informazioni su come eseguire la migrazione dei criteri, consulta Eseguire la migrazione dei criteri di sicurezza pre-Istio 1.4 Alpha alle API attuali. Per ulteriori informazioni sul messaggio di errore, consulta security-policy-migrate.
Rilevata configurazione VirtualService potenzialmente incompatibile. <Configurazione deprecata specifica>. Devi aggiornare le seguenti
VirtualService
configurazioni:- L'utilizzo di
appendHeaders
non è supportato. Usa invece il criteriospec.http.headers
. - Non è necessario utilizzare
websocketUpgrade
. È attiva per impostazione predefinita. - Sostituisci il campo
abort.percent
conabort.percentage
.
- L'utilizzo di
È stata rilevata l'installazione personalizzata delle risorse mixer di cui non è stato possibile eseguire la migrazione. Richiede la migrazione manuale a Telemetryv2. Se i criteri del mixer personalizzati sono configurati oltre all'installazione predefinita di Istio su GKE, devi eseguire manualmente la migrazione di questi criteri alla telemetria v2. Per ulteriori informazioni su come eseguire questa operazione, consulta Personalizzazione delle metriche di Istio.
Il deployment <deploymentName> potrebbe essere un gateway personalizzato. Esegui la migrazione manuale. Devi eseguire manualmente la migrazione di tutti i deployment 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:
Esegui la migrazione manuale di tutte le configurazioni personalizzate (tranne l'ultima configurazione elencata) prima di procedere con il passaggio 2.
Utilizza lo strumento di migrazione per eseguire la migrazione delle configurazioni di cui è possibile eseguire la migrazione automatica (o di cui è possibile ignorare).
${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
Applica il trust root di Mesh CA. In questo modo puoi eseguire la migrazione dall'attuale Citadel CA a Mesh CA senza tempi di inattività per le 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 affinché il certificato radice di Anthos Service Mesh venga distribuito a tutti gli spazi dei nomi. Attendi il completamento dello script con un messaggio
OK
.
Il passaggio precedente svolge le seguenti operazioni:
- Installa la radice di attendibilità Mesh CA per tutti i carichi di lavoro nel cluster.
Modifica le configurazioni dei deployment del piano di controllo
istio-pilot
,istiod
eistio-citadel
. Le modifiche includono quanto segue:- Upgrade delle immagini alle build più recenti.
- Disattivo la verifica di
trust-domain
impostandoPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true
. - Aggiunta della radice di attendibilità CA mesh a
istio-citadel
per distribuireConfigMap
a tutti gli spazi dei nomi. - Aggiunta della radice di attendibilità CA Mesh a
istio-ca-secret
per distribuire il certificato radice.
Archivia i manifest di configurazione precedenti in
tmpdir
.Fornisce i passaggi per la funzione di rollback (documentati in seguito).
Migrazione dei carichi di lavoro in Anthos Service Mesh
In questa sezione eseguirai la migrazione ad Anthos Service Mesh dei carichi di lavoro in esecuzione su Istio su GKE. Dopo la migrazione, verificherai che i proxy sidecar (Anthos Service Mesh) corretti siano inseriti in ogni pod e che l'applicazione funzioni come previsto.
Se stai eseguendo questa procedura su un cluster esistente, seleziona uno spazio dei nomi di cui eseguire la migrazione.
Definisci lo spazio dei nomi come variabile; viene eseguita la migrazione di questo spazio dei nomi ad Anthos Service Mesh:
export NAMESPACE=NAMESPACE_NAME
Per eseguire la migrazione dei carichi di lavoro ad Anthos Service Mesh, devi rietichettare lo spazio dei nomi per Anthos Service Mesh. L'etichettatura dello spazio dei nomi consente ad Anthos Service Mesh di 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
Esegui un riavvio in sequenza 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 ...
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. Assicurati che il valore sia breve, ad esempio pochi minuti.Controlla la versione del proxy Envoy del file collaterale da uno qualsiasi dei pod di qualsiasi deployment nello spazio dei nomi per verificare che sia stato eseguito il deployment dei proxy Envoy di Anthos 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"
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}'
(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 completate, 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 ad Anthos Service Mesh è stato eseguito correttamente. Per aggiornare manualmente il piano dati, completa i passaggi descritti in Eseguire la migrazione dei carichi di lavoro.
Se migrationStatus
restituisce stati diversi da SUCCESS
, puoi scegliere di:
- Non intraprendere alcuna azione aggiuntiva se l'errore di migrazione non influisce sui carichi di lavoro Istio esistenti su GKE. In caso contrario, rollback, se necessario.
- Aggiorna le configurazioni personalizzate nel cluster ed esegui di nuovo la migrazione manualmente se
migrationStatus
mostraMIGRATION_CONFIG_ERROR
.
Puoi visualizzare le metriche del piano di controllo in Metrics Explorer dopo aver completato la migrazione. Consulta verify_control_plane_metrics
Accedi alle dashboard di Anthos Service Mesh
In questa sezione, vai alle dashboard di Anthos Service Mesh e assicurati di ricevere i segnali finali per tutti i servizi. Dovresti anche riuscire a vedere la topologia della tua applicazione.
Nella console Google Cloud, vai alla pagina Anthos Service Mesh.
Dovresti essere in grado di visualizzare le metriche e la topologia dei tuoi servizi.
Per scoprire di più sulle dashboard di Anthos Service Mesh, consulta Esplorazione di Anthos Service Mesh nella console Google Cloud.
Completare una migrazione
In questa sezione finalizzerai la migrazione di Istio su GKE alla migrazione ad Anthos Service Mesh. Prima di procedere con questa sezione, assicurati di voler procedere con Anthos Service Mesh. Questa sezione ti aiuta anche a ripulire gli artefatti Istio su GKE. Se vuoi eseguire il rollback a Istio su GKE, vai alla sezione successiva.
Sostituisci
istio-ingressgateway
(parte dell'Istio standard su GKE) con il gateway per il controllo delle versioni del piano di controllo gestito da Google:${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
Riconfigura il webhook per utilizzare il piano di controllo gestito da Google. Tutti i carichi di lavoro vengono avviati 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
Rietichetta tutti gli spazi dei nomi con l'etichetta Anthos Service Mesh ed esegui un riavvio in sequenza di tutti i carichi di lavoro per inserirli sul 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"
nell'output. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichettaistio-injection
, cosa che dovresti aspettarti nelle nuove installazioni di Anthos Service Mesh o nei nuovi deployment. Poiché l'inserimento automatica non riesce se uno spazio dei nomi contiene sia l'etichettaistio-injection
sia l'etichetta di revisione, tutti i comandikubectl label
nella documentazione di Istio su GKE includono la rimozione dell'etichettaistio-injection
.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
Disabilita Istio su GKE eseguendo questo 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
Esegui la pulizia delle configurazioni eseguendo questo 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
Assicurati che i deployment e i servizi Istio su GKE siano stati rimossi 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 in entrata Anthos Service Mesh.
Complimenti. Hai eseguito correttamente la migrazione da Istio su GKE ad Anthos Service Mesh con il piano di controllo e la CA mesh gestiti da Google, senza tempi di inattività per le tue applicazioni.
Esegui il rollback delle modifiche
In questa sezione, se non vuoi procedere con Anthos Service Mesh, puoi eseguire il rollback delle modifiche ad Anthos Service Mesh. Dopo aver completato questa sezione, i carichi di lavoro torneranno a Istio su GKE.
Esegui il rollback delle modifiche al webhook mutanti:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook
Rietichetta gli spazi dei nomi per utilizzare Istio sull'inserimento sidecar GKE anziché su Anthos Service Mesh eseguendo questo comando:
per gli spazi dei nomi con carichi di lavoro della 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 della versione 1.6:
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite
Esegui un riavvio in sequenza di tutti i deployment nello spazio dei nomi:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
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 ...
Verifica la versione del proxy Envoy del file collaterale da uno qualsiasi dei pod, per confermare che sia stato eseguito il deployment dei proxy Envoy di Istio 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"
Verifica e testa le applicazioni dopo il riavvio.
Esegui il rollback delle modifiche di Mesh CA:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
Riattiva il webhook Istio Galley:
${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook
Hai eseguito il rollback delle modifiche a Istio su GKE.
Implementa Boutique online
In questa sezione eseguirai il deployment nel cluster GKE di un'applicazione di esempio basata su microservizi, basata Online. Il deployment di Online Boutique viene eseguito in uno spazio dei nomi abilitato per Istio. Verifica che l'applicazione funzioni e che Istio su GKE inserisca i proxy sidecar in ogni pod.
Se hai già cluster con applicazioni, puoi saltare la creazione di un nuovo spazio dei nomi e il deployment di Online Boutique. Puoi seguire la stessa procedura per tutti gli spazi dei nomi nella sezione Migrazione dei carichi di lavoro ad Anthos Service Mesh.
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
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
Assicurati che ci siano due container per pod: il container dell'applicazione e il proxy sidecar Istio che Istio su GKE inserisce automaticamente 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
Puoi anche controllare la versione del proxy Envoy del file collaterale da uno qualsiasi dei pod per confermare che è stato 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"
Accedi all'applicazione passando all'indirizzo IP dell'indirizzo IP del servizio
istio-ingressgateway
: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 relative risposte sulla migrazione da Istio on GKE ad Anthos Service Mesh.
Perché viene eseguita la migrazione da Istio su GKE ad Anthos Service Mesh?
Istio su Google Kubernetes Engine è una funzionalità beta che esegue il deployment di Istio gestito da Google su un cluster Google Kubernetes Engine (GKE). Istio su GKE esegue il deployment di una versione non supportata (Istio versione 1.4). Per fornirti le funzionalità più recenti del mesh di servizi e un'implementazione supportata del mesh di servizi, stiamo eseguendo l'upgrade ad Anthos Service Mesh per tutti gli utenti di Istio su GKE.
Anthos Service Mesh è il prodotto mesh di servizi gestito e supportato da Google, basato sulle API Istio. Anthos Service Mesh è quello di Istio, che GKE è in Kubernetes. Poiché Anthos Service Mesh è basato sulle API Istio, puoi continuare a utilizzare le tue configurazioni Istio quando esegui la migrazione ad Anthos Service Mesh. Inoltre, non esistono vincoli al fornitore di proprietà.
Anthos Service Mesh offre i seguenti vantaggi:
- Un mesh di servizi gestito e supportato da Google.
- API Istio senza vincoli al fornitore.
- Dashboard di telemetria pronte all'uso e gestione degli SLO senza la necessità di gestire ulteriori soluzioni di terze parti.
- Opzioni dell'autorità di certificazione ospitata da Google.
- Integrazione con il networking di Google Cloud e Identity-Aware Proxy (IAP).
- Supporto di piattaforme ibride e multi-cloud.
Per saperne di più sulle funzionalità e sulle funzionalità di Anthos Service Mesh, consulta Funzionalità supportate dal piano di controllo gestito da Google.
Ci sono tempi di inattività associati a questa migrazione?
Lo script di migrazione è progettato per evitare tempi di inattività. Lo script installa Anthos Service Mesh come piano di controllo canary insieme al piano di controllo Istio esistente. Viene eseguito l'upgrade di istio-ingressgateway
. Quindi rietichetta gli spazi dei nomi abilitati per Istio per iniziare a utilizzare Anthos Service Mesh con l'autorità di certificazione Anthos Service Mesh (Mesh CA).
Assicurati di aver configurato correttamente PodDisruptionBudgets per le tue applicazioni in modo da non riscontrare tempi di inattività delle applicazioni. Anche se puoi evitare tempi di inattività, se esegui la migrazione in autonomia, ti consigliamo di eseguirla durante un periodo di manutenzione pianificato. Le migrazioni basate su Google vengono eseguite durante un periodo di manutenzione di GKE. Assicurati che nei tuoi cluster GKE siano configurati periodi di manutenzione.
È previsto un costo associato all'utilizzo di Anthos Service Mesh?
Esistono due modi per utilizzare Anthos Service Mesh su GKE:
Se hai un abbonamento a GKE Enterprise, Anthos Service Mesh è incluso nell'abbonamento a GKE Enterprise.
Se non sei un abbonato a GKE Enterprise, puoi utilizzare Anthos Service Mesh come prodotto autonomo su GKE (su Google Cloud). Per maggiori informazioni, consulta i dettagli dei prezzi di Anthos Service Mesh.
Esistono funzionalità o configurazioni non supportate nella versione più recente di Anthos Service Mesh?
Lo script controlla tutte le configurazioni Istio e ne esegue la migrazione all'ultima versione di Anthos Service Mesh. Esistono alcune configurazioni che potrebbero richiedere passaggi aggiuntivi per la migrazione da Istio versione 1.4 ad Anthos Service Mesh versione 1.10. Lo script esegue un controllo della configurazione e ti informa se eventuali configurazioni richiedono passaggi aggiuntivi.
La migrazione modifica le mie attuali configurazioni Istio?
No, le tue configurazioni Istio funzionano su Anthos Service Mesh senza richiedere alcuna modifica.
Dopo aver eseguito la migrazione ad Anthos Service Mesh, posso eseguire nuovamente la migrazione a Istio?
Sì, non è richiesto alcun impegno per l'utilizzo di Anthos Service Mesh. Puoi disinstallare Anthos Service Mesh e reinstallare Istio in qualsiasi momento.
Se la migrazione non va a buon fine, è possibile eseguire il rollback?
Sì, lo script consente di eseguire il rollback alla precedente versione di Istio su GKE.
Di quale versione di Istio posso eseguire la migrazione con questo script?
Lo script ti assiste nella migrazione da Istio su GKE versione 1.4 ad Anthos Service Mesh versione 1.10. Lo script convalida la versione Istio durante la fase di pre-migrazione e indica se è possibile eseguire la migrazione della versione Istio.
Come posso ricevere ulteriore assistenza per questa migrazione?
Il nostro team di assistenza è a tua disposizione. Puoi aprire una richiesta di assistenza dalla console Google Cloud. Per scoprire di più, consulta Gestire le richieste di assistenza.
Cosa succede se non eseguo la migrazione ad Anthos Service Mesh?
I componenti Istio continuano a funzionare, ma Google non gestisce più l'installazione di Istio. Non riceverai più aggiornamenti automatici e non è garantito che l'installazione funzioni come aggiornamenti della versione del cluster Kubernetes.
Per ulteriori informazioni, consulta l'assistenza di Istio.