Aggiornamenti della configurazione per la modernizzazione

Questo documento descrive gli aggiornamenti di configurazione che devi apportare ai cluster Cloud Service Mesh gestiti se segnalati dai controlli di compatibilità prima di eseguire la modernizzazione dal control plane ISTIOD deprecato al control plane TRAFFIC_DIRECTOR prima della scadenza del supporto.

Di seguito è riportato un elenco dei possibili aggiornamenti della configurazione necessari per preparare il cluster alla modernizzazione. Per le istruzioni di aggiornamento, consulta ogni sezione:

• Multi-cluster
• Abilita Workload Identity Federation for GKE
• Abilita CNI gestita
• Utilizzo di file binari non standard nel sidecar
• Esegui la migrazione al gateway Istio Ingress
• Modernizza le configurazioni del compressore EnvoyFilter
• Abilita gruppi di endpoint di rete internet
• Autorizzazioni VPC condiviso
• Configurazione del control plane mancante

Per saperne di più sul flusso di lavoro di modernizzazione, consulta la pagina Modernizzazione del control plane gestito.

Esegui la migrazione dai secret Istio a multicluster_mode

I secret multi-cluster non sono supportati quando un cluster utilizza il control plane TRAFFIC_DIRECTOR. Questo documento descrive come eseguire la modernizzazione passando dall'utilizzo dei secret multi-cluster di Istio all'utilizzo di multicluster_mode.

Panoramica dei secret di Istio rispetto all'API dichiarativa

Il rilevamento degli endpoint multi-cluster Istio open source funziona utilizzando istioctl o altri strumenti per creare un secret Kubernetes in un cluster. Questo secret consente a un cluster di bilanciare il carico del traffico verso un altro cluster nel mesh. Il control plane di ISTIOD legge quindi questo secret e inizia a instradare il traffico verso l'altro cluster.

Cloud Service Mesh ha un'API dichiarativa per controllare il traffico multi-cluster anziché creare direttamente i secret di Istio. Questa API tratta i secret Istio come un dettaglio di implementazione ed è più affidabile rispetto alla creazione manuale dei secret Istio. Le funzionalità future di Cloud Service Mesh dipenderanno dall'API dichiarativa e non potrai utilizzarle direttamente con i secret di Istio. L'API dichiarativa è l'unico percorso supportato.

Se utilizzi i secret di Istio, esegui la migrazione all'utilizzo dell'API dichiarativa il prima possibile. Tieni presente che l'impostazione multicluster_mode indica a ogni cluster di indirizzare il traffico a tutti gli altri cluster nel mesh. L'utilizzo dei secret consente una configurazione più flessibile, permettendoti di configurare per ogni cluster verso quale altro cluster deve indirizzare il traffico nel mesh. Per un elenco completo delle differenze tra le funzionalità supportate dell'API dichiarativa e dei secret di Istio, consulta Funzionalità supportate che utilizzano le API Istio.

Importante: con l'API dichiarativa, l'intero cluster viene attivato per il rilevamento degli endpoint alla volta. Ciò significa che ogni cluster con `multicluster_mode=connected` rileverà gli endpoint per ogni altro cluster del parco risorse che ha anche `multicluster_mode=connected`.

Esegui la migrazione dai secret di Istio all'API dichiarativa

Se hai eseguito il provisioning di Cloud Service Mesh utilizzando la gestione automatica con l'API della funzionalità del parco risorse, non devi seguire queste istruzioni. Questi passaggi si applicano solo se hai eseguito l'onboarding utilizzando asmcli --managed.

Tieni presente che questo processo modifica i secret che puntano a un cluster. Durante questo processo, gli endpoint vengono rimossi e poi aggiunti di nuovo. Tra la rimozione e l'aggiunta degli endpoint, il traffico tornerà brevemente al routing locale anziché al bilanciamento del carico verso altri cluster. Per saperne di più, consulta il problema di GitHub.

Per passare dall'utilizzo dei secret Istio all'API dichiarativa, segui questi passaggi. Esegui questi passaggi contemporaneamente o in rapida successione:

1. Abilita l'API dichiarativa per ogni cluster del parco risorse in cui vuoi attivare il rilevamento degli endpoint multi-cluster impostando multicluster_mode=connected. Tieni presente che devi impostare esplicitamente multicluster_mode=disconnected se non vuoi che il cluster sia rilevabile.

   Utilizza il seguente comando per attivare un cluster per il discovery degli endpoint multi-cluster:

    kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
   

   Utilizza il seguente comando per disattivare il rilevamento degli endpoint per un cluster:

    kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
   

2. Elimina i vecchi secret.

   Dopo aver impostato multicluster_mode=connected sui tuoi cluster, per ogni cluster verrà generato un nuovo secret per ogni altro cluster su cui è impostato multicluster_mode=connected. Il secret viene inserito nello spazio dei nomi istio-system e ha il seguente formato:

   istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
   

   A ogni secret verrà applicata anche l'etichetta istio.io/owned-by: mesh.googleapis.com.

   Una volta creati i nuovi secret, puoi eliminare tutti i secret creati manualmente con istioctl create-remote-secret:

   kubectl delete secret SECRET_NAME -n istio-system
   

Una volta eseguita la migrazione, controlla le metriche delle richieste per assicurarti che vengano indirizzate come previsto.

Abilita la federazione delle identità per i workload per GKE

La federazione delle identità per i workload è il metodo sicuro consigliato per i workload di Google Kubernetes Engine. In questo modo, è possibile accedere ai servizi Google Cloud come Compute Engine, BigQuery e le API di machine learning. La federazione delle identità per i workload non richiede la configurazione manuale o metodi meno sicuri come i file delle chiavi dei account di servizio, perché utilizza le policy IAM. Per maggiori dettagli sulla federazione delle identità per i workload, consulta Come funziona la federazione delle identità per i workload per GKE.

La sezione seguente descrive come abilitare la federazione delle identità per i workload.

Abilita la federazione delle identità per i workload sui cluster

