Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il provisioning di Anthos Service Mesh gestito

Panoramica

Anthos Service Mesh gestito è un mesh di servizi gestito da Google che puoi semplicemente attivare. Google gestisce l'affidabilità, gli upgrade, la scalabilità e la sicurezza per te in modo compatibile con le versioni precedenti.

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

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

Google applica la configurazione del piano di controllo consigliata
Google attiva la gestione automatica del piano dati
Il cluster è registrato in un canale di rilascio di Anthos Service Mesh basato sul canale di rilascio del tuo cluster Google Kubernetes Engine (GKE). Il piano di controllo e il piano dati vengono 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.

Usa questo percorso di onboarding se vuoi:

Per utilizzare gcloud per configurare Anthos Service Mesh gestito utilizzando le API Google Cloud e IAM.
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.

Prerequisiti

Come punto di partenza, questa guida presuppone che tu abbia:

Un progetto cloud
Un account di fatturazione Cloud
Ottenere le autorizzazioni richieste per eseguire il provisioning di Anthos Service Mesh gestito
Abilitato Workload Identity nei tuoi cluster.

Requisiti

Uno o più cluster con una versione supportata di GKE, in una delle regioni supportate.
Assicurati che la macchina client di cui esegui il provisioning da Anthos Service Mesh abbia una connettività di rete al server API.
I cluster devono essere registrati in un parco risorse. Questo comando è incluso nelle istruzioni o può essere eseguito separatamente prima del provisioning.
Il tuo progetto deve avere la funzionalità del parco risorse Service Mesh abilitata. Questo passaggio è incluso nelle istruzioni o può essere eseguito separatamente.
GKE Autopilot è supportato solo con GKE versione 1.21.3 e successive. CNI verrà installato e gestito da Google.
Anthos Service Mesh gestito può utilizzare più cluster GKE in un ambiente a rete singola con progetto singolo o in un ambiente a rete singola con più progetti.

Limitazioni

Ti consigliamo di consultare l'elenco delle funzionalità e delle limitazioni supportate da Anthos Service Mesh. 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, vedi Abilitare funzionalità facoltative su Anthos Service Mesh gestito. Puoi anche utilizzare lo strumento di migrazione incluso con asmcli per convertire automaticamente altre funzionalità facoltative di IstioOperator in modo che siano compatibili con il piano di controllo gestito. Per maggiori informazioni, consulta la pagina 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 mesh di servizi richiede Certificate Authority Service (Servizio CA), segui i passaggi per eseguire 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. Analogamente, 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 GKE Autopilot, le richieste e i limiti predefiniti di risorse proxy sono impostati su 500 m CPU e 512 Mb di memoria. Puoi sostituire i valori predefiniti utilizzando l'iniezione personalizzata.
Le funzionalità effettive disponibili per Anthos Service Mesh gestito dipendono dal canale di rilascio. Per maggiori informazioni, consulta l'elenco completo delle funzionalità e delle limitazioni supportate da Anthos Service Mesh.
Durante il processo di provisioning di un piano di controllo gestito, viene eseguito il provisioning di CRD Istio corrispondenti al canale selezionato nel cluster specificato. Se nel cluster sono presenti CRD Istio esistenti, verranno sovrascritti.
Istio CNI non è compatibile con GKE Sandbox. Anthos Service Mesh gestito su Autopilot, pertanto, non funziona con GKE Sandbox poiché è necessario l'interfaccia CNI gestita di Istio.

Prima di iniziare

Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

Vai al selettore progetti

Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

Vai al selettore progetti

Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

Abilitare le API richieste nel progetto host del parco risorse.

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

dove:

FLEET_PROJECT_ID è l'ID del tuo progetto Fleet Host.

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

API	Purpose	Può essere disattivato
`meshconfig.googleapis.com`	Anthos Service Mesh utilizza l'API Mesh Configuration per inoltrare i dati di configurazione del 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 (Mesh CA).	No
`meshca.googleapis.com`	Relativa all'autorità di certificazione Anthos Service Mesh utilizzata dalla versione gestita di Anthos Service Mesh.	No
`container.googleapis.com`	Richiesto per creare cluster Google Kubernetes Engine (GKE).	No
`gkehub.googleapis.com`	Necessario per gestire il mesh come mezzo.	No
`monitoring.googleapis.com`	Necessario per acquisire la telemetria per i carichi di lavoro mesh.	No
`stackdriver.googleapis.com`	Richiesto per utilizzare l'interfaccia utente dei servizi.	No
`opsconfigmonitoring.googleapis.com`	Richiesto per utilizzare l'UI dei servizi per i cluster esterni a Google Cloud.	No
`connectgateway.googleapis.com`	Richiesto in modo che il piano di controllo gestito di Anthos Service Mesh possa accedere ai carichi di lavoro mesh.	Sì*

