Esegui il provisioning di un control plane Cloud Service Mesh gestito su GKE

Cloud Service Mesh è un mesh di servizi gestito da Google che devi solo attivare. Google ne gestisce affidabilità, upgrade, scalabilità e sicurezza al posto tuo.

Questa pagina mostra come utilizzare l'API fleet per configurare Cloud Service Mesh gestito utilizzando le API Istio.

Prerequisiti

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

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 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 è incluso nelle istruzioni se non è già registrato prima del provisioning.

  • Nel progetto deve essere abilitata la funzionalità del parco risorse Service Mesh. Queste informazioni sono incluse nelle istruzioni se non l'hai ancora attivata.

  • GKE Autopilot è supportato solo con GKE versione 1.21.3+.

  • Cloud Service Mesh può utilizzare più cluster GKE in un ambiente a progetto singolo e rete singola o in un ambiente multi-progetto e rete singola.

    • Se unisci cluster che non si trovano nello stesso progetto, questi devono essere registrati nello stesso progetto host del parco risorse e 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 dell'organizzazione e la configurazione esistente lo consentono, ti consigliamo di utilizzare il progetto VPC condiviso come progetto host del parco risorse. Per maggiori informazioni, vedi Configurazione di cluster con VPC condiviso.

Ruoli richiesti per installare Cloud Service Mesh

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