1. Verifica che la federazione delle identità per i workload sia abilitata per il tuo cluster. Per farlo, assicurati che nel cluster GKE sia configurato un set di pool di federazione delle identità per i workload, essenziale per la convalida delle credenziali IAM.

   Utilizza il seguente comando per controllare il pool di identità del workload impostato per un cluster:

   gcloud container clusters describe CLUSTER_NAME \
     --format="value(workloadIdentityConfig.workloadPool)"
   

   Sostituisci CLUSTER_NAME con il nome del tuo cluster GKE. Se non hai ancora specificato una zona o una regione predefinita per gcloud, potresti dover specificare anche un flag --region o --zone quando esegui questo comando.

2. Se l'output è vuoto, segui le istruzioni riportate in Aggiorna un cluster esistente per abilitare Workload Identity sui cluster GKE esistenti.

Abilita la federazione delle identità per i workload sui pool di nodi

Dopo aver attivato la federazione delle identità per i workload su un cluster, i node pool devono essere configurati per utilizzare il server metadati GKE.

1. Elenca tutti i node pool di un cluster Standard. Esegui il comando gcloud container node-pools list:

   gcloud container node-pools list --cluster CLUSTER_NAME
   

   Sostituisci CLUSTER_NAME con il nome del tuo cluster GKE. Se non hai ancora specificato una zona o una regione predefinita per gcloud, potresti dover specificare anche un flag --region o --zone quando esegui questo comando.

2. Verifica che ogni pool di nodi utilizzi il server di metadati GKE:

   gcloud container node-pools describe NODEPOOL_NAME \
       --cluster=CLUSTER_NAME \
       --format="value(config.workloadMetadataConfig.mode)"
   

   Sostituisci quanto segue:

   • NODEPOOL_NAME con il nome del tuo node pool.
   • CLUSTER_NAME con il nome del tuo cluster GKE.

3. Se l'output non contiene GKE_METADATA, aggiorna il pool di nodi utilizzando la guida Aggiorna un node pool esistente.

Abilita l'interfaccia di rete container (CNI) gestita

Questa sezione illustra come attivare CNI gestito per Cloud Service Mesh su Google Kubernetes Engine.

Panoramica di CNI gestito

Container Network Interface (CNI) gestita è un'implementazione di Istio CNI gestita da Google. Il plug-in CNI semplifica il networking dei pod configurando le regole iptables. In questo modo, il traffico viene reindirizzato tra le applicazioni e i proxy Envoy, eliminando la necessità di autorizzazioni con privilegi per il container init necessarie per gestire iptables.

Il plug-in Istio CNI sostituisce il container istio-init. Il container istio-init era precedentemente responsabile della configurazione dell'ambiente di rete del pod per abilitare l'intercettazione del traffico per il sidecar Istio. Il plug-in CNI esegue la stessa funzione di reindirizzamento della rete, ma con l'ulteriore vantaggio di ridurre la necessità di privilegi elevati, migliorando così la sicurezza.

Pertanto, per una maggiore sicurezza e affidabilità e per semplificare la gestione e la risoluzione dei problemi, è necessario un CNI gestito in tutti i deployment di Cloud Service Mesh gestito.

Impatto sui container init

I container init sono container specializzati che vengono eseguiti prima dei container dell'applicazione per le attività di configurazione. Le attività di configurazione possono includere attività come il download di file di configurazione, la comunicazione con servizi esterni o l'esecuzione dell'inizializzazione pre-applicazione. I container init che si basano sull'accesso alla rete potrebbero riscontrare problemi quando CNI gestito è abilitato nel cluster.

La procedura di configurazione dei pod con CNI gestita è la seguente:

1. Il plug-in CNI configura le interfacce di rete dei pod, assegna gli IP dei pod e reindirizza il traffico al proxy sidecar Istio, che non è ancora stato avviato.
2. Tutti i container init vengono eseguiti e completati.
3. Il proxy sidecar di Istio viene avviato insieme ai container dell'applicazione.

Pertanto, se un container init tenta di stabilire connessioni di rete in uscita o di connettersi ai servizi all'interno del mesh, le richieste di rete provenienti dai container init potrebbero essere ignorate o indirizzate in modo errato. Questo perché il proxy sidecar Istio, che gestisce il traffico di rete per il pod, non è in esecuzione quando vengono effettuate le richieste. Per maggiori dettagli, consulta la documentazione di Istio CNI.

Abilita CNI gestita per il cluster

Segui i passaggi descritti in questa sezione per abilitare CNI gestita nel tuo cluster.

1. Rimuovi le dipendenze di rete dal container init. Prendi in considerazione le seguenti alternative:

   • Modifica la logica o i container dell'applicazione: puoi modificare i servizi per rimuovere la dipendenza dai container init che richiedono richieste di rete o eseguire operazioni di rete all'interno dei container dell'applicazione, dopo l'avvio del proxy sidecar.
   • Utilizza i secret o i ConfigMap di Kubernetes: archivia i dati di configurazione recuperati dalla richiesta di rete nei secret o nei ConfigMap di Kubernetes e montali nei container dell'applicazione. Per soluzioni alternative, consulta la documentazione di Istio.

2. Abilita CNI gestita nel cluster:

   1. Apporta le seguenti modifiche alla configurazione:

      1. Esegui questo comando per individuare controlPlaneRevision.

         kubectl get controlplanerevision -n istio-system
         

      2. Nella risorsa personalizzata (CR) ControlPlaneRevision (CPR), imposta l'etichetta mesh.cloud.google.com/managed-cni-enabled su true.

         kubectl label controlplanerevision CPR_NAME \
             -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
             --overwrite
         

         Sostituisci CPR_NAME con il valore nella colonna NAME dell'output del passaggio precedente.

      3. In ConfigMap asm-options, imposta il valore ASM_OPTS su CNI=on.

         kubectl patch configmap asm-options -n istio-system \
             -p '{"data":{"ASM_OPTS":"CNI=on"}}'
         

      4. Nella risorsa personalizzata (CR) ControlPlaneRevision (CPR), imposta l'annotazione mesh.cloud.google.com/force-reprovision su true. Questa azione attiva il riavvio del control plane.

         Nota: questo metodo non è quello consigliato per riavviare il control plane e deve essere utilizzato solo per le attività di modernizzazione di Cloud Service Mesh.

         kubectl annotate controlplanerevision CPR_NAME \
             -n istio-system mesh.cloud.google.com/force-reprovision=true \
             --overwrite
         

   2. Controlla lo stato della funzionalità. Recupera lo stato funzionalità utilizzando il seguente comando:

      gcloud container fleet mesh describe --project FLEET_PROJECT_ID
      

      Sostituisci FLEET_PROJECT_ID con l'ID del progetto host del parco risorse. In genere, il FLEET_PROJECT_ID ha lo stesso nome del progetto.

      • Verifica che la condizione MANAGED_CNI_NOT_ENABLED sia stata rimossa da servicemesh.conditions.
      • Tieni presente che l'aggiornamento dello stato potrebbe richiedere fino a 15-20 minuti. Prova ad attendere qualche minuto ed esegui di nuovo il comando.

   3. Una volta che controlPlaneManagement.state è Active nello stato funzionalità del cluster, riavvia i pod.