Avviso: la disabilitazione di connectgateway.googleapis.com comporta l'interruzione del funzionamento del piano di controllo Anthos Service Mesh gestito. Se il parco risorse non utilizza Anthos Service Mesh gestito su alcun cluster, questa API può essere disabilitata.

Abilita la funzionalità del parco risorse Anthos Service Mesh

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

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Configura ogni cluster

Utilizza i seguenti passaggi per configurare Anthos Service Mesh gestito per ogni cluster nel tuo mesh.

Configura gcloud

Esegui i passaggi seguenti anche se utilizzi Cloud Shell.

Autentica con Google Cloud CLI:
```
gcloud auth login --project PROJECT_ID
```
Aggiorna i componenti:
```
gcloud components update
```
Configura kubectl in modo che punti al cluster.

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

Registra i cluster in un parco risorse

Registra un cluster GKE utilizzando Workload Identity in un parco risorse:
```
gcloud container fleet memberships register MEMBERSHIP_NAME \
  --gke-uri=GKE_URI \
  --enable-workload-identity \
  --project FLEET_PROJECT_ID
```
dove:
- MEMBERSHIP_NAME è il nome dell'appartenenza che scegli di rappresentare in modo univoco il cluster che viene registrato nel parco risorse.
- GKE_URI è l'URI del cluster GKE. Ad esempio: https://container.googleapis.com/v1/projects/my-gke-project/locations/us-central1-a/clusters/my-gke-cluster. Puoi ottenere l'URI eseguendo gcloud container clusters list --uri.

Verifica che il cluster sia registrato:

gcloud container fleet memberships list --project FLEET_PROJECT_ID

Se il progetto del cluster è diverso da quello del tuo 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. Dovrai 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 parco risorse, queste 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 "PROJECT_ID"  \
  --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
  --role roles/anthosservicemesh.serviceAgent
```
Puoi ottenere il numero del progetto del tuo parco risorse eseguendo questo comando:
```
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_NUMBER)"
```
Abilita l'API Mesh sul progetto del cluster:
```
gcloud services enable mesh.googleapis.com \
  --project=PROJECT_ID
