Questa guida spiega come eseguire l'upgrade di Anthos Service Mesh dalla versione 1.4.5+ alla versione 1.4.10 su Google Kubernetes Engine. Se vuoi eseguire l'upgrade ad Anthos Service Mesh 1.5, consulta la versione 1.5 dell'articolo Upgrade di Anthos Service Mesh su GKE.
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.
Preparazione per l'upgrade
Questa sezione illustra i passaggi da seguire per eseguire l'upgrade di Anthos Service Mesh.
Consulta le funzionalità supportate e questa guida all'upgrade per acquisire familiarità con le funzionalità e il processo di upgrade.
Esamina i tuoi criteri di autorizzazione per vedere se devono essere aggiornati.
Se hai attivato le funzionalità facoltative quando hai installato la versione precedente di Anthos Service Mesh aggiungendo i flag
--set values
alla riga di comandoistioctl apply
, dovrai utilizzare gli stessi flag quando eseguiistioctl apply
per eseguire l'upgrade a 1.4.10.Se hai abilitato le funzionalità facoltative quando hai installato la versione precedente di Anthos Service Mesh aggiungendo il flag
-f
alla riga di comandoistioctl apply
per specificare un file YAML, devi specificare lo stesso file (o un file con gli stessi contenuti) quando eseguiistioctl apply
per eseguire l'upgrade a 1.4.10.Programma un tempo di riposo. L'upgrade 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
Ottieni l'ID del progetto in cui è stato creato il cluster:
gcloud
gcloud projects list
Console
Nella console Google Cloud, vai alla pagina Dashboard:
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.
Crea una variabile di ambiente per l'ID progetto:
export PROJECT_ID=
YOUR_PROJECT_ID
Crea una variabile di ambiente per il numero di progetto:
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
Imposta l'ID progetto predefinito per Google Cloud CLI:
gcloud config set project ${PROJECT_ID}
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
Imposta il pool di carichi di lavoro.
export WORKLOAD_POOL=${PROJECT_ID}.svc.id.goog
Imposta l'ID mesh.
export MESH_ID="proj-${PROJECT_NUMBER}"
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
-
Ottieni le
credenziali di autenticazione per interagire con il cluster:
gcloud container clusters get-credentials ${CLUSTER_NAME}
-
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...
-
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
-
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
-
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-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
: utilizziistioctl
per installare Anthos Service Mesh.asmctl
: utilizziasmctl
per convalidare la configurazione di sicurezza dopo l'installazione di Anthos Service Mesh. (Attualmente,asmctl
non è supportato su GKE su VMware).
- Applicazioni di esempio in
-
Assicurati di essere nella directory principale dell'installazione di Anthos Service Mesh.
cd istio-1.4.10-asm.18
-
Per praticità, aggiungi gli strumenti nella directory
/bin
al tuo PERCORSO:export PATH=$PWD/bin:$PATH
Linux
Mac OS
Windows
Upgrade di Anthos Service Mesh
Questa sezione spiega come eseguire l'upgrade 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 basa la dashboard Anthos Service Mesh nella console Google Cloud.
Per informazioni sull'abilitazione delle funzionalità facoltative supportate, consulta Attivazione delle funzionalità facoltative.
Per eseguire l'upgrade di 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 \ --set values.global.trustDomain=${WORKLOAD_POOL} \ --set values.global.sds.token.aud=${WORKLOAD_POOL} \ --set values.nodeagent.env.GKE_CLUSTER_URL=https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${CLUSTER_LOCATION}/clusters/${CLUSTER_NAME} \ --set values.global.meshID=${MESH_ID} \ --set values.global.proxy.env.GCP_METADATA="${PROJECT_ID}|${PROJECT_NUMBER}|${CLUSTER_NAME}|${CLUSTER_LOCATION}"
mTLS STRETTA
istioctl manifest apply --set profile=asm \ --set values.global.trustDomain=${WORKLOAD_POOL} \ --set values.global.sds.token.aud=${WORKLOAD_POOL} \ --set values.nodeagent.env.GKE_CLUSTER_URL=https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${CLUSTER_LOCATION}/clusters/${CLUSTER_NAME} \ --set values.global.meshID=${MESH_ID} \ --set values.global.proxy.env.GCP_METADATA="${PROJECT_ID}|${PROJECT_NUMBER}|${CLUSTER_NAME}|${CLUSTER_LOCATION}" \ --set values.global.mtls.enabled=true
Controlla i componenti del piano di controllo
L'upgrade richiede la reinstallazione dei componenti del piano di controllo, che 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
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'upgrade in corso...
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:
- Che le API richieste da Anthos Service Mesh siano abilitate nel progetto.
- Che Istio-Ingressgateway sia configurato correttamente per le chiamate alla CA mesh.
- 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:
- La comunicazione TLS reciproca (mTLS) sia configurata correttamente.
- 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
:
Assicurati che le credenziali gcloud application-default siano impostate:
gcloud auth application-default login
Se non l'hai ancora fatto, ottieni credenziali di autenticazione per interagire con il cluster:
gcloud container clusters get-credentials ${CLUSTER_NAME}
Per eseguire sia il test di base che quello di sicurezza (supponendo che
istio-1.4.10-asm.18/bin
) sia nel tuoPATH
:asmctl validate --with-testing-workloads
In caso di esito positivo, il comando risponde con un output simile al seguente:
[asmctl version 0.3.0] Using Kubernetes context: example-project_us-central1-example-cluster To change the context, use the --context flag Validating enabled APIs OK Validating ingressgateway configuration OK Validating istio system OK Validating sample traffic Launching example services... Sent traffic to example service http code: 200 verified mTLS configuration OK Validating issued certs OK
Aggiornamento dei proxy sidecar
Tutti i carichi di lavoro in esecuzione sul tuo cluster prima dell'upgrade di Anthos Service Mesh devono avere inserito o aggiornato il proxy sidecar in modo che abbia la versione attuale di Anthos Service Mesh.
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.
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
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 ...
Aggiornamento dei criteri di autorizzazione
Se stai eseguendo l'upgrade da Istio 1.4.x open source o da una versione precedente di Anthos Service Mesh e hai criteri di autorizzazione esistenti, potresti doverli aggiornare. Per ulteriori informazioni, consulta Aggiornamento dei criteri di autorizzazione.