Cloud Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il provisioning di Cloud Service Mesh gestito con asmcli

Panoramica

Managed Cloud Service Mesh con asmcli è un control plane gestito e un piano dati gestito che puoi semplicemente configurare. Google ne gestisce affidabilità, upgrade, scalabilità e sicurezza al posto tuo in modo compatibile con le versioni precedenti. Questa guida spiega come configurare o eseguire la migrazione delle applicazioni a Cloud Service Mesh gestito in una configurazione a uno o più cluster con asmcli.

Per scoprire di più sulle funzionalità supportate e sulle limitazioni di Cloud Service Mesh gestito, consulta Funzionalità supportate di Cloud Service Mesh gestito.

Prerequisiti

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

Un progetto Cloud
Un account di fatturazione Cloud
Ottenute le autorizzazioni richieste per il provisioning di Cloud Service Mesh
Lo strumento di installazione asmcli, kpt e altri strumenti specificati in Installare gli strumenti richiesti

Per un provisioning più rapido, i cluster devono avere Workload Identity abilitato. Se Workload Identity non è abilitato, il provisioning lo attiverà automaticamente.

Requisiti

Uno o più cluster con una versione di GKE supportata, in una delle regioni supportate.
Tieni presente che Cloud Service Mesh gestito utilizza i canali di rilascio di GKE per bilanciare stabilità e velocità di upgrade. Le nuove modifiche ai componenti in-cluster di Cloud Service Mesh (inclusi CNI, MDPC, proxy e CRD Istio) verranno implementate prima nei cluster che si iscrivono al canale rapido GKE. Verranno poi promosse al canale regolare GKE e infine al canale stabile GKE, una volta dimostrata una stabilità sufficiente.
- Managed Cloud Service Mesh non supporta la modifica sicura dei canali di rilascio di GKE.
- Se modifichi il canale di rilascio GKE, Cloud Service Mesh esegue automaticamente l'upgrade/il downgrade dei componenti in-cluster (CNI, MDPC, versione del proxy inserito predefinita e CRD Istio) in modo che siano allineati al canale di rilascio GKE corrente.
Assicurati che il cluster abbia capacità sufficiente per i componenti richiesti che Cloud Service Mesh gestito installa nel cluster.
- Il deployment mdp-controller nello spazio dei nomi kube-system richiede cpu: 50m, memory: 128Mi.
- Il daemonset istio-cni-node nello spazio dei nomi kube-system richiede cpu: 100m, memory: 100Mi su ogni nodo.
Assicurati che il criterio dell'organizzazione constraints/compute.disableInternetNetworkEndpointGroup sia disattivato. Se il criterio è attivato, ServiceEntry potrebbe non funzionare.
Assicurati che la macchina client da cui esegui il provisioning di Cloud Service Mesh gestito abbia la connettività di rete al server API.
I cluster devono essere registrati in un parco risorse. Questo passaggio può essere eseguito separatamente prima del provisioning o come parte del provisioning passando i flag --enable-registration e --fleet-id.
Nel progetto deve essere abilitata la funzionalità del parco risorse Service Mesh. Puoi abilitarlo nell'ambito del provisioning passando --enable-gcp-components o eseguendo il comando seguente:
```
gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
```
dove FLEET_PROJECT_ID è l'ID progetto del progetto host del parco risorse.
GKE Autopilot è supportato solo con GKE versione 1.21.3+.
Cloud Service Mesh può utilizzare più cluster GKE in un ambiente single-project single-network o in un ambiente multi-project single-network.
- Se unisci cluster che non si trovano nello stesso progetto, devono essere registrati nello stesso progetto host del parco risorse e i cluster devono trovarsi in una configurazione VPC condivisa insieme sulla stessa rete.
- Per un ambiente multicluster a progetto singolo, il progetto del parco risorse può essere lo stesso del progetto del cluster. Per saperne di più sui parchi risorse, consulta la pagina Panoramica dei parchi risorse.
- Per un ambiente multi-progetto, ti consigliamo di ospitare il parco risorse in un progetto separato dai progetti del cluster. Se i criteri organizzativi e la configurazione esistente lo consentono, ti consigliamo di utilizzare il progetto VPC condiviso come progetto host del parco risorse. Per maggiori informazioni, vedi Configurazione di cluster con VPC condiviso.
- Se la tua organizzazione utilizza Controlli di servizio VPC e esegui il provisioning di Cloud Service Mesh sui cluster GKE con una release maggiore o uguale a 1.22.1-gke.10, potresti dover eseguire passaggi di configurazione aggiuntivi:
  - Se esegui il provisioning di Cloud Service Mesh sul canale di rilascio regolare o stabile , devi utilizzare il flag aggiuntivo --use-vpcsc quando applichi il control plane gestito e segui la guida a Controlli di servizio VPC (anteprima). In caso contrario, il provisioning non supererà i controlli di sicurezza.
  - Se esegui il provisioning di Cloud Service Mesh sul canale di rilascio rapido, non devi utilizzare il flag --use-vpcsc aggiuntivo quando applichi il control plane gestito, ma devi seguire la guida ai Controlli di servizio VPC (GA).

