Installazione di Anthos Service Mesh

Questa pagina spiega come eseguire lo script per installare la versione 1.8.6 di Anthos Service Mesh su un cluster GKE per un mesh contenente uno o più cluster nello stesso progetto Google Cloud.

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

Questa pagina è dedicata alle installazioni di Anthos Service Mesh: nuove installazioni o reinstallazione della stessa versione con un'altra configurazione.

Sebbene l'esecuzione dello script per le nuove installazioni sia simile per la reinstallazione della stessa versione e per gli upgrade e le migrazioni da Istio, questi casi d'uso richiedono una pianificazione aggiuntiva. Per ulteriori informazioni, consulta le seguenti risorse:

• Upgrade di Anthos Service Mesh
• Migrazione da Istio
• Reinstallazione della stessa versione

Prima di iniziare

Prima di iniziare l'installazione, assicurati di avere:

• Requisiti esaminati
• Scegliere un'autorità di certificazione (CA)
• Hai registrato il cluster
• Ha installato gli strumenti richiesti
• Hai scaricato lo script

Lo script richiede che tu disponga delle autorizzazioni richieste o che includa i flag --enable_all o --enable_gcp_iam_roles per consentire allo script di abilitare l'autorizzazione per te. Analogamente, per consentire allo script di abilitare le API richieste e aggiornare il cluster, specifica il flag --enable_all o i flag di abilitazione più granulari.

Installazione di Anthos Service Mesh

1. Imposta le opzioni e specifica i flag per eseguire lo script. Includi sempre le seguenti opzioni: --project_id, --cluster_name, --cluster_location e --mode install. Se vuoi utilizzare Citadel come CA, devi specificare l'opzione --ca e alcune altre opzioni, come descritto in Installazione con Citadel come CA. Per una descrizione completa degli argomenti dello script, consulta Opzioni e flag.

2. 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.

La seguente sezione fornisce esempi tipici per l'esecuzione dello script. Guarda la barra di navigazione sulla destra per un elenco di esempi.

Esempi

Questa sezione mostra esempi di esecuzione dello script per un'installazione con alcuni argomenti aggiuntivi che potrebbero esserti utili. Guardate 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 alcuna modifica al progetto o al cluster e non installa Anthos Service Mesh. Quando specifichi --only_validate,lo script non riesce se includi uno dei flag --enable_*.

Lo script verifica che:

• Il tuo ambiente dispone degli strumenti necessari.
• Hai l'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 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 semplifica l'utilizzo dello strumento a riga di comando istioctl, se necessario. Inoltre, i file di configurazione per abilitare le 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

In caso di esito positivo, 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 obbligatorie, verrà visualizzato il seguente errore:

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

Se hai ricevuto un messaggio di errore relativo alla necessità di eseguire lo script con un flag di abilitazione, puoi includere il flag specifico del messaggio di errore o il flag --enable_all quando esegui lo script senza --only_validate. Se preferisci, puoi aggiornare autonomamente il progetto e il cluster prima di eseguire lo script come descritto nelle sezioni Configurazione del progetto e Configurazione del cluster della Guida all'installazione per più progetti.

Installazione

Il seguente comando esegue lo script per una nuova installazione, abilita mesh CA, che è la CA predefinita per le installazioni. Pertanto, in questo caso non è necessaria l'opzione --ca. Il flag --enable_all consente allo script di abilitare le API di Google richieste, impostare le autorizzazioni di Identity and Access Management e apportare gli aggiornamenti necessari al cluster, inclusa l'abilitazione di GKE Workload Identity.

Se prevedi di utilizzare Mesh CA, puoi utilizzare il pool di identità per i carichi di lavoro del parco risorse come alternativa all'identità dei carichi di lavoro GKE. Per un esempio, vedi Abilitare Mesh CA con il pool di identità dei carichi di lavoro del parco risorse.

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

Potresti anche voler includere quanto segue:

• --output_dir DIR_PATH Se non hai eseguito l'unico esempio di convalida, includi questa opzione per specificare una directory esistente in cui lo script scarica il pacchetto asm e il file di installazione di Anthos Service Mesh, che contiene istioctl, esempi e manifest. In caso contrario, lo script scarica il pacchetto asm e il file di installazione in una directory temporanea.

• --enable-registration Questo flag consente allo script di registrare il cluster nel progetto in cui si trova il cluster. Se non includi questo flag, segui i passaggi descritti in Registrazione di un cluster per registrare manualmente il cluster.

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 certificati CA. In questa configurazione, tutti i carichi di lavoro nel mesh di servizi utilizzano la stessa CA radice. Ogni CA Anthos Service Mesh utilizza una chiave e un certificato di firma della CA intermedi, firmati dalla CA radice. L'esistenza di più CA all'interno di un mesh determina 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.

Importante: questi passaggi creano certificati e chiavi utilizzando un comando make fornito a solo scopo illustrativo. Per la massima sicurezza, utilizza un computer offline protetto e strumenti pronti per la produzione, ad esempio utilizzando HashiCorp Vault per generare e proteggere in modo sicuro la chiave di firma della CA.

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
   

   Questo genera i seguenti file:

   • root-cert.pem: il certificato radice
   • root-key.pem: la chiave radice
   • root-ca.conf: la configurazione di beginsl per generare il certificato radice
   • root-cert.csr: la richiesta di firma del certificato per il certificato radice

