Downgrade di Anthos Service Mesh su GKE

Questa guida spiega come eseguire il downgrade di Anthos Service Mesh da 1.5.10 a 1.4.10 su Google Kubernetes Engine.

Attenzione: Il downgrade è un'azione di disturbo sul tuo cluster e devi pianificarla di conseguenza.

Il deployment dei componenti del piano di controllo di Anthos Service Mesh richiede circa 5-10 minuti. Inoltre, devi inserire nuovi proxy sidecar in tutti i tuoi carichi di lavoro in modo che vengano aggiornati all'attuale versione di Anthos Service Mesh. Il tempo necessario per aggiornare i proxy sidecar dipende da molti fattori, come il numero di pod e di nodi, le impostazioni di scalabilità del deployment, i budget per l'interruzione dei pod e altre impostazioni di configurazione. Una stima approssimativa del tempo necessario per aggiornare i proxy sidecar è di 100 pod al minuto.

Panoramica del downgrade

Questa sezione illustra i passaggi da seguire per eseguire il downgrade di Anthos Service Mesh.

1. Consulta le funzionalità supportate e questa guida per acquisire familiarità con le funzionalità e la procedura di downgrade.

2. Se hai abilitato funzionalità facoltative quando hai installato la versione precedente di Anthos Service Mesh, devi abilitare le stesse funzionalità quando esegui il downgrade. Puoi abilitare le funzionalità facoltative aggiungendo i flag --set values o specificando il flag -f con un file YAML quando esegui il comando istioctl apply.

   Attenzione: l'omissione dei flag --set values o del flag -f con il file YAML comporta l'avvenuta installazione. Tuttavia, ha una configurazione diversa da quella prevista perché i valori omessi vengono reimpostati sui valori predefiniti quando viene eseguito nuovamente il deployment di Anthos Service Mesh. Devi utilizzare gli stessi flag quando esegui istioctl apply per eseguire il downgrade a 1.5.10.

   Se esegui il downgrade da Anthos Service Mesh 1.5.10 a 1.4.10 e hai abilitato funzionalità facoltative in un file YAML, devi convertire il codice YAML dall'API IstioOperator all'API IstioControlPlane.

3. Se esegui il downgrade a 1.4.10 su un cluster privato, devi aggiungere una regola firewall per aprire la porta 9443 se vuoi utilizzare l'inserimento automatico di sidecar. Se non aggiungi la regola firewall e l'inserimento automatico di sidecar è abilitato, ricevi un errore quando esegui il deployment dei carichi di lavoro. Per maggiori dettagli sull'aggiunta di una regola firewall, consulta Aggiunta di regole firewall per casi d'uso specifici.

4. Programma un tempo di riposo. Il downgrade può richiedere fino a un'ora, a seconda della scala del cluster. Tieni presente che non è incluso il tempo necessario per rieseguire il deployment dei carichi di lavoro per aggiornare i proxy sidecar.

Impostazione delle impostazioni predefinite per progetti e cluster

1. Ottieni l'ID del progetto in cui è stato creato il cluster:

   gcloud

   gcloud projects list

   Console

   1. Nella console Google Cloud, vai alla pagina Dashboard:

      Vai alla pagina Dashboard

   2. Fai clic sull'elenco a discesa Seleziona da nella parte superiore della pagina. Nella finestra Seleziona da visualizzata, seleziona il tuo progetto. L'ID progetto viene visualizzato nella scheda Informazioni sul progetto della dashboard del progetto.

2. Crea una variabile di ambiente per l'ID progetto:

   export PROJECT_ID=YOUR_PROJECT_ID

3. Imposta l'ID progetto predefinito per Google Cloud CLI:

   gcloud config set project ${PROJECT_ID}
   

4. Crea le seguenti variabili di ambiente:

   • Imposta il nome del cluster:

     export CLUSTER_NAME=YOUR_CLUSTER_NAME

   • Imposta CLUSTER_LOCATION sulla zona o sulla regione del cluster:

     export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