Ruoli richiesti per installare Cloud Service Mesh

La seguente tabella descrive i ruoli necessari per installare managed Cloud Service Mesh.

Nome del ruolo	ID ruolo	Concedi la posizione	Descrizione
Amministratore GKE Hub	roles/gkehub.admin	Progetto del parco risorse	Accesso completo a GKE Hub e alle risorse correlate.
Amministratore Service Usage	roles/serviceusage.serviceUsageAdmin	Progetto del parco risorse	Può abilitare, disabilitare e analizzare gli stati dei servizi, analizzare le operazioni e utilizzare la quota e la fatturazione per un progetto consumer. ^{(Nota 1)}
Amministratore del servizio CA ^Beta	roles/privateca.admin	Progetto del parco risorse	Accesso completo a tutte le risorse del servizio CA. ^{(Nota 2)}

Ruoli richiesti per eseguire Cloud Service Mesh

La tabella seguente descrive i ruoli richiesti dal account di servizio per eseguire Cloud Service Mesh gestito. Se i progetti di rete o cluster differiscono dal progetto host del parco risorse, devi concedere alaccount di serviziot nel progetto del parco risorse l'accesso a questi ruoli negli altri progetti.

Nome del ruolo	ID ruolo	Concedi la posizione	Descrizione
Anthos Service Mesh Service Agent	roles/anthosservicemesh.serviceAgent	Progetto del parco risorse
Mesh Managed Control Plane Service Agent (legacy)	roles/meshcontrolplane.serviceAgent	Progetto del parco risorse	Si tratta di un ruolo legacy che faceva parte delle installazioni precedenti di Cloud Service Mesh. Se la tua installazione ha questo ruolo di servizio, puoi lasciarlo così com'è. Le nuove installazioni non richiedono questo ruolo.

Limitazioni

Ti consigliamo di esaminare l'elenco delle funzionalità e limitazioni supportate di Cloud Service Mesh. In particolare, tieni presente quanto segue:

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

Nota :puoi comunque abilitare le funzionalità facoltative senza utilizzare l'API IstioOperator. Consulta la sezione Attivazione di funzionalità facoltative su Cloud 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 la pagina Eseguire la migrazione da IstioOperator.
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 delle risorse di GKE Autopilot, le richieste e i limiti delle risorse proxy predefiniti sono impostati su 500 m di CPU e 512 MB di memoria. Puoi eseguire l'override dei valori predefiniti utilizzando l'inserimento personalizzato.
Per i cluster GKE Autopilot, potrebbero essere visualizzati avvisi per i componenti di Cloud Service Mesh "DaemonSet has no nodes selected" finché non viene eseguito lo scale del NodePool dei cluster.
Durante il processo di provisioning di un control plane gestito, le CRD Istio vengono sottoposte a provisioning nel cluster specificato. Se nel cluster esistono CRD Istio, verranno sovrascritti.
Istio CNI e Cloud Service Mesh non sono compatibili con GKE Sandbox. Pertanto, Cloud Service Mesh gestito con l'implementazione TRAFFIC_DIRECTOR non supporta i cluster con GKE Sandbox abilitato.
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 di Virtual Private Cloud (VPC) che fornisce un accesso specifico.