Abbandona l'utilizzo di file binari non standard in Sidecar

Questa sezione suggerisce modi per rendere i tuoi deployment compatibili con l'immagine proxy Envoy distroless.

Immagini sidecar del proxy Envoy distroless

Cloud Service Mesh utilizza due tipi di immagini sidecar del proxy Envoy in base alla configurazione del control plane: l'immagine proxy default (contenente vari binari di debug) e l'immagine proxy distroless.

Per i cluster con il control plane TRAFFIC_DIRECTOR gestito:

• Cluster con onboarding diretto: utilizza le immagini distroless per impostazione predefinita.
• Cluster di cui è stata eseguita la migrazione da CSM-ISTIOD: utilizza le immagini default per impostazione predefinita. Puoi attivare esplicitamente le immagini distroless per migliorare la tua security posture.

Per attivare le immagini distroless per un cluster di cui è stata eseguita la migrazione da CSM-ISTIOD, puoi configurarle a livello globale utilizzando defaultConfig.image.imageType: distroless nel tuo MeshConfig o per workload utilizzando l'annotazione del pod sidecar.istio.io/proxyImageType: distroless.

Le immagini di base distroless sono immagini container minime che danno priorità alla sicurezza e all'ottimizzazione delle risorse includendo solo i componenti essenziali. La superficie di attacco è ridotta per contribuire a prevenire le vulnerabilità. Per saperne di più, consulta la documentazione sull'immagine proxy distroless.

Compatibilità binaria

Come best practice, devi limitare i contenuti di un runtime del container solo ai pacchetti necessari. Questo approccio migliora la sicurezza e il rapporto segnale/rumore degli scanner di vulnerabilità ed esposizioni comuni (CVE). L'immagine sidecar distroless ha un insieme minimo di dipendenze, privo di tutti gli eseguibili, le librerie e gli strumenti di debug non essenziali. Pertanto, non è possibile eseguire un comando shell o utilizzare curl, ping o altre utilità di debug come kubectl exec all'interno del container.

Rendi i cluster compatibili con le immagini distroless

• Rimuovi i riferimenti a eventuali programmi binari non supportati (come bash o curl) dalla configurazione. In particolare, all'interno dei probe di idoneità, avvio e attività e degli hook PostStart e PreStop del ciclo di vita all'interno dei container istio-proxy, istio-init o istio-validation.
• Prendi in considerazione alternative come holdApplicationUntilProxyStarts per determinati casi d'uso.
• Per il debug, puoi utilizzare i container temporanei da collegare a un pod del workload in esecuzione. Puoi quindi ispezionarlo ed eseguire comandi personalizzati. Per un esempio, consulta Raccolta dei log di {service_mesh_name}.

Se non riesci a trovare una soluzione per il tuo caso d'uso specifico, contatta l'assistenza Google Cloud all'indirizzo Richiedere assistenza.

Esegui la migrazione al gateway Istio Ingress

Questa sezione mostra come eseguire la migrazione al gateway Istio Ingress. Esistono due metodi per eseguire la migrazione al gateway Istio Ingress:

1. Migrazione in fasi con suddivisione del traffico

   Questo metodo dà la priorità alla riduzione al minimo delle interruzioni, inviando in modo incrementale il traffico al nuovo gateway Istio, consentendoti di monitorare le sue prestazioni su una piccola percentuale di richieste e di eseguire rapidamente il rollback, se necessario. Tieni presente che la configurazione della suddivisione del traffico di livello 7 può essere difficile per alcune applicazioni, quindi devi gestire entrambi i sistemi gateway contemporaneamente durante la transizione. Per i passaggi, consulta Migrazione in fasi con suddivisione del traffico.

2. Migrazione diretta

   Questo metodo prevede il cambio percorso simultaneo di tutto il traffico verso il nuovo gateway Istio una volta completati i test. Il vantaggio di questo approccio è la completa separazione dall'infrastruttura del gateway precedente, che consente una configurazione adattabile del nuovo gateway senza i vincoli della configurazione esistente. Tuttavia, esiste un rischio maggiore di tempi di inattività nel caso in cui si verifichino problemi imprevisti con il nuovo gateway durante la transizione. Per i passaggi, consulta Migrazione diretta.

I seguenti esempi di migrazione presuppongono che tu abbia un servizio HTTP (httpbin) in esecuzione nello spazio dei nomi dell'applicazione (predefinito) ed esposto esternamente utilizzando l'API Gateway di Kubernetes. Le configurazioni pertinenti sono:

• Gateway: k8-api-gateway (nello spazio dei nomi istio-ingress) - configurato per ascoltare il traffico HTTP sulla porta 80 per qualsiasi nome host che termina con .example.com.
• HTTPRoute: httpbin-route (nello spazio dei nomi default) - indirizza qualsiasi richiesta HTTP con il nome host httpbin.example.com e un percorso che inizia con /get al servizio httpbin nello spazio dei nomi default.
• L'applicazione httpbin è accessibile utilizzando l'IP esterno 34.57.246.68.

Migrazione in fasi con suddivisione del traffico

Esegui il provisioning di un nuovo Istio Ingress Gateway

