Installazione di Anthos Service Mesh su GKE

Questa guida spiega come installare, migrare o eseguire l'upgrade ad Anthos Service Mesh versione 1.7.8 per un mesh contenente uno o più cluster GKE nello stesso progetto. Utilizza uno script fornito da Google che configura il progetto e il cluster, quindi installa Anthos Service Mesh.

Puoi utilizzare questa guida e lo script per i seguenti casi d'uso:

  • Nuove installazioni di Anthos Service Mesh.

  • Upgrade da Anthos Service Mesh 1.6 o una versione patch 1.7. Gli upgrade alle versioni precedenti non sono supportati.

  • Migrazione da Istio open source 1.6 o 1.7 ad Anthos Service Mesh. La migrazione da una versione precedente di Istio non è supportata.

  • Migrazione dalla versione 1.6 del componente aggiuntivo Istio su GKE ad Anthos Service Mesh. Prima di poter eseguire la migrazione ad Anthos Service Mesh, devi eseguire l'upgrade a Istio 1.6 con Operator. Per la procedura di migrazione completa dal componente aggiuntivo, consulta Migrazione ad Anthos Service Mesh nella documentazione di Istio su GKE.

Per un mesh multi-cluster in cui i cluster si trovano in progetti diversi, consulta Installazione e migrazione di più cluster/più progetti per GKE.

Prima di iniziare

Questa guida presuppone che tu disponga di:

Se esegui la migrazione da Istio, assicurati di consultare la sezione Preparazione per la migrazione da Istio.

Differenze tra Anthos e Anthos Service Mesh

  • Abbonati a GKE Enterprise, assicurati di abilitare l'API GKE Enterprise.

    Abilitare l'API

  • Se non hai un abbonamento a GKE Enterprise, puoi comunque installare Anthos Service Mesh, ma alcuni elementi dell'interfaccia utente e funzionalità della console Google Cloud sono disponibili solo per gli abbonati a GKE Enterprise. Per informazioni su cosa è disponibile per gli abbonati e i non abbonati, consulta le Differenze nell'interfaccia utente di GKE Enterprise e Anthos Service Mesh. Per informazioni sui prezzi di Anthos Service Mesh per i non abbonati, consulta i prezzi.

Lo script abilita tutte le altre API di Google richieste per te.

Requisiti

  • Il cluster GKE deve soddisfare i seguenti requisiti:

    • Un tipo di macchina con almeno quattro vCPU, ad esempio e2-standard-4. Se il tipo di macchina per il tuo cluster non ha almeno quattro vCPU, modifica il tipo di macchina come descritto in Migrazione dei carichi di lavoro a tipi di macchina diversi.

    • Il numero minimo di nodi dipende dal tipo di macchina. Anthos Service Mesh richiede almeno otto vCPU. Se il tipo di macchina ha quattro vCPU, il cluster deve avere almeno due nodi. Se il tipo di macchina ha 8 vCPU, il cluster ha bisogno di un solo nodo. Se devi aggiungere nodi, consulta Ridimensionamento di un cluster.

    • Lo script abilita Workload Identity sul tuo cluster. Workload Identity è il metodo consigliato per chiamare le API di Google. L'abilitazione di Workload Identity cambia il modo in cui vengono protette le chiamate dai carichi di lavoro alle API di Google, come descritto in Limitazioni di Workload Identity.

    • (Facoltativo ma consigliato) registra il cluster in un canale di rilascio. Ti consigliamo di registrarti al canale di rilascio regolare perché altri canali potrebbero essere basati su una versione di GKE non supportata con Anthos Service Mesh 1.7.8. Per ulteriori informazioni, consulta la sezione Ambienti supportati. Segui le istruzioni in Registrazione di un cluster esistente in un canale di rilascio se hai una versione di GKE statica.

  • Per essere incluse nel mesh di servizi, è necessario assegnare un nome alle porte di servizio e il nome deve includere il protocollo della porta con la seguente sintassi: name: protocol[-suffix] dove le parentesi quadre indicano un suffisso facoltativo che deve iniziare con un trattino. Per ulteriori informazioni, consulta Denominazione delle porte dei servizi.

  • Se stai installando Anthos Service Mesh su un cluster privato, devi aprire la porta 15017 nel firewall affinché il webhook utilizzato con l'inserimento collaterale automatico funzioni correttamente. Per maggiori informazioni, consulta Apertura di una porta su un cluster privato.

  • Se hai creato un perimetro di servizio nella tua organizzazione, potrebbe essere necessario aggiungere il servizio Mesh CA al perimetro. Per ulteriori informazioni, consulta Aggiunta di mesh CA a un perimetro di servizio.

  • Per le migrazioni, istiod deve essere installato nello spazio dei nomi istio-system, che in genere è il caso.