```

Applica l'etichetta mesh_id

Cluster di zona

gcloud container clusters update  --project PROJECT_ID CLUSTER_NAME \
  --zone CLUSTER_LOCATION --update-labels mesh_id=proj-FLEET_PROJECT_NUMBER

Cluster a livello di regione

gcloud container clusters update  --project PROJECT_ID CLUSTER_NAME \
  --region CLUSTER_LOCATION --update-labels mesh_id=proj-FLEET_PROJECT_NUMBER

dove:

PROJECT_ID è l'identificatore univoco del progetto del cluster.
CLUSTER_NAME è il nome del tuo cluster.
CLUSTER_LOCATION è la zona o la regione di computing del cluster.
FLEET_PROJECT_NUMBER è il numero del tuo progetto host del parco risorse.

Attiva gestione automatica

Esegui questo comando per abilitare la gestione automatica:

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

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

Verificare il provisioning del piano di controllo

Dopo alcuni minuti, verifica che lo stato del piano di controllo sia ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

L'output è simile al seguente:

...
membershipSpecs:
  projects/746296320118/locations/global/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/global/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 di revisione nel campo details, ad esempio, asm-managed nell'output fornito. Se utilizzi le etichette di revisione, devi impostarle prima di eseguire il deployment delle applicazioni. Se utilizzi etichette di iniezione predefinite, non è necessario impostarle.

Piano dati gestito

Se utilizzi Anthos Service Mesh gestito con l'API del parco risorse, Google gestirà completamente gli upgrade dei proxy, a meno che non disattivi la funzionalità a livello di spazio dei nomi o di carico di lavoro.

Se questa opzione è abilitata, i proxy sidecar 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. Di solito, questa operazione viene completata 1-2 settimane dopo l'upgrade del piano di controllo gestito.

Se è disabilitata, la gestione dei proxy è determinata dal 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 eliminando i pod che eseguono versioni precedenti del proxy. Le eliminazioni vengono eseguite gradualmente, rispettando il budget di interruzione dei pod e controllando la frequenza di modifica.

Tieni presente che il piano dati gestito richiede il plug-in Istio Container Network Interface (CNI) che è abilitato per impostazione predefinita quando esegui il deployment del piano di controllo gestito.

Il piano dati gestito non gestisce quanto segue:

Pod non inseriti
Pod inseriti manualmente
Job
StatefulSet
DaemonSet

(Facoltativo) Disattiva il piano dati gestito

Puoi disabilitare il piano dati gestito per i singoli spazi dei nomi o pod.

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"}'

Abilita notifiche di manutenzione

Puoi richiedere che ti venga inviata una notifica relativa alla manutenzione futura 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.

Per attivare le notifiche di manutenzione del piano dati gestito:

Vai alla pagina Comunicazione.

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

È necessario che gli utenti che vogliono ricevere notifiche debbano attivarli separatamente. Se vuoi impostare un filtro email per queste notifiche, l'oggetto è:

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

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

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

Gentile utente 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}) verrà eseguito il giorno ${scheduled_date_essere_leggibile} alle ore ${scheduled_time_essere_leggibili}

Puoi controllare le note di rilascio (https://cloud.google.com/service-mesh/docs/release-notes) per scoprire di più sul nuovo aggiornamento.

Se questa manutenzione viene annullata, 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 informarti di importanti cambiamenti che interessano Google Cloud Platform o il 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}

Configura Rilevamento endpoint (solo per installazioni multi-cluster)

Prima di continuare, devi aver già configurato Anthos Service Mesh gestito su ogni cluster come descritto nei passaggi precedenti. Non è necessario indicare che un cluster è 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 del progetto e del cluster.

Cluster pubblici

Configurare il rilevamento degli endpoint tra cluster pubblici

L'abilitazione di Anthos Service Mesh gestito con l'API del parco risorse consentirà l'individuazione degli endpoint per questo cluster. Tuttavia, devi aprire le porte del firewall. Per disabilitare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disattivarlo 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 consentirà l'individuazione degli endpoint per questo cluster. Tuttavia, devi aprire le porte del firewall. Per disabilitare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disattivarlo nella sezione Rilevamento degli endpoint tra cluster privati con API dichiarativa.

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

Esegue 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

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.

Si tratta dell'etichetta di revisione identificata quando hai verificato il piano di controllo. Per sostituire l'etichetta con una specifica etichetta di revisione, fai clic sulla REVISION_LABEL e sostituiscila con l'etichetta applicabile: asm-managed-rapid per Rapido, asm-managed per Normale o asm-managed-stable per Stabile.

L'etichetta di 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

A questo punto, hai configurato correttamente il piano di controllo gestito di Anthos Service Mesh. Se sono presenti carichi di lavoro esistenti negli spazi dei nomi etichettati, riavviali in modo che ricevano i proxy inseriti.

Ora puoi eseguire il deployment delle 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 piano di controllo in tutti i cluster, a meno che non prevedi di limitare la configurazione specifica a un sottoinsieme di cluster. La configurazione applicata a un particolare cluster è la fonte di riferimento per il cluster.

Personalizza l'inserimento (facoltativo)

La configurazione per pod è disponibile per eseguire l'override di queste opzioni nei singoli pod. Per farlo, aggiungi un container istio-proxy al pod. L'inserimento sidecar tratterà qualsiasi configurazione definita qui come una sostituzione del modello di iniezione predefinito.

Ad esempio, la seguente configurazione personalizza una serie di impostazioni, tra cui la riduzione delle richieste di CPU, l'aggiunta di un punto di 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 di un pod. Tuttavia, occorre prestare attenzione per determinati campi:

Kubernetes richiede che il campo image sia impostato prima che l'iniezione venga eseguita. Anche se puoi impostare un'immagine specifica per sostituire quella predefinita, ti consigliamo di impostare image su auto, in modo che l'iniettore sidecar selezioni automaticamente l'immagine da usare.
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 che limits per le risorse in PodSpec. GKE Autopilot prende in considerazione solo requests. Per ulteriori informazioni, consulta Impostazione dei limiti delle risorse in Autopilot.

Inoltre, alcuni campi sono configurabili tramite annotazioni sul pod, anche se consigliamo di utilizzare l'approccio sopra riportato per personalizzare le impostazioni. Presta particolare attenzione per alcune annotazioni:

Per GKE Standard, se sidecar.istio.io/proxyCPU è impostato, assicurati di impostare esplicitamente sidecar.istio.io/proxyCPULimit. Altrimenti, il limite di CPU del sidecar verrà impostato come 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 sidecar verrà impostato come illimitato.
Per GKE Autopilot, la configurazione delle risorse requests e limits tramite le annotazioni potrebbe causare il provisioning eccessivo delle risorse. Utilizza il modello di immagine per evitare. Consulta Esempi di modifica delle risorse in Autopilot.

Ad esempio, vedi la seguente configurazione di 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:

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

Vai a Metrics Explorer
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"
- Group By (Raggruppa per): etichetta di revisione ed etichetta proxy_version
- Somma aggregatore
- Periodo: 1 minuto
Quando esegui Anthos Service Mesh sia con un piano di controllo gestito da Google sia con un piano di controllo nel 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".
Verifica la versione del piano di controllo e quella del proxy esaminando i seguenti campi in Metrics Explorer:
- Il campo revision indica la versione del piano di controllo.
- Il campo proxy_version indica il proxy_version.
- Il campo value indica il numero di proxy connessi.
Per la mappatura della versione attuale del canale ad Anthos Service Mesh, consulta Versioni di Anthos Service Mesh per canale.

Migra le applicazioni in Anthos Service Mesh gestito

Per eseguire la migrazione delle applicazioni da Anthos Service Mesh in-cluster ad Anthos Service Mesh gestito, esegui i seguenti passaggi:

Sostituisci l'etichetta dello spazio dei nomi corrente. I passaggi richiesti variano a seconda che tu voglia utilizzare etichette di iniezione 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 il comando seguente 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
```
Esegui un upgrade in sequenza dei deployment nello spazio dei nomi:
```
kubectl rollout restart deployment -n NAMESPACE
```
Testa la tua applicazione per verificare che i carichi di lavoro funzionino correttamente.
Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi precedenti per ogni spazio dei nomi.
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 non sia necessario limitare questa configurazione solo a un sottoinsieme di cluster. La configurazione applicata a un particolare cluster è la fonte di riferimento per il cluster.
Controlla che le metriche vengano visualizzate come previsto seguendo la procedura descritta in Verificare le metriche del piano di controllo.