Prima di iniziare

Configura gcloud

Completa i seguenti passaggi anche se utilizzi Cloud Shell.

Autenticati con Google Cloud CLI:
```
gcloud auth login --project PROJECT_ID
```
dove PROJECT_ID è l'identificatore univoco del progetto cluster. Esegui questo comando per ottenere il tuo PROJECT_ID:
```
   gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```
```
Aggiorna i componenti:
```
gcloud components update
```

Configura kubectl in modo che punti al cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID

Scaricare lo strumento di installazione

Scarica la versione più recente dello strumento nella directory di lavoro corrente:
```
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
```
Rendi eseguibile lo strumento:
```
chmod +x asmcli
```

Configura ogni cluster

Per configurare Cloud Service Mesh gestito per ogni cluster nel mesh, segui questi passaggi.

Applica il control plane gestito

Prima di applicare il control plane gestito, devi selezionare un canale di rilascio. Il canale Cloud Service Mesh è determinato dal canale del cluster GKE al momento del provisioning di Cloud Service Mesh gestito. Tieni presente che più canali nello stesso cluster contemporaneamente non sono supportati.

Esegui lo strumento di installazione per ogni cluster che utilizzerà Cloud Service Mesh gestito. Ti consigliamo di includere entrambe le seguenti opzioni:

--enable-registration --fleet_id FLEET_PROJECT_ID Questi due flag registrano il cluster in un parco risorse, dove FLEET_ID è l'ID progetto del progetto host del parco risorse. Se utilizzi un singolo progetto, FLEET_PROJECT_ID è uguale a PROJECT_ID, il progetto host del parco e il progetto del cluster sono gli stessi. In configurazioni più complesse come quelle multi-progetto, consigliamo di utilizzare un progetto host del parco risorse separato.
--enable-all. Questo flag abilita sia i componenti obbligatori sia la registrazione.

Lo strumento asmcli configura il control plane gestito direttamente utilizzando strumenti e logica all'interno dello strumento CLI. Utilizza il set di istruzioni riportato di seguito a seconda della CA preferita.

Autorità di certificazione

Seleziona un'autorità di certificazione da utilizzare per il mesh.

Mesh CA

Esegui questo comando per installare il control plane con le funzionalità predefinite e Mesh CA. Inserisci i valori nei segnaposto forniti.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

Servizio CA

Segui i passaggi descritti in Configurare Certificate Authority Service.
Esegui questo comando per installare il control plane con le funzionalità predefinite e il servizio di autorità di certificazione. Inserisci i valori nei segnaposto forniti.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

Lo strumento scarica tutti i file per configurare il control plane gestito nel --output_dir specificato, installando lo strumento istioctl e le applicazioni di esempio. I passaggi di questa guida presuppongono che tu esegua istioctl dalla posizione --output_dir specificata durante l'esecuzione di asmcli install, con istioctl presente nella sottodirectory <Istio release dir>/bin.

Se esegui di nuovo asmcli sullo stesso cluster, sovrascrive la configurazione esistente del control plane. Assicurati di specificare le stesse opzioni e gli stessi flag se vuoi la stessa configurazione.

Verifica che il control plane sia stato sottoposto al provisioning

Dopo qualche minuto, verifica che lo stato del control plane sia ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

L'output è simile al seguente:

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

Se lo stato non raggiunge ACTIVE` in pochi minuti, consulta la sezione Controllare lo stato del control plane gestito per ulteriori informazioni sui possibili errori.

Upgrade zero-touch

Una volta installato il piano di controllo gestito, Google eseguirà automaticamente l'upgrade quando saranno disponibili nuove release o patch.

Piano dati gestito

Se utilizzi Cloud Service Mesh gestito, Google gestisce completamente gli upgrade dei proxy.

Con la funzionalità del data plane gestito attivata, i proxy sidecar e i gateway inseriti vengono aggiornati attivamente e automaticamente insieme al control plane gestito riavviando i carichi di lavoro per inserire nuovamente le nuove versioni del proxy. Inizia dopo l'upgrade del control plane e normalmente viene completato entro due settimane dall'inizio.

