Installa Cloud Service Mesh

Questa pagina spiega come installare Cloud Service Mesh su GKE e su piattaforme on-premise:

• Esegui asmcli per eseguire una nuova installazione di Cloud Service Mesh 1.20.8-asm.10.
• (Facoltativo) Esegui il deployment di un gateway in entrata.
• Esegui il deployment o il ricoinvolgimento dei carichi di lavoro per iniettare i proxy sidecar.

Limitazioni

Nota. Vi sono delle limitazioni:

• Per utilizzare Cloud Service Mesh, tutti i cluster Cloud Service Mesh per un mesh devono essere registrati allo stesso parco risorse in qualsiasi momento. Gli altri cluster del progetto di un cluster Cloud Service Mesh non devono essere registrati in un parco risorse diverso.

• Lo strumento asmcli deve avere accesso all'endpoint Google Kubernetes Engine (GKE). Puoi configurare l'accesso tramite un server "jump", ad esempio una VM Compute Engine all'interno del Virtual Private Cloud (VPC) che fornisce accesso specifico.

Prima di iniziare

Prima di iniziare, assicurati di:

• Esamina i prerequisiti.
• Esamina le informazioni riportate in Pianificare l'installazione.
• Installa gli strumenti richiesti.
• Scarica asmcli.
• Concedi le autorizzazioni di amministratore del cluster.
• Convalida il progetto e il cluster.

Installazione di Anthos Service Mesh

Di seguito viene descritto come installare Cloud Service Mesh:

1. Esegui asmcli install per installare il piano di controllo in-cluster su un singolo cluster. Per esempi di riga di comando, consulta le sezioni seguenti. Gli esempi contengono sia argomenti obbligatori sia argomenti facoltativi che potresti trovare utili. Ti consigliamo di specificare sempre l'argomento output_dir in modo da poter individuare facilmente gateway e strumenti di esempio come istioctl. Consulta la barra di navigazione sulla destra per un elenco degli esempi.

2. I cluster GKE privati richiedono un ulteriore passaggio di configurazione del firewall per permitire il traffico verso istiod.

3. (Facoltativo) Installa un gateway di ingresso. Per impostazione predefinita, asmcli non installa istio-ingressgateway. Ti consigliamo di eseguire il deployment e gestire il piano di controllo e i gateway separatamente. Se hai bisogno del valore predefinito istio-ingressgateway installato con il piano di controllo in-cluster, includi l'argomento --option legacy-default-ingressgateway.

4. Per completare la configurazione di Cloud Service Mesh, devi attivare l'iniezione automatica dei sidecar e eseguire il deployment o il redeployment dei carichi di lavoro.

5. Se stai installando Cloud Service Mesh su più di un cluster, esegui asmcli install su ogni cluster. Quando esegui asmcli install, assicurati di utilizzare lo stesso FLEET_PROJECT_ID per ogni cluster. Dopo aver installato Cloud Service Mesh, consulta le istruzioni per configurare un mesh multi-cluster su GKE o al di fuori di Google Cloud.

6. Se i tuoi cluster si trovano su reti diverse (come accade in modalità isola), devi passare un nome di rete univoco a asmcli utilizzando il flag --network_id.

Installa le funzionalità predefinite e la CA Mesh

Questa sezione mostra come eseguire asmcli per installare Cloud Service Mesh con le funzionalità supportate predefinite per la tua piattaforma e attivare l'autorità di certificazione Cloud Service Mesh come autorità di certificazione.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

Installa le funzionalità predefinite e il servizio Certificate Authority (CA)

Questa sezione mostra come eseguire asmcli per installare Cloud Service Mesh con le funzionalità supportate predefinite per la tua piattaforma e attivare il servizio CA come autorità di certificazione.

Oltre a Mesh CA, puoi configurare Cloud Service Mesh per utilizzare Certificate Authority Service. Questa guida ti offre l'opportunità di eseguire l'integrazione con CA Service, consigliato per i seguenti casi d'uso:

• Se hai bisogno di autorità di certificazione diverse per firmare i certificati dei carichi di lavoro su cluster diversi.
• Se vuoi utilizzare i istiod certificati del plug-in CA personalizzato.
• Se devi eseguire il backup delle chiavi di firma in un HSM gestito.
• Se operi in un settore altamente regolamentato e sei soggetto a conformità.
• Se vuoi collegare la CA Cloud Service Mesh a un certificato radice aziendale personalizzato per firmare i certificati dei carichi di lavoro.

Il costo del CA Mesh è incluso nei prezzi di Cloud Service Mesh. Il servizio CA non è incluso nel prezzo base di Cloud Service Mesh e viene addebitato separatamente. Inoltre, il servizio CA è dotato di un SLA esplicito, mentre Mesh CA no.

Per questa integrazione, a tutti i carichi di lavoro in Cloud Service Mesh vengono concessi ruoli IAM:

• privateca.workloadCertificateRequester
• privateca.auditor
• privateca.template (obbligatorio se utilizzi un modello di certificato)

Configura CA Service

1. Crea il pool di CA nel livello DevOps e nella stessa regione del cluster a cui serve per evitare problemi di latenza eccessiva o potenziali interruzioni tra regioni. Per saperne di più, vedi Livelli ottimizzati per il carico di lavoro.
2. Crea l'autorità di certificazione per avere almeno un'autorità di certificazione attiva nel pool di CA nello stesso progetto del cluster GKE. Utilizza le CA subordinate per firmare i certificati dei carichi di lavoro di Cloud Service Mesh. Prendi nota del pool di CA corrispondente alla CA subordinata.

3. Se è destinata a gestire solo i certificati per i carichi di lavoro Cloud Service Mesh, imposta il seguente criterio di emissione per il pool di CA:

   policy.yaml

   baselineValues:
     keyUsage:
       baseKeyUsage:
         digitalSignature: true
         keyEncipherment: true
       extendedKeyUsage:
         serverAuth: true
         clientAuth: true
     caOptions:
       isCa: false
   identityConstraints:
     allowSubjectPassthrough: false
     allowSubjectAltNamesPassthrough: true
     celExpression:
       expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
   

4. Per aggiornare il criterio di emissione del pool di CA, usa il seguente comando:

   gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml
   

   Per informazioni su come impostare un criterio in un pool, consulta Utilizzare una norma di emissione dei certificati.

5. Se utilizzi un modello di certificato, configuralo ora. Per saperne di più, consulta la guida di CA Service per i certificati Workload Identity. Assicurati che il modello di certificato venga creato nella stessa regione del pool di CA. Se sono presenti più regioni per i pool di CA, crea un modello di certificato per regione.

Configura Cloud Service Mesh per utilizzare CA Service

Installa le funzionalità predefinite con la CA Istio

Questa sezione spiega come:

• Genera certificati e chiavi per la CA Istio utilizzata da Cloud Service Mesh per firmare i tuoi workload.
• Esegui asmcli per installare Cloud Service Mesh con le funzionalità predefinite e attivare la CA Istio.

Per impostazione predefinita, gli ambienti che installano Cloud Service Mesh con Istio CA registrano le metriche in Prometheus. Se vuoi utilizzare le dashboard di Cloud Service Mesh, devi attivare Stackdriver. Per ulteriori informazioni, vedi Installare con funzionalità facoltative.

Per la massima sicurezza, ti consigliamo vivamente di gestire una CA principale offline e di utilizzare le CA secondarie per emettere certificati per ogni cluster. Per ulteriori informazioni, consulta Collegare i certificati CA. In questa configurazione, tutti i carichi di lavoro nel mesh di servizi utilizzano la stessa autorità di certificazione (CA) principale. Ogni CA Cloud Service Mesh utilizza una chiave di firma e un certificato CA intermedia, firmati dalla CA radice. Quando esistono più CA all'interno di un mesh, viene stabilita 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.

Il file Makefile per generare i certificati si trova nella sottodirectory istio-1.20.8-asm.10 della directory --output_dir specificata nel comando asmcli validate. Se non hai eseguito asmcli validate o se non hai la directory scaricata localmente, puoi ottenere il file Makefile scaricando il file di installazione di Cloud Service Mesh ed estraendo i contenuti.

