Esegui il provisioning di Anthos Service Mesh gestito

Anthos Service Mesh gestito è un mesh di servizi gestito da Google che devi solo abilitare. Google gestisce affidabilità, upgrade, scalabilità e sicurezza al posto tuo in modo compatibile con le versioni precedenti.

Questa pagina mostra come utilizzare l'API della funzionalità fleet per configurare Anthos Service Mesh gestito.

Quando abiliti Anthos Service Mesh gestito utilizzando l'API del parco risorse:

• Google applica la configurazione consigliata del piano di controllo
• Google consente la gestione automatica del piano dati
• Il cluster è registrato in un canale di rilascio Anthos Service Mesh basato sul canale di rilascio del cluster Google Kubernetes Engine (GKE) e il piano di controllo e il piano dati vengono mantenuti aggiornati a ogni nuova release.
• Google abilita il rilevamento degli endpoint e il bilanciamento del carico tra cluster in tutto il mesh di servizi con impostazioni predefinite, anche se devi creare regole firewall.

Se vuoi:

• Per utilizzare gcloud per configurare Anthos Service Mesh gestito utilizzando le API e IAM di Google Cloud.
• Per configurare Anthos Service Mesh utilizzando le stesse API delle altre funzionalità del parco risorse.
• Per ottenere automaticamente la configurazione consigliata di Anthos Service Mesh per ciascuno dei tuoi cluster.

Nota: consigliamo di utilizzare l'API delle funzionalità del parco risorse per configurare automaticamente Anthos Service Mesh gestito, ma puoi anche configurare Anthos Service Mesh gestito utilizzando lo strumento asmcli. Devi utilizzare quella configurazione manuale per utilizzare CA privata o per scegliere un canale Anthos Service Mesh diverso dal tuo canale Google Kubernetes Engine (GKE).

Prerequisiti

Per iniziare, questa guida presuppone che tu abbia:

• Un progetto Cloud
• Un account di fatturazione Cloud
• Ottenute le autorizzazioni richieste per il provisioning di Anthos Service Mesh gestito
• Abilita Workload Identity sui tuoi cluster.

Requisiti

• Uno o più cluster con una versione supportata di GKE, in una delle regioni supportate.
• Assicurati che il cluster abbia una capacità sufficiente per i componenti richiesti che gestisce Anthos Service Mesh installa nel cluster.
  • Il deployment mdp-controller nello spazio dei nomi kube-system richiede CPU: 50 m, memoria: 128 Mi.
  • Il daemonset istio-cni-node nello spazio dei nomi kube-system richiede CPU: 100 m, memoria: 100 Mi su ciascun nodo.
• Assicurati che la macchina client da cui esegui il provisioning di Anthos Service Mesh gestito disponga di connettività di rete al server API.
• I cluster devono essere registrati in un parco risorse. Questa operazione è inclusa nelle istruzioni o può essere eseguita separatamente prima del provisioning.
• Nel progetto deve essere abilitata la funzionalità del parco risorse mesh di servizi. Questa operazione è inclusa nelle istruzioni o può essere eseguita separatamente.

• GKE Autopilot è supportato solo con GKE versione 1.21.3 e successive.

• Istio CNI è obbligatorio e installato per impostazione predefinita durante il provisioning di Anthos Service Mesh gestito.

• Anthos Service Mesh gestito può utilizzare più cluster GKE in un ambiente con rete singola a progetto singolo o in un ambiente con rete singola con più progetti.

  • Se unisci cluster che non sono nello stesso progetto, devono essere registrati nello stesso progetto host del parco risorse e i cluster devono trovarsi insieme in una configurazione di VPC condivisi sulla stessa rete.
  • Per un ambiente multi-cluster a progetto singolo, il progetto del parco risorse può essere uguale al progetto del cluster. Per ulteriori informazioni sui parchi risorse, consulta la Panoramica dei parchi risorse.
  • Per un ambiente con più progetti, ti consigliamo di ospitare il parco risorse in un progetto separato da quello dei progetti del cluster. Se i criteri dell'organizzazione e la configurazione esistente lo consentono, ti consigliamo di utilizzare il progetto VPC condiviso come progetto host del parco risorse. Per maggiori informazioni, consulta Configurazione dei cluster con un VPC condiviso.
  • Se la tua organizzazione utilizza Controlli di servizio VPC e stai eseguendo il provisioning di Anthos Service Mesh gestito su cluster GKE, devi anche seguire i passaggi descritti in Controlli di servizio VPC per Anthos Service Mesh.