5. Imposta la zona o la regione predefinita per Google Cloud CLI.

   • Se hai un cluster a zona singola, imposta la zona predefinita:

     gcloud config set compute/zone ${CLUSTER_LOCATION}

   • Se hai un cluster a livello di regione, imposta la regione predefinita:

     gcloud config set compute/region ${CLUSTER_LOCATION}

Impostazione di credenziali e autorizzazioni

1. Ottieni le credenziali di autenticazione per interagire con il cluster:

   gcloud container clusters get-credentials ${CLUSTER_NAME}

2. Concedi all'utente corrente le autorizzazioni di amministratore del cluster. Devi disporre delle seguenti autorizzazioni per creare le regole di controllo dell'accesso basato sui ruoli (RBAC) necessarie per Anthos Service Mesh:

   kubectl create clusterrolebinding cluster-admin-binding \
     --clusterrole=cluster-admin \
     --user="$(gcloud config get-value core/account)"

   Se viene visualizzato l'errore "cluster-admin-binding" already exists, puoi tranquillamente ignorarlo e continuare con l'associazione cluster-admin-binding esistente.

Download del file di installazione in corso...

Linux

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro attuale:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz

Scarica il file della firma e utilizza openssl per verificare la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz.1.sig
openssl dgst -verify - -signature istio-1.4.10-asm.18-linux.tar.gz.1.sig istio-1.4.10-asm.18-linux.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

L'output previsto è: Verified OK

Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.4.10-asm.18-linux.tar.gz

Il comando crea una directory di installazione nella directory di lavoro attuale denominata istio-1.4.10-asm.18 che contiene:

• Applicazioni di esempio in samples
• I seguenti strumenti nella directory bin:
  • istioctl: utilizzi istioctl per installare Anthos Service Mesh.
  • asmctl: utilizzi asmctl per convalidare la configurazione di sicurezza dopo l'installazione di Anthos Service Mesh. (Attualmente, asmctl non è supportato su GKE su VMware).

Mac OS

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro attuale:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz

Scarica il file della firma e utilizza openssl per verificare la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.4.10-asm.18-osx.tar.gz.1.sig istio-1.4.10-asm.18-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

L'output previsto è: Verified OK

Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.4.10-asm.18-osx.tar.gz

Il comando crea una directory di installazione nella directory di lavoro attuale denominata istio-1.4.10-asm.18 che contiene:

• Applicazioni di esempio in samples
• I seguenti strumenti nella directory bin:
  • istioctl: utilizzi istioctl per installare Anthos Service Mesh.
  • asmctl: utilizzi asmctl per convalidare la configurazione di sicurezza dopo l'installazione di Anthos Service Mesh. (Attualmente, asmctl non è supportato su GKE su VMware).

Windows

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro attuale:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip

Scarica il file della firma e utilizza openssl per verificare la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip.1.sig
openssl dgst -verify - -signature istio-1.4.10-asm.18-win.zip.1.sig istio-1.4.10-asm.18-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

L'output previsto è: Verified OK

Estrai i contenuti del file in qualsiasi posizione nel file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf istio-1.4.10-asm.18-win.zip

Il comando crea una directory di installazione nella directory di lavoro attuale denominata istio-1.4.10-asm.18 che contiene:

• Applicazioni di esempio in samples
• I seguenti strumenti nella directory bin:
  • istioctl: utilizzi istioctl per installare Anthos Service Mesh.
  • asmctl: utilizzi asmctl per convalidare la configurazione di sicurezza dopo l'installazione di Anthos Service Mesh. (Attualmente, asmctl non è supportato su GKE su VMware).

1. Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh.

   cd istio-1.4.10-asm.18

2. Per praticità, aggiungi gli strumenti nella directory /bin al tuo PERCORSO:

   export PATH=$PWD/bin:$PATH

Preparazione dei file di configurazione delle risorse

Quando esegui il istioctl apply command per eseguire il downgrade di Anthos Service Mesh, devi specificare -f istio-operator.yaml nella riga di comando. Questo file contiene informazioni sul progetto e sul cluster necessarie per abilitare le funzionalità di sicurezza mesh e di telemetria mesh. Devi scaricare i file di configurazione istio-operator.yaml e di altre risorse e impostare le informazioni sul progetto e sul cluster.