Tieni presente che il piano dati gestito si basa sul canale di rilascio GKE. Se modifichi il canale di rilascio di GKE mentre è abilitato il piano dati gestito, managed Cloud Service Mesh aggiornerà i proxy di tutti i workload esistenti come un rollout del piano dati gestito.

Se disabled, la gestione dei proxy viene eseguita passivamente, in base al ciclo di vita naturale dei pod nel cluster e deve essere attivata manualmente dall'utente per controllare la velocità di aggiornamento.

Gli upgrade del data plane gestito eseguono l'upgrade dei proxy eliminando i pod che eseguono versioni precedenti del proxy. Le espulsioni vengono eseguite gradualmente, rispettando il budget di interruzione dei pod e controllando il tasso di modifica.

Il piano dati gestito non gestisce quanto segue:

Pod non iniettati
Pod inseriti manualmente
Job
StatefulSet
DaemonSet

Se hai eseguito il provisioning di Cloud Service Mesh gestito su un cluster precedente, puoi attivare la gestione del piano dati per l'intero cluster:

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

In alternativa, puoi attivare il piano dati gestito in modo selettivo per una revisione, uno spazio dei nomi o un pod del piano di controllo specifici annotandolo con la stessa annotazione. Se controlli i singoli componenti in modo selettivo, l'ordine di precedenza è revisione del control plane, poi spazio dei nomi, poi pod.

Potrebbero essere necessari fino a dieci minuti prima che il servizio sia pronto per gestire i proxy nel cluster. Esegui questo comando per controllare lo stato:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Output previsto:

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

Se il servizio non diventa pronto entro dieci minuti, consulta Stato del piano dati gestito per i passaggi successivi.

(Facoltativo) Disattiva il piano dati gestito

Se esegui il provisioning di Cloud Service Mesh gestito su un nuovo cluster, puoi disattivare completamente il piano dati gestito o per singoli spazi dei nomi o pod. Il piano dati gestito continuerà a essere disattivato per i cluster esistenti in cui è stato disattivato per impostazione predefinita o manualmente.

Per disattivare il piano dati gestito a livello di cluster e ripristinare la gestione autonoma dei proxy sidecar, modifica l'annotazione:

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

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

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

Per disattivare il piano dati gestito per un pod:

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

Abilitare i periodi di manutenzione per il piano dati gestito

Se hai configurato un periodo di manutenzione di GKE, gli upgrade attivi inizieranno all'inizio del successivo periodo di manutenzione disponibile e continueranno senza interruzioni finché tutti i pod gestiti non saranno stati aggiornati (di solito 12 ore). Il periodo di manutenzione non viene rispettato per i rollout correlati alle CVE.

Cloud Service Mesh utilizza la finestra di manutenzione di GKE per allinearsi a GKE.

Attiva le notifiche di manutenzione per il piano dati gestito

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

Per attivare le notifiche di manutenzione del piano dati gestito:

Vai alla pagina Comunicazione.

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

Ogni utente che vuole ricevere le notifiche deve attivare l'opzione separatamente. Se vuoi impostare un filtro email per queste notifiche, l'oggetto è:

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

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

Oggetto: Prossimo upgrade per il cluster Cloud Service Mesh "<location/cluster-name>"

Gentile utente Cloud Service Mesh,

L'upgrade dei componenti Cloud 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_readable} alle ore ${scheduled_time_human_readable}.

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 Cloud Service Mesh

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

Configura il rilevamento degli endpoint (solo per installazioni multicluster)

Se la tua mesh ha un solo cluster, salta questi passaggi multi-cluster e vai a Deploy di applicazioni o Migrazione di applicazioni.

Prima di continuare, assicurati che Cloud Service Mesh sia configurato su ogni cluster.

Cluster pubblici

Configura l'individuazione degli endpoint tra cluster pubblici

Se operi su cluster pubblici (non privati), puoi configurare l'individuazione degli endpoint tra cluster pubblici o, più semplicemente, abilitare l'individuazione degli endpoint tra cluster pubblici.

