Aggiungi macchine virtuali Compute Engine ad Anthos Service Mesh

Questa pagina descrive come aggiungere macchine virtuali (VM) Compute Engine ad Anthos Service Mesh su Google Kubernetes Engine (GKE). Questa pagina mostra come installare Anthos Service Mesh 1.10.6 con l'opzione che prepara il cluster per l'aggiunta di una VM.

  • Se hai già installato Anthos Service Mesh 1.9 or a 1.10 patch release, questa pagina mostra come eseguire l'upgrade ad Anthos Service Mesh 1.10.6 con l'opzione richiesta per aggiungere una VM.

  • Se disponi di Anthos Service Mesh 1.9 e non vuoi eseguire l'upgrade, consulta la guida di Anthos Service Mesh 1.9 per istruzioni sull'aggiunta di VM ad Anthos Service Mesh 1.9.

  • Se hai una versione precedente di Anthos Service Mesh, devi prima eseguire l'upgrade di Anthos Service Mesh alla versione 1.9 o successiva.

Questa pagina fornisce la riga di comando per l'installazione del piano di controllo nel cluster.

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. È una procedura simile a quella dei 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 out del numero di carichi di lavoro sulle istanze 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 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 nell'interfaccia utente di GKE Enterprise e Anthos Service Mesh.

Prerequisiti

Prima di iniziare:

Esamina il progetto Cloud, le licenze di GKE Enterprise e i requisiti generali descritti in Prerequisiti.

Requisiti per i cluster

Prima di continuare, assicurati che il cluster soddisfi i requisiti di GKE. Inoltre, il supporto delle VM Anthos Service Mesh richiede che:

  • Puoi specificare Mesh CA come autorità di certificazione (CA) quando installi Anthos Service Mesh.
  • Non esegui l'override di Stackdriver per la telemetria. Stackdriver è configurato per impostazione predefinita quando installi Anthos Service Mesh.
  • Il cluster è registrato in un parco risorse. Tuttavia, se il cluster non è registrato, il processo di installazione della VM registra il cluster nel progetto specificato.

Per iniziare

Segui la procedura descritta in Inizia per:

Se non hai installato Anthos Service Mesh, vai alla sezione successiva. Se disinstalla Anthos Service Mesh, segui i passaggi descritti in Installazioni esistenti.

Nuova installazione

Configura il cluster Anthos Service Mesh per le VM preparando il piano di controllo 1.10 di Anthos Service Mesh.

Il seguente comando mostra come installare il piano di controllo nel cluster di Anthos Service Mesh con --option vm, che prepara il piano di controllo per l'aggiunta di VM.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm
  • --project_id, --cluster_name e --cluster_location Specifica l'ID progetto in cui si trova il cluster, il nome del cluster e la zona o la regione del cluster.
  • --output_dir Includi questa opzione per specificare una directory in cui asmcli scarica il pacchetto anthos-service-mesh ed estrae il file di installazione, che contiene istioctl, esempi e file manifest. In caso contrario, asmcli scarica i file in una directory tmp. Puoi specificare un percorso relativo o un percorso completo. La variabile di ambiente $PWD non funziona in questo caso.
  • --enable_all Consente allo script di:
    • Concedi le autorizzazioni IAM richieste.
    • Abilita le API di Google richieste.
    • Imposta un'etichetta sul cluster che identifica il mesh.
    • Registra il cluster nel parco risorse, se non è già registrato.

  • --ca mesh_ca Utilizza Mesh CA come autorità di certificazione. asmcliConfigura Mesh CA per utilizzare l'identità del carico di lavoro del parco risorse
  • --option vm prepara il cluster per l'inclusione di una VM nel mesh di servizi.

Se sul tuo cluster sono già in esecuzione carichi di lavoro, esegui nuovamente il deployment dei carichi di lavoro e poi torna a questa pagina per aggiungere le VM.

Installazioni esistenti

Se Anthos Service Mesh è già stato installato sul tuo cluster, segui questi passaggi:

  1. Registra il cluster nel parco risorse, se non l'hai ancora fatto.

  2. Esegui il comando seguente per preparare e verificare che l'installazione di Anthos Service Mesh sia pronta per i carichi di lavoro delle VM.

    ./asmcli experimental vm prepare-cluster \
    --project_id PROJECT_ID \
    --cluster_name CLUSTER_NAME \
    --cluster_location CLUSTER_LOCATION

    In caso di esito positivo, il comando restituisce quanto segue:

    The cluster is ready for adding VM workloads.
Please follow the Anthos Service Mesh for Compute Engine VM user guide to add
Compute Engine VMs to your mesh.

Il comando svolge le seguenti operazioni:

  1. Abilita la registrazione automatica delle VM: questa operazione viene eseguita impostando le variabili PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION e PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY 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. Su tutti i piani di controllo Anthos Service Mesh 1.9 o versioni successive installati con asmcli, la registrazione automatica delle VM sarà abilitata per impostazione predefinita.

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

  3. Installa il CRD IdentityProvider e registra una RP Google IdentityProvider per consentire alle VM di autenticarsi sul piano di controllo Anthos Service Mesh e comunicare in modo sicuro con il resto del mesh di servizi.

  4. Registra il cluster in un parco risorse e abilita l'identità del carico di lavoro, se utilizzi --enable_all o --enable_registration nello script asmcli.

  5. Abilita la funzionalità Service Mesh nel parco risorse. Questa funzionalità gestirà i criteri necessari per consentire alle VM di comunicare in modo sicuro con il mesh.

Installa gateway in entrata