Nome del ruolo ID ruolo Concedi 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. (Note 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 all'account di servizio nel progetto del parco risorse l'accesso a questi ruoli negli altri progetti.

Nome del ruolo ID ruolo Concedi 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.

  • L'utilizzo di Certificate Authority Service (CA Service) richiede la configurazione di Cloud Service Mesh per cluster e non è supportato quando si utilizza la configurazione predefinita del parco risorse in GKE Enterprise.

  • 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 sostituire i 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" (DaemonSet non ha nodi selezionati) 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.

Prima di iniziare

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

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

    Go to project selector

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

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

    Go to project selector

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

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

             gcloud auth login --project FLEET_PROJECT_ID

    2. Aggiorna i componenti:

             gcloud components update

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

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

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

    API Finalità Può essere disattivato
    meshconfig.googleapis.com Cloud Service Mesh utilizza l'API Mesh Configuration per trasmettere i dati di configurazione dalla mesh a Google Cloud. Inoltre, l'abilitazione dell'API Mesh Configuration ti consente di accedere alle pagine di Cloud Service Mesh nella console Google Cloud e di utilizzare l'autorità di certificazione Cloud Service Mesh. No
    meshca.googleapis.com Relativo all'autorità di certificazione Cloud Service Mesh utilizzata da Cloud Service Mesh gestito. No
    container.googleapis.com Obbligatorio per creare cluster Google Kubernetes Engine (GKE). No
    gkehub.googleapis.com Obbligatorio per gestire la mesh come parco risorse. No
    monitoring.googleapis.com Obbligatorio per acquisire la telemetria per i carichi di lavoro mesh. No
    stackdriver.googleapis.com Obbligatorio per utilizzare la UI dei servizi. No
    opsconfigmonitoring.googleapis.com Obbligatorio per utilizzare l'interfaccia utente dei servizi per i cluster off-Google Cloud. No
    connectgateway.googleapis.com Obbligatorio per consentire al control plane di Cloud Service Mesh gestito di accedere ai carichi di lavoro mesh. Sì*
    trafficdirector.googleapis.com Consente un control plane gestito altamente disponibile e scalabile. Sì*
    networkservices.googleapis.com Consente un control plane gestito altamente disponibile e scalabile. Sì*
    networksecurity.googleapis.com Consente un control plane gestito altamente disponibile e scalabile. Sì*

    Configurazione di Cloud Service Mesh gestito

    I passaggi necessari per il provisioning di Cloud Service Mesh gestito utilizzando l'API Fleet dipendono dall'abilitazione per impostazione predefinita per i nuovi cluster del parco risorse o per cluster.

    Configurare per il tuo parco risorse

    Per abilitare Cloud Service Mesh gestito come configurazione predefinita per il tuo parco risorse, devi aver abilitato Google Kubernetes Engine (GKE) Enterprise. Ciò significa che ogni nuovo cluster GKE su Google Cloud registrato durante la creazione del cluster avrà Cloud Service Mesh gestito abilitato sul cluster. Puoi scoprire di più sulla configurazione predefinita del parco risorse in Gestire le funzionalità a livello di parco risorse.

    L'abilitazione di Cloud Service Mesh gestito come configurazione predefinita per il parco risorse e la registrazione dei cluster al parco risorse durante la creazione del cluster supporta solo Mesh CA. Se vuoi utilizzare Certificate Authority Service, ti consigliamo di attivarlo per cluster.

    Per attivare i valori predefiniti a livello di parco risorse per Cloud Service Mesh gestito, completa i seguenti passaggi:

    Console

    1. Nella console Google Cloud , vai alla pagina Feature Manager.

      Vai a Gestore funzionalità

    2. Nel riquadro Service Mesh, fai clic su Configura.

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

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

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

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

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

    gcloud

    Per configurare i valori predefiniti a livello di parco risorse utilizzando Google Cloud CLI, devi stabilire le seguenti impostazioni:

    • Impostazioni a livello di parco risorse

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

        echo "management: automatic" > mesh.yaml

      • Attiva Cloud Service Mesh per il tuo parco risorse:

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

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

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

    • Impostazioni a livello di rete

      • Se il progetto della tua rete è diverso dal progetto host del parco (ad esempio, se utilizzi un VPC condiviso), devi consentire agli account di servizio Cloud Service Mesh nel progetto del parco di accedere al progetto di rete. Dovrai farlo solo una volta per il progetto di rete.

        Concedi ai service account nel progetto fleet l'autorizzazione per accedere al progetto di rete:

        gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

    • Impostazioni a livello di cluster

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

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

        Per ottenere il numero di progetto del tuo progetto di flotta, esegui questo comando:

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

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

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

        Concedi ai service account nel progetto del parco risorse l'autorizzazione per accedere al progetto del cluster:

        gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

        Abilita l'API Mesh sul progetto del cluster:

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

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

    Vai a Verifica che il piano di controllo sia stato sottoposto al provisioning.

    Configura per cluster

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

    Attiva la funzionalità di flotta Cloud Service Mesh

    Attiva la funzionalità mesh nel progetto della flotta. Tieni presente che se prevedi di registrare più cluster, l'abilitazione della funzionalità del parco risorse Cloud Service Mesh avviene a livello di parco risorse, quindi devi eseguire questo comando una sola volta.

    gcloud container fleet mesh enable --project FLEET_PROJECT_ID

    Registra i cluster in un parco risorse

    1. Registra un cluster GKE utilizzando Workload Identity del parco risorse. Il flag --location è la zona di computing o la regione (ad esempio us-central1-a o us-central1) per il cluster.

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

    2. Verifica che il cluster sia registrato:

      gcloud container fleet memberships list --project FLEET_PROJECT_ID

      Output di esempio:

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

      Prendi nota del MEMBERSHIP_NAME, in quanto ti servirà quando attiverai la gestione automatica.

    3. Se il progetto della rete del cluster è diverso dal progetto host del parco (ad esempio, se utilizzi un VPC condiviso), devi consentire agli service account di Cloud Service Mesh nel progetto del parco di accedere al progetto di rete. Dovrai farlo solo una volta per il progetto di rete.

      Concedi ai service account nel progetto fleet l'autorizzazione per accedere al progetto di rete:

       gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent

    4. Se il progetto del cluster è diverso dal progetto host del parco risorse, devi consentire agli account di servizio Cloud Service Mesh nel progetto del parco risorse di accedere al progetto del cluster e abilitare le API richieste nel progetto del cluster.

      Devi eseguire questa operazione una sola volta per ogni progetto cluster. Se in precedenza hai configurato Cloud Service Mesh gestito per questa combinazione di progetti cluster e fleet, queste modifiche sono già state applicate e non devi eseguire i seguenti comandi.

      Concedi ai service account nel progetto del parco risorse l'autorizzazione ad accedere al progetto del cluster:

       gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
     --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
     --role roles/anthosservicemesh.serviceAgent

      Abilita l'API Mesh sul progetto del cluster:

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

    Configura il servizio CA (facoltativo)

    Se il deployment di mesh di servizi richiede Certificate Authority Service (CA Service), segui la procedura descritta in Configurare Certificate Authority Service per Cloud Service Mesh gestito per abilitarlo per il tuo parco progetti. Assicurati di completare tutti i passaggi prima di procedere alla sezione successiva.

    Attivare la gestione automatica

    Esegui questo comando per abilitare la gestione automatica:

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

    dove:

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

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

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

      Questo valore potrebbe essere global se ti sei registrato prima di maggio 2023 o se hai specificato la posizione global al momento della registrazione dell'abbonamento. Puoi controllare la posizione del tuo abbonamento con gcloud container fleet memberships list --project FLEET_PROJECT_ID.

    Supporto di Terraform

    Cloud Service Mesh supporta il provisioning tramite Terraform tramite il modulo di appartenenza alla funzionalità GKE Hub.

    Per istruzioni dettagliate, consulta l'esercitazione sul provisioning di un mesh di servizi gestito.

    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:

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

    Prendi nota del control plane visualizzato nel campo implementation, ovvero ISTIOD o TRAFFIC_DIRECTOR. Consulta Funzionalità supportate di Cloud Service Mesh per le differenze del control plane e le configurazioni supportate, nonché per la modalità di selezione dell'implementazione del control plane.

    Configura kubectl in modo che punti al cluster

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

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

    Tieni presente che un gateway in entrata non viene implementato automaticamente con il control plane. Il disaccoppiamento del deployment del gateway di ingresso e del control plane ti consente di gestire i gateway in un ambiente di produzione. Se vuoi utilizzare un gateway in entrata o in uscita Istio, consulta Deploy gateways. Se vuoi utilizzare l'API Kubernetes Gateway, consulta Preparare il gateway per Mesh. Per attivare altre funzionalità facoltative, consulta Attivazione di funzionalità facoltative su Cloud Service Mesh.

    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'espulsione dei 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

    (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 relative alla 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:

    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 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 il tuo 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.

    L'abilitazione di Cloud Service Mesh con l'API Fleet attiverà il rilevamento degli endpoint per questo cluster. Tuttavia, devi aprire le porte del firewall. Per disattivare il rilevamento degli endpoint per uno o più cluster, consulta le istruzioni per disattivarlo in Rilevamento degli endpoint tra cluster con API dichiarativa.

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

    Esegue il deployment delle applicazioni

    Se nella flotta sono presenti più cluster che utilizzano Cloud Service Mesh gestito, assicurati che l'individuazione degli endpoint o le porte firewall siano configurate come previsto prima di procedere e di eseguire il deployment delle applicazioni.

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

    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 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:

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

    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 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 riferimento 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 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 sostituire 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, l'avvio del pod potrebbe non riuscire.
    • 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 sul 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"

    Esegui la migrazione delle applicazioni a Cloud Service Mesh gestito

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

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

    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 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:

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

    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 in sequenza 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 ogni 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 si voglia limitare la configurazione 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 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 Risoluzione dei problemi del piano di controllo gestito e, se necessario, esegui 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

    Esegui i seguenti passaggi se devi eseguire il rollback alla versione precedente del control plane:

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

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

      kubectl rollout restart deployment -n NAMESPACE

    Il piano di controllo gestito verrà scalato automaticamente a zero e non utilizzerà alcuna risorsa quando non è in uso. I webhook di modifica 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 Cloud Service Mesh

    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.