1. Esegui il deployment di un nuovo gateway in entrata seguendo i passaggi descritti nella sezione Esegui il deployment del gateway di esempio e personalizza le configurazioni di esempio in base alle tue esigenze. Gli esempi nel repository anthos-service-mesh sono destinati al deployment di un servizio istio-ingressgateway loadBalancer e dei pod ingress-gateway corrispondenti.

   Esempio di risorsa Gateway (istio-ingressgateway.yaml)

    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: istio-api-gateway
      namespace: GATEWAY_NAMESPACE
    spec:
      selector:
        istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:   # or specific hostnames if needed
        - "httpbin.example.com"
   

2. Applica la configurazione Gateway per gestire il traffico:

   kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
   

   Assicurati che "spec.selector" nella risorsa Gateway corrisponda alle etichette dei pod ingress-gateway. Ad esempio, se i pod ingress-gateway hanno l'etichetta istio=ingressgateway, anche la configurazione del gateway deve selezionare questa etichetta istio=ingressgateway.

Configura il routing iniziale per il nuovo gateway

1. Definisci le regole di instradamento iniziali per la tua applicazione utilizzando un VirtualService di Istio.

   Esempio di VirtualService (my-app-vs-new.yaml):

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: httpbin-vs
     namespace: APPLICATION_NAMESPACE
   spec:
       gateways:
       - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
       hosts:
       - httpbin.example.com
       http:
       - match:
         - uri:
             prefix: /get
         route:
         - destination:
             host: httpbin
             port:
               number: 8000
   

2. Applica il VirtualService:

   kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE
   

Accedi al servizio di backend (httpbin) tramite il gateway Istio Ingress di cui è stato appena eseguito il deployment

1. Imposta la variabile di ambiente Ingress Host sull'indirizzo IP esterno associato al bilanciatore del carico istio-ingressgateway di cui è stato eseguito il deployment di recente:

   export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   

2. Verifica che l'applicazione (httpbin) sia accessibile utilizzando il nuovo gateway:

   curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
   

   L'output è simile al seguente:

   HTTP/1.1 200 OK
   

Modifica l'Ingress esistente per la suddivisione del traffico

Dopo aver confermato la corretta configurazione del nuovo gateway (ad es. istio-api-gateway), puoi iniziare a instradare una parte del traffico attraverso di esso. Per farlo, aggiorna la risorsa HTTPRoute attuale in modo da indirizzare una piccola percentuale di traffico al nuovo gateway, mentre la parte più grande continua a utilizzare il gateway esistente (k8-api-gateway).

1. Apri httproute per la modifica:

   kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE
   

2. Aggiungi un nuovo riferimento di backend che punti al servizio del bilanciatore del carico del nuovo gateway in entrata con un peso iniziale del 10% e aggiorna il peso per il backend del gateway precedente.

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: httpbin-route
     namespace: MY_APP_NAMESPACE  # your application's namespace
   spec:
     parentRefs:
     - name: k8-api-gateway
       namespace: istio-ingress
     hostnames: ["httpbin.example.com"]
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: /get
       backendRefs:
       - name: httpbin
         port: 8000
         weight: 90
       - name: istio-ingressgateway # Newly deployed load balancer service
         namespace: GATEWAY_NAMESPACE
         port: 80
         weight: 10
   

3. Concedi l'autorizzazione per i riferimenti tra spazi dei nomi con ReferenceGrant.

   Per consentire a HTTPRoute nello spazio dei nomi dell'applicazione (predefinito) di accedere al servizio loadbalancer nello spazio dei nomi del gateway (istio-ingress), potrebbe essere necessario creare una concessione di riferimento. Questa risorsa funge da controllo di sicurezza, definendo esplicitamente quali riferimenti tra spazi dei nomi sono consentiti.

   Il seguente istio-ingress-grant.yaml descrive un esempio di concessione di riferimento:

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: ReferenceGrant
   metadata:
     name: istio-ingressgateway-grant
     namespace: istio-ingress # Namespace of the referenced resource
   spec:
     from:
     - group: gateway.networking.k8s.io
       kind: HTTPRoute
       namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
     to:
     - group: ""               # Core Kubernetes API group for Services
       kind: Service
       name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway
   

4. Applica la concessione di riferimento:

   kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE
   

5. Verifica le richieste all'indirizzo IP esterno esistente (ad es. 34.57.246.68) non presentano errori. Il seguente check-traffic-flow.sh descrive uno script per verificare gli errori delle richieste:

   # Update the following values based on your application setup
   external_ip="34.57.246.68" # Replace with existing external IP
   url="http://$external_ip/get"
   host_name="httpbin.example.com"
   
   # Counter for successful requests
   success_count=0
   
   # Loop 50 times
   for i in {1..50}; do
     # Perform the curl request and capture the status code
     status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
     # Check if the request was successful (status code 200)
     if [ "$status_code" -eq 200 ]; then
       ((success_count++))  # Increment the success counter
     else
       echo "Request $i: Failed with status code $status_code"
     fi
   done
   
   # After the loop, check if all requests were successful
   if [ "$success_count" -eq 50 ]; then
     echo "All 50 requests were successful!"
   else
     echo "Some requests failed.  Successful requests: $success_count"
   fi
   

6. Esegui lo script per verificare che nessuna richiesta non vada a buon fine, indipendentemente dal percorso del traffico:

   chmod +x check-traffic-flow.sh
   ./check-traffic-flow.sh
   

Aumenta lentamente la percentuale di traffico

Se non vengono rilevati errori di richiesta per l'indirizzo IP esterno esistente (ad esempio 34.57.246.68), sposta gradualmente più traffico verso il nuovo gateway Istio Ingress modificando i pesi del backend in HTTPRoute. Aumenta il peso per istio-ingressgateway e diminuisci il peso per il vecchio gateway con piccoli incrementi, ad esempio 10%, 20% e così via.

Importante: osserva continuamente le metriche chiave come il tasso di successo delle richieste, la latenza, le percentuali di errore e l'utilizzo delle risorse dei pod dell'applicazione per garantire la stabilità a ogni incremento.