Se ritieni che la tua applicazione funzioni come previsto, puoi rimuovere istiod nel cluster dopo aver passato tutti gli spazi dei nomi al piano di controllo gestito oppure mantenerli come backup. istiod verrà ridimensionato automaticamente per utilizzare meno risorse. Per rimuoverlo, passa a Elimina il piano di controllo precedente.

Se si verificano problemi, puoi identificarli e risolverli utilizzando le informazioni riportate in Risolvere i problemi relativi al piano di controllo gestito e, se necessario, eseguire il rollback alla versione precedente.

Elimina vecchio piano di controllo

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

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

Se hai utilizzato istioctl kube-inject invece di 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 pari a zero.

Rollback

Esegui il passaggio seguente se devi eseguire il rollback alla versione precedente del piano di controllo:

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 tuo piano di controllo precedente.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
Riavvia i pod per attivare la nuova inserimento in modo che i proxy dispongano della versione precedente:
```
kubectl rollout restart deployment -n NAMESPACE
```

Il piano di controllo gestito scala automaticamente a zero e non utilizza alcuna risorsa quando non è in uso. I webhook e il provisioning mutanti rimarranno e non influiscono sul comportamento del cluster.

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

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

Il risultato è previsto:

deployment.apps/istio-ingressgateway rolled back

Disattiva gestione automatica

La disabilitazione della gestione automatica non esegue il deprovisioning di alcuna risorsa. Tutte le risorse vengono lasciate nel cluster per la gestione o la rimozione manuali, in modo simile al risultato del provisioning di Anthos Service Mesh gestito con asmcli.

Esegui questo comando per disattivare la gestione automatica:

gcloud container fleet mesh update \
   --management manual \
   --memberships MEMBERSHIP_NAME \
   --project FLEET_PROJECT_ID

Dopo alcuni minuti, verifica che lo stato della gestione del piano di controllo sia DISABLED:

gcloud container fleet mesh describe --project PROJECT_ID

L'output è simile al seguente:

...
membershipSpecs:
  projects/projectid/locations/global/memberships/cluster-name:
    mesh:
      controlPlane: management
membershipStates:
  projects/projectid/locations/global/memberships/cluster-name:
    servicemesh:
      controlPlaneManagement:
        state: DISABLED
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

Disinstallazione di Anthos Service Mesh

Per disinstallare completamente Anthos Service Mesh, vedi Disinstallare Anthos Service Mesh.

Risolvere i problemi

Per identificare e risolvere i problemi quando utilizzi il piano di controllo gestito, consulta Risolvere i problemi del piano di controllo gestito.

Passaggi successivi

Scopri come abilitare funzionalità facoltative gestite di Anthos Service Mesh, ad esempio:
Configurare la sicurezza dei trasferimenti per proteggere il tuo mesh.