Stai visualizzando la documentazione di Service Mesh precedente alla versione 1.18.

Versioni disponibili

Cloud Service Mesh
Archivio 1.22
Archivio 1.21
Archivio 1.20
Archivio 1.19
Archivio 1.18

Questa pagina è stata tradotta dall'API Cloud Translation.

Migrazione a Mesh CA basata su canary

La migrazione all'autorità di certificazione (Mesh CA) di Cloud Service Mesh dall'autorità di certificazione Istio (nota anche come Citadel) richiede la migrazione del root of trust. Prima di Cloud Service Mesh 1.10, se volevi eseguire la migrazione da Istio su Google Kubernetes Engine (GKE) a Cloud Service Mesh con Mesh CA, dovevi pianificare il tempo di riposo perché Cloud Service Mesh non era in grado di caricare più certificati principali. Pertanto, durante la migrazione, i carichi di lavoro appena di cui è stato eseguito il deployment si basano sul nuovo certificato radice, mentre altri si basano sul vecchio certificato radice. I carichi di lavoro che utilizzano certificati firmati da certificati radice diversi non possono autenticarsi tra loro. Ciò significa che il traffico TLS (mTLS) reciproco viene interrotto durante la migrazione. L'intero cluster si riprende completamente solo quando il piano di controllo e tutti i carichi di lavoro in tutti gli spazi dei nomi vengono nuovamente implementati con il certificato dell'autorità di certificazione Mesh. Se il tuo mesh ha più cluster con workload che inviano richieste a workload su un altro cluster, devono essere aggiornati anche tutti i workload su questi cluster.

Segui i passaggi descritti in questa guida per i seguenti casi d'uso:

Esegui la migrazione da Istio on GKE al piano di controllo interno al cluster di Cloud Service Mesh 1.18.7-asm.26 con Mesh CA.
Esegui l'upgrade da Cloud Service Mesh 1.15 o una release di patch 1.16 con Istio CA al control plane in-cluster di Cloud Service Mesh 1.18.7-asm.26 con Mesh CA.

Limitazioni

Tutti i cluster GKE devono trovarsi nello stesso progetto Google Cloud.

Prerequisiti

Segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster per:

Strumenti richiesti

Durante la migrazione, esegui uno strumento fornito da Google, migrate_ca, per verificare quanto segue per ogni pod del cluster:

Il certificato radice per la CA Istio e la CA Mesh.
Il certificato mTLS del carico di lavoro emesso dalla CA Istio e dalla CA Mesh.
I domini attendibili configurati da Istio CA e Mesh CA.

Questo strumento ha le seguenti dipendenze:

awk
grep
istioctl L'esecuzione di asmcli install scarica la versione di istioctl corrispondente alla versione di Cloud Service Mesh che stai installando.
jq
kubectl
openssl

Panoramica della migrazione

Per eseguire la migrazione a Mesh CA, segui la procedura di migrazione in base alle revisioni (indicata anche come "upgrade canary"). Con una migrazione basata su revisioni, viene implementata una nuova revisione del piano di controllo insieme a quella esistente. Poi, muovi gradualmente i carichi di lavoro alla nuova revisione, in modo da monitorare l'effetto della migrazione durante la procedura. Durante la procedura di migrazione, l'autenticazione e l'autorizzazione sono completamente funzionali tra i carichi di lavoro che utilizzano la CA Mesh e i carichi di lavoro che utilizzano la CA Istio.

Di seguito è riportato uno schema della migrazione a Mesh CA:

Distribuisci la radice di attendibilità della CA Mesh.
1. Installa una nuova revisione del piano di controllo che utilizza la CA Istio con un'opzione che distribuirà la radice di attendibilità della CA Mesh.
2. Esegui la migrazione dei carichi di lavoro al nuovo piano di controllo, uno spazio dei nomi alla volta, e testa la tua applicazione. Una volta eseguita la migrazione di tutti i workload al nuovo piano di controllo, rimuovi il vecchio piano di controllo.
Esegui la migrazione a Mesh CA. Ora che tutti i proxy sidecar sono configurati con la vecchia radice di attendibilità e la radice di attendibilità della CA Mesh, puoi eseguire la migrazione alla CA Mesh senza tempi di riposo. Anche in questo caso, segui la procedura di migrazione basata sulle revisioni:
1. Installa una revisione del piano di controllo con Mesh CA abilitato.
2. Esegui la migrazione dei carichi di lavoro alla nuova revisione del piano di controllo, uno spazio dei nomi alla volta, e testa l'applicazione. Una volta eseguita la migrazione di tutti i workload al nuovo piano di controllo, rimuovi il vecchio piano di controllo.
3. Rimuovi i secret della CA nel cluster associati alla vecchia CA e riavvia il nuovo piano di controllo.

Distribuisci la radice di attendibilità della CA Mesh