Limitazioni

Attenzione: tieni presente le seguenti limitazioni specifiche del parco risorse: - Tutti i cluster Anthos Service Mesh per un mesh devono essere sempre registrati nello stesso parco risorse per utilizzare Anthos Service Mesh. Gli altri cluster nel progetto di un cluster Anthos Service Mesh non devono essere registrati in un parco risorse diverso.

Ti consigliamo di rivedere l'elenco delle funzionalità e delle limitazioni supportate da Anthos Service Mesh gestito. In particolare, tieni presente quanto segue:

• L'API IstioOperator non è supportata perché il suo scopo principale è controllare i componenti nel cluster.

  Nota: puoi comunque abilitare le funzionalità facoltative senza utilizzare l'API IstioOperator. Consulta Abilitazione delle funzionalità facoltative su Anthos Service Mesh gestito. Puoi anche utilizzare lo strumento di migrazione incluso in asmcli per convertire automaticamente altre funzionalità facoltative di IstioOperator in modo che siano compatibili con il piano di controllo gestito. Per maggiori informazioni, consulta Eseguire la migrazione da IstioOperator.

• L'abilitazione di Anthos Service Mesh gestito con l'API del parco risorse utilizzerà Mesh CA. Se il deployment della rete mesh di servizi prevede carichi di lavoro regolamentati o richiede Certificate Authority Service (CA Service), segui la procedura descritta in Esegui il provisioning di Anthos Service Mesh gestito utilizzando asmcli.

• Le migrazioni da Anthos Service Mesh gestito con asmcli a Anthos Service Mesh con API del parco risorse non sono supportate. Allo stesso modo, la configurazione di Anthos Service Mesh gestito con l'API del parco risorse da --management manual a --management automatic non è supportata.

• Per i cluster GKE Autopilot, la configurazione tra progetti è supportata solo con GKE 1.23 o versioni successive.

• Per i cluster GKE Autopilot, per adattarsi al limite di risorse di GKE Autopilot, i limiti e le richieste di risorse proxy predefiniti sono impostati su 500 milioni di CPU e 512 Mb di memoria. Puoi eseguire l'override dei valori predefiniti utilizzando l'inserimento personalizzato.

• Le funzionalità effettive disponibili per Anthos Service Mesh gestito dipendono dal canale di rilascio. Per ulteriori informazioni, consulta l'elenco completo delle funzionalità e delle limitazioni supportate da Anthos Service Mesh gestito.

• Durante il processo di provisioning per un piano di controllo gestito, viene eseguito il provisioning dei CRD Istio corrispondenti al canale selezionato nel cluster specificato. Se nel cluster sono presenti CRD Istio, verranno sovrascritti.

• Istio CNI non è compatibile con GKE Sandbox. Anthos Service Mesh gestito su Autopilot, quindi, non funziona con GKE Sandbox perché è richiesto CNI di Istio gestito.

Prima di iniziare

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. Configura gcloud (anche se utilizzi Cloud Shell).
1. Esegui l'autenticazione con Google Cloud CLI, dove FLEET_PROJECT_ID è l'ID del progetto host del parco risorse. In genere, FLEET_PROJECT_ID viene creato per impostazione predefinita e ha lo stesso nome del progetto.

          gcloud auth login --project FLEET_PROJECT_ID
   

2. Aggiorna i componenti:

          gcloud components update
   

7. Abilita le API richieste nel progetto host del parco risorse.

     gcloud services enable mesh.googleapis.com \
         --project=FLEET_PROJECT_ID
   

L'abilitazione di mesh.googleapis.com abilita le seguenti API:

Nota: alcune API obbligatorie hanno dipendenze transitive su altre API.