Limitazioni

A un progetto Google Cloud è possibile associare un solo mesh.

Scelta di un'autorità di certificazione

Sia per le nuove installazioni che per le migrazioni, puoi utilizzare l'autorità di certificazione Anthos Service Mesh (Mesh CA) o Citadel (ora incorporata in istiod) come autorità di certificazione (CA) per l'emissione di certificati mTLS (mutual TLS).

In genere consigliamo di utilizzare Mesh CA per i seguenti motivi:

  • Mesh CA è un servizio altamente affidabile e scalabile, ottimizzato per carichi di lavoro con scalabilità dinamica su Google Cloud.
  • Con Mesh CA, Google gestisce la sicurezza e la disponibilità del backend della CA.
  • Mesh CA consente di usare un'unica radice di attendibilità tra i cluster.
Per le nuove installazioni di Anthos Service Mesh, per impostazione predefinita, lo script abilita Mesh CA.

Tuttavia, in alcuni casi potresti prendere in considerazione l'utilizzo di Citadel, ad esempio:

  • Se hai una CA personalizzata,

  • Se esegui la migrazione da Istio.

    Se scegli Citadel, non ci sono tempi di inattività perché il traffico mTLS non viene interrotto durante la migrazione. Se scegli Mesh CA, devi pianificare il tempo di inattività per la migrazione perché la radice di attendibilità cambia da Citadel a Mesh CA. Per completare la migrazione alla radice di attendibilità della CA mesh, devi riavviare tutti i pod in tutti gli spazi dei nomi. Durante questo processo, i pod precedenti non possono stabilire connessioni mTLS con i nuovi pod.

I certificati di CA mesh includono i seguenti dati sui servizi dell'applicazione:

  • L'ID progetto Google Cloud
  • Lo spazio dei nomi GKE
  • Il nome dell'account di servizio GKE

Preparazione per una migrazione o un upgrade

Se esegui la migrazione da Istio, assicurati di consultare la sezione Preparazione per la migrazione da Istio.

Se hai personalizzato l'installazione precedente, devi avere le stesse personalizzazioni quando esegui la migrazione o l'upgrade ad Anthos Service Mesh. Se hai personalizzato l'installazione aggiungendo il flag --set values, ti consigliamo di aggiungere queste impostazioni a un file di configurazione IstioOperator. Puoi specificare il file di configurazione utilizzando --custom_overlay con il file di configurazione quando esegui lo script.

Installazione degli strumenti richiesti

Puoi eseguire lo script su Cloud Shell o sulla tua macchina locale su cui è in esecuzione Linux.

Per eseguire lo script localmente:

  1. Assicurati di aver installato i seguenti strumenti:

  2. Esegui l'autenticazione con gcloud CLI:

    gcloud auth login

  3. Aggiorna i componenti:

    gcloud components update

  4. Assicurati che git sia nel tuo percorso in modo che kpt possa trovarlo.

  5. Scarica la versione richiesta di kpt.

Esecuzione dello script

