Esegui il provisioning di Cloud Service Mesh gestito con asmcli

Panoramica

Cloud Service Mesh gestito con asmcli è un piano di controllo e un piano dati gestiti che puoi semplicemente configurare. Google ne gestisce affidabilità, upgrade, scalabilità e sicurezza 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 un solo cluster o a più cluster con asmcli.

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

Prerequisiti

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

Requisiti

  • Uno o più cluster con una versione supportata di GKE, in una delle regioni supportate.

  • Tieni presente che Cloud Service Mesh gestito utilizza i canali di rilascio GKE per trovare il giusto equilibrio tra 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 per primi nei cluster che si abbonano al canale GKE Rapid. Una volta dimostrata sufficiente stabilità, verranno promosse al canale GKE regolare e infine al canale GKE stabile.

    • Cloud Service Mesh gestito non supporta la modifica sicura dei canali di rilascio GKE.
    • Se modifichi il canale di rilascio GKE, Cloud Service Mesh esegue automaticamente l'upgrade/il downgrade dei componenti all'interno del cluster (CNI, MDPC, versione del proxy iniettata predefinita e CRD di Istio) in modo che siano in linea con l'attuale canale di rilascio GKE.

  • Assicurati che il cluster abbia una capacità sufficiente per i componenti richiesti che Cloud Service Mesh gestito installa nel cluster.

    • Il deployment mdp-controller nel namespace kube-system richiede cpu: 50m, memory: 128 Mi.
    • Il daemonset istio-cni-node nello spazio dei nomi kube-system richiede cpu: 100m, memory: 100 Mi su ogni nodo.

  • Assicurati che il criterio dell'organizzazione constraints/compute.disableInternetNetworkEndpointGroup sia disattivato. Se il criterio è attivato, ServiceEntry potrebbe non funzionare.

  • Assicurati che il computer client da cui esegui il provisioning di Cloud Service Mesh gestito abbia connettività di rete al server API.

  • I cluster devono essere registrati a un parco risorse. Questo passaggio può essere eseguito separatamente prima della creazione o nell'ambito della creazione passando i flag --enable-registration e --fleet-id.

  • Nel progetto deve essere abilitata la funzionalità del parco risorse Service Mesh. Puoi attivarla nell'ambito della definizione passando --enable-gcp-components o eseguendo il seguente comando:

    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 e successive.

  • Cloud Service Mesh può utilizzare più cluster GKE in un ambiente con una rete e un progetto oppure in un ambiente con più progetti e una rete.

    • Se colleghi cluster che non si trovano nello stesso progetto, questi devono essere registrati allo stesso progetto host del parco risorse e devono essere configurati in un VPC condiviso sulla stessa rete.
    • Per un ambiente multi-cluster con un solo progetto, il progetto del parco risorse può essere uguale al progetto del cluster. Per saperne di più sui parchi risorse, consulta la panoramica dei parchi risorse.
    • Per un ambiente multi-progetto, ti consigliamo di ospitare il parco risorse in un progetto distinto dai progetti del cluster. Se i criteri della tua organizzazione e la configurazione esistente lo consentono, ti consigliamo di utilizzare il progetto VPC condiviso come progetto host del parco. Per ulteriori informazioni, consulta Configurare i cluster con VPC condiviso.
    • Se la tua organizzazione utilizza i 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 ulteriori passaggi di configurazione:

Ruoli richiesti per installare Cloud Service Mesh

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

Nome del ruolo ID ruolo Concedere l'accesso alla posizione Descrizione
Amministratore GKE Hub roles/gkehub.admin Progetto parco risorse Accesso completo a GKE Hub e alle risorse correlate.
Amministratore Service Usage roles/serviceusage.serviceUsageAdmin Progetto 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)
CA Service Admin Beta roles/privateca.admin Progetto parco risorse Accesso completo a tutte le risorse del servizio CA. (Nota 2)