Cluster privati

Configura il rilevamento degli endpoint tra cluster privati

Quando utilizzi i cluster privati GKE, devi configurare l'endpoint del control plane del cluster in modo che sia l'endpoint pubblico anziché quello privato. Consulta Configurare il rilevamento degli endpoint tra cluster privati.

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

Esegue il deployment delle applicazioni

Attiva lo spazio dei nomi per l'inserimento. I passaggi dipendono dall'implementazione del control plane.

Gestito (TD)

Applica l'etichetta di inserimento predefinita allo spazio dei nomi:

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

Gestito (Istiod)

Consigliato:esegui questo comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:

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

Se sei un utente esistente con il piano di controllo Istiod gestito: ti consigliamo di utilizzare l'inserimento predefinito, ma è supportato anche l'inserimento basato sulla revisione. Segui queste istruzioni:

Esegui questo comando per individuare i canali di rilascio disponibili:
```
kubectl -n istio-system get controlplanerevision
```
L'output è simile al seguente:
```
NAME                AGE
asm-managed-rapid   6d7h
```
NOTA: se nell'elenco precedente sono presenti due revisioni del control plane, rimuovine una. Non è supportato l'utilizzo di più canali del control plane nel cluster.

Nell'output, il valore nella colonna NAME è l'etichetta della revisione corrispondente al canale di rilascio disponibile per la versione di Cloud Service Mesh.

Applica l'etichetta di revisione allo spazio dei nomi:

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

Verifica che l'etichetta dello spazio dei nomi sia applicata correttamente utilizzando il comando seguente.

  kubectl get namespace -L istio-injection

Output di esempio:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

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

Se esegui il deployment di un'applicazione in una configurazione multi-cluster, replica la configurazione di Kubernetes e del control plane in tutti i cluster, a meno che tu non preveda di limitare quella particolare configurazione a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte di verità per quel cluster.

Personalizza l'inserimento (facoltativo)

Puoi eseguire l'override dei valori predefiniti e personalizzare le impostazioni di inserimento, ma ciò può comportare errori di configurazione imprevisti e problemi risultanti con i contenitori sidecar. Prima di personalizzare l'inserimento, leggi le informazioni dopo l'esempio per note su impostazioni e consigli particolari.

La configurazione per pod è disponibile per ignorare queste opzioni sui singoli pod. A questo scopo, aggiungi un container istio-proxy al tuo pod. L'inserimento del sidecar tratterà qualsiasi configurazione definita qui come override del modello di inserimento predefinito.

Ad esempio, la seguente configurazione personalizza una serie di 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"
      limits:
        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, è necessario prestare attenzione a determinati campi:

Kubernetes richiede che il campo image sia impostato prima dell'esecuzione dell'inserimento. 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 utilizzare.
Alcuni campi in containers dipendono da impostazioni correlate. Ad esempio, deve essere inferiore o uguale al limite della CPU. Se entrambi i campi non sono configurati correttamente, il pod potrebbe non avviarsi.
Kubernetes ti consente di impostare sia requests sia limits per le risorse nel pod spec. GKE Autopilot prende in considerazione solo requests. Per ulteriori informazioni, consulta Impostare i limiti delle risorse in Autopilot.

Inoltre, alcuni campi sono configurabili tramite annotazioni nel pod, anche se è consigliabile utilizzare l'approccio precedente per personalizzare le impostazioni. Presta particolare attenzione alle seguenti annotazioni:

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

Ad esempio, vedi l'annotazione delle risorse riportata di seguito:

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 control plane

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

Per verificare che la configurazione funzioni come previsto:

Nella console Google Cloud , visualizza le metriche del control plane:

Vai a Esplora metriche
Scegli il tuo spazio 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
- Periodo: 1 minuto
Quando esegui Cloud Service Mesh con un control plane gestito da Google e uno in-cluster, puoi distinguere le metriche in base al nome del container. Ad esempio, le metriche gestite hanno container_name="cr-asm-managed", mentre quelle 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 control plane e del proxy esaminando i seguenti campi in Metrics Explorer:
- Il campo revisione indica la versione del control plane.
- Il campo proxy_version indica proxy_version.
- Il campo Valore indica il numero di proxy connessi.
Per la mappatura attuale del canale alla versione di Cloud Service Mesh, consulta Versioni di Cloud Service Mesh per canale.