3. Genera un certificato e una chiave intermedi:

   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
   Nota: puoi sostituire cluster1 con un nome diverso. Ad esempio, make mycluster-certs crea una directory denominata mycluster.

   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 overlay è un file YAML contenente una risorsa IstioOperator personalizzata (CR) 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 aggiungere più overlay: 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 predefinite 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_all \
  --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 il file per te, 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_all \
  --option egressgateways

Puoi utilizzare --option per abilitare una funzionalità facoltativa. Se devi apportare modifiche a uno dei file 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.8-asm asm

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

Abilita Mesh CA con parco risorse

Anteprima - Mesh CA with fleet

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. 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.

L'anteprima di Mesh CA con il parco risorse è limitata alle nuove installazioni di Anthos Service Mesh su GKE. Gli upgrade e le migrazioni non sono supportati durante l'anteprima.

Questo esempio mostra come abilitare Mesh CA per utilizzare il pool di identità per i carichi di lavoro del parco risorse. Mesh CA con parco risorse consente di unire i cluster in progetti Google Cloud separati a un singolo dominio di attendibilità corrispondente al parco risorse.

Per attivare Mesh CA con il parco risorse:

Se non hai già registrato il cluster, assicurati di includere il flag --enable-registration come mostrato nel seguente esempio:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --enable-registration \
  --option hub-meshca

Questo comando esegue lo script per una nuova installazione, configura il progetto e il cluster con le opzioni richieste da Anthos Service Mesh, registra il cluster nel progetto in cui si trova il cluster e configura Mesh CA per l'utilizzo del pool di identità dei carichi di lavoro del parco risorse.

Deployment e nuovo deployment dei carichi di lavoro

Anthos Service Mesh utilizza i proxy sidecar per migliorare la sicurezza, l'affidabilità e l'osservabilità della rete. Con Anthos Service Mesh, queste funzioni vengono astratte dal container principale dell'applicazione e implementate in un proxy out-of-process comune, fornito come container separato nello stesso pod.

L'installazione non è completa finché non attivi l'inserimento automatico del proxy sidecar (inserimento automatico) e riavvii i pod per qualsiasi carico di lavoro in esecuzione sul tuo cluster prima dell'installazione di Anthos Service Mesh.

Per abilitare l'inserimento automatico, etichetta gli spazi dei nomi con l'etichetta di revisione che è stata impostata il giorno istiod al momento dell'installazione di Anthos Service Mesh. L'etichetta di revisione viene utilizzata dal webhook iniettore sidecar 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.

Prima di eseguire il deployment di nuovi carichi di lavoro in un nuovo spazio dei nomi, assicurati di configurare l'inserimento automatico in modo che Anthos Service Mesh possa monitorare e proteggere il traffico.

Per abilitare l'inserimento automatico:

1. Utilizza il seguente comando per individuare l'etichetta di revisione su istiod:

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

   L'output è simile al seguente:

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-asm-186-8-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586
   istiod-asm-186-8-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586

   Nell'output, sotto la colonna LABELS, prendi nota del valore dell'etichetta di revisione istiod, che segue il prefisso istio.io/rev=. In questo esempio, il valore è asm-186-8.

2. Applica l'etichetta di revisione e rimuovi l'etichetta istio-injection, se esistente. Nel seguente comando, NAMESPACE è il nome dello spazio dei nomi in cui vuoi abilitare l'inserimento automatico e REVISION è l'etichetta di revisione che hai annotato nel passaggio precedente.

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

   Puoi ignorare il messaggio "istio-injection not found" nell'output. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection, cosa che dovresti aspettarti nelle nuove installazioni di Anthos Service Mesh o nei nuovi deployment. Poiché l'inserimento automatica non riesce se uno spazio dei nomi contiene sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh comprendono la rimozione dell'etichetta istio-injection.

3. Se i carichi di lavoro erano in esecuzione sul tuo cluster prima dell'installazione di Anthos Service Mesh, riavvia i pod per attivare la reiniezione.

   La modalità di riavvio dei pod dipende dall'applicazione e dall'ambiente in cui si trova il cluster. Ad esempio, nell'ambiente di gestione temporanea potresti semplicemente eliminare tutti i pod, il che comporta il riavvio. Tuttavia, nell'ambiente di produzione potresti avere un processo che implementa un deployment blu/verde in modo da poter riavviare i pod in modo sicuro ed evitare interruzioni del traffico.

   Puoi utilizzare kubectl per eseguire un riavvio in sequenza:

   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
   

Visualizzazione delle dashboard di Anthos Service Mesh

Dopo aver eseguito il deployment dei carichi di lavoro nel tuo cluster con i proxy sidecar 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 sono necessari circa uno o due minuti per la visualizzazione dei dati di telemetria nella console Google Cloud dopo il deployment dei carichi di lavoro.

L'accesso ad Anthos Service Mesh nella console Google Cloud è controllato da Identity and Access Management (IAM). Per accedere alle pagine di Anthos Service Mesh, un Proprietario progetto deve concedere agli utenti il ruolo Editor di progetto o Visualizzatore 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 disponi di più mesh di servizi, selezionalo dall'elenco a discesa Mesh di servizi.

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

Oltre alle pagine Anthos Service Mesh, le metriche relative ai tuoi servizi (ad esempio 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 la pagina relativa alle metriche Istio nella documentazione di Cloud Monitoring.

Passaggi successivi

• Esegui il deployment dell'applicazione di esempio di Boutique Online
• Aggiungi cluster ad Anthos Service Mesh