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 su GKE abilitato. Se hai più cluster GKE, segui la stessa procedura per tutti i cluster.
Istio on GKE deve essere della 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 uno di questi di 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 Cloud Service Mesh gestito da Google nel canale normale. Questa guida è specifica per il canale regolare, mentre i canali stabile o rapido richiedono istruzioni leggermente modificate. Per scoprire di più sui canali di rilascio, visita questo link.
- Esegui la migrazione delle configurazioni di Istio a Cloud Service Mesh.
- Configura l'autorità di certificazione Cloud Service Mesh.
- Esegui la migrazione delle applicazioni a Cloud Service Mesh.
- Esegui l'upgrade di
istio-ingressgateway
da Istio on GKE a Cloud Service Mesh. - Finalizza la migrazione di Cloud Service Mesh o esegui il rollback a Istio su GKE.
Configura l'ambiente
Per configurare l'ambiente:
Nella console Google Cloud, attiva Cloud Shell.
Nella parte inferiore della pagina della console Google Cloud, viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell in cui sono già installati Google Cloud CLI e Google Cloud CLI e in cui sono già impostati i valori per il progetto corrente. 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 vengono inseriti inWORKDIR
, quindi puoi 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 fileKUBECONFIG
esistente contenente il contesto del cluster per il cluster GKE di cui vuoi eseguire la migrazione a Cloud Service Mesh.touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
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}
I cluster devono essere registrati a un parco risorse. Questo passaggio può essere eseguito separatamente prima dell'installazione o nell'ambito dell'installazione passando l'opzione --fleet-id e uno dei flag --enable-all o --enable-registration.
Nel progetto deve essere attivata la funzionalità Service Mesh. Puoi attivarla durante l'installazione passando uno dei flag --enable-all o --enable-registration oppure 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 è 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 zonali
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, esegui il deployment di Cloud Service Mesh con il piano di controllo gestito da Google del canale normale sul cluster GKE. Questo piano di controllo viene inizialmente implementato come secondo piano di controllo (o canary).
Scarica la versione più recente dello script che installa Cloud Service Mesh nella directory di lavoro corrente e rendilo eseguibile:
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 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.
Copia
istioctl
nella cartellaWORKDIR
: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
. Puoi utilizzare
WORKDIR
sia per l'utilità a riga di comando istioctl
sia per
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.
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 delle configurazioni 1.4 a Cloud Service Mesh. Rispondi
Y
a entrambe 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 di alcune configurazioni di cui è necessario eseguire la migrazione manuale prima 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
Potresti dover eseguire manualmente la migrazione delle configurazioni personalizzate prima di eseguire la migrazione a Cloud Service Mesh. Lo script precedente identifica le configurazioni personalizzate e stampa le informazioni su ciò che è richiesto. Queste personalizzazioni sono come segue:
I filtri Envoy personalizzati rilevati non sono supportati da Cloud Service Mesh. Rimuovile, se possibile. I filtri Envoy non sono attualmente supportati nel piano di controllo gestito da Google.
È stato rilevato un certificato plug-in personalizzato. I certificati del plug-in non saranno è stata migrata in Cloud Service Mesh. Se vengono utilizzati certificati dei plug-in 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 Google Cloud Service Mesh. I certificati dei plug-in non sono supportati dall'autorità di certificazione Cloud Service Mesh. Questo messaggio è puramente 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>. Solitamente questa operazione non riesce a causa di criteri alpha AuthZ che devono essere manualmente, Per ulteriori informazioni e contesto su come eseguire la migrazione dei criteri, consulta la pagina Eseguire la migrazione dei criteri di sicurezza precedenti a Istio 1.4 Alpha alle API attuali. Per ulteriori informazioni sul messaggio di errore, consulta security-policy-migrate.
È stata rilevata una configurazione VirtualService potenzialmente incompatibile. <specifico deprecata config>. Devi aggiornare i seguenti
VirtualService
configurazioni:- L'utilizzo di
appendHeaders
non è supportato. Usa invece il criteriospec.http.headers
. - L'utilizzo di
websocketUpgrade
non è necessario. Questa funzionalità è attiva per impostazione predefinita. - Sostituisci il campo
abort.percent
conabort.percentage
.
- L'utilizzo di
È 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 sono configurati criteri di mixer personalizzati oltre all'installazione predefinita di Istio su GKE, devi eseguire manualmente la migrazione di questi criteri alla telemetria v2. Per saperne di più su come eseguire questa operazione, consulta Personalizzazione delle metriche Istio.
Deployment <deploymentName> potrebbe essere un gateway personalizzato. Esegui migrazione manualmente. Devi eseguire manualmente la migrazione di tutti i deployment gateway rispetto a
istio-ingressgateway
(installato per impostazione predefinita). Per informazioni su come eseguire l'upgrade dei gateway per il piano di controllo gestito da Google, vedi Configurazione del piano di controllo gestito da Google.
Per eseguire la migrazione delle configurazioni:
Esegui la migrazione manuale di tutte le configurazioni personalizzate (tranne l'ultima configurazione) elencato) prima di andare al passaggio 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
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 la radice di attendibilità dell'autorità di certificazione Cloud Service Mesh per tutti i carichi di lavoro in in un cluster Kubernetes.
Modifica le configurazioni dei deployment del piano di controllo
istio-pilot
,istiod
eistio-citadel
. Le modifiche includono:- È in corso l'upgrade delle immagini alle build più recenti.
- Disattivare la verifica di
trust-domain
impostandoPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true
. - Aggiunta dell'autorità di certificazione radice di attendibilità di Cloud Service Mesh a
istio-citadel
per distribuireConfigMap
a tutti gli spazi dei nomi. - Aggiunta della radice di attendibilità dell'autorità di certificazione Cloud Service Mesh a
istio-ca-secret
per distribuire la radice certificato.
Archivia i manifest di configurazione precedenti in
tmpdir
.Fornisce i passaggi per la funzione di rollback (documentata di seguito).
Esegui la migrazione dei carichi di lavoro a Cloud Service Mesh
In questa sezione, eseguirai la migrazione a Cloud Service Mesh dei carichi di lavoro in esecuzione su Istio su GKE. 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.
Definisci lo spazio dei nomi come variabile. viene eseguita la migrazione di questo spazio dei nomi Cloud Service Mesh:
export NAMESPACE=NAMESPACE_NAME
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 di iniettare automaticamente i sidecar in tutti i carichi di lavoro. Per etichettare lo spazio dei nomi, esegui il seguente 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 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 ...
Assicurati che tutti i pod siano stati riavviati e siano in esecuzione con due contenitori 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 alcuni minuti.Controlla la versione del proxy Envoy sidecar da uno dei pod di qualsiasi deployment nel namespace per verificare di aver ora implementato i 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"
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
Visualizzare lo stato della migrazione
Esegui il seguente 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
in Migrazione dei carichi di lavoro.
Se migrationStatus
restituisce uno stato diverso da SUCCESS
, puoi scegliere di
in uno dei seguenti modi:
- 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 inoltre essere di vedere la topologia della tua applicazione.
Nella console Google Cloud, vai alla pagina Cloud Service Mesh.
Dovresti essere in grado di visualizzare le metriche e la topologia dei tuoi servizi.
Per scoprire 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 che che vuoi 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.
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
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
Rietichetta tutti gli spazi dei nomi con l'etichetta Cloud Service Mesh ed esegui una il riavvio in sequenza di tutti i carichi di lavoro per 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 in precedenza lo spazio dei nomi non aveva Etichettaistio-injection
, prevista nelle nuove di Cloud Service Mesh o di nuovi deployment. Poiché l'inserimento automatico non riesce se uno spazio dei nomi contiene siaistio-injection
sia dell'etichetta di revisione, tutti i comandikubectl label
nella La documentazione di Istio su GKE include la rimozione Etichettaistio-injection
.Per completare la migrazione, esegui il seguente 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 zonali
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
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
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
Vedi solo il servizio e il deployment del gateway in entrata di Cloud Service Mesh.
Complimenti. Hai eseguito la migrazione da Istio su GKE a Cloud Service Mesh con il piano di controllo gestito da Google e la certificazione dell'autorità Cloud Service Mesh senza tempi di riposo delle applicazioni.
Esegui il rollback delle modifiche
In questa sezione, se non vuoi procedere con Cloud Service Mesh, puoi eseguire il rollback delle modifiche di Cloud Service Mesh. Dopo aver completato questa sezione, i carichi di lavoro tornano a Istio su GKE.
Esegui il rollback delle modifiche al webhook mutante:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook
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 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 graduale 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 dei pod per confermare di aver eseguito il deployment dei proxy Envoy di Istio on GKE 1.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.
Ripristina le modifiche all'autorità di certificazione di Cloud Service Mesh:
${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.
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 nella sezione Eseguire la migrazione dei carichi di lavoro in Cloud 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 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
Puoi anche controllare la versione del proxy Envoy del file collaterale da uno qualsiasi dei Pod per confermare che hai Istio su proxy Envoy v1.4 di GKE di cui è stato eseguito il deployment:
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 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é viene eseguita la migrazione da Istio su GKE a Cloud Service Mesh?
Istio su Google Kubernetes Engine è una funzionalità beta che esegue il deployment di Istio gestito da Google in un 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 di service mesh gestito e supportato di Google basato sulle API Istio. Cloud Service Mesh è per Istio ciò che GKE è per 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 esiste alcun vincolo 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 dell'autorità di certificazione ospitata da Google.
- Integrazione con il networking Google Cloud e Identity-Aware Proxy (IAP).
- Supporto di piattaforme ibride e multi-cloud.
Per saperne di più sulle caratteristiche e funzionalità di Cloud Service Mesh, consulta Funzionalità supportate dal piano di controllo gestito da Google.
Sono presenti 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 configurato correttamente i PodDisruptionBudget per le tue applicazioni in modo da evitare tempi di inattività. Anche se puoi evitare i tempi di riposo, se stai eseguendo la migrazione autonomamente, ti consigliamo di eseguirla durante una finestra 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:
Se hai un abbonamento a GKE Enterprise, Cloud Service Mesh è incluso come parte del tuo abbonamento a GKE Enterprise.
Se non hai un abbonamento a GKE Enterprise, puoi utilizzare Cloud Service Mesh come prodotto autonomo su GKE (su Google Cloud). Per ulteriori informazioni, vedi Dettagli dei prezzi di Cloud Service Mesh.
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 della configurazione e ti informa se sono presenti di configurazione richiedono passaggi aggiuntivi.
La migrazione cambia le mie configurazioni Istio attuali?
No, le configurazioni Istio funzionano su Cloud Service Mesh senza richiedere alcuna modifiche.
Dopo la migrazione a Cloud Service Mesh, posso eseguire la migrazione inversa a Istio?
Sì, non è previsto alcun impegno per l'utilizzo di Cloud Service Mesh. Puoi disinstallare Cloud Service Mesh e reinstalla 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 è possibile eseguire la migrazione della versione di Istio.
Come posso ricevere ulteriore assistenza per questa migrazione?
Il nostro team di assistenza sarà 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ù la tua installazione di Istio. Non ricevi più aggiornamenti automatici e l'installazione viene il suo funzionamento durante l'aggiornamento della versione del cluster Kubernetes.
Per ulteriori informazioni, consulta Assistenza Istio.