API	Finalità	Può essere disabilitato
meshconfig.googleapis.com	Anthos Service Mesh utilizza l'API Mesh Configuration per inoltrare i dati di configurazione dal tuo mesh a Google Cloud. Inoltre, l'abilitazione dell'API Mesh Configuration ti consente di accedere alle pagine Anthos Service Mesh nella console Google Cloud e di utilizzare l'autorità di certificazione Anthos Service Mesh (Mesh CA).	No
meshca.googleapis.com	Correlata all'autorità di certificazione Anthos Service Mesh utilizzata da Anthos Service Mesh gestito.	No
container.googleapis.com	Necessario per creare cluster Google Kubernetes Engine (GKE).	No
gkehub.googleapis.com	Necessario per gestire il mesh come un parco risorse.	No
monitoring.googleapis.com	Necessaria per acquisire la telemetria per i carichi di lavoro mesh.	No
stackdriver.googleapis.com	Obbligatorio per utilizzare l'interfaccia utente dei servizi.	No
opsconfigmonitoring.googleapis.com	Necessario per utilizzare l'UI dei servizi per cluster esterni a Google Cloud.	No
connectgateway.googleapis.com	Richiesto per consentire al piano di controllo Anthos Service Mesh gestito di accedere ai carichi di lavoro mesh.	Sì*
trafficdirector.googleapis.com	Abilita un piano di controllo gestito scalabile e a disponibilità elevata.	Sì*
networkservices.googleapis.com	Abilita un piano di controllo gestito scalabile e a disponibilità elevata.	Sì*
networksecurity.googleapis.com	Abilita un piano di controllo gestito scalabile e a disponibilità elevata.	Sì*

Avviso: la disabilitazione di connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com e/o networksecurity.googleapis.com comporta l'interruzione del funzionamento del piano di controllo gestito Anthos Service Mesh. Se il parco risorse non utilizza Anthos Service Mesh gestito su nessun cluster, è possibile disabilitare queste API.

Configurazione di Anthos Service Mesh gestito

I passaggi necessari per eseguire il provisioning di Anthos Service Mesh gestito utilizzando l'API del parco risorse dipendono dal fatto che tu preferisca l'attivazione per impostazione predefinita per i nuovi cluster del parco risorse o abilitarla per cluster.

Configura per il tuo parco risorse

Se hai abilitato la versione Google Kubernetes Engine (GKE) Enterprise, puoi abilitare Anthos Service Mesh gestito come configurazione predefinita per il tuo parco risorse. Ciò significa che per ogni nuovo cluster GKE su Google Cloud registrato durante la creazione del cluster sarà abilitato Anthos Service Mesh gestito sul cluster. Per saperne di più sulla configurazione predefinita del parco risorse, consulta Gestire le funzionalità a livello di parco risorse.

Per attivare le impostazioni predefinite a livello di parco risorse per Anthos Service Mesh gestito, completa i seguenti passaggi:

Console

1. Nella console Google Cloud, vai alla pagina Gestione funzionalità.

   Vai a Gestore funzionalità

2. Nel riquadro Mesh di servizi, fai clic su Configura.

3. Esamina le impostazioni ereditate da tutti i nuovi cluster che crei nella console Google Cloud e registra nel parco risorse.

   Nota: queste sono impostazioni di GKE che sono prerequisiti per l'utilizzo di Anthos Service Mesh.

4. Per applicare queste impostazioni, fai clic su Configura.

5. Nella finestra di dialogo di conferma, fai clic su Conferma.

6. (Facoltativo) Sincronizza i cluster esistenti con le impostazioni predefinite:

   1. Nell'elenco Cluster nel parco risorse, seleziona i cluster che vuoi sincronizzare. Puoi selezionare solo i cluster in cui è installato Anthos Service Mesh.
   2. Fai clic su Sincronizza con le impostazioni del parco risorse e fai clic su Conferma nella finestra di dialogo di conferma visualizzata. Questa operazione può richiedere alcuni minuti.

gcloud

Per configurare le impostazioni predefinite a livello di parco risorse utilizzando Google Cloud CLI, devi definire le seguenti impostazioni:

• Impostazioni a livello di parco risorse

  • Crea un file mesh.yaml contenente solo la singola riga management: automatic:

    echo "management: automatic" > mesh.yaml
    

  • Abilita Anthos Service Mesh per il tuo parco risorse:

    gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
        --fleet-default-member-config mesh.yaml
    

    Se viene visualizzato il seguente errore, devi abilitare GKE Enterprise.

    ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
    [anthos.googleapis.com] service is required for this operation and is not
    enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
    Console to enable it.: failed precondition
    