Per preparare i file di configurazione delle risorse:

1. Se non l'hai ancora fatto, installa kpt:

   gcloud components install kpt
   

2. Facoltativamente, crea una nuova directory per i file di configurazione delle risorse del pacchetto Anthos Service Mesh. Se prevedi di configurare più cluster, potresti voler utilizzare il nome del cluster come nome della directory.

3. Passa alla directory in cui vuoi scaricare il pacchetto Anthos Service Mesh.

4. Scarica il pacchetto Anthos Service Mesh nella directory di lavoro attuale:

   kpt pkg get \
   https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.4-asm .
   

5. Imposta il nome del cluster:

     kpt cfg set asm cluster-name ${CLUSTER_NAME}

6. Facoltativamente, personalizza i file di configurazione delle risorse utilizzando i setter di kpt. Per impostazione predefinita, questi setter utilizzano i valori predefiniti per gcloud config. Se imposti i valori predefiniti di gcloud config o se vuoi modificare i valori, esegui i seguenti setter:

   • Imposta l'ID progetto:

     kpt cfg set asm gcloud.core.project ${PROJECT_ID}

   • Imposta la zona o la regione predefinita:

     kpt cfg set asm gcloud.compute.zone ${CLUSTER_LOCATION}

7. Facoltativamente, puoi registrare i file di configurazione delle risorse nel tuo sistema di controllo del codice sorgente, ad esempio Cloud Source Repositories, in modo da poter tenere traccia delle modifiche ai file.

Downgrade di Anthos Service Mesh

Questa sezione spiega come eseguire il downgrade di Anthos Service Mesh e attivare:

• Le funzionalità predefinite supportate elencate nella pagina Funzionalità supportate.
• Autorità di certificazione Anthos Service Mesh (Mesh CA).
• La pipeline di dati di telemetria su cui si basano le dashboard di Anthos Service Mesh nella console Google Cloud.

Per informazioni sull'abilitazione delle funzionalità facoltative supportate, consulta Attivazione delle funzionalità facoltative.

Per installare Anthos Service Mesh:

Scegli uno dei seguenti comandi per configurare Anthos Service Mesh in modalità di autenticazione PERMISSIVE mTLS (mutual TLS) o STRICT in modalità mTLS.

mTLS PERMISSIVO

istioctl manifest apply --set profile=asm \
  -f asm/cluster/istio-operator.yaml

Attenzione: in modalità PERMISSIVE, i tuoi servizi possono accettare sia il traffico di testo normale sia il traffico TLS reciproco contemporaneamente e inviare il traffico intra-mesh di testo non crittografato per impostazione predefinita. Per proteggere il tuo mesh di servizi dopo il downgrade, esegui la migrazione dei servizi alla modalità TLS reciproca STRICT, come descritto in Migrazione TLS reciproca.

mTLS STRETTA

istioctl manifest apply --set profile=asm \
  -f asm/cluster/istio-operator.yaml \
  --set values.global.mtls.enabled=true

Controlla i componenti del piano di controllo

Il downgrade richiede la reinstallazione dei componenti del piano di controllo, il cui completamento richiede circa 5-10 minuti. I vecchi componenti del piano di controllo vengono terminati e poi eliminati man mano che vengono installati i nuovi componenti. Puoi verificare l'avanzamento osservando il valore nella colonna AGE dei carichi di lavoro.

kubectl get pod -n istio-system

Output di esempio:

NAME                                     READY   STATUS        RESTARTS   AGE
istio-galley-76d684bf9-jwz65             2/2     Running       0          5m36s
istio-ingressgateway-5bfdf7c586-v6wxx    2/2     Terminating   0          25m
istio-ingressgateway-7b598c5557-b88md    2/2     Running       0          5m44s
istio-nodeagent-bnjg7                    1/1     Running       0          5m16s
istio-nodeagent-cps2j                    1/1     Running       0          5m10s
istio-nodeagent-f4x46                    1/1     Running       0          5m26s
istio-nodeagent-jbl5x                    1/1     Running       0          5m38s
istio-pilot-5dc4bc4dbf-ds5dh             2/2     Running       0          5m30s
istio-pilot-74665549c5-7r6qh             2/2     Terminating   0          25m
istio-sidecar-injector-7ddff4b99-b76l7   1/1     Running       0          5m36s
promsd-6d4d5b7c5c-dgnd7                  2/2     Running       0          5m30s