1. Passa alla directory istio-1.20.8-asm.10.

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

   mkdir -p certs && \
   pushd certs

3. Genera un certificato e una chiave radice:

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

   Vengono generati i seguenti file:

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

4. Genera un certificato e una chiave intermedi:

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

   Verranno generati questi file in una directory denominata cluster1:

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

   Se esegui questi passaggi utilizzando un computer offline, copia la directory generata su un computer con accesso ai cluster.

5. Torna alla directory precedente:

   popd

6. Esegui asmcli per installare un mesh utilizzando la CA Istio:

   GKE

   Esegui il seguente comando per installare il piano di controllo con le funzionalità predefinite e la CA Istio. Inserisci i valori nei segnaposto forniti.

    ./asmcli install \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME \
      --cluster_location CLUSTER_LOCATION \
      --fleet_id FLEET_PROJECT_ID \
      --output_dir DIR_PATH \
      --enable_all \
      --ca citadel \
      --ca_cert CA_CERT_FILE_PATH \
      --ca_key CA_KEY_FILE_PATH \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH
   

   • --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.
   • --fleet_id L'ID del progetto host del parco risorse. Se non includi questa opzione, asmcli utilizza il progetto in cui è stato creato il cluster durante la registrazione 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, i sample e i 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 qui.
   • --enable_all Consente allo script di:
     • Concedi le autorizzazioni IAM richieste.
     • Abilita le API Google richieste.
     • Imposta un'etichetta sul cluster che identifichi il mesh.
     • Registra il cluster nel parco risorse, se non è già registrato.

   • -ca citadel Utilizza la CA Istio come autorità di certificazione.
   • --ca_cert Il certificato intermedio
   • --ca_key La chiave del certificato intermedio
   • --root_cert Il certificato radice
   • --cert_chain La catena di certificati

   On-premise

   Esegui i seguenti comandi su Google Distributed Cloud o su Google Distributed Cloud per installare il piano di controllo con le funzionalità predefinite e la CA Istio. Inserisci i valori nei segnaposto forniti.

   1. Imposta il contesto corrente sul cluster di utenti:

      kubectl config use-context CLUSTER_NAME
      

   2. Esegui asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id L'ID del progetto host del parco risorse.
      • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative che utilizzano un carattere `~` non funzioneranno.
      • --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, i sample e i 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 qui.
      • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
      • --enable_all Consente allo script di:
        • Concedi le autorizzazioni IAM richieste.
        • Abilita le API Google richieste.
        • Imposta un'etichetta sul cluster che identifichi il mesh.
        • Registra il cluster nel parco risorse, se non è già registrato.
      • -ca citadel Utilizza la CA Istio come autorità di certificazione.
      • --ca_cert Il certificato intermedio
      • --ca_key La chiave del certificato intermedio
      • --root_cert Il certificato radice
      • --cert_chain La catena di certificati

   AWS

   Esegui i seguenti comandi su GKE su AWS per installare il piano di controllo con le funzionalità predefinite e la CA Istio. Inserisci i valori nei segnaposto forniti. Puoi scegliere di attivare Ingress per la subnet pubblica o per la subnet privata.

   Pubblico

   1. Imposta il contesto corrente sul cluster di utenti:

      kubectl config use-context CLUSTER_NAME
      

   2. Esegui asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id L'ID del progetto host del parco risorse.
      • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative che utilizzano un carattere `~` non funzioneranno.
      • --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, i sample e i 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 qui.
      • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
      • --enable_all Consente allo script di:
        • Concedi le autorizzazioni IAM richieste.
        • Abilita le API Google richieste.
        • Imposta un'etichetta sul cluster che identifichi il mesh.
        • Registra il cluster nel parco risorse, se non è già registrato.
      • -ca citadel Utilizza la CA Istio come autorità di certificazione.
      • --ca_cert Il certificato intermedio.
      • --ca_key La chiave del certificato intermedio.
      • --root_cert Il certificato radice.
      • --cert_chain La catena di certificati.

   Privato

   1. Imposta il contesto corrente sul cluster di utenti:

      kubectl config use-context CLUSTER_NAME
      

   2. Salva il seguente codice YAML in un file denominato istio-operator-internal-lb.yaml:

      apiVersion: install.istio.io/v1alpha1
      kind: IstioOperator
      spec:
        components:
          ingressGateways:
          - enabled: true
            k8s:
              serviceAnnotations:
                service.beta.kubernetes.io/aws-load-balancer-internal: "true"
            name: istio-ingressgateway
      

   3. Esegui asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --ca citadel \
        --ca_cert FILE_PATH \
        --ca_key FILE_PATH \
        --root_cert FILE_PATH \
        --cert_chain FILE_PATH \
        --custom_overlay istio-operator-internal-lb.yaml
      

      • --fleet_id L'ID del progetto host del parco risorse.
      • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative che utilizzano un carattere `~` non funzioneranno.
      • --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, i sample e i 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 qui.
      • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
      • --enable_all Consente allo script di:
        • Concedi le autorizzazioni IAM richieste.
        • Abilita le API Google richieste.
        • Imposta un'etichetta sul cluster che identifichi il mesh.
        • Registra il cluster nel parco risorse, se non è già registrato.
      • -ca citadel Utilizza la CA Istio come autorità di certificazione.
      • --ca_cert Il certificato intermedio.
      • --ca_key La chiave del certificato intermedio.
      • --root_cert Il certificato radice.
      • --cert_chain La catena di certificati.
      • --custom_overlay Il nome del file overlay creato. Per ulteriori informazioni sui file overlay, consulta Attivare funzionalità facoltative nel piano di controllo in-cluster.

   Azure

   Esegui i comandi seguenti su GKE su Azure (anteprima) per installare il piano di controllo con le funzionalità predefinite e la CA Istio. Inserisci i valori nei segnaposto forniti. Puoi scegliere di attivare Ingress per la subnet pubblica o per la subnet privata.

   Pubblico

   1. Imposta il contesto corrente sul cluster di utenti:

      kubectl config use-context CLUSTER_NAME
      

   2. Esegui asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --option attached-cluster \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH
      

      • --fleet_id L'ID del progetto host del parco risorse.
      • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative che utilizzano un carattere `~` non funzioneranno.
      • --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, i sample e i 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 qui.
      • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
      • --enable_all Consente allo script di:
        • Concedi le autorizzazioni IAM richieste.
        • Abilita le API Google richieste.
        • Imposta un'etichetta sul cluster che identifichi il mesh.
        • Registra il cluster nel parco risorse, se non è già registrato.
      • --option attached-cluster Imposta istiod come utility di firma predefinita.
      • -ca citadel Utilizza la CA Istio come autorità di certificazione.
      • --ca_cert Il certificato intermedio.
      • --ca_key La chiave del certificato intermedio.
      • --root_cert Il certificato radice.
      • --cert_chain La catena di certificati.

   Privato

   1. Imposta il contesto corrente sul cluster di utenti:

      kubectl config use-context CLUSTER_NAME
      

   2. Salva il seguente codice YAML in un file denominato istio-operator-internal-lb.yaml:

      apiVersion: install.istio.io/v1alpha1
      kind: IstioOperator
      spec:
        components:
          ingressGateways:
          - enabled: true
            k8s:
              serviceAnnotations:
                service.beta.kubernetes.io/aws-load-balancer-internal: "true"
            name: istio-ingressgateway
      

   3. Esegui asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --option attached-cluster \
        --ca citadel \
        --ca_cert FILE_PATH \
        --ca_key FILE_PATH \
        --root_cert FILE_PATH \
        --cert_chain FILE_PATH \
        --custom_overlay istio-operator-internal-lb.yaml
      

      • --fleet_id L'ID del progetto host del parco risorse.
      • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative che utilizzano un carattere `~` non funzioneranno.
      • --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, i sample e i 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 qui.
      • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
      • --enable_all Consente allo script di:
        • Concedi le autorizzazioni IAM richieste.
        • Abilita le API Google richieste.
        • Imposta un'etichetta sul cluster che identifichi il mesh.
        • Registra il cluster nel parco risorse, se non è già registrato.
      • --option attached-cluster Imposta istiod come utility di firma predefinita.
      • -ca citadel Utilizza la CA Istio come autorità di certificazione.
      • --ca_cert Il certificato intermedio.
      • --ca_key La chiave del certificato intermedio.
      • --root_cert Il certificato radice.
      • --cert_chain La catena di certificati.
      • --custom_overlay Il nome del file overlay creato. Per ulteriori informazioni sui file overlay, consulta Attivare funzionalità facoltative nel piano di controllo in-cluster.

   Amazon EKS

   Esegui i seguenti comandi su Amazon EKS per installare il piano di controllo con le funzionalità predefinite e la CA Istio. Inserisci i valori nei segnaposto forniti.

   1. Imposta il contesto corrente sul cluster di utenti:

      kubectl config use-context CLUSTER_NAME
      

   2. Esegui asmcli install:

      ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --option attached-cluster \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH \
        --network_id default
      

      • --fleet_id L'ID del progetto host del parco risorse.
      • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative che utilizzano un carattere `~` non funzioneranno.
      • --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, i sample e i 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 qui.
      • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
      • --enable_all Consente allo script di:
        • Concedi le autorizzazioni IAM richieste.
        • Abilita le API Google richieste.
        • Imposta un'etichetta sul cluster che identifichi il mesh.
        • Registra il cluster nel parco risorse, se non è già registrato.
      • --option attached-cluster Imposta istiod come utility di firma predefinita.
      • -ca citadel Utilizza la CA Istio come autorità di certificazione.
      • --ca_cert Il certificato intermedio
      • --ca_key La chiave del certificato intermedio
      • --root_cert Il certificato radice
      • --cert_chain La catena di certificati
      • --network_id Se stai configurando una rete mesh con più reti, imposta --network_id su un valore univoco per ogni cluster della rete mesh.

   Microsoft AKS

   Esegui i seguenti comandi su Microsoft AKS per installare il piano di controllo con le funzionalità predefinite e la CA Istio. Inserisci i valori nei segnaposto forniti.

   1. Imposta il contesto corrente sul cluster di utenti:

      kubectl config use-context CLUSTER_NAME
      

   2. Esegui asmcli install:

      HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
        --fleet_id FLEET_PROJECT_ID \
        --kubeconfig KUBECONFIG_FILE \
        --output_dir DIR_PATH \
        --platform multicloud \
        --enable_all \
        --option attached-cluster \
        --ca citadel \
        --ca_cert CA_CERT_FILE_PATH \
        --ca_key CA_KEY_FILE_PATH \
        --root_cert ROOT_CERT_FILE_PATH \
        --cert_chain CERT_CHAIN_FILE_PATH \
        --network_id default
      

      • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer Consente la registrazione a GKE Hub.
      • --fleet_id L'ID del progetto host del parco risorse.
      • --kubeconfig Il percorso completo del file kubeconfig. La variabile di ambiente $PWD non funziona qui. Inoltre, le posizioni dei file kubeconfig relative che utilizzano un carattere `~` non funzioneranno.
      • --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, i sample e i 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 qui.
      • --platform multicloud Specifica che la piattaforma è diversa da Google Cloud, ad esempio on-premise o multi-cloud.
      • --enable_all Consente allo script di:
        • Concedi le autorizzazioni IAM richieste.
        • Abilita le API Google richieste.
        • Imposta un'etichetta sul cluster che identifichi il mesh.
        • Registra il cluster nel parco risorse, se non è già registrato.
      • --option attached-cluster Imposta istiod come utility di firma predefinita.
      • -ca citadel Utilizza la CA Istio come autorità di certificazione.
      • --ca_cert Il certificato intermedio
      • --ca_key La chiave del certificato intermedio
      • --root_cert Il certificato radice
      • --cert_chain La catena di certificati
      • --network_id Se stai configurando una rete mesh con più reti, imposta --network_id su un valore univoco per ogni cluster della rete mesh.