• Impostazioni a livello di cluster

  • Quando è tutto pronto per creare cluster da utilizzare con Anthos Service Mesh, creali e registrali in un unico passaggio con Google Cloud CLI per utilizzare la configurazione predefinita. Ad esempio:

    gcloud container clusters create-auto CLUSTER_NAME \
        --fleet-project FLEET_PROJECT_ID \
        --location=LOCATION
    

    Puoi ottenere il numero di progetto per il tuo progetto del parco risorse eseguendo questo comando:

    gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
    

    Il flag --location è la zona o la regione di computing (ad esempio us-central1-a o us-central1) per il cluster.

  • Se il progetto del cluster è diverso da quello host del parco risorse, devi consentire agli account di servizio Anthos Service Mesh nel progetto del parco risorse di accedere al progetto cluster e abilitare le API richieste nel progetto del cluster. Devi eseguire questa operazione una sola volta per ogni progetto del cluster.

    Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione ad accedere al progetto cluster:

    gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
    

    Abilita l'API Mesh sul progetto del cluster:

    gcloud services enable mesh.googleapis.com \
      --project=CLUSTER_PROJECT_ID
    

    Sostituisci CLUSTER_PROJECT_ID con l'identificatore univoco del progetto del cluster. Se hai creato il cluster nello stesso progetto del tuo parco risorse, CLUSTER_PROJECT_ID corrisponde a FLEET_PROJECT_ID.

Vai a Verificare che sia stato eseguito il provisioning del piano di controllo.

Configura per cluster

Segui questi passaggi per configurare Anthos Service Mesh gestito per ogni cluster nel tuo mesh individualmente.

Attiva la funzionalità del parco risorse Anthos Service Mesh

Abilita Anthos Service Mesh nel progetto del parco risorse. Tieni presente che se prevedi di registrare più cluster, l'abilitazione di Anthos Service Mesh avviene a livello di parco risorse, quindi devi eseguire questo comando una sola volta.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Registra i cluster in un parco risorse

1. Registra un cluster GKE utilizzando l'identità del carico di lavoro del parco risorse. Il flag --location è la zona o la regione di computing (ad esempio us-central1-a o us-central1) per il cluster.

   gcloud container clusters update CLUSTER_NAME \
     --location CLUSTER_LOCATION \
     --fleet-project FLEET_PROJECT_ID
   

2. Verifica che il cluster sia registrato:

   gcloud container fleet memberships list --project FLEET_PROJECT_ID
   

   Output di esempio:

   NAME                 EXTERNAL_ID                           LOCATION
   cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1
   

   Prendi nota del MEMBERSHIP_NAME, perché ti servirà quando attivi la gestione automatica.

3. Se il progetto del cluster è diverso dal progetto host del parco risorse, devi consentire agli account di servizio Anthos Service Mesh nel progetto del parco risorse di accedere al progetto del cluster e abilitare le API richieste nel progetto del cluster. Devi eseguire questa operazione una sola volta per ogni progetto del cluster.

   Se in precedenza hai utilizzato asmcli per configurare Anthos Service Mesh gestito per questa combinazione di progetti cluster e del parco risorse, le modifiche sono già state applicate e non devi eseguire i comandi seguenti.

   Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione ad accedere al progetto del cluster:

   gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
     --member "serviceAccount:[e-mail]" \
     --role roles/anthosservicemesh.serviceAgent
   

   Abilita l'API Mesh sul progetto del cluster:

   gcloud services enable mesh.googleapis.com \
     --project=CLUSTER_PROJECT_ID
   

Abilita gestione automatica

Esegui questo comando per abilitare la gestione automatica:

Nota: puoi applicare questa modifica a più cluster alla volta passando un elenco di nomi di appartenenza separati da virgole come parametro --memberships.

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

dove:

• MEMBERSHIP_NAME è il nome dell'appartenenza elencato quando hai verificato che il cluster sia stato registrato nel parco risorse.

• MEMBERSHIP_LOCATION è la località in cui hai sottoscritto l'abbonamento (una regione o global).

  Se di recente hai creato l'appartenenza utilizzando il comando in questa guida, questa dovrebbe essere la regione del tuo cluster. Se disponi di un cluster di zona, utilizza la regione corrispondente alla zona del cluster. Ad esempio, se disponi di un cluster di zona in us-central1-c, utilizza il valore us-central1.

  Questo valore può essere global se hai effettuato la registrazione prima di maggio 2023 o se hai specificato la località global al momento della registrazione dell'abbonamento. Puoi controllare la località del tuo abbonamento con gcloud container fleet memberships list --project FLEET_PROJECT_ID.

Verifica che sia stato eseguito il provisioning del piano di controllo

Dopo qualche minuto, verifica che lo stato del piano di controllo sia ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

L'output è simile a questo:

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

Prendi nota dell'etichetta della revisione nel campo details, ad esempio asm-managed nell'output fornito. Se utilizzi etichette di revisione, devi impostarla prima di eseguire il deployment delle applicazioni. Se utilizzi etichette di iniezione predefinite, non è necessario impostarla.

Configura kubectl in modo che punti al cluster