Utilizza il seguente comando per aggiornare il HTTPRoute esistente:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migrazione completa del traffico e rimozione del vecchio gateway

1. Quando il nuovo gateway in entrata Istio mostra prestazioni stabili e una gestione delle richieste riuscita, sposta tutto il traffico verso di esso. Aggiorna la tua HTTPRoute per impostare il peso del backend del gateway precedente su 0 e quello del nuovo gateway su 100.

2. Una volta che il traffico è stato completamente instradato al nuovo gateway, aggiorna i record DNS esterni per il nome host della tua applicazione (ad esempio, httpbin.example.com) in modo che puntino all'indirizzo IP esterno del servizio del bilanciatore del carico creato in Esegui il provisioning di un nuovo Istio Ingress Gateway.

3. Infine, elimina il vecchio gateway e le risorse associate:

   kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
   kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
   

Migrazione diretta

Esegui il provisioning di un nuovo Istio Ingress Gateway

1. Esegui il deployment di un nuovo gateway in entrata seguendo i passaggi descritti nella sezione Esegui il deployment del gateway di esempio e personalizza le configurazioni di esempio in base alle tue esigenze. Gli esempi nel repository anthos-service-mesh sono destinati al deployment di un servizio istio-ingressgateway loadBalancer e dei pod ingress-gateway corrispondenti.

   Esempio di risorsa Gateway (istio-ingressgateway.yaml)

    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: istio-api-gateway
      namespace: GATEWAY_NAMESPACE
    spec:
      selector:
        istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:   # or specific hostnames if needed
        - "httpbin.example.com"
   

2. Applica la configurazione Gateway per gestire il traffico:

   kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
   

   Assicurati che "spec.selector" nella risorsa Gateway corrisponda alle etichette dei pod ingress-gateway. Ad esempio, se i pod ingress-gateway hanno l'etichetta istio=ingressgateway, anche la configurazione del gateway deve selezionare questa etichetta istio=ingressgateway.

Configura il routing iniziale per il nuovo gateway

1. Definisci le regole di instradamento iniziali per la tua applicazione utilizzando un VirtualService di Istio.

   Esempio di VirtualService (my-app-vs-new.yaml):

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: httpbin-vs
     namespace: APPLICATION_NAMESPACE
   spec:
       gateways:
       - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
       hosts:
       - httpbin.example.com
       http:
       - match:
         - uri:
             prefix: /get
         route:
         - destination:
             host: httpbin
             port:
               number: 8000
   

2. Applica il VirtualService:

   kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE
   

Accedi al servizio di backend (httpbin) tramite il gateway Istio Ingress di cui è stato appena eseguito il deployment

1. Imposta la variabile di ambiente Ingress Host sull'indirizzo IP esterno associato al bilanciatore del carico istio-ingressgateway di cui è stato eseguito il deployment di recente:

   export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   

2. Verifica che l'applicazione (httpbin) sia accessibile utilizzando il nuovo gateway:

   curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
   

   L'output è simile al seguente:

   HTTP/1.1 200 OK
   

Testa e monitora il nuovo gateway

1. Testa tutte le regole di instradamento, convalida la configurazione TLS, le policy di sicurezza e altre funzionalità. Esegui test di carico per verificare che il nuovo gateway possa gestire il traffico previsto.

2. Una volta testato completamente il nuovo gateway, aggiorna i record DNS esterni per il nome host dell'applicazione (ad esempio httpbin.example.com) in modo che puntino all'indirizzo IP esterno del servizio del bilanciatore del carico creato in Esegui il provisioning di un nuovo Istio Ingress Gateway.

3. Monitora le metriche chiave, come il tasso di successo delle richieste, la latenza, le percentuali di errore e l'utilizzo delle risorse dei pod dell'applicazione, per verificare la stabilità con il nuovo Istio Ingress Gateway. Una volta stabilizzato, puoi eliminare il gateway precedente e le risorse associate

   kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
   kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
   

Considerazioni importanti: se la tua applicazione richiede HTTPS, assicurati che i certificati e le configurazioni TLS siano configurati correttamente sul nuovo gateway in entrata Istio. Per maggiori dettagli, consulta Configura la terminazione TLS nel gateway in entrata.

Correggi più control plane

In precedenza, Cloud Service Mesh supportava l'onboarding utilizzando asmcli (ritirato), che non bloccava il provisioning di più control plane. Cloud Service Mesh ora applica la best practice di eseguire il deployment di un solo canale per cluster che corrisponde al canale del cluster e non supporta l'utilizzo di più canali di cui è stato eseguito il deployment nello stesso cluster.

Se vuoi eseguire deployment canary su nuove versioni del mesh nel canale rapido prima che diventino disponibili nel canale stabile o regolare, devi utilizzare due cluster diversi, ciascuno con un canale separato. Tieni presente che i canali sono controllati dal canale del cluster GKE e che Mesh non ha un canale separato associato.

Puoi verificare se hai più canali cercando la condizione di stato UNSUPPORTED_MULTIPLE_CONTROL_PLANES nel tuo abbonamento. Se questo avviso non viene visualizzato, significa che non sei interessato e puoi saltare la lettura di questa sezione.

1. Esegui questo comando per verificare se il cluster ha più canali del control plane:

   gcloud container fleet mesh describe
   

   L'output è simile al seguente:

   ...
   projects/.../locations/global/memberships/my-membership:
       servicemesh:
         conditions:
         - code: UNSUPPORTED_MULTIPLE_CONTROL_PLANES
           details: 'Using multiple control planes is not supported. Please remove a control plane from your cluster.'
           documentationLink: https://cloud.google.com/service-mesh/v1.30/docs/migrate/modernization-configuration-updates#multiple_control_planes
           severity: WARNING
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed-stable'
           implementation: ISTIOD
           state: ACTIVE
   ...
   