Installazione con la CA Istio con Google Cloud Observability abilitata

Se vuoi utilizzare le dashboard di Cloud Service Mesh, devi abilitare Stackdriver.

./asmcli install \
   --project_id PROJECT_ID \
   --cluster_name CLUSTER_NAME \
   --cluster_location CLUSTER_LOCATION \
   --fleet_id FLEET_PROJECT_ID \
   --output_dir DIR_PATH \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH

Installazione con funzionalità facoltative

Un file overlay è un file YAML contenente una risorsa personalizzata IstioOperator (CR) che viene passata a asmcli per configurare il piano di controllo. Puoi override la configurazione predefinita del piano di controllo e attivare una funzionalità facoltativa passando il file YAML a asmcli. Puoi applicare altri overlay e ogni file di overlay sostituisce la configurazione dei livelli precedenti. Come best practice, consigliamo di salvare i file di overlay nel sistema di controllo delle versioni.

Esistono due opzioni per attivare le funzionalità facoltative: --option e --custom_overlay.

Utilizza --option se non devi modificare il file di overlay. Con questo metodo, asmclirecupera il file dal repository GitHub per te.

Utilizza --custom_overlay quando devi personalizzare il file di overlay.

Per ulteriori informazioni, consulta Attivare le funzionalità facoltative nel piano di controllo in-cluster.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

