Anthos Service Mesh 1.9 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade da versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

Versioni disponibili

1.20 (più recente)
1,19
1,18
1,17
1,16
1,15
1.14
1.13
1.12
1.12

Aggiungi macchine virtuali Compute Engine ad Anthos Service Mesh

Introduzione

Anthos Service Mesh ti consente di gestire, osservare e proteggere i servizi in esecuzione su gruppi di istanze gestite, insieme ai servizi in esecuzione sui cluster Google Kubernetes Engine (GKE) nel mesh. In questo modo puoi eseguire le seguenti operazioni con le istanze di Compute Engine nel tuo mesh:

Gestire il traffico.
Applica mTLS.
Applica controllo dell'accesso al traffico dei servizi.
Accedi in sicurezza ai servizi Google Cloud.
Raccogli metriche e dati di logging e tracciamento.
Monitorare i servizi utilizzando la console Google Cloud.

Ciò consente alle applicazioni legacy non adatte o pronte per la containerizzazione di sfruttare le funzionalità di Anthos Service Mesh e di integrare questi carichi di lavoro con il resto dei servizi.

Come funziona

ASM fornisce due definizioni di risorse personalizzate (CRD) correlate per rappresentare i carichi di lavoro delle macchine virtuali:

WorkloadGroup rappresenta un gruppo logico di carichi di lavoro di macchine virtuali che condividono proprietà comuni. Questo processo è simile a un deployment in Kubernetes.
WorkloadEntry rappresenta una singola istanza di un carico di lavoro di una macchina virtuale. È simile a un pod in Kubernetes.
Un Service può quindi selezionare WorkloadGroup e fare in modo che ASM instrada il traffico all'istanza VM in modo simile a Pod. Ciò consente alla VM di agire come qualsiasi altro carico di lavoro nel mesh.

Devi creare un modello di istanza Compute Engine per ogni gruppo di istanze Compute Engine, che specifica un agente proxy di servizio per ogni istanza Compute Engine all'interno del gruppo. Durante l'installazione, l'agente esegue il bootstrap del proxy di servizio, configura l'intercettazione del traffico e monitora l'integrità del proxy di servizio per tutta la durata dell'istanza Compute Engine. Il proxy si connette con il piano di controllo di Anthos Service Mesh, quindi registra automaticamente ogni istanza di Compute Engine come WorkloadEntry per il WorkloadGroup corrispondente. In questo modo Anthos Service Mesh tratti ogni istanza come endpoint di servizio, come i pod Kubernetes nel cluster. Puoi anche creare servizi Kubernetes per i carichi di lavoro delle VM, come faresti per i pod Kubernetes.

Per fare lo scale up o lo scale down del numero di carichi di lavoro sulle istanze di Compute Engine, partendo da una dimensione minima del gruppo di istanze gestite pari a zero, consulta Scalabilità automatica dei gruppi di istanze.

L'agente proxy di servizio si affida a VM Manager per garantire che l'agente sia installato in ogni VM nel gruppo di istanze gestite. Per saperne di più sui gruppi di istanze e sulla gestione delle VM, consulta Gruppo di istanze gestite e VM Manager.

Distribuzioni Linux supportate

Versione sistema operativo	supportato
Debian 10
Debian 9
Centos 8
Centos 7

Consulta l'assistenza Debian o l'assistenza CentOS per ulteriori informazioni sulle distribuzioni del sistema operativo.

Limitazioni

Il piano di controllo della rete mesh deve essere Anthos Service Mesh 1.9 o versioni successive.
Sono supportati solo i gruppi di istanze gestite di Compute Engine creati da un modello di istanza di Compute Engine.
Il cluster e le VM devono trovarsi nella stessa rete, nello stesso progetto e utilizzare una singola interfaccia di rete.
Puoi utilizzare questa funzionalità senza un abbonamento a GKE Enterprise, ma alcuni elementi UI e funzionalità della console Google Cloud sono disponibili solo per gli abbonati a GKE Enterprise. Per informazioni su ciò che è disponibile per abbonati e non abbonati, consulta Differenze nella UI di GKE Enterprise e Anthos Service Mesh.

Prerequisiti

Prima di iniziare, controlla i seguenti prerequisiti.

Cluster