Le sezioni seguenti prevedono l'esecuzione di comandi kubectl su ciascuno dei cluster. Prima di procedere nelle sezioni seguenti, esegui questo comando per ciascuno dei tuoi cluster per configurare kubectl in modo che punti al cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

Tieni presente che il deployment di un gateway in entrata non viene eseguito automaticamente con il piano di controllo. La disaccoppiamento del deployment del gateway in entrata e del piano di controllo consente di gestire più facilmente i gateway in un ambiente di produzione. Se il cluster richiede un gateway in entrata o in uscita, consulta Eseguire il deployment dei gateway. Per abilitare altre funzionalità facoltative, consulta Abilitazione di funzionalità facoltative su Anthos Service Mesh gestito.

Piano dati gestito

Se utilizzi Anthos Service Mesh gestito, Google gestisce completamente gli upgrade dei proxy, a meno che non li disattivi a livello di spazio dei nomi, carico di lavoro o revisione.

Con il piano dati gestito, i proxy collaterali e i gateway inseriti vengono aggiornati automaticamente in combinazione con il piano di controllo gestito riavviando i carichi di lavoro per reinserire nuove versioni del proxy. In genere questa operazione viene completata 1-2 settimane dopo l'upgrade del piano di controllo gestito.

Se disabilitata, la gestione del proxy si basa sul ciclo di vita naturale dei pod nel cluster e deve essere attivata manualmente dall'utente per controllare la frequenza di aggiornamento.

Il piano dati gestito esegue l'upgrade dei proxy rimuovendo i pod in esecuzione nelle versioni precedenti del proxy. Le rimozioni vengono eseguite gradualmente, rispettando il budget di interruzione dei pod e controllando la frequenza di modifica.

Nota: se nel cluster è stato definito un periodo di manutenzione di GKE, le rimozioni dei pod inizieranno all'inizio del successivo periodo di manutenzione disponibile e continueranno senza pause fino a quando tutti i pod gestiti non saranno stati aggiornati (di solito 12 ore). Il periodo di manutenzione non viene osservato per le implementazioni correlate a CVE.

Il piano dati gestito non gestisce quanto segue:

• Pod non inseriti
• Pod inseriti manualmente
• Job
• StatefulSets
• DaemonSets

(Facoltativo) Disattivare il piano dati gestito

Se esegui il provisioning di Anthos Service Mesh gestito su un nuovo cluster, puoi disabilitare completamente il piano dati gestito oppure per singoli spazi dei nomi o pod. Il piano dati gestito continuerà a essere disabilitato per i cluster esistenti in cui era disabilitato per impostazione predefinita o manualmente.

Per disabilitare il piano dati gestito a livello di cluster e tornare alla gestione autonoma dei proxy collaterali, modifica l'annotazione:

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Per disabilitare il piano dati gestito per uno spazio dei nomi:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Per disabilitare il piano dati gestito per un pod:

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Attiva le notifiche di manutenzione

Puoi richiedere di ricevere una notifica relativa alla prossima manutenzione del piano dati gestito fino a una settimana prima della pianificazione della manutenzione. Le notifiche di manutenzione non vengono inviate per impostazione predefinita. Devi inoltre configurare un periodo di manutenzione di GKE prima di poter ricevere le notifiche. Se abilitato, le notifiche vengono inviate almeno due giorni prima dell'operazione di upgrade.

Per attivare le notifiche di manutenzione del piano dati gestito:

1. Vai alla pagina Comunicazione.

   Vai alla pagina Comunicazione

2. Nella riga Anthos Service Mesh Upgrade, nella colonna Email, seleziona il pulsante di opzione per attivare le notifiche di manutenzione.

Ogni utente che vuole ricevere le notifiche deve attivarli separatamente. Se vuoi impostare un filtro email per queste notifiche, la riga dell'oggetto è:

Upcoming upgrade for your Anthos Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME".

L'esempio seguente mostra una tipica notifica di manutenzione del piano dati gestito:

Oggetto: Upgrade imminente per il cluster ASM "<location/cluster-name>"

Gentile utente di Anthos Service Mesh,

L'upgrade dei componenti Anthos Service Mesh nel tuo cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) è pianificato per il giorno ${scheduled_date_human_read}.