Installare i gateway

Cloud Service Mesh ti offre la possibilità di eseguire il deployment e gestire i gateway all'interno del tuo mesh di servizi. Un gateway descrive un bilanciatore del carico che opera all'esterno della rete mesh e riceve connessioni HTTP/TCP in entrata o in uscita. I gateway sono proxy Envoy che ti offrono un controllo granulare sul traffico in entrata e in uscita dal mesh.

1. Crea un nome di spazio per il gateway di ingresso se non ne hai già uno. I gateway sono carichi di lavoro utente e, come best practice, non devono essere eseguiti nel spazio dei nomi del piano di controllo. Sostituisci GATEWAY_NAMESPACE con il nome dello spazio dei nomi.

   kubectl create namespace GATEWAY_NAMESPACE
   

   Risultato previsto:

   namespace/GATEWAY_NAMESPACE created
   

2. Attiva l'iniezione automatica sul gateway. I passaggi richiesti dipendono dal fatto che tu voglia utilizzare le etichette di inserimento predefinite (ad esempio istio-injection=enabled) o l'etichetta di revisione nello spazio dei nomi del gateway. Il tag di revisione e l'etichetta di revisione predefiniti vengono utilizzati dall'webhook dell'iniettore sidecar per associare i proxy iniettati a una determinata revisione del piano di controllo.

   Etichette di inserimento predefinite

   Applica le etichette di inserimento predefinite allo spazio dei nomi.

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

   Etichetta revisione

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

      kubectl get deploy -n istio-system -l app=istiod -o \
        "jsonpath={.items[*].metadata.labels['istio\.io/rev']}{'\n'}"
      

      Il comando restituisce l'etichetta di revisione corrispondente alla versione di Cloud Service Mesh, ad esempio: asm-1208-10

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

      kubectl label namespace GATEWAY_NAMESPACE \
        istio.io/rev=REVISION --overwrite
      

      Risultato previsto:

      namespace/GATEWAY_NAMESPACE labeled
      

   Puoi ignorare il messaggio "istio.io/rev" not found nell'output. Ciò significa che in precedenza lo spazio dei nomi non aveva l'etichetta istio.io/rev, che dovresti aspettarti nelle nuove installazioni di Cloud Service Mesh o nei nuovi deployment. Poiché l'iniezione automatica non va a buon fine se uno spazio dei nomi ha sia l'etichetta istio.io/rev sia l'etichetta istio-injection, tutti i comandi kubectl label nella documentazione di Cloud Service Mesh specificano esplicitamente entrambe le etichette.

   Se lo spazio dei nomi del gateway non è etichettato, i pod istio-ingressgateway non andranno a buon fine con un errore ImagePullBackOff quando il gateway tenta di estrarre l'immagine auto. Questa immagine deve essere sostituita dall'webhook.