Questa pagina include l'opzione per installare Anthos Service Mesh come parte dei passaggi o per aggiornare un cluster su cui è già installato Anthos Service Mesh. In entrambi i casi, questi passaggi richiedono Anthos Service Mesh 1.9 o versioni successive e un cluster che soddisfi questi requisiti. Inoltre, il supporto delle VM Anthos Service Mesh prevede ulteriori requisiti:

Il piano di controllo deve essere installato in un cluster controllato da te. I piani di controllo gestiti da Google non sono supportati. Per ulteriori informazioni, consulta Piani di controllo gestiti da Google.
Utilizza Mesh CA come autorità di certificazione.
Utilizza Stackdriver per la telemetria.
Abbia abilitato il deployment Canonical Service, che viene attivato automaticamente dal processo di installazione di Anthos Service Mesh.

Il cluster deve essere registrato in un parco risorse. Tuttavia, se la VM non è già registrata, il processo di installazione della VM può registrarla nel progetto specificato.

Se hai un abbonamento a GKE Enterprise, abilita l'API GKE Enterprise.

Abilitare l'API

Strumenti dell'interfaccia a riga di comando

Il processo di installazione richiede i seguenti strumenti, che sono già installati se utilizzi Google Cloud Shell:

gcloud
kubectl
kpt
curl
jq
awk
printf
tr
grep
tail

Download dello script in corso...

Questa sezione descrive come scaricare lo script per l'onboarding delle VM.

Scarica lo script VM per Anthos Service Mesh 1.9.8 nella directory di lavoro corrente:
```
curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9 > asm_vm
```

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

curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9.sha256 > asm_vm.sha256

Con entrambi i file nella stessa directory, verifica il download:
```
sha256sum -c --ignore-missing asm_vm.sha256
```
Se la verifica ha esito positivo, il comando restituisce: asm_vm: OK

Per motivi di compatibilità, il file asm_vm.sha256 include il checksum due volte per consentire a qualsiasi versione dello script di essere rinominata in asm_vm. Se viene visualizzato un errore che indica che --ignore-missing non esiste, esegui nuovamente il comando precedente senza il flag --ignore-missing.
Rendi eseguibile lo script:
```
chmod +x asm_vm
```

Per iniziare

Questa sezione illustra i passaggi per aggiungere istanze di Compute Engine ad Anthos Service Mesh.

Configura l'ambiente

Utilizza gcloud per configurare lo strumento kubectl in modo che punti al cluster specificato, poiché alcuni dei passaggi riportati di seguito richiedono di apportare modifiche direttamente al cluster.

Nota: utilizza --region anziché --zone, se il cluster è a livello di regione.
```
gcloud container clusters get-credentials CLUSTER_NAME --zone CLUSTER_LOCATION --project PROJECT_ID
```

Prepara il cluster

Configura il cluster Anthos Service Mesh per le VM, preparando il piano di controllo di Anthos Service Mesh 1.9 o versioni successive.

Scegli il passaggio successivo a seconda che Anthos Service Mesh 1.9 o versioni successive sia già installato sul tuo cluster.

Non installata

Se Anthos Service Mesh 1.9 o versioni successive non è stato installato sul tuo cluster, l'esempio seguente mostra come aggiungere le opzioni vm e hub-meshca per modificare i consueti passaggi di installazione di Anthos Service Mesh forniti in Installazione, migrazione ed upgrade per GKE. Spiega inoltre come scaricare lo script install_asm utilizzato nell'esempio seguente.

Dopo aver scaricato lo script install_asm, puoi installare Anthos Service Mesh nel cluster includendo i flag --option hub-meshca, --option vm e --enable_all. Per maggiori informazioni, consulta Abilitare Mesh CA con parco risorse e Flag di abilitazione.

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

Installata

Se Anthos Service Mesh 1.9 o versioni successive è già stato installato sul tuo cluster e ha CA mesh con parco risorse abilitato, aggiorna il piano di controllo di Anthos Service Mesh per supportare i carichi di lavoro basati su VM. Lo script consente inoltre di verificare se l'installazione di Anthos Service Mesh nel cluster è pronta per i carichi di lavoro delle VM. In particolare, il sottocomando prepare_cluster aggiorna tutte le revisioni in Anthos Service Mesh 1.9 e versioni successive per essere pronte per i carichi di lavoro delle VM.