Questa sezione descrive come scaricare lo script, impostare i parametri obbligatori e facoltativi ed eseguire lo script. Per una spiegazione dettagliata di ciò che fa lo script, consulta Comprensione dello script.

  1. Scarica la versione dello script che installa Anthos Service Mesh 1.7.8 nella directory di lavoro corrente:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7 > install_asm

    Anche se scarichi lo script da un percorso sicuro di Cloud Source Repositories, lo script è disponibile anche su GitHub nel repository anthos-service-mesh-packages, così puoi vedere cosa fa prima di scaricarlo. La versione dello script install_asm nel ramo release-1.7-asm installa Anthos Service Mesh 1.7.8.

  2. Scarica l'algoritmo SHA-256 del file nella directory di lavoro corrente:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7.sha256 > install_asm.sha256

  3. Poiché entrambi i file si trovano nella stessa directory, verifica il download:

    sha256sum -c --ignore-missing install_asm.sha256

    Se la verifica ha esito positivo, il comando restituisce: install_asm: OK

    Per la compatibilità, il file install_asm.sha256 include il checksum due volte per consentire a qualsiasi versione dello script di essere rinominata in install_asm. Se viene visualizzato un errore che indica che --ignore-missing non esiste, esegui nuovamente il comando precedente senza il flag --ignore-missing.

  4. Rendi eseguibile lo script:

    chmod +x install_asm

  5. Imposta le opzioni e specifica i flag per eseguire lo script. Includi sempre le seguenti opzioni: project_id, cluster_name, cluster_location e mode. A seconda del mode, potrebbe essere necessario includere l'opzione ca.

    • Le opzioni project_id, cluster_name e cluster_location identificano il cluster su cui installare Anthos Service Mesh.
    • Il valore mode è install, migrate o upgrade.
    • Il parametro ca specifica l'autorità di certificazione come mesh_ca o citadel.

    La seguente sezione fornisce esempi tipici per l'esecuzione dello script. Per una descrizione completa degli argomenti dello script, consulta Opzioni e flag.

  6. Per completare la configurazione di Anthos Service Mesh, devi abilitare l'inserimento automatico di file collaterali e eseguire il deployment o rieseguire il deployment dei carichi di lavoro.

Esempi

Questa sezione mostra esempi di esecuzione dello script in ogni mode e alcuni argomenti aggiuntivi che potresti trovare utili. Guarda la barra di navigazione a destra per un elenco di esempi.

Solo convalida

L'esempio seguente mostra l'esecuzione dello script con l'opzione --only_validate. Con questa opzione, lo script non apporta modifiche al cluster e non installa Anthos Service Mesh. Lo script verifica che:

  • Il tuo ambiente dispone degli strumenti necessari.
  • Disponi dell'autorizzazione richiesta per il progetto specificato.
  • Il cluster soddisfa i requisiti minimi.
  • Nel progetto sono abilitate tutte le API di Google richieste.

Per impostazione predefinita, lo script scarica ed estrae il file di installazione e scarica il pacchetto di configurazione di asm da GitHub a una directory temporanea. Prima di uscire, lo script genera un messaggio che fornisce il nome della directory temporanea. Puoi specificare una directory esistente per i download con l'opzione --output_dir DIR_PATH. L'opzione --output_dir consente di utilizzare facilmente lo strumento a riga di comando istioctl in caso di necessità. Inoltre, i file di configurazione per abilitare funzionalità facoltative sono inclusi nella directory asm/istio/options.

Esegui questo comando per convalidare la configurazione e scaricare il file di installazione e il pacchetto asm nella directory OUTPUT_DIR:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --output_dir DIR_PATH \
  --only_validate

Se l'operazione riesce, lo script restituisce quanto segue:

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Se uno dei test non supera la convalida, lo script restituisce un messaggio di errore. Ad esempio, se nel progetto non sono abilitate tutte le API di Google richieste, viene visualizzato il seguente errore:

ERROR: One or more APIs are not enabled. Please enable them and retry, or
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

Installazione