In questo esempio sono presenti due istanze di istio-ingressgateway e istio-pilot. È in corso l'arresto delle istanze con 25m nella colonna AGE. Tutti gli altri componenti sono stati installati di recente.

Convalida dell'installazione in corso...

Beta

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Ti consigliamo di utilizzare lo strumento di analisi asmctl per convalidare la configurazione di base del progetto, del cluster e dei carichi di lavoro. Se un test asmctl non va a buon fine, asmctl consiglia le soluzioni, se possibile. Il comando asmctl validate esegue test di base che verificano:

1. Che le API richieste da Anthos Service Mesh siano abilitate nel progetto.
2. Che Istio-Ingressgateway sia configurato correttamente per le chiamate alla CA mesh.
3. Stato generale di Istiod e Istio-Ingressgateway.

Se esegui il comando asmctl validate con il flag facoltativo --with-testing-workloads, oltre ai test di base, asmctl esegue test di sicurezza che controllano:

1. La comunicazione TLS reciproca (mTLS) sia configurata correttamente.
2. Mesh CA può emettere certificati.

Per eseguire i test di sicurezza, asmctl esegue il deployment dei carichi di lavoro sul tuo cluster in uno spazio dei nomi di test, esegue i test di comunicazione mTLS, restituisce i risultati ed elimina lo spazio dei nomi di test.

Per eseguire asmctl:

1. Assicurati che le credenziali gcloud application-default siano impostate:

    gcloud auth application-default login
   

2. Se non l'hai ancora fatto, ottieni credenziali di autenticazione per interagire con il cluster:

    gcloud container clusters get-credentials ${CLUSTER_NAME}
   

3. Per eseguire sia il test di base che quello di sicurezza (supponendo che istio-1.4.10-asm.18/bin) sia nel tuo PATH:

   asmctl validate --with-testing-workloads
   

   In caso di esito positivo, il comando risponde con un output simile al seguente:

   Using Kubernetes context: meshci145g-20200219_us-central1-a_meshci145g
   To change the context, use the --context flag
   Validating enabled APIs
   OK
   Validating Node-Agent configuration
   OK
   Validating Istio system
   OK
   Validating issued certs
   OK
   Validating sample traffic
   Launching example services...
   Sent traffic to example service http code: 200
   verified mTLS configuration
   OK

Aggiornamento dei proxy sidecar

Tutti i carichi di lavoro in esecuzione sul tuo cluster prima del downgrade di Anthos Service Mesh devono avere inserito o aggiornato il proxy sidecar in modo che abbia la versione attuale di Anthos Service Mesh.

Attenzione: a meno che tu non abbia configurato un bilanciatore del carico o un router per i deployment blu/verde, assicurati di testare il riavvio dei pod in un ambiente gestione temporanea per verificare che i servizi siano in grado di gestire eventuali interruzioni del traffico.

Con l'inserimento automatico dei file collaterali, puoi aggiornare i file collaterali per i pod esistenti con il riavvio dei pod. La modalità di riavvio dei pod dipende dal fatto che siano stati creati nell'ambito di un deployment.

1. Se hai utilizzato un deployment, riavvialo, in modo da riavviare tutti i pod con i file collaterali:

   kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE

   Se non hai utilizzato un deployment, elimina i pod, che vengono ricreati automaticamente con i file collaterali:

   kubectl delete pod -n YOUR_NAMESPACE --all

2. Verifica che tutti i pod nello spazio dei nomi abbiano dei sidecar inseriti:

   kubectl get pod -n YOUR_NAMESPACE --all

   Nel seguente esempio di output del comando precedente, puoi notare che la colonna READY indica che esistono due container per ciascuno dei tuoi carichi di lavoro: il container principale e il container per il proxy sidecar.

   NAME                    READY   STATUS    RESTARTS   AGE
   YOUR_WORKLOAD           2/2     Running   0          20s
   ...