2. Se è presente la condizione UNSUPPORTED_MULTIPLE_CONTROL_PLANES, determina quali canali esistono per il tuo cluster:

   kubectl get controlplanerevisions -n istio-system
   

   L'output è simile al seguente:

   NAME                 RECONCILED   STALLED   AGE
   asm-managed-stable   True         False     97d
   asm-managed          True         False     97d
   asm-managed-rapid    True         False     97d
   

   In questo esempio, è stato eseguito il provisioning di tutti e tre i canali:

   • asm-managed-stable -> STABLE
   • asm-managed -> REGULAR
   • asm-managed-rapid -> RAPID

   Se viene visualizzato un solo risultato, significa che è stato eseguito il provisioning di un solo canale sul tuo cluster e puoi saltare il resto di questi passaggi.

   Se vengono visualizzati due o più risultati, segui i passaggi rimanenti per rimuovere i canali in eccesso.

Consolida i workload in un unico canale

Prima di poter rimuovere canali aggiuntivi, devi assicurarti che i tuoi workload utilizzino un solo canale.

1. Trova tutte le etichette che utilizzi nel cluster:

   kubectl get namespaces -l istio.io/rev=RELEASE_CHANNEL
   

   A seconda dell'output del comando precedente, sostituisci RELEASE_CHANNEL con asm-managed-stable, asm-managed o asm-managed-rapid. Ripeti questo passaggio per ogni canale di cui è stato eseguito il provisioning.

   L'output è simile al seguente:

   NAME      STATUS   AGE
   default   Active   110d
   

   Tieni presente che in questo esempio lo spazio dei nomi predefinito viene inserito con il canale regolare.

   Se tutti i tuoi workload utilizzano già lo stesso canale, puoi andare al passaggio Rimuovi i canali aggiuntivi. In caso contrario, continua in questa sezione.

2. Modifica le etichette in modo che venga utilizzato un solo canale:

   Attenzione: prima di modificare le etichette, tieni presente quanto segue.
   • In alcuni casi, i pod possono anche essere inseriti direttamente con l'etichetta sidecar.istio.io/inject. Assicurati di controllare anche questi per l'utilizzo.
   • Puoi ignorare le etichette istio-injection=enabled per questo passaggio. Gli spazi dei nomi con questa etichetta cambieranno automaticamente in modo da corrispondere al canale rimasto nel cluster.
   • Quando selezioni un canale da mantenere, prova a selezionare quello che corrisponde al canale del cluster GKE. Se questo canale non esiste, seleziona uno dei canali attivi.
   • Il canale effettivo selezionato non è importante. Il canale del cluster GKE determina la versione del mesh che ricevi, non il canale del mesh.
   • Controlla la configurazione di meshconfig tra tutti i canali attivi in uso per assicurarti che non ci siano differenze tra loro. Ogni canale utilizza un configmap separato per la configurazione, quindi il consolidamento di due canali in uno dovrebbe garantire un comportamento coerente tra i due canali. kubectl get configmap istio-asm-managed{-rapid | -stable} -n istio-system -o yaml

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

   Sostituisci NAMESPACE con il nome del tuo namespace.

   La best practice è utilizzare istio-injection=enabled. Tuttavia, se non vuoi utilizzare questa etichetta, puoi anche utilizzare istio.io/rev=RELEASE_CHANNEL.

   Dopo aver modificato l'etichetta di uno spazio dei nomi o di un pod, devi riavviare tutti i workload in modo che vengano inseriti dal control plane corretto.

Rimuovi i canali aggiuntivi

Dopo aver verificato che tutti i workload sono in esecuzione su un singolo canale, puoi rimuovere i canali aggiuntivi inutilizzati. Se è stato eseguito il provisioning di tutti e tre i canali di rilascio, ricordati di eseguire i seguenti comandi per ogni canale.

1. Elimina la risorsa ControlPlaneRevision aggiuntiva:

   kubectl delete controlplanerevision RELEASE_CHANNEL -n istio-system
   

   Sostituisci RELEASE_CHANNEL con asm-managed-stable, asm-managed o asm-managed-rapid.

2. Elimina MutatingWebhookConfiguration:

   kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL
   

3. Elimina il configmap meshconfig:

   kubectl delete configmap istio-RELEASE_CHANNEL
   

Attiva la gestione automatica

Attenzione: l'abilitazione della gestione automatica del control plane abilita automaticamente il multi-cluster e il data plane gestito su quel cluster.

1. Esegui questo comando per attivare la gestione automatica:

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

   Sostituisci quanto segue:

   • MEMBERSHIP_NAME è il nome dell'appartenenza elencato quando hai verificato che il cluster era registrato nel parco risorse.
   • PROJECT_ID è l'ID progetto del tuo progetto.
   • MEMBERSHIP_LOCATION è la località del tuo abbonamento (una regione o global). Puoi controllare la località del tuo abbonamento con gcloud container fleet memberships list --project PROJECT_ID.

2. Verifica che la gestione automatica sia abilitata:

   gcloud container fleet mesh describe
   

   L'output è simile al seguente:

   ...
   membershipSpecs:
     projects/.../locations/us-central1/memberships/my-member:
       mesh:
         management: MANAGEMENT_AUTOMATIC
   membershipStates:
     projects/.../locations/us-central1/memberships/my-member:
       servicemesh:
         conditions:
         - code: VPCSC_GA_SUPPORTED
           details: This control plane supports VPC-SC GA.
           documentationLink: http://cloud.google.com/service-mesh/v1.30/docs/managed/vpc-sc
           severity: INFO
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed'
           implementation: TRAFFIC_DIRECTOR
           state: ACTIVE
         dataPlaneManagement:
           details:
           - code: OK
             details: Service is running.
           state: ACTIVE
       state:
         code: OK
         description: |-
           Revision ready for use: asm-managed.
           All Canonical Services have been reconciled successfully.
   ...
   

Modernizza le configurazioni del compressore EnvoyFilter

Se utilizzi il filtro envoy.extensions.filters.http.compressor.v3.Compressor, diversi campi di primo livello sono stati ritirati in Envoy e spostati in response_direction_config.common_config e request_direction_config.common_config.

Per scoprire come aggiornare le risorse EnvoyFilter al formato moderno e supportato, consulta la guida Modernizza le configurazioni del compressore EnvoyFilter.

Abilitazione di una policy dell'organizzazione obbligatoria