Esegui la migrazione delle applicazioni a Cloud Service Mesh gestito

Prepararsi alla migrazione

Per prepararti a eseguire la migrazione delle applicazioni da Cloud Service Mesh in-cluster a Cloud Service Mesh gestito, esegui questi passaggi:

Esegui lo strumento come indicato nella sezione Applica il control plane gestito da Google.

(Facoltativo) Se vuoi utilizzare il data plane gestito da Google, attiva la gestione del data plane:

  kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

Eseguire la migrazione delle applicazioni

Per eseguire la migrazione delle applicazioni da Cloud Service Mesh in-cluster a Cloud Service Mesh gestito, svolgi i seguenti passaggi:

Sostituisci l'etichetta dello spazio dei nomi corrente. I passaggi dipendono dall'implementazione del control plane.

Gestito (TD)

Applica l'etichetta di inserimento predefinita allo spazio dei nomi:

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

Gestito (Istiod)

Consigliato:esegui questo comando per applicare l'etichetta di inserimento predefinita allo spazio dei nomi:

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

Esegui questo comando per individuare i canali di rilascio disponibili:
```
kubectl -n istio-system get controlplanerevision
```
L'output è simile al seguente:
```
NAME                AGE
asm-managed-rapid   6d7h
```
NOTA: se nell'elenco precedente sono presenti due revisioni del control plane, rimuovine una. Non è supportato l'utilizzo di più canali del control plane nel cluster.

Nell'output, il valore nella colonna NAME è l'etichetta della revisione corrispondente al canale di rilascio disponibile per la versione di Cloud Service Mesh.

Applica l'etichetta di revisione allo spazio dei nomi:

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 l'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 si voglia limitare la configurazione a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte di verità per quel cluster.

Se ritieni che la tua applicazione funzioni come previsto, puoi rimuovere istiod nel cluster dopo aver trasferito tutti gli spazi dei nomi al piano di controllo gestito oppure conservarli come backup. istiod verrà fare lo scale down automaticamente per utilizzare meno risorse. Per rimuovere, vai a Elimina il vecchio control plane.

Se riscontri 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 il 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 anziché l'inserimento automatico o se hai installato gateway aggiuntivi, controlla le metriche del control plane e verifica che il numero di endpoint connessi sia zero.

Rollback

Segui questi passaggi se devi eseguire il rollback alla versione precedente del control plane:

Aggiorna i workload in modo che vengano inseriti con la versione precedente del control plane. Nel comando seguente, il valore di revisione asm-191-1 viene utilizzato solo come esempio. Sostituisci il valore di esempio con l'etichetta della revisione del control plane precedente.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
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 verrà scalato automaticamente a zero e non utilizzerà alcuna risorsa quando non è in uso. I webhook di mutazione e il provisioning rimarranno e non influiranno sul comportamento del cluster.

Il gateway è ora impostato sulla revisione asm-managed. Per eseguire il rollback, esegui di nuovo il comando di installazione di Cloud Service Mesh, che eseguirà di nuovo il deployment del gateway in modo che punti di nuovo al control plane in-cluster:

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

In caso di esito positivo, dovresti visualizzare questo output:

deployment.apps/istio-ingressgateway rolled back

Disinstalla

Il control plane gestito viene scalato automaticamente a zero quando nessuno spazio dei nomi lo utilizza. Per la procedura dettagliata, vedi Disinstallare Cloud Service Mesh.

Risoluzione dei problemi

Per identificare e risolvere i problemi durante l'utilizzo del control plane gestito, consulta Risoluzione dei problemi relativi al control plane gestito.

Passaggi successivi

Scopri di più sui canali di rilascio.
Esegui la migrazione da IstioOperator.
Esegui la migrazione di un gateway al control plane gestito.
Scopri come attivare le funzionalità facoltative di Cloud Service Mesh gestito, ad esempio: