Esegui il provisioning di un piano di controllo Cloud Service Mesh gestito su GKE

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

In questa pagina viene illustrato come utilizzare l'API fleet per configurare i servizi Cloud Service Mesh utilizzando le API Istio.

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.
  • Assicurati che il cluster abbia una 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 la CPU: 50 m, memoria: 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 viene attivato, ServiceEntry potrebbe non funzionare.
  • Assicurati che il computer 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. Questa operazione è inclusa nelle istruzioni o può essere eseguita separatamente prima della provisioning.
  • Nel tuo progetto deve essere abilitata la funzionalità del parco risorse Service Mesh. Questo è incluse nelle istruzioni o possono essere eseguite separatamente.

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

  • Cloud Service Mesh può utilizzare più cluster GKE in un un ambiente con una singola rete a progetto o una rete singola con più progetti completamente gestito di Google Cloud.

    • Se unisci cluster che non si trovano nello stesso progetto, questi devono essere registrati con la stessa progetto host del parco risorse, e i cluster devono trovarsi in un VPC condiviso configurazione sulla stessa rete.
    • Per un ambiente multi-cluster a progetto singolo, il progetto del parco risorse può essere come per il progetto del cluster. Per ulteriori informazioni sui parchi risorse, vedi Panoramica dei parchi risorse.
    • Per un ambiente con più progetti, ti consigliamo di ospitare il parco risorse in un un progetto separato 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, vedi Configurazione di cluster con VPC condiviso

Ruoli richiesti per installare Cloud Service Mesh

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

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 limitazioni e delle funzionalità supportate da Cloud Service Mesh. In particolare, tieni presente quanto segue:

  • L'API IstioOperator non è supportata perché il suo scopo principale è controllare nel 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 è supportato 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 eseguire l'override dei valori predefiniti utilizzando iniezione personalizzata.

  • Durante il processo di provisioning per un piano di controllo gestito, i CRD di Istio di cui è stato eseguito il provisioning 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 la sandbox GKE abilitata.

Prima di iniziare

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

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

    Go to project selector

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

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

    Go to project selector

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

  6. Configura gcloud (anche se utilizzi Cloud Shell).
    1. Esegui l'autenticazione con Google Cloud CLI, dove FLEET_PROJECT_ID è l'ID del progetto host del parco risorse. In genere, FLEET_PROJECT_ID viene creato per impostazione predefinita e ha lo stesso nome come 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 consente le seguenti API:

    API Finalità Può essere disattivato
    meshconfig.googleapis.com Cloud Service Mesh utilizza l'API Mesh Configuration per inoltrare i dati di configurazione dal tuo mesh a Google Cloud. Inoltre, l'abilitazione dell'API Mesh Configuration ti consente di accedere ai alle pagine Cloud Service Mesh nella console Google Cloud e per utilizzare dell'autorità di certificazione Cloud Service Mesh. No
    meshca.googleapis.com Contenuti correlati 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 Necessaria per gestire la rete mesh come flotta. No
    monitoring.googleapis.com Obbligatorio per acquisire la telemetria per i carichi di lavoro mesh. No
    stackdriver.googleapis.com Necessaria per utilizzare l'UI dei Servizi. No
    opsconfigmonitoring.googleapis.com Obbligatorio per utilizzare l'interfaccia utente dei servizi per i cluster al di fuori di Google Cloud. No
    connectgateway.googleapis.com Obbligatorio affinché il control plane di Cloud Service Mesh gestito possa accedere ai carichi di lavoro di mesh. Sì*
    trafficdirector.googleapis.com Abilita un piano di controllo gestito scalabile e a disponibilità elevata. Sì*
    networkservices.googleapis.com Abilita un piano di controllo gestito scalabile e a disponibilità elevata. Sì*
    networksecurity.googleapis.com Abilita un piano di controllo gestito scalabile e a disponibilità elevata. Sì*

    Configurare Cloud Service Mesh gestito

    I passaggi necessari per eseguire il provisioning di Cloud Service Mesh gestito utilizzando l'API del parco risorse dipendono sulla tua preferenza per l'attivazione valore predefinito per i nuovi cluster del parco risorse o per cluster.

    Configurazione per il tuo parco risorse

    Se hai attivato Google Kubernetes Engine (GKE) Enterprise, puoi abilita Cloud Service Mesh gestito come configurazione predefinita per il tuo parco risorse. Questo significa che ogni nuovo cluster GKE su Google Cloud registrato durante il cluster della creatività in cui è abilitato Cloud Service Mesh gestito sul cluster. Puoi scoprire di più su configurazione predefinita del parco risorse in Gestisci a livello di parco risorse funzionalità.

    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 il servizio Certificate Authority, ti consigliamo di attivarlo per cluster.

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

    Console

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

      Vai a Gestione funzionalità

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

    3. Rivedi le impostazioni ereditate da tutti i nuovi cluster che creali nella console Google Cloud e registrati 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 ti interessano da sincronizzare. Puoi selezionare solo cluster in cui è installato Cloud Service Mesh.
      2. Fai clic su Sincronizza con le impostazioni del parco e poi su Conferma nella finestra di dialogo di conferma visualizzata. Questa operazione può richiedere alcuni minuti per completare l'operazione.

    gcloud

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

    • Impostazioni a livello di parco risorse

      • Crea un file mesh.yaml contenente una sola riga management: automatic:

        echo "management: automatic" > mesh.yaml

      • Abilita 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 rete è diverso dal progetto host del parco risorse (ad esempio se utilizzi un VPC condiviso), devi consentire agli account di servizio Cloud Service Mesh nel progetto del parco risorse di accedere al progetto della rete. Dovrai eseguire questa operazione una sola volta per il progetto di rete.

        Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione ad accedere a 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, crea registrale in un unico passaggio con Google Cloud CLI per utilizzare il valore predefinito configurazione. Ad esempio:

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

        Puoi ottenere il numero di progetto per il tuo progetto di flotta eseguendo il seguente 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 attivare le API richieste nel progetto del cluster. Devi eseguire devi eseguire questa operazione una volta per ogni progetto del cluster.

        Concedi agli account di servizio 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 nel progetto del cluster:

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

        Sostituisci CLUSTER_PROJECT_ID con l'identificatore univoco di del progetto di cluster. Se hai creato il cluster nello stesso progetto del tuo parco risorse, il valore CLUSTER_PROJECT_ID sarà uguale a FLEET_PROJECT_ID.

    Procedi a Verifica che sia stato eseguito il provisioning del piano di controllo.

    Configura per cluster

    Segui questi passaggi per configurare Cloud Service Mesh gestito per ogni cluster in un unico cluster nella tua rete mesh.

    Abilita la funzionalità del parco risorse Cloud Service Mesh

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

    gcloud container fleet mesh enable --project FLEET_PROJECT_ID

    Registra i cluster in un parco risorse

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

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

    2. Verifica che il cluster sia registrato:

      gcloud container fleet memberships list --project FLEET_PROJECT_ID

      Output di esempio:

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

      Prendi nota di MEMBERSHIP_NAME, che ti servirà quando abilitare la gestione automatica.

    3. Se il progetto della rete del cluster è diverso dal progetto host del parco risorse (ad esempio, utilizzi un VPC condiviso), devi consentire agli account di servizio Cloud Service Mesh nel progetto del parco risorse di accedere al progetto della rete. Dovrai eseguire questa operazione una sola volta per il progetto di rete.

      Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione ad accedere a 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 del cluster. Se in precedenza configurato Cloud Service Mesh gestito per questa combinazione di cluster e progetti del parco risorse, queste modifiche sono già state applicate e devi eseguire questi comandi.

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

       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 Certificate Authority Service (facoltativo)

    Se il deployment del tuo service mesh richiede Certificate Authority Service (CA Service), segui la procedura descritta in Configurare Certificate Authority Service per Cloud Service Mesh gestito per attivarlo per il tuo parco risorse. Assicurati di completare tutti i passaggi prima di procedere alla prossima sezione.

    Attiva 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'abbonamento indicato al momento della verifica che il cluster sia stato registrato nel parco risorse.

    • MEMBERSHIP_LOCATION è la località del tuo abbonamento (una regione o global).

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

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

    Verifica che sia stato eseguito il provisioning del piano di controllo

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

    gcloud container fleet mesh describe --project FLEET_PROJECT_ID

    L'output è simile al seguente:

    ...