Se l'opzione Mesh CA con parco risorse non è abilitata nell'installazione di Anthos Service Mesh 1.9 o versioni successive, reinstalla o esegui l'upgrade dell'installazione di Anthos Service Mesh 1.9 o versioni successive includendo i flag --option hub-meshca e --option vm nello script install_asm.

./asm_vm prepare_cluster \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION

I passaggi precedenti hanno comportato le seguenti azioni:

Abilita la registrazione automatica delle VM: questa operazione viene eseguita impostando la variabile PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION su true. Se questa opzione è abilitata, le nuove istanze VM verranno registrate con WorkloadGroup e verranno create nuove RP WorkloadEntry per instradare il traffico alle VM. Tutti i piani di controllo Anthos Service Mesh 1.9 e versioni successive installati con install_asm includeranno questo elemento per impostazione predefinita.
Installa un gateway di espansione: questo gateway è denominato gateway eastwest ed è definito nel pacchetto di configurazione Anthos Service Mesh. In questo modo il piano di controllo verrà esposto anche alle VM.
Installa il CRD IdentityProvider e registra una RP Google IdentityProvider per consentire alle VM di autenticarsi nel piano di controllo Anthos Service Mesh e comunicare in modo sicuro con il resto del mesh di servizi.
Registra il cluster in un parco risorse e abilita l'identità del carico di lavoro, se utilizzi --enable_all o --enable_registration nello script install_asm.
Abilita la funzionalità Service Mesh nel parco risorse. Questa funzionalità gestirà i criteri necessari per consentire alle VM di comunicare in modo sicuro con la rete mesh.

Aggiungi le tue VM

In questa sezione aggiungerai istanze di Compute Engine al tuo mesh in base al modello di istanza che crei con lo script asm_vm. Lo script genera solo la configurazione necessaria per l'agente proxy di servizio. Per includere più configurazioni nel modello di istanza, crea un modello di istanza di origine e aggiungilo allo script.

Per aggiungere VM al tuo mesh, segui questi passaggi:

Imposta le seguenti variabili di ambiente da utilizzare nei passaggi successivi. Imposta queste variabili per ogni carico di lavoro VM:
- WORKLOAD_NAME è il nome del carico di lavoro di cui la VM fa parte, che deve essere un sottodominio DNS-1123 conforme composto da caratteri alfanumerici minuscoli.
- WORKLOAD_VERSION è la versione del carico di lavoro di cui fa parte la VM. Facoltativo.
- WORKLOAD_SERVICE_ACCOUNT è l'account di servizio Google Cloud su cui viene eseguita la VM.
- WORKLOAD_NAMESPACE è lo spazio dei nomi per il carico di lavoro.
- ASM_INSTANCE_TEMPLATE è il nome del modello di istanza da creare. Il nome del modello di istanza Compute Engine non consente i trattini bassi.
- SOURCE_INSTANCE_TEMPLATE è il nome del modello su cui basare il modello generato. Facoltativo.
Se non esiste già, crea lo spazio dei nomi per i carichi di lavoro VM:
```
kubectl create ns WORKLOAD_NAMESPACE
```
Etichetta lo spazio dei nomi con la revisione del piano di controllo. Per un esempio di come trovare la revisione del piano di controllo mostrata come REVISION nell'esempio seguente, consulta Deployment e nuova esecuzione del deployment dei carichi di lavoro.
```
kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```

Crea il WorkloadGroup per le VM da registrare:

kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
 name: WORKLOAD_NAME
 namespace: WORKLOAD_NAMESPACE
spec:
 metadata:
   labels:
     app.kubernetes.io/name: WORKLOAD_NAME
     app.kubernetes.io/version: WORKLOAD_VERSION
   annotations:
     security.cloud.google.com/IdentityProvider: google
 template:
   serviceAccount: WORKLOAD_SERVICE_ACCOUNT
EOF

Campo	Description
`name`	Il nome del carico di lavoro di cui fa parte la VM.
`namespace`	Lo spazio dei nomi di cui fa parte il carico di lavoro.
`app.kubernetes.io/name`	Le etichette consigliate per le applicazioni Kubernetes. Puoi utilizzare le tue etichette per i carichi di lavoro delle VM.
`app.kubernetes.io/version`	Le etichette consigliate per le applicazioni Kubernetes. Puoi utilizzare le tue etichette per i carichi di lavoro delle VM.
`serviceAccount`	L'identità dell'account di servizio utilizzata dalla VM e dal progetto, che verrà usata come parte dell'identità del carico di lavoro nel formato SPIFFE. Per saperne di più, vedi Account di servizio.
`security.cloud.google.com/IdentityProvider`	Il provider di identità utilizzato dalla VM, che dovrebbe essere già registrato nel cluster. Per le VM di Compute Engine deve essere impostato su `google`. "IdentityProvider" indica al piano di controllo come autenticare le credenziali della VM e dove estrarre l'account di servizio della VM.