Per informazioni sul nuovo aggiornamento, consulta le note di rilascio (https://cloud.google.com/service-mesh/docs/release-notes).

Se questo intervento di manutenzione verrà annullato, riceverai un'altra email.

Cordiali saluti,

Il team di Anthos Service Mesh

(c) 2022 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA Ti abbiamo inviato questo annuncio per aggiornarti su importanti modifiche relative alla Google Cloud Platform o al tuo account. Puoi disattivare le notifiche relative al periodo di manutenzione modificando le preferenze utente: https://console.cloud.google.com/user-preferences/communication?project=${project_id}

Configurare il rilevamento degli endpoint (solo per le installazioni multi-cluster)

Nota: se la tua rete mesh ha un solo cluster, ignora questi passaggi multi-cluster e passa a Eseguire il deployment delle applicazioni o a Eseguire la migrazione delle applicazioni.

Prima di continuare, dovresti aver già configurato Anthos Service Mesh gestito su ciascun cluster, come descritto nei passaggi precedenti. Non è necessario indicare che un cluster è primario, questo è il comportamento predefinito.

Inoltre, assicurati di aver scaricato asmcli (solo se vuoi verificare la configurazione con l'applicazione di esempio) e di impostare le variabili di progetto e cluster.

Nota: per saperne di più sul rilevamento degli endpoint, consulta Rilevamento degli endpoint con più piani di controllo.

Cluster pubblici

Configura il rilevamento degli endpoint tra cluster pubblici

L'abilitazione di Anthos Service Mesh gestito con l'API del parco risorse abiliterà il rilevamento degli endpoint per questo cluster. Tuttavia, devi aprire le porte firewall. Per disabilitare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disabilitarlo in Rilevamento degli endpoint tra cluster pubblici con API dichiarativa.

Cluster privati

Configura il rilevamento degli endpoint tra cluster privati

L'abilitazione di Anthos Service Mesh gestito con l'API del parco risorse abiliterà il rilevamento degli endpoint per questo cluster. Tuttavia, devi aprire le porte firewall. Per disabilitare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disabilitarlo in Rilevamento degli endpoint tra cluster privati con API dichiarativa.

Per un'applicazione di esempio con due cluster, vedi Esempio di servizio HelloWorld.

Nota: l'esempio del servizio HelloWorld utilizza Docker Hub. In un cluster privato, il runtime del container può estrarre le immagini container da Artifact Registry per impostazione predefinita. Il runtime del container non può eseguire il pull di immagini da altri registri di immagini container su internet. Puoi scaricare l'immagine ed eseguirne il push su Artifact Registry oppure utilizzare Cloud NAT per fornire l'accesso a internet in uscita per determinati nodi privati. Per saperne di più, consulta Eseguire la migrazione di container esterni e Creare un cluster privato.

Esegue il deployment delle applicazioni

Se nel parco risorse sono presenti più cluster che utilizzano Anthos Service Mesh gestito, assicurati che le porte di rilevamento degli endpoint o firewall siano configurate come previsto prima di procedere ed eseguire il deployment delle applicazioni.

Per eseguire il deployment delle applicazioni, utilizza l'etichetta corrispondente al canale configurato durante l'installazione oppure istio-injection=enabled se utilizzi etichette di iniezione predefinite.

Etichetta iniezione predefinita

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

Nota: puoi ignorare eventuali errori label "istio.io/rev" not found.

Etichetta revisione

Prima di eseguire il deployment delle applicazioni, rimuovi eventuali etichette istio-injection precedenti dagli spazi dei nomi e imposta invece l'etichetta istio.io/rev=REVISION_LABEL.

Questa è l'etichetta di revisione che hai identificato quando hai verificato il piano di controllo. Per modificarla con un'etichetta di revisione specifica, fai clic su REVISION_LABEL e sostituiscila con l'etichetta applicabile: asm-managed-rapid per Rapida, asm-managed per Normale o asm-managed-stable per Stabile.

L'etichetta della revisione corrisponde a un canale di rilascio:

Etichetta revisione	Canale
asm-managed	Normale
asm-managed-rapid	Rapida
asm-managed-stable	Stabile

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

Nota: puoi ignorare qualsiasi errore label "istio-injection" not found.

A questo punto, hai configurato correttamente Anthos Service Mesh gestito. Se disponi di carichi di lavoro esistenti in spazi dei nomi etichettati, riavviali in modo che vengano inseriti i proxy.

Ora puoi eseguire il deployment delle tue applicazioni oppure puoi eseguire il deployment dell'applicazione di esempio Bookinfo.

Se esegui il deployment di un'applicazione in una configurazione multi-cluster, replica la configurazione di Kubernetes e del piano di controllo in tutti i cluster, a meno che tu non preveda di limitare la configurazione specifica a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte attendibile per il cluster.

Personalizza l'inserimento (facoltativo)

Attenzione: eseguire l'override e personalizzare le impostazioni di inserimento può causare errori di configurazione imprevisti e problemi con i container collaterali.

È disponibile la configurazione per pod per eseguire l'override di queste opzioni sui singoli pod. Per farlo, devi aggiungere un container istio-proxy al tuo pod. L'inserimento collaterale tratterà qualsiasi configurazione qui definita come un override del modello di iniezione predefinito.

Ad esempio, la configurazione seguente personalizza varie impostazioni, tra cui la riduzione delle richieste di CPU, l'aggiunta di un montaggio del volume e l'aggiunta di un hook preStop:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limites:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

In generale, è possibile impostare qualsiasi campo in un pod. Tuttavia, occorre prestare attenzione a determinati campi:

• Kubernetes richiede che il campo image sia impostato prima dell'esecuzione dell'inserimento. Sebbene sia possibile impostare un'immagine specifica in modo da sostituire quella predefinita, è consigliabile impostare image su auto, in modo che l'iniettore collaterale selezioni automaticamente l'immagine da utilizzare.
• Alcuni campi in containers dipendono dalle impostazioni correlate. Ad esempio, la richiesta di CPU deve essere inferiore al limite di CPU. Se entrambi i campi non sono configurati correttamente, il pod potrebbe non avviarsi.
• Kubernetes consente di impostare sia requests sia limits per le risorse in PodSpec. GKE Autopilot considera solo requests. Per ulteriori informazioni, consulta Impostare i limiti delle risorse in Autopilot.

Inoltre, alcuni campi sono configurabili da annotazioni sul pod, anche se è consigliabile utilizzare l'approccio precedente per personalizzare le impostazioni. Presta particolare attenzione ad alcune annotazioni:

• Per GKE Standard, se sidecar.istio.io/proxyCPU è impostato, assicurati di impostare esplicitamente sidecar.istio.io/proxyCPULimit. In caso contrario, il limite di CPU del componente collaterale verrà impostato su illimitato.
• Per GKE Standard, se sidecar.istio.io/proxyMemory è impostato, assicurati di impostare esplicitamente sidecar.istio.io/proxyMemoryLimit. In caso contrario, il limite di memoria del file collaterale verrà impostato come illimitato.
• Per GKE Autopilot, la configurazione delle risorse requests e limits mediante annotazioni potrebbe eseguire l'overprovisioning delle risorse. Per evitarlo, usa l'approccio con modello di immagine. Vedi Esempi di modifica delle risorse in Autopilot.

Ad esempio, consulta la seguente configurazione dell'annotazione delle risorse:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

Verifica le metriche del piano di controllo

Puoi visualizzare la versione del piano di controllo e del piano dati in Metrics Explorer.

Per verificare che la configurazione funzioni correttamente:

1. Nella console Google Cloud, visualizza le metriche del piano di controllo:

   Vai a Metrics Explorer

2. Scegli la tua area di lavoro e aggiungi una query personalizzata utilizzando i seguenti parametri:

   • Tipo di risorsa: container Kubernetes
   • Metrica: client proxy
   • Filtro: container_name="cr-REVISION_LABEL"
   • Raggruppa per: etichetta revision ed etichetta proxy_version
   • Aggregatore: somma
   • Ciclo: 1 minuto

   Quando esegui Anthos Service Mesh sia con un piano di controllo gestito da Google sia con un piano di controllo in-cluster, puoi distinguere le metriche in base al nome del container. Ad esempio, le metriche gestite hanno container_name="cr-asm-managed", mentre le metriche non gestite hanno container_name="discovery". Per visualizzare le metriche di entrambi, rimuovi il filtro su container_name="cr-asm-managed".

3. Verifica la versione del piano di controllo e della versione del proxy ispezionando i seguenti campi in Metrics Explorer:

   • Il campo revision indica la versione del piano di controllo.
   • Il campo proxy_version indica proxy_version.
   • Il campo value indica il numero di proxy connessi.

   Per la mappatura della versione di Anthos Service Mesh dal canale corrente, consulta Versioni di Anthos Service Mesh per canale.

Esegui la migrazione delle applicazioni ad Anthos Service Mesh gestito

Avviso: durante il processo di migrazione, i CRD Istio corrispondenti al canale selezionato vengono installati nel cluster specificato. Se nel cluster sono presenti CRD Istio, verranno sovrascritti.

Per eseguire la migrazione delle applicazioni da Anthos Service Mesh nel cluster ad Anthos Service Mesh gestito, esegui questi passaggi:

Nota: assicurati di aver eseguito il provisioning di Anthos Service Mesh gestito seguendo tutte le sezioni precedenti di questa guida.

1. Sostituisci l'etichetta dello spazio dei nomi attuale. I passaggi richiesti variano a seconda che tu voglia utilizzare le etichette di inserimento predefinite (ad esempio, istio-injection enabled) o l'etichetta di revisione.

   Etichetta iniezione predefinita

   1. Esegui questo comando per spostare il tag predefinito nella revisione gestita:

      istioctl tag set default --revision REVISION_LABEL
      

   2. Esegui questo comando per etichettare lo spazio dei nomi utilizzando istio-injection=enabled, se non lo era già:

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

   Etichetta revisione

   Se hai utilizzato l'etichetta istio.io/rev=REVISION_LABEL, esegui questo comando:

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

2. Esegui un upgrade in sequenza dei deployment nello spazio dei nomi:

   kubectl rollout restart deployment -n NAMESPACE
   

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

4. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi precedenti per ogni spazio dei nomi.

5. Se hai eseguito il deployment dell'applicazione in una configurazione multi-cluster, replica la configurazione di Kubernetes e Istio in tutti i cluster, a meno che tu non voglia limitare questa configurazione solo a un sottoinsieme di cluster. La configurazione applicata a un particolare cluster è la fonte attendibile per il cluster.

6. Verifica che le metriche vengano visualizzate come previsto seguendo i passaggi descritti in Verificare le metriche del piano di controllo.

Se ritieni che la tua applicazione funzioni come previsto, puoi rimuovere istiod nel cluster dopo aver spostato tutti gli spazi dei nomi sul piano di controllo gestito oppure mantenerli come backup: istiod farà automaticamente fare lo scale down per utilizzare meno risorse. Per rimuoverlo, vai a Elimina piano di controllo precedente.

In caso di problemi, puoi identificarli e risolverli utilizzando le informazioni riportate in Risolvere i problemi del piano di controllo gestito e, se necessario, eseguire il rollback alla versione precedente.

Elimina piano di controllo precedente

Dopo aver installato e confermato che tutti gli spazi dei nomi utilizzano il piano di controllo gestito da Google, puoi eliminare il piano di controllo precedente.

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

Se hai utilizzato istioctl kube-inject anziché l'inserimento automatico o se hai installato gateway aggiuntivi, controlla le metriche per il piano di controllo e verifica che il numero di endpoint connessi sia zero.

Rollback

Segui questi passaggi se devi eseguire il rollback alla versione precedente del piano di controllo:

1. Aggiorna i carichi di lavoro da inserire con la versione precedente del piano di controllo. Nel comando seguente, il valore di revisione asm-191-1 viene utilizzato solo come esempio. Sostituisci il valore di esempio con l'etichetta di revisione del piano di controllo precedente.

   kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
   

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

   kubectl rollout restart deployment -n NAMESPACE
   

Il piano di controllo gestito eseguirà automaticamente la scalabilità fino a zero e non utilizzerà alcuna risorsa quando non in uso. I webhook mutanti e il provisioning rimarranno invariati e non influiranno sul comportamento del cluster.

Ora il gateway è impostato sulla revisione asm-managed. Per eseguire il rollback, esegui nuovamente il comando di installazione di Anthos Service Mesh, che eseguirà nuovamente il deployment del gateway puntando al piano di controllo nel cluster:

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

In caso di esito positivo, è previsto questo output:

deployment.apps/istio-ingressgateway rolled back

Disinstallazione di Anthos Service Mesh

Il piano di controllo gestito scala automaticamente fino a zero quando non è utilizzato da nessuno spazio dei nomi. Per la procedura dettagliata, consulta Disinstallare Anthos Service Mesh.

Risoluzione dei problemi

Per identificare e risolvere i problemi riscontrati durante l'utilizzo del piano di controllo gestito, vedi Risoluzione dei problemi del piano di controllo gestito.

Passaggi successivi

• Scopri come abilitare le funzionalità facoltative di Anthos Service Mesh gestite, ad esempio:
  • Log degli accessi di Envoy
  • Tracciamento
  • Immagini senza distribuzioni
  • Autenticazione dell'utente finale
• È in corso la configurazione della sicurezza dei trasporti per proteggere il tuo mesh.