membershipSpecs:
  projects/746296320118/locations/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 piano di controllo visualizzato nel campo implementation, ISTIOD o TRAFFIC_DIRECTOR. Consulta: Funzionalità supportate da Cloud Service Mesh per scoprire le differenze del piano di controllo e le configurazioni supportate, è selezionata l'implementazione del piano di controllo.

    Configura kubectl in modo che punti al cluster

    Le sezioni seguenti richiedono l'esecuzione di comandi kubectl su ciascuno dei tuoi cluster. Prima di procedere con le sezioni seguenti, esegui il seguente comando per ciascun cluster per configurare kubectl in modo che indichi il cluster.

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

    Tieni presente che non viene eseguito automaticamente il deployment di un gateway in entrata con il controllo aereo. Disaccoppiamento del deployment del gateway in entrata e del piano di controllo consente di gestire i gateway in un ambiente di produzione. Se vuoi utilizzare un gateway di ingresso o di uscita Istio, consulta Eseguire il deployment dei gateway. Se vuoi utilizzare l'API Kubernetes Gateway, consulta Preparare il gateway per il mesh. Per attivare altre funzionalità facoltative, consulta Attivare le funzionalità facoltative su Cloud Service Mesh.

    Piano dati gestito

    Se utilizzi Cloud Service Mesh gestito, Google gestisce completamente gli upgrade dei proxy, a meno che tu non lo disattivi.

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

    Se disattivata, la gestione dei proxy è basata sul ciclo di vita naturale dei pod nel cluster e deve essere attivata manualmente dall'utente per controllare la frequenza di aggiornamento.

    Il piano dati gestito esegue gli upgrade dei proxy eliminando i pod in esecuzione 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 inseriti manualmente
    • Job
    • StatefulSet
    • DaemonSet

    (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 spazi dei nomi o pod. Il piano di dati gestito continuerà a essere disattivato per i cluster esistenti in cui è stato disattivato per impostazione predefinita o manualmente.

    Per disabilitare il piano dati gestito a livello di cluster e tornare a gestire autonomamente i proxy collaterali, modifica l'annotazione:

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

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

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

    Per disattivare il piano di dati gestito per un pod:

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

    Attiva le notifiche di manutenzione

    Puoi richiedere di ricevere notifiche sull'imminente manutenzione del piano dati gestito alla settimana prima della pianificazione della manutenzione. Le notifiche di manutenzione non vengono inviate per impostazione predefinita. Devi inoltre Configura un periodo di manutenzione di GKE prima di poter ricevere le notifiche. Quando questa impostazione è attiva, le notifiche vengono inviate al almeno due giorni prima dell'operazione di upgrade.

    Per attivare le notifiche di manutenzione del piano di 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 per 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 di dati gestito:

    Oggetto: Upgrade imminente del 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 l'upgrade il giorno ${scheduled_date_human_Leggi} alle ore ${scheduled_time_human_ read}.

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

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

    Cordiali saluti,

    Il team di 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 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 multi-cluster)

    Se il mesh ha un solo cluster, salta questi passaggi per l'utilizzo di più cluster e procedi con Esegui il deployment delle applicazioni o Eseguire la migrazione delle applicazioni.

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

    L'abilitazione di Cloud Service Mesh con l'API del parco risorse abiliterà il rilevamento degli endpoint per in 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 declarative.

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

    Esegue il deployment delle applicazioni

    Se hai più di un cluster nel parco risorse che utilizza Cloud Service Mesh gestito, assicurati che la rilevamento degli endpoint o le porte del firewall siano configurate come previsto prima di procedere ed eseguire il deployment delle applicazioni.

    Abilita lo spazio dei nomi per l'inserimento. 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 questo comando per applicare l'inserimento predefinito etichetta 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 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 piano di controllo, rimuovine una. La presenza di più canali del piano di controllo 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

    A questo punto, hai configurato correttamente 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 a problemi con i contenitori sidecar. Prima di personalizzare l'iniezione, leggi le informazioni dopo il sample per trovare note su impostazioni e consigli specifici.

    È disponibile la configurazione per pod per eseguire l'override di queste opzioni sui singoli pod. Per farlo, devi aggiungere un container istio-proxy al tuo pod. L'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 sia impostato prima dell'esecuzione dell'inserimento. Puoi impostare un'immagine specifica in modo da sostituire quella predefinita, ma ti consigliamo di impostare image su auto, il che comporterà l'inserimento dell'iniettore collaterale per selezionare automaticamente l'immagine da utilizzare.
    • Alcuni campi in containers dipendono dalle impostazioni correlate. Ad esempio: deve essere minore o uguale al limite di 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 maggiori informazioni consulta Impostare i limiti per le 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, imposta 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, configurazione delle risorse requests e limits l'uso delle annotazioni potrebbe eseguire l'overprovisioning delle risorse. Utilizza l'approccio del modello di immagine per evitarlo. Consulta gli esempi di modifica delle risorse in Autopilot.

    Ad esempio, consulta la seguente annotazione per le risorse:

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

    Esegui la migrazione delle applicazioni a Cloud Service Mesh gestito

    Per eseguire la migrazione delle applicazioni da Cloud Service Mesh nel cluster a Cloud Service Mesh gestito: segui questi passaggi:

    1. Sostituisci l'etichetta dello spazio dei nomi attuale. 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 questo comando per applicare l'inserimento predefinito etichetta 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 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 riportato sopra sono presenti due revisioni del piano di controllo, rimuovine una. La presenza di più canali del piano di controllo nel cluster non è supportata.

      Nell'output, il valore sotto la colonna NAME è l'etichetta di revisione che corrisponde 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 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 sia necessario limitare la configurazione solo a un sottoinsieme di cluster. La di sicurezza applicata a un determinato cluster è la fonte di riferimento 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à scalato automaticamente per utilizzare meno risorse. Per rimuoverlo, vai a Elimina il piano di controllo precedente.

    Se riscontri problemi, puoi identificarli e risolverli utilizzando le informazioni in Risolvere i problemi relativi al piano di controllo gestito e, se necessario, esegui 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 al posto dell'inserimento automatico o se hai installato gateway aggiuntivi, controlla le metriche per il piano di controllo e verificare che il numero di endpoint connessi sia zero.

    Rollback

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

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

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

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

      kubectl rollout restart deployment -n NAMESPACE

    Il piano di controllo gestito scalerà automaticamente fino a zero e non utilizzerà quando non è in uso. I webhook mutanti e il provisioning rimarranno e non influiscono 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 rieseguirà il deployment del gateway al piano di controllo nel 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 piano di controllo gestito scala automaticamente fino a zero quando non è utilizzato da nessuno spazio dei nomi. Per i passaggi dettagliati, vedi Disinstallare Cloud Service Mesh.