Cloud Service Mesh richiede l'attivazione di policy specifiche per funzionare correttamente.

Policy obbligatorie

compute.disableInternetNetworkEndpointGroup

Cloud Service Mesh richiede la possibilità di creare gruppi di endpoint di rete (NEG) internet. Questi NEG sono componenti essenziali per il routing del traffico ai servizi esterni a Google Cloud.

Il vincolo constraints/compute.disableInternetNetworkEndpointGroup può impedire la creazione di questi NEG internet necessari.

Se questa policy dell'organizzazione viene applicata al tuo progetto, alla tua cartella o alla tua organizzazione, impedirà il corretto funzionamento di Cloud Service Mesh con il control plane di Traffic Director. In questo modo, la migrazione o il funzionamento di questa configurazione di Cloud Service Mesh non andranno a buon fine.

Se Enforced è impostato su true, la creazione di NEG internet è disattivata.

Come faccio a sapere se il problema mi riguarda?

Puoi controllare la policy effettiva per il tuo progetto utilizzando la console Google Cloud o Google Cloud CLI. Le istruzioni per visualizzare le policy dell'organizzazione sono disponibili nella sezione Visualizzazione delle policy dell'organizzazione della documentazione ufficiale.

Ad esempio, puoi utilizzare questo comando di Google Cloud CLI:

gcloud resource-manager org-policies describe constraints/compute.disableInternetNetworkEndpointGroup --project YOUR_PROJECT_ID --effective

Se la policy mostra il valore enforced: true, significa che l'impatto è presente.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy:
  enforced: true

Se la policy mostra un valore diverso o è vuota, non sei interessato.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy: {}

Risoluzione del problema

Se la policy viene applicata, dovrai disattivare questo vincolo (impostato su false) a livello di organizzazione, cartella o progetto.

Per istruzioni dettagliate su come modificare le policy dell'organizzazione, inclusi i vincoli booleani come questo, consulta la guida Creazione e gestione delle policy dell'organizzazione. In genere, per apportare queste modifiche è necessario il ruolo roles/orgpolicy.policyAdmin.

Autorizzazioni VPC condiviso

Quando utilizzi Cloud Service Mesh gestito con un VPC condiviso in cui i cluster si trovano in un progetto di servizio e la rete VPC si trova in un progetto host, sono necessarie autorizzazioni aggiuntive per l'agente di servizio Cloud Service Mesh nel progetto del parco risorse.

Nell'ambito della migrazione a un control plane TRAFFIC_DIRECTOR, Cloud Service Mesh richiede le autorizzazioni per gestire le regole firewall nel progetto host per garantire un controllo di integrità e una funzionalità di rete corretti. Questo non era necessario per il control plane ISTIOD precedente.

Come faccio a sapere se il problema mi riguarda?

Il tuo account è interessato se:

1. I cluster GKE si trovano in un progetto di servizio.
2. Questi cluster utilizzano una rete VPC condiviso ospitata in un progetto diverso (il progetto host VPC).
3. L'agente di servizio Cloud Service Mesh del progetto del parco risorse non dispone dell'autorizzazione per gestire le regole firewall nel progetto host VPC.

Potresti visualizzare un messaggio di avviso con il codice SHARED_VPC_MISSING_PERMISSIONS nello stato della funzionalità del parco risorse. Per ulteriori dettagli su come comprendere e risolvere questo problema, incluse le opzioni gestite dal sistema e dall'utente, consulta Informazioni sui controlli di integrità.

Configurazione del control plane mancante

Le best practice di Cloud Service Mesh per la gestione di un mesh di servizi utilizzano l'API Fleet di Google Kubernetes Engine per impostare il campo Management su AUTOMATIC. In questo modo, viene fornita la gestione completamente automatica di molte funzionalità del mesh, come i webhook e il control plane. Inoltre, configura il cluster in modo che riceva automaticamente i nuovi aggiornamenti e le nuove funzionalità non appena vengono rilasciati. Alcuni metodi di installazione legacy non configuravano Cloud Service Mesh in questo modo e devi eseguire alcuni passaggi manuali per applicare le patch.

Come faccio a sapere se il problema mi riguarda?

Controlla se nel tuo cluster è presente un ControlPlaneRevision:

kubectl get controlplanerevisions -n istio-system

Se hai già un ControlPlaneRevision nel tuo cluster, questa guida non è applicabile. Se non hai un ControlPlaneRevision, utilizza questa guida per modernizzare i tuoi cluster.

Nota: esiste un problema noto per cui l'avviso MISSING_CONTROL_PLANE_CONFIG viene segnalato anche se il cluster ha già un ControlPlaneRevision. Questo accade se in precedenza il cluster aveva più di un canale del control plane e hai eliminato ControlPlaneRevision per uno di questi canali. Se il comando precedente restituisce almeno un ControlPlaneRevision, il mesh è configurato correttamente, non è richiesta alcuna azione e puoi ignorare l'avviso.

Se ricevi l'avviso MISSING_CONTROL_PLANE_CONFIG e non vuoi utilizzare Cloud Service Mesh, disabilita Cloud Service Mesh.

Passaggi di modernizzazione

Segui questi passaggi per determinare cosa è necessario fare per allineare la tua configurazione agli standard attuali.

gcloud container fleet mesh describe --project PROJECT_ID

Esegui questi passaggi a seconda dell'output:

Output	Passaggio da eseguire
API [gkehub.googleapis.com] not enabled on project [my-project]. Would you like to enable and retry (this will take a few minutes)? (y/N)?	Rispondi y e riprova.
ERROR: (gcloud.container.fleet.mesh.describe) Service Mesh Feature for project [my-project] is not enabled	Vai al passaggio 1. Attiva la funzionalità mesh.
... resourceState: state: ACTIVE ...	Vai al passaggio 2. Registra il cluster nel parco risorse.

1. Attiva la funzionalità mesh

Per attivare la funzionalità mesh, utilizza il seguente comando. In questo modo, Cloud Service Mesh può essere eseguito nel tuo progetto. Per maggiori dettagli e potenziali effetti collaterali, consulta Esegui il provisioning di Service Mesh.