3. Scarica il file di configurazione .yaml del gateway di ingresso di esempio dal repository anthos-service-mesh-packages.

4. Applica la configurazione .yaml del gateway in entrata di esempio così com'è o modificala come necessario.

   kubectl apply -n GATEWAY_NAMESPACE \
     -f CONFIG_PATH/istio-ingressgateway
   

   Risultato previsto:

   deployment.apps/istio-ingressgateway created
   poddisruptionbudget.policy/istio-ingressgateway created
   horizontalpodautoscaler.autoscaling/istio-ingressgateway created
   role.rbac.authorization.k8s.io/istio-ingressgateway created
   rolebinding.rbac.authorization.k8s.io/istio-ingressgateway created
   service/istio-ingressgateway created
   serviceaccount/istio-ingressgateway created
   

Scopri di più sulle best practice per i gateway.

Esegui il deployment e il nuovo deployment dei carichi di lavoro

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

L'installazione non è completa finché non attivi l'iniezione automatica del proxy sidecar (iniezione automatica) e riavvii i pod per tutti i carichi di lavoro in esecuzione sul cluster prima dell'installazione di Cloud Service Mesh.

Per attivare l'iniezione automatica, etichetta gli spazi dei nomi con le etichette di iniezione predefinite se è configurato il tag predefinito o con un'etichetta di revisione impostata su istiod quando hai installato Cloud Service Mesh. Il tag revisione e l'etichetta revisione predefiniti vengono utilizzati dall'webhook di iniezione di sidecar per associare i sidecar iniettati a una revisione istiod. Dopo aver aggiunto l'etichetta, tutti i pod esistenti nello spazio dei nomi devono essere riavviati per l'iniezione dei sidecar.

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