Esegui lo script asm_vm con le opzioni e i flag seguenti per creare un modello di istanza per le tue istanze Compute Engine Anthos Service Mesh.

Lo script verifica i prerequisiti del cluster, aggiunge etichette VM per Anthos Service Mesh, genera la configurazione di metadati personalizzata per l'agente proxy del servizio e crea un nuovo modello di istanza.

Se disponi già di un modello di istanza su cui vuoi basare lo script, puoi specificare l'opzione --source_instance_template. Se vuoi aggiungere VM non predefinite ad Anthos Service Mesh, crea un modello di istanza con la distribuzione del sistema operativo prevista e utilizza quel modello come valore per il flag --source_instance_template nello script asm_vm. Se il modello di istanza esistente include uno script di avvio che richiede la connettività di rete, lo script deve essere resiliente ai problemi di connettività di rete temporanei. Consulta l'applicazione demo per un esempio di come aggiungere resilienza contro un'interruzione temporanea della rete.

./asm_vm create_gce_instance_template \
ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE

Opzioni

Opzione	Description
`-p\|--project_id 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.
`-w\|--workload_name WORKLOAD_NAME`	Il nome del carico di lavoro rappresentato dalle istanze di Compute Engine.
`--workload_namespace WORKLOAD_NAMESPACE`	Facoltativo. Lo spazio dei nomi del carico di lavoro. Il valore predefinito è "default".
`-s\|--source_instance_template SOURCE_INSTANCE_TEMPLATE_NAME`	Facoltativo. Un modello di istanza esistente da utilizzare come base per il modello di istanza Compute Engine di Anthos Service Mesh. Se non specificato, viene creato un modello di istanza con valori predefiniti.

Flag

Segnala	Description
`-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 creare un nuovo modello di istanza Compute Engine.
`-h\|--help`	Mostra un messaggio della guida che descrive le opzioni, i flag e l'uscita.

Imposta le seguenti variabili di ambiente per ogni gruppo di istanze gestite che crei:
- INSTANCE_GROUP_NAME è il nome del gruppo di istanze Compute Engine da creare.
- ASM_INSTANCE_TEMPLATE è il nome del modello di istanza da creare. Il nome del modello di istanza Compute Engine non consente i trattini bassi.
- INSTANCE_GROUP_ZONE è la zona del gruppo di istanze Compute Engine da creare.
- PROJECT_ID è l'ID progetto in cui è stato creato il cluster.
- SIZE è la dimensione del gruppo di istanze da creare. Può essere modificato dopo la creazione del gruppo di istanze.
- WORKLOAD_NAME è il nome del carico di lavoro di cui fa parte la VM.
- WORKLOAD_NAMESPACE è lo spazio dei nomi per il carico di lavoro.
Crea un gruppo di istanze gestite per i carichi di lavoro delle VM, utilizzando le variabili create nei passaggi precedenti:
```
gcloud compute instance-groups managed create \
INSTANCE_GROUP_NAME \
--template ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE \
--project=PROJECT_ID \
--size=SIZE
```
Per fare lo scale up o lo scale down del numero di carichi di lavoro sulle istanze di Compute Engine, a partire da una dimensione del gruppo di istanze gestite a livello di zona o di regione pari a zero, consulta Scalabilità automatica dei gruppi di istanze. Per ulteriori informazioni sulla creazione di gruppi, vedi gcloud compute instances-groups managed create.