Prima di poter eseguire la migrazione a Mesh CA, tutti i cluster GKE nel mesh devono avere Cloud Service Mesh 1.10 o versioni successive e tutti i cluster devono essere configurati con un'opzione di piano di controllo che attivi la radice di attendibilità per la distribuzione di Mesh CA ai proxy di tutti i carichi di lavoro sul cluster. Al termine del processo, ogni proxy è configurato sia con la vecchia sia con la nuova radice della attendibilità. Con questo schema, quando esegui la migrazione a Mesh CA, i carichi di lavoro che utilizzano Mesh CA potranno autenticarsi con i carichi di lavoro che utilizzano la vecchia CA.

Installa una nuova revisione del piano di controllo

Installa una revisione del piano di controllo con un'opzione che distribuisce la radice di attendibilità della CA Mesh.

Segui i passaggi descritti in Installare gli strumenti dipendenti e convalidare il cluster per prepararti a utilizzare uno strumento fornito da Google, asmcli, per installare la nuova revisione del piano di controllo.
Assicurati di avere la versione di asmcli che installa Cloud Service Mesh 1.11 o versioni successive:
```
./asmcli --version
```

Esegui asmcli install. Nel seguente comando, sostituisci i segnaposto con i tuoi valori.

 ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH \
   --option ca-migration-citadel \
   --revision_name REVISION_1 \
   --output_dir DIR_PATH