Anthos Service Mesh ti offre la possibilità di eseguire il deployment e gestire gateway come parte del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera sul perimetro della rete mesh che riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti forniscono un controllo granulare sul traffico in entrata e in uscita dal mesh.

  1. Crea uno spazio dei nomi per il gateway in entrata, se non ne hai già uno. I gateway sono carichi di lavoro degli utenti e, come best practice, non deve essere eseguito il deployment nello spazio dei nomi del piano di controllo. Sostituisci GATEWAY_NAMESPACE con il nome del tuo spazio dei nomi.

    kubectl create namespace GATEWAY_NAMESPACE

  2. Abilita l'inserimento automatico sul gateway applicando un'etichetta di revisione allo spazio dei nomi del gateway. L'etichetta di revisione viene utilizzata dal webhook dell'iniettore sidecar per associare i proxy inseriti a una determinata revisione del piano di controllo. L'etichetta di revisione da utilizzare dipende dal deployment di Anthos Service Mesh gestito o del piano di controllo nel cluster.

    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-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,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-1106-2.

    2. Applica l'etichetta di revisione allo spazio dei nomi. Nel comando seguente, REVISION è il valore dell'etichetta di revisione istiod che hai annotato nel passaggio precedente.

      kubectl label namespace GATEWAY_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. Passa alla directory specificata in --output_dir.

  4. Puoi eseguire il deployment della configurazione del gateway in entrata di esempio che si trova nella directory samples/gateways/istio-ingressgateway/ così com'è oppure modificarla in base alle tue esigenze.

    kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway

Scopri di più sulle best practice per i gateway.

Aggiungi le tue VM

In questa sezione aggiungerai istanze di Compute Engine al tuo mesh in base al modello di istanza che crei con gcloud. gcloud genera solo la configurazione necessaria per l'agente proxy di servizio. Per includere ulteriori configurazioni nel modello di istanza, utilizza la guida di riferimento di gcloud per ulteriori informazioni.

Per aggiungere VM al tuo mesh, segui questi passaggi:

  1. Imposta le seguenti variabili di ambiente da utilizzare nei passaggi successivi. Imposta queste variabili per ogni carico di lavoro delle 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.

  2. Se non esiste già, crea lo spazio dei nomi per i carichi di lavoro VM:

    kubectl create ns WORKLOAD_NAMESPACE

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

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

  5. Utilizza il comando gcloud beta compute instance-templates create con il flag --mesh per creare un modello di istanza per le tue istanze Compute Engine Anthos Service Mesh.

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

    Se il modello di istanza 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 interruzioni temporanee della rete.

    Per saperne di più sulla creazione di modelli di istanza, consulta Creazione di modelli di istanza.

    gcloud beta compute instance-templates create \
ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

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

  7. 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 out del numero di carichi di lavoro sulle istanze Compute Engine, partendo da una dimensione MIG 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.

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

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

  10. Per utilizzare un'applicazione di esempio sulla tua VM, consulta Deployment di un'applicazione di esempio.

Esegui di nuovo il deployment dei carichi di lavoro dopo l'upgrade di un piano di controllo nel cluster

Se hai eseguito l'upgrade di Anthos Service Mesh nella sezione precedente e alcuni carichi di lavoro sono in esecuzione sul tuo cluster, esegui il passaggio al nuovo piano di controllo.

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:

  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 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-1106-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1106-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1106-2,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-1106-2.

    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.

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

  3. Crea un nuovo modello di istanza utilizzando gcloud. Assicurati di includere la stessa configurazione se avessi un modello di istanza per lo stesso carico di lavoro.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

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

  5. 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 alla configurazione del modello di istanza, è 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.

  1. Crea un nuovo modello di istanza utilizzando gcloud.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

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

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

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

  2. Per attivare l'inserimento automatico di sidecar, scegli l'istruzione seguente in base al tipo di piano di controllo di Anthos Service Mesh.

    Utilizza il seguente comando per individuare l'etichetta in 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-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,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-1106-2.

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

  4. Esegui il deployment dell'applicazione nello spazio dei nomi predefinito utilizzando kubectl:

    kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

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

    e

    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

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

  7. Verifica che la pagina del prodotto sia accessibile. Nel comando seguente, GATEWAY_NAMESPACE è lo spazio dei nomi del gateway Istio.

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n GATEWAY_NAMESPACE 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.

  1. Crea 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 il server mariadb 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

# Wait until DNS is ready before installing mysql
while true; do
  curl -I productpage.default.svc:9080
  if [[ $? -eq 0 ]]; then
    echo "dns 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.10/samples/bookinfo/src/mysql/mysqldb-init.sql

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

    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

# Wait until DNS is ready before installing mysql
while true; do
  curl -I productpage.default.svc:9080
  if [[ $? -eq 0 ]]; then
    echo "dns 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.10/samples/bookinfo/src/mysql/mysqldb-init.sql

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

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

  3. Utilizza gcloud per creare un nuovo modello di istanza al fine di preparare le istanze per il mesh e includere lo script di avvio creato in precedenza.

    Debian

    gcloud beta compute instance-templates create asm-mysql-instance-template \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
--project PROJECT_ID \
--metadata-from-file=startup-script=init-mysql \
--image-project=debian-cloud --image-family=debian-10 --boot-disk-size=10GB

    CentOS

    gcloud beta compute instance-templates create asm-mysql-instance-template \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
--project PROJECT_ID \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud --image-family=centos-8 --boot-disk-size=20GB

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

Crea un servizio Kubernetes per il servizio MySQL 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 con i servizi in esecuzione nel 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.

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

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

  3. 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 GATEWAY_NAMESPACE

    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

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

  2. Per visualizzare la pagina web BookInfo, inserisci il seguente indirizzo nel browser:

    http://EXTERNAL_IP/productpage

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