All'avvio dell'istanza, verrà eseguita automaticamente l'autenticazione con il piano di controllo Anthos Service Mesh sul tuo cluster e il piano di controllo registrerà ogni VM come WorkloadEntry.
Al termine dell'avvio dell'istanza VM nel gruppo di istanze gestite, puoi visualizzare le VM registrate nello spazio dei nomi del carico di lavoro utilizzando il seguente comando:
```
   kubectl get workloadentry -n WORKLOAD_NAMESPACE
```
Nota: se le risorse personalizzate WorkloadGroup o IdentityProvider vengono eliminate, la tua VM non sarà in grado di comunicare con il mesh.
Aggiungi un servizio Kubernetes per esporre i carichi di lavoro delle VM aggiunti sopra. Assicurati che il servizio selezioni l'etichetta corrispondente sulla VM WorkloadGroup registrata in precedenza per il routing del traffico corretto.

L'esempio seguente crea un servizio Kubernetes denominato WORKLOAD_NAME nello spazio dei nomi WORKLOAD_NAMESPACE, che espone i carichi di lavoro delle VM con l'etichetta app.kubernetes.io/name: WORKLOAD_NAME nella porta HTTP 80.
```
kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
 name: WORKLOAD_NAME
 namespace: WORKLOAD_NAMESPACE
 labels:
   asm_resource_type: VM
spec:
 ports:
 - port: 80
   name: http
 selector:
   app.kubernetes.io/name: WORKLOAD_NAME
EOF
```
Per maggiori dettagli su come creare un servizio Kubernetes, consulta https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service.
Per utilizzare un'applicazione di esempio sulla tua VM, vedi Eseguire il deployment di un'applicazione di esempio.

Upgrade del piano di controllo di Anthos Service Mesh

Esegui l'upgrade del piano di controllo di Anthos Service Mesh a una nuova versione utilizzando le istruzioni riportate in Upgrade di Anthos Service Mesh alla versione più recente. Dopo aver installato una nuova versione del piano di controllo Anthos Service Mesh, esegui nuovamente il deployment dei carichi di lavoro Kubernetes seguendo le istruzioni riportate in Deployment e nuova esecuzione del deployment dei carichi di lavoro.

Per i carichi di lavoro delle VM, crea un nuovo modello di istanza ed esegui un aggiornamento in sequenza delle VM nel gruppo di istanze gestite:

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 del comando è simile al seguente. Tieni presente che l'output per le migrazioni è leggermente diverso da quello per gli upgrade. Il seguente output di esempio 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-198-6-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-198-6-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
```
1. Nell'output, sotto la colonna LABELS, prendi nota del valore dell'etichetta di revisione istiod per la nuova versione, che segue il prefisso istio.io/rev=. In questo esempio, il valore è asm-198-6.
2. Nota anche il valore nell'etichetta di revisione per la vecchia versione di istiod. Questa operazione ti consente di eliminare la versione precedente di istiod quando hai finito di spostare i carichi di lavoro alla nuova versione. Nell'output di esempio, il valore dell'etichetta di revisione per la versione precedente di istiod è default.
Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta istio-injection (se esistente). Nel comando seguente, imposta REVISION sul valore che corrisponde alla nuova revisione di istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```
Se vedi "istio-injection not found" nell'output, puoi ignorarlo. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection. 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.
Crea un nuovo modello di istanza utilizzando lo script asm_vm. Assicurati di utilizzare un nuovo nome di modello di istanza e di includere lo stesso modello di istanza di origine se ne hai avuto uno per lo stesso carico di lavoro.

Nota: il flag --source_instance_template è facoltativo. Se hai un modello di origine, devi includerlo. Se non hai un modello di origine, non includere il flag.
```
./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE
```
Esegui un aggiornamento in sequenza del gruppo di istanze gestite esistente per il carico di lavoro.

Per ulteriori informazioni, consulta Avvio di un aggiornamento in sequenza di base.
```
gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE
```
Testa il carico di lavoro della VM per assicurarti che funzioni come previsto.

Esegui l'upgrade delle applicazioni VM

In caso di aggiornamenti all'applicazione, incluse modifiche a WorkloadGroup e/o al modello di istanza di origine, è necessario un nuovo modello di istanza per aggiornare il gruppo di istanze gestite dei carichi di lavoro delle VM.

Quando viene applicata la modifica a WorkloadGroup e/o viene creato il nuovo modello di istanza di origine, devi creare un nuovo modello di istanza per Anthos Service Mesh ed eseguire un aggiornamento in sequenza delle VM nel gruppo di istanze gestite.

Crea un nuovo modello di istanza utilizzando lo script asm_vm. Assicurati di utilizzare un nuovo nome di modello di istanza e di includere il nuovo modello di istanza di origine se ne hai creato uno per l'aggiornamento dell'applicazione.