--fleet_id L'ID del progetto host del parco risorse.
--kubeconfig Il percorso del file kubeconfig Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona qui.
--output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, i sample e i manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona qui.
--enable_all Consente allo strumento di:
- Concedi le autorizzazioni IAM richieste.
- Abilita le API Google richieste.
- Imposta un'etichetta sul cluster che identifichi il mesh.
- Registra il cluster nel parco risorse, se non è già registrato.
-ca citadel Per evitare tempi di inattività, specifica la CA Istio (l'opzione citadel corrisponde alla CA Istio). A questo punto, non passare a Mesh CA.
--ca_cert Il certificato intermedio.
--ca_key La chiave per il certificato intermedio
--root_cert Il certificato radice.
--cert_chain La catena di certificati.
--option ca-migration-citadel Quando esegui il ricollocamento dei workload, questa opzione attiva la distribuzione della nuova radice di attendibilità ai proxy sidecar dei workload.
REVISION_1: consigliato. Un'etichetta di revisione è una coppia chiave-valore impostata sul piano di controllo. La chiave dell'etichetta di revisione è sempre istio.io/rev. Per impostazione predefinita, lo strumento imposta il valore per l'etichetta della revisione in base alla versione di Cloud Service Mesh, ad esempio:asm-1187-26. Ti consigliamo di includere questa opzione e di sostituire REVISION_1 con un nome che descriva l'installazione, ad esempio asm-1187-26-distribute-root. Il nome deve essere un'etichetta DNS-1035 e deve essere costituito da caratteri alfanumerici in minuscolo o -, deve iniziare con un carattere alfabetico e terminare con un carattere alfanumerico (ad esempio my-name o abc-123).

Esegui la migrazione dei carichi di lavoro al nuovo control plane

Per completare la distribuzione della nuova radice di attendibilità, devi etichettare i tuoi spazi dei nomi con l'etichetta di revisioneistio.io/rev=<var>REVISION_1</var>-distribute-root e riavviare i carichi di lavoro. Quando testi i carichi di lavoro dopo averli riavviati, esegui uno strumento per verificare che il proxy sidecar sia configurato sia con la vecchia sia con la nuova radice di attendibilità per la CA Mesh.

Imposta il contesto corrente per kubectl. Nel seguente comando, sostituisci --region con --zone se hai un cluster a zona singola.
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=CLUSTER_LOCATION
```

Scarica lo strumento di convalida:

curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca

Imposta il bit eseguibile sullo strumento:
```
chmod +x migrate_ca
```
Lo strumento migrate_ca chiama istioctl, che dipende dalla versione. Lo strumento asmcli aggiunge un link simbolico a istioctl nella directory specificata per --output_dir. Assicurati che la directory sia all'inizio del percorso. Nel comando seguente, sostituisci ISTIOCTL_PATH con la directory contenente istioctl scaricata dallo strumento.
```
export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH
```

Recupera l'etichetta di revisione su istiod e istio-ingressgateway.

kubectl get pod -n istio-system -L istio.io/rev

L'output è simile al seguente:

NAME                                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

Nell'output, nella colonna REV, prendi nota del valore dell'etichetta della revisione per la nuova revisione, che corrisponde all'etichetta della revisione specificata quando hai eseguito asmcli install. In questo esempio, il valore è asm-1187-26-distribute-root.
Devi eliminare la vecchia revisione di istiod al termine del trasferimento dei carichi di lavoro alla nuova revisione. Prendi nota del valore nell'etichetta della revisione per la revisione istiod precedente. L'output di esempio mostra una migrazione da Istio, che utilizza la revisione default.

Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta istio-injection (se esistente). Nel comando seguente, sostituisci NAMESPACE con lo spazio dei nomi da etichettare.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
```
Se nell'output viene visualizzato "istio-injection not found", puoi ignorarlo. Ciò significa che lo spazio dei nomi non aveva precedentemente l'etichettaistio-injection. Poiché il comportamento di inserimento automatico è undefined quando uno spazio dei nomi ha sia l'etichetta istio-injection sia l'etichetta revision, tutti i comandi kubectl label nella documentazione di Cloud Service Mesh garantiscono esplicitamente che ne sia impostato solo uno.

Riavvia i pod per attivare la re-iniezione.

kubectl rollout restart deployment -n NAMESPACE

Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
Verifica che i proxy sidecar per tutti i workload del cluster siano configurati sia con i certificati principali vecchi che con quelli nuovi:
```
./migrate_ca check-root-cert
```
Risultato previsto:
```
Namespace: foo
httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
```
Se devi eseguire la migrazione dei gateway, segui i passaggi descritti in Upgrade Canary (avanzato) per installare i nuovi deployment dei gateway. Tieni presente quanto segue:
- Utilizza REVISION_1 come etichetta di revisione.
- Esegui il deployment delle risorse del gateway nello stesso spazio dei nomi del gateway dell'installazione precedente per eseguire la migrazione senza tempi di riposo. Assicurati che le risorse di servizio che rimandano al gateway precedente includano ora anche le implementazioni più recenti.
- Non eliminare i deployment del gateway precedenti finché non avrai la certezza che la tua applicazione funzioni correttamente (dopo il passaggio successivo).
Se ritieni che la tua applicazione funzioni come previsto, continua con i passaggi per la transizione alla nuova versione di istiod. Se si verifica un problema con la tua applicazione, segui i passaggi per il rollback.
Completare la transizione
Se ritieni che la tua applicazione funzioni come previsto, rimuovi il vecchio piano di controllo per completare la transizione alla nuova versione.
1. Vai alla directory in cui si trovano i file del anthos-service-mesh repository GitHub.
2. Configura il webhook di convalida in modo che utilizzi il nuovo piano di controllo.
  kubectl apply -f asm/istio/istiod-service.yaml
3. Elimina il vecchio istio-ingressgatewaydeployment. Il comando eseguito dipende dal fatto che tu stia eseguendo la migrazione da Istio o l'upgrade da una versione precedente di Cloud Service Mesh:
  Esegui la migrazione
  Se hai eseguito la migrazione da Istio, il vecchio istio-ingressgateway non ha un'etichetta di revisione.
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  Esegui l'upgrade
  Se hai eseguito l'upgrade da una versione precedente di Cloud Service Mesh, nel comando seguente, sostituisci OLD_REVISION con l'etichetta di revisione per la versione precedente del istio-ingressgateway.
  
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
4. Elimina la vecchia revisione di istiod. Il comando che utilizzi dipende se esegui la migrazione da Istio o l'upgrade da una versione precedente di Cloud Service Mesh.
  Esegui la migrazione
  Se hai eseguito la migrazione da Istio, il vecchio istio-ingressgateway non ha un'etichetta di revisione.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Esegui l'upgrade
  Se hai eseguito l'upgrade da una versione precedente di Cloud Service Mesh, nel comando seguente assicurati che OLD_REVISION corrisponda all'etichetta di revisione della versione precedente di istiod.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
5. Rimuovi la versione precedente della configurazione IstioOperator.
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  L'output previsto è simile al seguente:
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Esegui il rollback
Se hai riscontrato un problema durante il test dell'applicazione con la nuova versione di istiod, segui questi passaggi per eseguire il rollback alla versione precedente:
1. Elimina i nuovi deployment del gateway installati nel passaggio 11.
2. Rinomina lo spazio dei nomi per attivare l'iniezione automatica con la versione precedente di istiod. Il comando che utilizzi dipende dal fatto che tu abbia usato un'etichetta di revisione o istio-injection=enabled con la versione precedente.
  - Se hai utilizzato un'etichetta di revisione per l'iniezione automatica:
    
    kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
  - Se hai utilizzato istio-injection=enabled:
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  Risultato previsto:
  namespace/NAMESPACE labeled
3. Verifica che l'etichetta di revisione nello spazio dei nomi corrisponda all'etichetta di revisione della versione precedente di istiod:
  kubectl get ns NAMESPACE --show-labels
4. Riavvia i pod per attivare la re-iniezione in modo che i proxy abbiano la versione precedente:
  kubectl rollout restart deployment -n NAMESPACE
5. Rimuovi il nuovo deployment istio-ingressgateway.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
6. Rimuovi la nuova revisione di istiod.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
7. Rimuovi la nuova configurazione di IstioOperator.
  kubectl delete IstioOperator installed-state-asm-1187-26-distribute-root -n istio-system
  L'output previsto è simile al seguente:
  istiooperator.install.istio.io "installed-state-asm-1187-26-distribute-root" deleted