gcloud container fleet mesh enable --project PROJECT_ID

Dopo aver attivato la funzionalità mesh, vai al passaggio 2. Registra il cluster nel parco risorse.

2. Registra il cluster nel parco risorse

Controlla se il cluster è già registrato nel parco risorse:

gcloud container fleet memberships list --project PROJECT_ID

Se il tuo cluster non è presente nell'elenco, segui queste istruzioni per registrarlo: Registrazione di un cluster nel parco risorse.

La registrazione di un cluster nel tuo parco risorse consentirà a quest'ultimo di gestire funzionalità, come Cloud Service Mesh, tramite il parco risorse.

3. Determina il canale mesh

Cloud Service Mesh dipende dal canale Google Kubernetes Engine del tuo cluster anziché da un canale mesh indipendente. In passato, Cloud Service Mesh supportava la scelta di uno o più canali mesh (diversi dal canale del cluster Google Kubernetes Engine). Potresti avere ancora riferimenti a questi canali nella configurazione del mesh.

Per prima cosa, determina quali canali stai utilizzando. Se utilizzi più canali, segui le istruzioni riportate in Correggi più control plane per ridurre l'utilizzo a un singolo canale.

Per determinare quale canale mesh stai utilizzando, controlla le etichette sui tuoi spazi dei nomi. Tieni presente che potresti dover controllare anche i workload se hai aggiunto etichette di inserimento specificamente ai workload. Il seguente comando controlla tutti i workload nel cluster e filtra l'output per mostrare i control plane e i tag di inserimento utilizzati per questi workload.

kubectl get namespaces,pods,deployments,statefulsets,daemonsets --all-namespaces --show-labels | grep -E "istio.io/rev|istio-injection"

Se hai creato manualmente tag o webhook personalizzati, devi controllare anche questi.

L'output è simile al seguente:

namespace/default                                 Active   153d   istio-injection=enabled,istio.io/rev=asm-managed,kubernetes.io/metadata.name=default
namespace/payments                                Active   42d    istio.io/rev=asm-managed-stable,kubernetes.io/metadata.name=payments
default    pod/frontend-847f569874-v9kjz          2/2      Running  0   2m     app=frontend,istio.io/rev=asm-managed,pod-template-hash=847f569874
payments   pod/checkout-0                         2/2      Running  0   5d     app=checkout,istio.io/rev=asm-managed-stable,controller-revision-hash=5c68b9487
default    deployment.apps/frontend               1/1      1        1   153d   app=frontend,istio.io/rev=asm-managed
payments   statefulset.apps/checkout              1/1      1        1   42d    app=checkout,istio.io/rev=asm-managed-stable

Prendi nota dei valori presenti per istio.io/rev={channel}. I nomi corrispondono ai canali in questo modo. Se sono in uso più canali, segui le istruzioni riportate in Correggi più control plane per ridurli a un singolo canale:

Valore	Canale
asm-managed-stable	Stabile
asm-managed	Normale
asm-managed-rapid	Rapido

Se il canale del mesh corrisponde al canale del cluster Google Kubernetes Engine, vai al passaggio 5.

4. Crea una risorsa ControlPlaneRevision per il tuo canale mesh

Se il canale del mesh corrisponde al canale del cluster Google Kubernetes Engine, puoi saltare questo passaggio. Se attivi la gestione automatica del control plane, questa risorsa ControlPlaneRevision verrà creata automaticamente se il tuo canale corrisponde al canale del cluster.

Crea una risorsa ControlPlaneRevision per il canale mesh che stai utilizzando:

Stabile

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-stable
  namespace: istio-system
spec:
  type: managed_service
  channel: stable
EOF

Normale

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed
  namespace: istio-system
spec:
  type: managed_service
  channel: regular
EOF

Rapido

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-rapid
  namespace: istio-system
spec:
  type: managed_service
  channel: rapid
EOF

5. Attiva la gestione automatica

Attenzione: l'attivazione della gestione automatica del control plane ha effetti collaterali come l'attivazione automatica del rilevamento degli endpoint multi-cluster e del data plane gestito.

Per disattivare il rilevamento degli endpoint multi-cluster, segui le istruzioni "Disattiva" in API dichiarativa di rilevamento degli endpoint prima di abilitare la gestione automatica del control plane.

Per disattivare il piano dati gestito, segui le istruzioni riportate in Disattiva il piano dati gestito.

Per attivare la gestione automatica, esegui il seguente comando. In questo modo, Cloud Service Mesh gestito dal parco risorse potrà gestire la configurazione del control plane del cluster.

gcloud container fleet mesh update --management automatic --memberships MY_CLUSTER_MEMBERSHIP --project PROJECT_ID

Sostituisci MY_CLUSTER_MEMBERSHIP con il nome dell'appartenenza del cluster.

6. Verifica l'installazione

Esegui questo comando:

gcloud container fleet mesh describe --project PROJECT_ID

L'output è simile al seguente:

createTime: '2025-02-24T22:10:10.826263363Z'
etag: XjjRZB3-ZsueoaKihEBUupYhMDUjvoSyUHTVD2YgR6k
membershipSpecs:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    mesh:
      management: MANAGEMENT_AUTOMATIC # See item 1 below
membershipStates:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    servicemesh:
      conditions: [] # See item 2 below
      controlPlaneManagement: # See item 3 below
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement: # See item 4 below
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
      updateTime: '2025-06-17T23:39:05.267540058Z'
name: projects/my-project/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
updateTime: '2025-02-25T04:12:16.280672401Z'

1. All'interno di membershipSpecs, ogni appartenenza all'interno del tuo parco risorse ha una specifica separata. Assicurati che per ogni membro la gestione sia impostata correttamente su MANAGEMENT_AUTOMATIC.
2. A ogni iscrizione è associato un elenco di condizioni di stato. Assicurati che non siano presenti errori o avvisi e segui i link alla documentazione forniti per risolvere eventuali problemi.
3. controlPlaneManagement contiene lo stato del control plane. Assicurati che il control plane sia nello stato ACTIVE.
4. dataPlaneManagement contiene lo stato del piano dati. Ti consigliamo di attivare questa opzione.