./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template NEW_SOURCE_INSTANCE_TEMPLATE

Esegui un aggiornamento in sequenza del gruppo di istanze gestite esistente per il carico di lavoro. Per ulteriori informazioni su come utilizzare l'aggiornamento in sequenza dei gruppi di istanze gestite, consulta Avvio di un aggiornamento in sequenza di base.
```
gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE
```
Testa il carico di lavoro della VM per assicurarti che funzioni come previsto.

Deployment di un'applicazione di esempio

Per dimostrare che la nuova configurazione mesh funziona correttamente, puoi installare l'applicazione di esempio Bookinfo. Questo esempio esegue un database MySQL sulla VM e il servizio di valutazione legge i valori delle valutazioni dal database.

Installa Bookinfo sul cluster

Segui questi passaggi per eseguire il deployment dei servizi dell'applicazione BookInfo con i proxy collaterali inseriti insieme a ogni servizio. Verrà eseguito il deployment dell'applicazione BookInfo nello spazio dei nomi default.

Nella riga di comando sul computer in cui hai installato Anthos Service Mesh, vai alla directory principale della directory di installazione di Anthos Service Mesh creata nel passaggio Download dello script.

Per abilitare l'inserimento automatico di sidecar, utilizza il comando seguente per individuare l'etichetta su istiod, che contiene il valore dell'etichetta di revisione da utilizzare nei passaggi successivi.

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

L'output è simile al seguente:

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-198-6-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586
istiod-asm-198-6-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-198-6,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-198-6.