Limitazioni

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

  • L'API IstioOperator non è supportata poiché il suo scopo principale è controllare i componenti all'interno del cluster.

  • 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, le richieste e i limiti di risorse proxy predefiniti sono impostati su 500 m di CPU e 512 Mb di memoria. Puoi sostituire i valori predefiniti utilizzando l'inserimento personalizzato.

  • Durante la procedura di provisioning di un piano di controllo gestito, vengono eseguiti il provisioning delle risorse CRD di Istio nel cluster specificato. Se nel cluster sono presenti CRD Istio esistenti, verranno sovrascritte.

  • 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 abilitata.

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

Prima di iniziare

Configura gcloud

Completa i seguenti passaggi anche se utilizzi Cloud Shell.

  1. Esegui l'autenticazione con Google Cloud CLI:

    gcloud auth login --project PROJECT_ID

    dove PROJECT_ID è l'identificatore univoco del progetto cluster. Esegui il seguente comando per recuperare il tuo PROJECT_ID:

       gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```

  2. Aggiorna i componenti:

    gcloud components update

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

  1. Scarica la versione più recente dello strumento nella directory di lavoro corrente:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli

  2. Rendi eseguibile lo strumento:

    chmod +x asmcli

Configura ogni cluster

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

Applica il control plane gestito

Prima di applicare il piano di controllo 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 non è supportato l'utilizzo di più canali nello stesso cluster contemporaneamente.

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 di destinazione del parco risorse e il progetto del cluster sono uguali. Per configurazioni più complesse come quelle multi-project, consigliamo di utilizzare un progetto di hosting del parco risorse distinto.

  • --enable-all. Questo flag attiva sia i componenti richiesti sia la registrazione.

Lo strumento asmcli configura il piano di controllo gestito direttamente utilizzando gli strumenti e la logica all'interno dello strumento CLI. Utilizza l'insieme di istruzioni riportato di seguito in base alla CA che preferisci.

Autorità di certificazione

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

Mesh CA

Esegui il seguente comando per installare il piano di controllo con le funzionalità predefinite e la CA Mesh. 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

  1. Segui i passaggi descritti in Configurare Certificate Authority Service.
  2. Esegui il seguente comando per installare il piano di controllo con le funzionalità predefinite e il servizio Certificate Authority. 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 la configurazione del piano di controllo gestito in --output_dir specificato, installando lo strumento istioctl e le applicazioni di esempio. I passaggi di questa guida presuppongono che tu esegua istioctl dalla --output_dir posizione specificata durante l'esecuzione di asmcli install, con istioctl presente nella sottodirectory <Istio release dir>/bin.

Se esegui di nuovo asmcli sullo stesso cluster, la configurazione del piano di controllo esistente viene sovrascritta. Assicurati di specificare le stesse opzioni e gli stessi flag se vuoi la stessa configurazione.

Verifica che sia stato eseguito 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:

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 Controllare lo stato del control plane gestito per ulteriori informazioni su possibili errori.

Upgrade zero-touch

Una volta installato il piano di controllo gestito, Google ne 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 piano di dati gestito abilitata, i proxy sidecar e i gateway iniettati vengono aggiornati attivamente e automaticamente in combinazione con il piano di controllo gestito riavviando i carichi di lavoro per iniettare nuovamente nuove versioni del proxy. Questo processo inizia dopo l'upgrade del piano di controllo e di solito viene completato entro due settimane dall'avvio.

Tieni presente che il piano dati gestito si basa sul canale di release GKE. Se modifichi il canale di rilascio di GKE mentre il piano dati gestito è abilitato, Cloud Service Mesh gestito aggiornerà i proxy di tutti i carichi di lavoro esistenti, ad esempio un'implementazione del piano dati gestito.

Se l'opzione è disattivata, la gestione dei proxy avviene in modo passivo, in base al ciclo di vita naturale dei pod nel cluster e deve essere attivata manualmente dall'utente per controllare la frequenza di aggiornamento.

Il piano di dati gestito esegue l'upgrade dei proxy espellendo i pod che eseguono versioni precedenti del proxy. Gli espulsioni vengono eseguite gradualmente, rispettando il budget per le interruzioni dei pod e controllando la frequenza delle modifiche.

Il piano dati gestito non gestisce quanto segue:

  • Pod non iniettati
  • Pod iniettati 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 di dati gestito in modo selettivo per una revisione, uno spazio dei nomi o un pod del piano di controllo specifico annotandolo con la stessa annotazione. Se controlli i singoli componenti in modo selettivo, l'ordine di precedenza è revisione del piano di controllo, spazio dei nomi e pod.

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

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Risultato 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 è pronto entro dieci minuti, consulta Stato del piano di dati gestito per conoscere i passaggi successivi.

(Facoltativo) Disattiva il piano di 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 namespace 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 tornare alla 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 di dati gestito per uno spazio dei nomi:

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

Per disattivare il piano di dati gestito per un pod:

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

Attivare i periodi di manutenzione

Se hai configurato una periodo di manutenzione GKE, gli upgrade attivi inizieranno all'inizio della successiva periodo di manutenzione disponibile e continueranno senza interruzioni finché non saranno stati aggiornati tutti i pod gestiti (di solito 12 ore). Il periodo di manutenzione non viene osservato per le implementazioni correlate alle CVE.

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

Attiva le notifiche di manutenzione

Puoi richiedere di ricevere una notifica relativa alla manutenzione imminente del piano di dati gestito fino a una settimana prima della pianificazione della manutenzione. Le notifiche relative alla manutenzione non vengono inviate per impostazione predefinita. Inoltre, devi configurare una finestra di manutenzione GKE prima di poter ricevere le notifiche. Se questa opzione è attivata, le notifiche vengono inviate almeno due giorni prima dell'operazione di upgrade.

Per attivare le notifiche relative alla manutenzione del piano dati gestito:

  1. Vai alla pagina Comunicazione.

    Vai alla pagina Comunicazione

  2. 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 notifiche deve attivarle separatamente. Se vuoi impostare un filtro email per queste notifiche, la riga dell'oggetto è:

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

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

Oggetto: Upgrade imminente per il cluster Cloud Service Mesh "<location/cluster-name>"

Gentile utente di Cloud Service Mesh,

L'upgrade dei componenti di 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 questa comunicazione 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 le installazioni su più cluster)

Se il tuo mesh ha un solo cluster, salta questi passaggi per più cluster e vai a Eseguire il deployment delle applicazioni o Eseguire la migrazione delle applicazioni.

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

Cluster pubblici

Configurare il rilevamento degli endpoint tra i cluster pubblici

Se utilizzi cluster pubblici (non privati), puoi configurare il rilevamento degli endpoint tra i cluster pubblici o, più semplicemente, abilitare il rilevamento degli endpoint tra i 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 come endpoint pubblico anziché 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'iniezione. I passaggi dipendono dall'implementazione del piano di controllo.

Gestito (TD)

  1. 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 il seguente 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 già un utente con il piano di controllo Istiod gestito: consigliamo di utilizzare l'iniezione predefinita, ma è supportata anche l'iniezione basata su revisione. Segui le istruzioni riportate di seguito:

  1. Esegui il comando seguente 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 riportato sopra sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del control plane nel cluster non è supportata.

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

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

  kubectl get namespace -L istio-injection

Output di esempio:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

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

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 non prevedi di limitare questa particolare configurazione a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte attendibile per quel cluster.

Personalizza l'iniezione (facoltativo)

Puoi eseguire l'override dei valori predefiniti e personalizzare le impostazioni di inserimento, ma questo può portare a errori di configurazione imprevisti e conseguenti problemi con i contenitori sidecar. Prima di personalizzare l'iniezione, leggi le informazioni riportate dopo il sample per trovare note su impostazioni e consigli specifici.

La configurazione per pod è disponibile per eseguire l'override di queste opzioni sui singoli pod. Aggiungi un contenitore istio-proxy al pod. L'iniezione sidecar considererà 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 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 per alcuni campi:

  • Kubernetes richiede che il campo image venga impostato prima dell'esecuzione dell'iniezione. Sebbene sia possibile 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 dalle impostazioni correlate. Ad esempio, deve essere inferiore o uguale al limite della CPU. Se entrambi i campi non sono configurati correttamente, l'avvio del pod potrebbe non riuscire.
  • Kubernetes ti consente di impostare sia requests che limits per le risorse nel tuo spec pod. GKE Autopilot prende in considerazione solo requests. Per ulteriori informazioni, consulta Impostare i limiti di risorse in Autopilot.

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

  • Per GKE Standard, se è impostato sidecar.istio.io/proxyCPU, assicurati di impostare esplicitamente sidecar.istio.io/proxyCPULimit. In caso contrario, il limite della CPU del sidecar verrà impostato come illimitato.
  • Per GKE Standard, se è impostato sidecar.istio.io/proxyMemory, 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 con le annotazioni potrebbe comportare un overprovisioning delle risorse. Utilizza l'approccio del modello di immagine per evitare. Consulta gli esempi di modifica delle risorse in Autopilot.

Ad esempio, consulta 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 piano di controllo

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

Per verificare che la configurazione funzioni come previsto:

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

    Vai a Esplora metriche

  2. Scegli l'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
    • Periodo: 1 minuto

    Quando esegui Cloud Service Mesh con un control plane gestito da Google e un altro in-cluster, puoi distinguere le metriche dal nome del contenitore. 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".

  3. Verifica la versione del piano di controllo e la versione del proxy controllando 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 del canale attuale 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 per la migrazione

Per prepararti a eseguire la migrazione delle applicazioni da Cloud Service Mesh all'interno del cluster a Cloud Service Mesh gestito, svolgi i seguenti passaggi:

  1. Esegui lo strumento come indicato nella sezione Applicare il piano di controllo gestito da Google.

  2. (Facoltativo) Se vuoi utilizzare il piano di dati gestito da Google, attiva la gestione del piano di dati:

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

Esegui la migrazione delle applicazioni

Per eseguire la migrazione delle applicazioni da Cloud Service Mesh all'interno del cluster a Cloud Service Mesh gestito, esegui i seguenti passaggi:

  1. Sostituisci l'etichetta dello spazio dei nomi corrente. I passaggi dipendono dall'implementazione del piano di controllo.

Gestito (TD)

  1. 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 il seguente 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 già un utente con il piano di controllo Istiod gestito: consigliamo di utilizzare l'iniezione predefinita, ma è supportata anche l'iniezione basata su revisione. Segui le istruzioni riportate di seguito:

  1. Esegui il comando seguente 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 riportato sopra sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del control plane nel cluster non è supportata.

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

  2. Applica l'etichetta di revisione allo spazio dei nomi:

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

  1. Esegui un upgrade graduale dei deployment nello spazio dei nomi:

    kubectl rollout restart deployment -n NAMESPACE

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

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

  4. 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 la configurazione solo a un sottoinsieme di cluster. La configurazione applicata a un determinato cluster è la fonte attendibile per quel cluster.

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

Se riscontri problemi, puoi identificarli e risolverli utilizzando le informazioni riportate nell'articolo Risolvere i problemi del piano di controllo gestito e, se necessario, eseguendo il rollback alla versione precedente.

Eliminare il vecchio piano di controllo

Dopo aver installato e verificato che tutti gli spazi dei nomi utilizzino 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'iniezione automatica o se hai installato gateway aggiuntivi, controlla le metriche per il piano di controllo e verifica che il numero di endpoint collegati sia pari a zero.

Rollback

Se devi eseguire il rollback alla versione precedente del piano di controllo, svolgi i seguenti passaggi:

  1. Aggiorna i workload da iniettare con la versione precedente del control plane. Nel seguente comando, 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 re-iniezione in modo che i proxy abbiano la versione precedente:

    kubectl rollout restart deployment -n NAMESPACE

Il piano di controllo gestito si ridurrà automaticamente a zero e non utilizzerà alcuna risorsa quando non è in uso. I webhook e il provisioning con mutazioni rimarranno e non influiscono sul comportamento del cluster.

Il gateway è ora impostato sulla revisione asm-managed. Per eseguire il rollback, esegui nuovamente il comando di installazione di Cloud Service Mesh, che eseguirà il redeployment del gateway che rimanda al tuo piano di controllo 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 si ridimensiona automaticamente a zero quando non viene utilizzato da nessun namespace. Per la procedura dettagliata, vedi Disinstallare Cloud Service Mesh.

Risoluzione dei problemi

Per identificare e risolvere i problemi relativi all'utilizzo del piano di controllo gestito, consulta Risolvere i problemi relativi al piano di controllo gestito.

Passaggi successivi