1. I passaggi necessari per attivare l'iniezione automatica dipendono dal fatto che tu voglia utilizzare le etichette di inserimento predefinite o l'etichetta di revisione:

   Etichette di inserimento predefinite

   Nel seguente comando, NAMESPACE è il nome dello spazio dei nomi in cui vuoi attivare l'iniezione automatica.

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

   Poiché le etichette di inserimento predefinite inseriscono la revisione a cui fa riferimento il tag predefinito, non è necessario rinominare gli spazi dei nomi.

   Etichetta revisione

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

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

   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 attivare l'iniezione automatica 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 in precedenza lo spazio dei nomi non aveva l'etichetta istio-injection, che dovresti aspettarti nelle nuove installazioni di Cloud Service Mesh o nei nuovi deployment. Poiché il comportamento di inserimento automatico non è definito quando uno spazio dei nomi ha sia l'etichetta istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label nella documentazione di Cloud Service Mesh assicurano esplicitamente che ne sia impostato solo uno.

2. Se i carichi di lavoro erano in esecuzione sul cluster prima dell'installazione di Cloud Service Mesh, riavvia i pod per attivare la reintegrazione.

   La modalità di riavvio dei pod dipende dall'applicazione e dall'ambiente in cui si trova il cluster. Ad esempio, nell'ambiente di staging, potresti semplicemente eliminare tutti i pod, che verranno riavviati. Tuttavia, nell'ambiente di produzione potresti avere una procedura che implementa un deployment blue-green in modo da poter riavviare in sicurezza i pod per evitare interruzioni del traffico.

   Puoi utilizzare kubectl per eseguire un riavvio graduale:

   kubectl rollout restart deployment -n NAMESPACE
   

Passaggi successivi

• Scopri come configurare un mesh multi-cluster:

  • Se il tuo mesh è costituito interamente da cluster GKE, consulta Configurare un mesh multi-cluster su GKE.

  • Se il tuo mesh è costituito da cluster esterni a Google Cloud, consulta Configurare un mesh multi-cluster al di fuori di Google Cloud.

• Configura un indirizzo IP esterno on-premise.

• Esegui il deployment dell'applicazione di esempio Online Boutique.