Applica l'etichetta di revisione allo spazio dei nomi default. Nel comando seguente, REVISION è il valore dell'etichetta di revisione istiod che hai annotato nel passaggio precedente.
```
kubectl label namespace default 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.
Esegui il deployment dell'applicazione nello spazio dei nomi predefinito utilizzando kubectl:
```
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
```

Verifica che il deployment dell'applicazione sia stato eseguito correttamente eseguendo questi comandi:

kubectl get services

Output previsto:

NAME                       CLUSTER-IP   EXTERNAL-IP   PORT(S)              AGE
details                    10.0.0.31    <none>        9080/TCP             6m
kubernetes                 10.0.0.1     <none>        443/TCP              7d
productpage                10.0.0.120   <none>        9080/TCP             6m
ratings                    10.0.0.15    <none>        9080/TCP             6m
reviews                    10.0.0.170   <none>        9080/TCP             6m

kubectl get pod

Output previsto:

NAME                                        READY     STATUS    RESTARTS   AGE
details-v1-1520924117-48z17                 2/2       Running   0          6m
productpage-v1-560495357-jk1lz              2/2       Running   0          6m
ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

Infine, definisci il routing del gateway in entrata per l'applicazione:

kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml

Output previsto:

gateway.networking.istio.io/bookinfo-gateway created
virtualservice.networking.istio.io/bookinfo created

Verifica che la pagina del prodotto sia accessibile.

export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
export GATEWAY_URL="${INGRESS_HOST}:${INGRESS_PORT}"
curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"

Output previsto:

<title>Simple Bookstore App</title>

Crea istanze Compute Engine e installa MySQL

In questo passaggio, creerai un modello di istanza Compute Engine per l'istanza MySQL in esecuzione sulla VM. Per la procedura dettagliata, consulta Bookinfo con una macchina virtuale.

Crea un modello di istanza Compute Engine che includa uno script di avvio per installare MySQL e aggiungi un database di valutazioni all'avvio. Tieni presente che se utilizzi CentOS, saranno necessari fino a 10 minuti prima che mariadb-server sia pronto.

Debian

cat << "EOF" > init-mysql
#!/bin/bash

# Wait until Envoy is ready before installing mysql
while true; do
  rt=$(curl -s 127.0.0.1:15000/ready)
  if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
    echo "envoy is ready"
    break
  fi
  sleep 1
done

sudo apt-get update && sudo apt-get install -y mariadb-server

sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf

cat <<EOD | sudo mysql
# Grant access to root
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

# Grant root access to other IPs
CREATE USER 'root'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
quit
EOD

sudo systemctl restart mysql

curl -LO https://raw.githubusercontent.com/istio/istio/release-1.9/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image=debian-10-buster-v20201014 \
--image-project=debian-cloud \
--boot-disk-size=10GB

CentOS

cat << "EOF" > init-mysql
#!/bin/bash

# Wait until Envoy is ready before installing mysql
while true; do
  rt=$(curl -s 127.0.0.1:15000/ready)
  if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
    echo "envoy is ready"
    break
  fi
  sleep 1
done

sudo yum update -y && sudo yum install -y mariadb-server

# Wait until mysql is ready
while true; do
  rt=$(which mysql)
  if [[ ! -z "${rt}" ]]; then
    echo "mysql is ready"
    break
  fi
  sleep 1
done

sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/my.cnf.d/mariadb-server.cnf

sudo systemctl restart mariadb

cat > grantaccess.sql << EOD

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

CREATE USER 'root'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
EOD

until sudo mysql < grantaccess.sql; do
   sleep 1
done

sudo systemctl restart mariadb

curl -LO https://raw.githubusercontent.com/istio/istio/release-1.9/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud \
--image-family=centos-8 \
--boot-disk-size=30GB

Crea un WorkloadGroup per il carico di lavoro MySQL

kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
 name: mysql
 namespace: default
spec:
 metadata:
   labels:
     app.kubernetes.io/name: mysql
   annotations:
     security.cloud.google.com/IdentityProvider: google
 template:
   serviceAccount: WORKLOAD_SERVICE_ACCOUNT
EOF

Utilizza lo script VM riportato sopra per creare un nuovo modello di istanza per preparare le istanze per il tuo mesh.

./asm_vm create_gce_instance_template \
asm-mysql-instance-template \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name mysql \
--source_instance_template mysql-instance-template

Crea un gruppo di istanze gestite di Compute Engine utilizzando il modello di istanza appena creato.

gcloud compute instance-groups managed create mysql-instance \
--template asm-mysql-instance-template \
--zone=us-central1-c \
--project=PROJECT_ID \
--size=1

Creare un servizio

Creare un servizio Kubernetes per il servizio MySQL.

Crea un servizio Kubernetes utilizzando questo comando:

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
 name: mysql
 namespace: default
 labels:
   asm_resource_type: VM
spec:
 ports:
 - name: mysql
   port: 3306
   protocol: TCP
   targetPort: 3306
 selector:
   app.kubernetes.io/name: mysql
EOF

Utilizzo della dashboard della UI di Anthos

Per visualizzare il nuovo servizio basato su VM che hai creato, fai clic su Anthos > Mesh di servizi dalla barra di navigazione principale a sinistra. Verrà visualizzata una tabella dei servizi in esecuzione nella tua rete mesh. Il servizio che hai aggiunto dovrebbe essere visualizzato nella tabella, con un valore Type pari a VM e alcune metriche di alto livello. Per visualizzare altri dati di telemetria relativi al servizio basato su VM, fai clic sul nome del servizio per visualizzare la dashboard del livello di servizio.

Per ulteriori informazioni su come utilizzare la dashboard della UI di Anthos, consulta Esplorazione di Anthos Service Mesh nella console Cloud.

Gestisci il traffico nei carichi di lavoro delle VM

Puoi modificare le regole di networking per controllare il flusso del traffico in entrata e in uscita dalle VM.

Controlla il traffico verso un nuovo servizio di classificazione (da pod a VM)

Crea un altro servizio di classificazione in Bookinfo che utilizzerà l'istanza MySQL creata in precedenza come origine dati e specifica una regola di routing che obbliga il servizio di recensione a utilizzare il nuovo servizio di classificazione.

Crea un nuovo servizio di valutazione per utilizzare l'istanza MySQL.

kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: ratings-v2-mysql-vm
 labels:
   app: ratings
   version: v2-mysql-vm
spec:
 replicas: 1
 selector:
   matchLabels:
     app: ratings
     version: v2-mysql-vm
 template:
   metadata:
     labels:
       app: ratings
       version: v2-mysql-vm
   spec:
     serviceAccountName: bookinfo-ratings
     containers:
     - name: ratings
       image: docker.io/istio/examples-bookinfo-ratings-v2:1.16.2
       imagePullPolicy: IfNotPresent
       env:
         - name: DB_TYPE
           value: "mysql"
         - name: MYSQL_DB_HOST
           value: mysql.default.svc.cluster.local
         - name: MYSQL_DB_PORT
           value: "3306"
         - name: MYSQL_DB_USER
           value: root
         - name: MYSQL_DB_PASSWORD
           value: password
       ports:
       - containerPort: 9080
EOF

Crea una regola di routing.

kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: reviews
spec:
 hosts:
 - reviews
 http:
 - route:
   - destination:
       host: reviews
       subset: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: ratings
spec:
 hosts:
 - ratings
 http:
 - route:
   - destination:
       host: ratings
       subset: v2-mysql-vm
EOF

Applica le regole di destinazione per i servizi creati.

kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: reviews
spec:
 host: reviews
 subsets:
 - name: v1
   labels:
     version: v1
 - name: v2
   labels:
     version: v2
 - name: v3
   labels:
     version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: ratings
spec:
 host: ratings
 subsets:
 - name: v1
   labels:
     version: v1
 - name: v2
   labels:
     version: v2
 - name: v2-mysql
   labels:
     version: v2-mysql
 - name: v2-mysql-vm
   labels:
     version: v2-mysql-vm
EOF

Convalida del deployment dell'applicazione in corso...

Per vedere se l'applicazione BookInfo funziona, devi inviare traffico al gateway in entrata.

Se hai installato Anthos Service Mesh su GKE, recupera l'indirizzo IP esterno del gateway in entrata che hai creato nei passaggi precedenti:

kubectl get svc istio-ingressgateway -n istio-system

Output:

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
istio-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

In questo esempio, l'indirizzo IP del servizio in entrata è 35.239.7.64.

Prova dell'applicazione

Verifica che l'app BookInfo funzioni con curl:
```
curl -I http://EXTERNAL_IP/productpage
```
Se la risposta mostra 200, significa che l'applicazione funziona correttamente con Anthos Service Mesh.
Per visualizzare la pagina web BookInfo, inserisci il seguente indirizzo nel browser:
```
http://EXTERNAL_IP/productpage
```
Verifica nella home page dell'applicazione Bookinfo che siano visualizzate cinque stelle da Reviewer1 e quattro stelle da Reviewer2.

Garantire la sicurezza nei carichi di lavoro delle VM

Applicare la sicurezza sui carichi di lavoro delle VM equivale a applicare la sicurezza sui carichi di lavoro Kubernetes. Per ulteriori informazioni, consulta la pagina relativa alla sicurezza di Istio.

Dopo aver completato i passaggi precedenti, la VM di Compute Engine avrà un certificato del carico di lavoro emesso da Google. Nel certificato, il valore SubjectAlternativeName mostra l'identità dei carichi di lavoro Anthos della VM nel formato spiffe://<workload_identity_pool>/ns/WORKLOAD_NAMESPACE/sa/WORKLOAD_SERVICE_ACCOUNT.

Per maggiori informazioni, consulta pool di identità per i carichi di lavoro.

Attiva la modalità restrittiva di mTLS per la rete mesh

Applica il seguente codice YAML per applicare il protocollo mTLS restrittivo a livello di mesh.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF

Autorizzazione per il traffico da servizio a servizio

Utilizza AuthorizationPolicy per controllare l'accesso tra le applicazioni sulla tua VM di Compute Engine e altri carichi di lavoro mesh (ad esempio, sul cluster GKE).

Esempio: impedire ai carichi di lavoro Kubernetes di accedere alle VM di Compute Engine

Il seguente criterio di autorizzazione nega a un carico di lavoro Kubernetes ratings di accedere ai carichi di lavoro delle VM di Compute Engine che gestiscono il server MySQL ratings.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: mysql-deny
  namespace: default
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: mysql
  action: DENY
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
EOF

Dopo aver applicato l'esempio AuthorizationPolicy, dovresti visualizzare un messaggio di errore Ratings service is currently unavailable nella sezione delle recensioni dei libri nella pagina del prodotto.

Installazione dell'agente Cloud Monitoring

Puoi installare l'agente Cloud Monitoring per raccogliere e monitorare le metriche di sistema e delle applicazioni dalle tue istanze VM. Ciò consente di monitorare le metriche chiave, ad esempio l'utilizzo di CPU e memoria sull'agente.

Per ulteriori informazioni, consulta la documentazione dell'agente Cloud Monitoring.

Risoluzione dei problemi

Per suggerimenti sulla risoluzione dei problemi, consulta Risoluzione dei problemi relativi al supporto delle VM.