Il comando seguente esegue lo script per una nuova installazione, abilita Mesh CA (la CA predefinita per le nuove installazioni, quindi in questo caso non è necessaria l'opzione ca) e consente allo script di abilitare le API di Google richieste.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis

Installazione con Citadel come CA

Questa sezione spiega come:

  • Genera certificati e chiavi che Anthos Service Mesh utilizza per firmare i tuoi carichi di lavoro.
  • Esegui lo script per un'installazione e abilita Citadel come CA.

Ti consigliamo di utilizzare Citadel come CA solo se ti occorre una CA personalizzata.

Per la massima sicurezza, consigliamo vivamente di mantenere una CA radice offline e di utilizzare le CA subordinate per emettere CA per ogni cluster. Per ulteriori informazioni, consulta la sezione Collegare i certificati CA. In questa configurazione, tutti i carichi di lavoro nel mesh di servizi utilizzano la stessa CA radice. Ogni CA di Anthos Service Mesh utilizza una chiave di firma e un certificato di una CA intermedia, firmata dalla CA radice. L'esistenza di più CA all'interno di un mesh consente di stabilire una gerarchia di attendibilità tra le CA. Puoi ripetere questi passaggi per eseguire il provisioning di certificati e chiavi per un numero qualsiasi di autorità di certificazione.

  1. Crea una directory per i certificati e le chiavi:

    mkdir -p certs && \
pushd certs

  2. Genera un certificato radice e una chiave:

    make -f ../tools/certs/Makefile.selfsigned.mk root-ca

    che genera i seguenti file:

    • root-cert.pem: il certificato radice
    • root-key.pem: la chiave radice
    • root-ca.conf: la configurazione diOpensl per generare il certificato radice
    • root-cert.csr: il CSR per il certificato radice

  3. Genera un certificato intermedio e una chiave:

    make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

    Questo genera i seguenti file in una directory denominata cluster1:

    • ca-cert.pem: i certificati intermedi
    • ca-key.pem: la chiave intermedia
    • cert-chain.pem: la catena di certificati utilizzata da istiod
    • root-cert.pem: il certificato radice

    Se esegui questa procedura utilizzando un computer offline, copia la directory generata sul computer su cui esegui lo script.

  4. Esegui lo script e includi i file generati in precedenza per i certificati e la chiave.

    ./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH \
  --enable_all

Installazione con un file di overlay

Un file di overlay è un file YAML contenente una risorsa (RP) IstioOperator personalizzata che passi a install_asm per configurare il piano di controllo. Puoi eseguire l'override della configurazione predefinita del piano di controllo e abilitare una funzionalità facoltativa passando il file YAML a install_asm. Puoi sovrapporre più overlay e ogni file di overlay sostituisce la configurazione dei livelli precedenti.

Se specifichi più di una RP in un file YAML, install_asm suddivide il file in più file YAML temporanei, uno per ogni RP. Lo script suddivide le risposte in file separati perché istioctl install applica solo la prima RP in un file YAML contenente più di una RP.

L'esempio seguente esegue un'installazione e include un file di overlay per personalizzare la configurazione del piano di controllo. Nel comando seguente, cambia OVERLAY_FILE nel nome del file YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --custom_overlay OVERLAY_FILE

Installazione con opzione

L'esempio seguente esegue un'installazione e include il file egressgateways.yaml del pacchetto asm, che consente un gateway in uscita. Tieni presente che non includi l'estensione .yaml. Lo script recupera automaticamente il file, così non devi prima scaricare il pacchetto asm.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --option egressgateways

Puoi utilizzare --option per abilitare una funzionalità facoltativa. Se devi apportare modifiche a uno dei file che si trova nella directory asm/istio/options del pacchetto asm, scarica il pacchetto asm, apporta le modifiche e includi il file utilizzando --custom_overlay.

Per scaricare il pacchetto asm nella directory di lavoro corrente in modo da poter apportare modifiche ai file:

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

Se hai eseguito l'esempio Solo convalida in cui hai specificato l'opzione --output_dir, i file di configurazione si trovano nella directory di output specificata in asm/istio/options.

Migrazione da Istio

Se stai eseguendo la migrazione da Istio con Citadel come CA, puoi continuare a utilizzare Citadel dopo la migrazione ad Anthos Service Mesh. Il seguente comando esegue lo script per una migrazione e abilita Citadel come CA. Questa migrazione esegue il deployment solo del piano di controllo. Non modifica la CA radice e non disturba i carichi di lavoro esistenti.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

Migrazione con un file di overlay

Un file di overlay è un file YAML contenente una risorsa (RP) IstioOperator personalizzata che passi a install_asm per configurare il piano di controllo. Puoi eseguire l'override della configurazione predefinita del piano di controllo e abilitare una funzionalità facoltativa passando il file YAML a install_asm. Puoi sovrapporre più overlay e ogni file di overlay sostituisce la configurazione dei livelli precedenti.

Se specifichi più di una RP in un file YAML, install_asm suddivide il file in più file YAML temporanei, uno per ogni RP. Lo script suddivide le risposte in file separati perché istioctl install applica solo la prima RP in un file YAML contenente più di una RP.

L'esempio seguente esegue una migrazione e include un file di overlay per personalizzare la configurazione del piano di controllo. Nel comando seguente, cambia OVERLAY_FILE nel nome del file YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Upgrade in corso

Il comando seguente esegue lo script di cui eseguire l'upgrade. Lo script non ti consente di passare a un'altra CA, quindi non è necessario includere l'opzione ca.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m upgrade \
  --enable_apis

Upgrade con un file di overlay

Un file di overlay è un file YAML contenente una risorsa (RP) IstioOperator personalizzata che passi a install_asm per configurare il piano di controllo. Puoi eseguire l'override della configurazione predefinita del piano di controllo e abilitare una funzionalità facoltativa passando il file YAML a install_asm. Puoi sovrapporre più overlay e ogni file di overlay sostituisce la configurazione dei livelli precedenti.

Se specifichi più di una RP in un file YAML, install_asm suddivide il file in più file YAML temporanei, uno per ogni RP. Lo script suddivide le risposte in file separati perché istioctl install applica solo la prima RP in un file YAML contenente più di una RP.

L'esempio seguente esegue un upgrade e include un file overlay per personalizzare la configurazione del piano di controllo. Nel comando seguente, cambia OVERLAY_FILE nel nome del file YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Opzioni e flag

Questa sezione descrive gli argomenti disponibili per lo script.

Opzioni

-p|--project_id CLUSTER_PROJECT_ID
L'ID progetto in cui è stato creato il cluster.
-n|--cluster_name CLUSTER_NAME
Il nome del cluster.
-l|--cluster_location CLUSTER_LOCATION
La zona (per i cluster a zona singola) o la regione (per i cluster a livello di regione) in cui è stato creato il cluster.
-m|--mode {install|migrate|upgrade}
Inserisci install se stai eseguendo un'installazione di Anthos Service Mesh. Inserisci migrate se stai eseguendo la migrazione da Istio. Inserisci upgrade per eseguire l'upgrade di un'installazione Anthos Service Mesh esistente a una nuova versione.
-c|--ca {mesh_ca|citadel}
Per le installazioni, se vuoi utilizzare Mesh CA, non devi includere questa opzione perché l'impostazione predefinita dello script è mesh CA. Per gli upgrade, non è necessario includere questa opzione perché lo script non consente di modificare la CA. Per le migrazioni, devi specificare citadel o mesh_ca. Se puoi pianificare il tempo di riposo per la migrazione, ti consigliamo di utilizzare mesh_ca. Per scoprire di più su quale CA utilizzare, consulta Scegliere un'autorità di certificazione. Per ulteriori opzioni che devi specificare quando utilizzi Citadel, vedi Opzioni per un certificato personalizzato per Citadel.
--co|--custom_overlay YAML_FILE
Il nome del file YAML della risorsa personalizzata (CR) IstioOperator per abilitare una funzionalità non abilitata per impostazione predefinita. Lo script deve essere in grado di individuare il file YAML, quindi il file deve trovarsi nella stessa directory dello script oppure puoi specificare un percorso relativo. Per aggiungere più file, specifica --co|--custom_overlay e il nome del file, ad esempio: --co overlay_file1.yaml --co overlay_file2.yaml --co overlay_file3.yaml
-o|--option OPTION_FILE
Il nome di un file YAML del pacchetto anthos-service-mesh che contiene la RP IstioOperator per abilitare una funzionalità facoltativa. Quando includi uno di questi file, non è necessario scaricare prima il pacchetto anthos-service-mesh e non specifichi l'estensione .yaml. Se devi modificare uno qualsiasi dei file, scarica il pacchetto anthos-service-mesh, apporta le modifiche e utilizza l'opzione --custom_overlay. Per aggiungere più file, specifica -o|--option e il nome del file, ad esempio: -o option_file1 -o option_file2 -o option_file3
-s|--service_account ACCOUNT
Il nome di un account di servizio utilizzato per installare Anthos Service Mesh. Se non specificato, viene utilizzato l'account utente attivo nell'attuale configurazione di gcloud. Se devi modificare l'account utente attivo, esegui gcloud auth login.
-k|--key_file FILE_PATH
Il file della chiave per un account di servizio. Ometti questa opzione se non utilizzi un account di servizio.
-D|--output_dir DIR_PATH
Se non specificata, lo script crea una directory temporanea in cui scarica i file e le configurazioni necessari per l'installazione di Anthos Service Mesh. Specifica il flag --output-dir per designare una directory esistente da utilizzare al suo posto. Al termine, la directory specificata contiene le sottodirectory asm e istio-1.7.8-asm.10. La directory asm contiene la configurazione per l'installazione. La directory istio-1.7.8-asm.10 contiene i contenuti estratti del file di installazione, che includono istioctl, esempi e manifest.

Flag

-e|--enable_apis
Consenti allo script di attivare le API Google richieste da Anthos Service Mesh. Senza questo flag, lo script viene chiuso se le API richieste non sono già abilitate. Per un elenco delle API abilitate dallo script, consulta set_up_project.
-v|--verbose
Stampa i comandi prima e dopo l'esecuzione.
--dry_run
Stampare i comandi, ma non eseguirli.
--only_validate
Esegui la convalida, ma non installare Anthos Service Mesh.
--print_config
Anziché installare Anthos Service Mesh, stampa tutti i file YAML compilati nell'output standard (stdout). Tutti gli altri output vengono scritti nell'errore standard (stderr), anche se normalmente vanno su stdout. Quando specifichi questo flag, lo script ignora tutte le convalide e la configurazione.
--disable_canonical_service
Per impostazione predefinita, lo script esegue il deployment del controller del servizio canonico nel cluster. Se non vuoi che lo script esegua il deployment del controller, specifica --disable_canonical_service. Per maggiori informazioni, consulta Attivare e disattivare il controller di servizio canonico.
-h|--help
Mostra un messaggio della guida che descrive le opzioni e i flag, quindi esci.
--version
Stampa la versione di install_asm ed esci. Se il comando non restituisce una versione, scarica la versione più recente di install_asm_1.7.

Opzioni per un certificato personalizzato per Citadel

Se hai specificato citadel e utilizzi una CA personalizzata, includi le seguenti opzioni:

  • --ca_cert FILE_PATH: il certificato intermedio
  • --ca_key FILE_PATH: la chiave per il certificato intermedio
  • --root_cert FILE_PATH: il certificato radice
  • --cert_chain FILE_PATH: la catena di certificati

Per maggiori informazioni, consulta la sezione Collegamento di certificati CA esistenti.

Deployment e nuovo deployment dei carichi di lavoro

L'installazione non è completa finché non abiliti l'inserimento automatico del proxy sidecar (inserimento automatico).

  • Per le nuove installazioni, devi abilitare l'inserimento automatico e riavviare i pod per tutti i carichi di lavoro in esecuzione sul cluster prima dell'installazione di Anthos Service Mesh.

  • Le migrazioni e gli upgrade seguono il processo di upgrade del piano di controllo doppio (definito "upgrade canary" nella documentazione di Istio). Con un upgrade del piano di controllo doppio, lo script installa una nuova versione di istiod oltre all'attuale istiod. quindi trasferirai alcuni carichi di lavoro alla nuova versione. Questo processo consente di monitorare l'effetto della nuova versione con una piccola percentuale dei carichi di lavoro prima di eseguire la migrazione di tutto il traffico alla nuova versione.

  • Prima di eseguire il deployment di nuovi carichi di lavoro, assicurati di abilitare l'inserimento automatico per consentire ad Anthos Service Mesh di monitorare e proteggere il traffico.

Per abilitare l'inserimento automatico, ricevi l'etichetta di revisione applicata dallo script a istiod ed etichetta gli spazi dei nomi con l'etichetta di revisione. Le seguenti sezioni forniscono i dettagli.

Recupera l'etichetta della revisione

Lo script aggiunge un'etichetta di revisione nel formato istio.io/rev=asm-178-10 a istiod. Per abilitare l'inserimento automatico, aggiungi un'etichetta di revisione corrispondente agli spazi dei nomi. L'etichetta della revisione viene utilizzata dal webhook dell'iniettore collaterale per associare i file collaterali inseriti a una determinata revisione istiod. Dopo aver aggiunto l'etichetta, tutti i pod esistenti nello spazio dei nomi devono essere riavviati per poter inserire i file collaterali.

  1. Imposta il contesto corrente per kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID

  2. Visualizza le etichette su istiod per ottenere l'etichetta di revisione impostata dallo script:

    kubectl -n istio-system get pods -l app=istiod --show-labels

    L'output del comando è simile al seguente. Tieni presente che l'output per le nuove installazioni, migrazioni e upgrade è leggermente diverso. L'output di esempio seguente proviene da una migrazione.

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-178-10-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-178-10-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7

    Nell'output, nella colonna LABELS, prendi nota del valore dell'etichetta di revisione istiod, che segue il prefisso istio.io/rev=. In questo esempio il valore è asm-178-10, ma potresti avere un valore diverso.

    Per gli upgrade e le migrazioni, prendi nota anche del valore nell'etichetta di revisione per la versione precedente di istiod. È necessario per eliminare la versione precedente di istiod al termine della migrazione o dell'upgrade. Nell'output di esempio, il valore nell'etichetta della revisione per la versione precedente di istiod è default, ma potresti avere un valore diverso.

Abilitazione dell'inserimento automatico in corso...

Segui questi passaggi per le nuove installazioni, migrazioni e upgrade per abilitare l'inserimento automatico.

  1. Recupera il valore nell'etichetta di revisione per istiod.

  2. Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta istio-injection. Nel comando seguente, modifica REVISION impostandolo sul valore corrispondente alla revisione del giorno istiod.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

  3. Riavvia i pod per attivare la reiniezione.

    kubectl rollout restart deployment -n NAMESPACE

  4. Verifica che i pod siano configurati in modo da puntare alla nuova versione di istiod.

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

  5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.

  6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.

Per la migrazione e gli upgrade:

Completa la transizione

Per le migrazioni e gli upgrade, devi rimuovere la versione precedente di istiod. Se l'applicazione funziona come previsto, rimuovi il piano di controllo precedente per completare la transizione alla nuova versione.

  1. Recupera il valore nell'etichetta di revisione per la versione precedente di istiod.

  2. Elimina la versione precedente di istiod. Nel comando seguente, sostituisci OLD_REVISION con la revisione del passaggio precedente.

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION  -n istio-system --ignore-not-found=true

Esegui il rollback alla versione precedente

Per le migrazioni e gli upgrade, 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. Rietichetta lo spazio dei nomi per abilitare l'inserimento automatico con la versione precedente di istiod. Il comando da utilizzare varia a seconda che tu abbia utilizzato un'etichetta di revisione o istio-injection=enabled con la versione precedente.

    • Se hai utilizzato un'etichetta di revisione per l'inserimento automatico:

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

    • Se hai usato istio-injection=enabled:

      kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

  2. Riavvia i pod per attivare la reiniezione in modo che i proxy abbiano la versione precedente:

    kubectl rollout restart deployment -n NAMESPACE

  3. Esegui di nuovo il deployment della versione precedente di istio-ingressgateway:

    kubectl -n istio-system rollout undo deploy istio-ingressgateway

  4. Rimuovi il nuovo istiod:

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

  5. Se non hai incluso il flag --disable_canonical_service, lo script abilitava il controller del servizio canonico. Segui i passaggi descritti in Attivazione e disattivazione del controller di servizio canonico per disabilitarlo.

Reinstallazione della stessa versione

Lo script install_asm chiama istioctl install per eseguire il deployment dei componenti del piano di controllo di Anthos Service Mesh (istiod e istio-ingressgateway) per installazioni, upgrade e migrazioni Istio. Poiché lo script utilizza istioctl install, se devi personalizzare Anthos Service Mesh per abilitare una funzionalità facoltativa, devi reinstallare il piano di controllo con la nuova configurazione.

È stata apportata una modifica allo script install_asm per consentirti di reinstallare la stessa versione di Anthos Service Mesh. Se reinstalli la stessa versione per abilitare una funzionalità facoltativa, la configurazione esistente del piano di controllo viene sovrascritta. Per questo motivo, se hai personalizzato l'installazione esistente, devi includere le stesse opzioni --option e/o --custom_overlay dell'installazione precedente e le opzioni --option e/o --custom_overlay per le nuove funzionalità che vuoi attivare.

Tieni presente che, se stai abilitando Cloud Trace o modifichi un'impostazione di tracciamento, devi anche rieseguire il deployment dei carichi di lavoro in modo che i proxy collaterali vengano reinseriti con la configurazione aggiornata del piano di controllo.

Quando reinstalli la stessa versione, specifichi --mode install come per le installazioni. Per informazioni sull'installazione tramite lo script, consulta Installazione di Anthos Service Mesh.

Se specifichi più di una risorsa (RP) personalizzata IstioOperator in un file YAML, install_asm suddivide il file in più file YAML temporanei, uno per ogni RP. Lo script suddivide le RP in file separati perché istioctl install applica solo la prima RP in un file YAML contenente più di una RP.

Visualizzazione delle dashboard di Anthos Service Mesh

Dopo aver eseguito il deployment dei carichi di lavoro nel cluster con i proxy collaterali inseriti, puoi esplorare le pagine Anthos Service Mesh nella console Google Cloud per vedere tutte le funzionalità di osservabilità offerte da Anthos Service Mesh. Tieni presente che dopo il deployment dei carichi di lavoro sono necessari circa uno o due minuti per la visualizzazione dei dati di telemetria nella console Google Cloud.

L'accesso ad Anthos Service Mesh nella console Google Cloud è controllato da Identity and Access Management (IAM). Per accedere alle pagine Anthos Service Mesh, un Proprietario progetto deve concedere agli utenti il ruolo Visualizzatore o Visualizzatore progetto oppure i ruoli più restrittivi descritti in Controllare l'accesso ad Anthos Service Mesh nella console Google Cloud.

  1. Nella console Google Cloud, vai ad Anthos Service Mesh.

    Vai ad Anthos Service Mesh

  2. Seleziona il progetto Google Cloud dall'elenco a discesa nella barra dei menu.

  3. Se hai più di un mesh di servizi, selezionalo dall'elenco a discesa Mesh di servizi.

Per saperne di più, consulta Esplorazione di Anthos Service Mesh nella console Google Cloud.

Oltre alle pagine Anthos Service Mesh, le metriche relative ai tuoi servizi (come il numero di richieste ricevute da un determinato servizio) vengono inviate a Cloud Monitoring, dove vengono visualizzate in Metrics Explorer.

Per visualizzare le metriche:

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

    Vai a Monitoring

  2. Seleziona Risorse > Metrics Explorer.

Per un elenco completo delle metriche, consulta Metriche IoT nella documentazione di Cloud Monitoring.

Registrazione del cluster

Devi registrare il tuo cluster con il parco risorse del progetto per ottenere l'accesso all'interfaccia utente unificata nella console Google Cloud. Un parco risorse fornisce un modo unificato per visualizzare e gestire i cluster e i relativi carichi di lavoro, inclusi i cluster esterni a Google Cloud.

Consulta Registrazione dei cluster nel parco risorse per informazioni sulla registrazione del cluster.

Comprensione dello script

Anche se scarichi lo script da una posizione sicura di Cloud Source Repositories, lo script è disponibile anche su GitHub in modo che tu possa vedere cosa fa prima di scaricarlo. Lo script verifica che il cluster soddisfi i requisiti e automatizza tutti i passaggi che eseguiresti manualmente in Installazione di Anthos Service Mesh su GKE.

Con Anthos Service Mesh 1.7.8, utilizzi la versione dello script install_asm sul ramo release-1.7-asm. Per una spiegazione del processo di controllo delle versioni e di rilascio, consulta Controllo delle versioni/rilascio.

validate_args e validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF
 
validate_dependencies() {
  validate_cli_dependencies
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_k8s
  validate_expected_control_plane

  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  elif [[ "${MODE}" = "upgrade" ]]; then
    validate_asm_version
    validate_ca_consistency
  fi

  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

Le funzioni validate_args e validate_dependencies:

  • Verifica che tutti gli strumenti necessari siano installati.
  • Verifica che l'ID progetto, il nome e la località del cluster che hai inserito come valori dei parametri siano validi.
  • Garantisce che il cluster soddisfi il tipo di macchina minimo richiesto e il numero di nodi.

set_up_project

Se hai incluso il flag --enable_apis, la funzione set_up_project abilita le API richieste:

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
stackdriver.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi
  add_cluster_labels
  enable_workload_identity

  init_meshconfig

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

La funzione set_up_cluster esegue i seguenti aggiornamenti al cluster:

  • Abilita Workload Identity, che rappresenta il metodo consigliato per accedere in sicurezza ai servizi Google Cloud dalle applicazioni GKE.

  • Abilita Cloud Monitoring e Cloud Logging su GKE.

  • Imposta sul cluster l'etichetta mesh_id, necessaria per visualizzare le metriche nelle pagine Anthos Service Mesh nella console Google Cloud.

  • Imposta un'etichetta come asmv=asm-178-10, in modo che tu possa capire che il cluster è stato modificato dallo script.

  • Associa l'account utente o di servizio della piattaforma Google Cloud che esegue lo script al ruolo cluster-admin sul tuo cluster.

install_asm

install_asm() {

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST} -f ${MULTICLUSTER_MANIFEST}"
  while read -d ',' -r yaml_file; do
    PARAMS="${PARAMS} -f ${yaml_file}"
  done <<EOF

La funzione install_asm:

  • Scarica il pacchetto kpt in una directory temporanea.
  • Esegue i setter kpt per configurare il file istio-operator.yaml.
  • Installa Anthos Service Mesh.

Passaggi successivi