Aggiornamenti della configurazione per la modernizzazione

Questo documento descrive gli aggiornamenti della configurazione che potresti dover apportare al tuo Cloud Service Mesh gestito prima di modernizzare il mesh al control plane TRAFFIC_DIRECTOR dal control plane ISTIOD.

Di seguito è riportato un elenco di possibili aggiornamenti della configurazione necessari per preparare il cluster per la modernizzazione. Consulta ogni sezione per le istruzioni di aggiornamento:

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

Migrazione dai secret Istio a multicluster_mode

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

Panoramica dei secret Istio e dell'API dichiarativa

Il rilevamento degli endpoint multi-cluster Istio open source funziona utilizzando istioctl o altri strumenti per creare un secret di 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 ISTIOD legge questo secret e inizia a instradare il traffico verso l'altro cluster.

Cloud Service Mesh dispone di un'API dichiarativa per controllare il traffico multicluster anziché creare direttamente i secret Istio. Questa API considera i secret Istio come un dettaglio di implementazione ed è più affidabile della creazione manuale dei secret Istio. Le future funzionalità di Cloud Service Mesh dipenderanno dall'API dichiarativa e non potrai utilizzare queste nuove funzionalità direttamente con i secret Istio. L'API dichiarativa è l'unico percorso supportato in futuro.

Se utilizzi i secret di Istio, esegui la migrazione all'API dichiarativa il prima possibile. Tieni presente che l'impostazione multicluster_mode indirizza ogni cluster a 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 a 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 Istio, consulta Funzionalità supportate che utilizzano le API Istio.

Esegui la migrazione dai secret Istio all'API dichiarativa

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

Tieni presente che questa procedura modifica i secret che puntano a un cluster. Durante questo processo, gli endpoint vengono rimossi e poi riaggiunti. Tra la rimozione e l'aggiunta degli endpoint, il traffico tornerà brevemente al routing locale anziché al bilanciamento del carico verso altri cluster. Per maggiori informazioni, consulta l'articolo su 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 nel parco risorse in cui vuoi abilitare l'individuazione degli endpoint multicluster impostando multicluster_mode=connected. Tieni presente che devi impostare multicluster_mode=disconnected in modo esplicito se non vuoi che il cluster sia rilevabile.

    Utilizza il seguente comando per attivare la scoperta degli endpoint multicluster per un 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 cluster, per ogni cluster verrà generato un nuovo secret per ogni altro cluster in cui è impostato anche 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 manualmente quelli creati 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. Ciò consente l'accesso a servizi come Compute Engine, BigQuery e API Machine Learning. Google Cloud La federazione delle identità per i workload non richiede la configurazione manuale o metodi meno sicuri come i file delle chiavi degli account di servizio perché utilizza i criteri IAM. Per ulteriori dettagli sulla federazione delle identità per i workload, consulta Come funziona Workload Identity Federation for GKE.

La sezione seguente descrive come attivare 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 il cluster GKE abbia un pool di federazione delle identità per i carichi di lavoro configurato, 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 nei cluster GKE esistenti.

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

Dopo aver abilitato la federazione delle identità per i carichi di lavoro 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 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 Container Network Interface (CNI) gestita

Questa sezione ti guida nell'attivazione di CNI gestito per Cloud Service Mesh su Google Kubernetes Engine.

Panoramica di CNI gestito

Container Network Interface (CNI) gestita è un'implementazione gestita da Google di Istio CNI. Il plug-in CNI semplifica il networking dei pod configurando le regole iptables. Ciò consente il reindirizzamento del traffico tra le applicazioni e i proxy Envoy, eliminando la necessità di autorizzazioni privilegiate per l'init-container necessario 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 di rete, ma con il vantaggio aggiuntivo 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 CNI gestito in tutti i deployment di Managed Cloud Service Mesh.

Impatto sui container di inizializzazione

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 di inizializzazione che si basano sull'accesso alla rete potrebbero riscontrare problemi quando CNI gestito è abilitato nel cluster.

La procedura di configurazione del 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 init container tenta di stabilire connessioni di rete in uscita o di connettersi a servizi all'interno del mesh, le richieste di rete dagli init container potrebbero essere eliminate 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 ulteriori dettagli, consulta la documentazione di Istio CNI.

Abilita CNI gestito per il cluster

Segui i passaggi descritti in questa sezione per attivare CNI gestito sul tuo cluster.

  1. Rimuovi le dipendenze di rete dal contenitore init. Valuta le seguenti alternative:

    • Modifica della logica dell'applicazione o dei container:puoi modificare i tuoi 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 ConfigMap o secret di Kubernetes:archivia i dati di configurazione recuperati dalla richiesta di rete in ConfigMap o secret di Kubernetes e montali nei container dell'applicazione. Per soluzioni alternative, consulta la documentazione di Istio.

  2. Abilita CNI gestito sul 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 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 della 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 ControlPlaneRevision (CPR), imposta l'annotazione mesh.cloud.google.com/force-reprovision su true. Questa azione attiva il riavvio del control plane.

        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 della funzionalità utilizzando il seguente comando:

      gcloud container fleet mesh describe --project FLEET_PROJECT_ID

      Sostituisci FLEET_PROJECT_ID con l'ID del tuo progetto host del parco risorse. In genere, 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 della funzionalità del cluster, riavvia i pod.

Abbandonare l'utilizzo di binari non standard in Sidecar

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

Immagini sidecar del proxy Envoy senza distribuzione

Cloud Service Mesh utilizza due tipi di immagini sidecar del proxy Envoy in base alla configurazione del control plane, all'immagine basata su Ubuntu contenente vari file binari e all'immagine Distroless. Le immagini di base Distroless sono immagini container minimali che danno la 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 ai soli pacchetti necessari. Questo approccio migliora la sicurezza e il rapporto segnale/rumore degli scanner di vulnerabilità ed esposizioni comuni (CVE). L'immagine di Sidecar senza distribuzione ha un insieme minimo di dipendenze, privato 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.

Rendere i cluster compatibili con le immagini distroless

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

Esegui la migrazione a Istio Ingress Gateway

Questa sezione mostra come eseguire la migrazione a Istio Ingress Gateway. Esistono due metodi per eseguire la migrazione a Istio Ingress Gateway:

  1. Migrazione graduale con suddivisione del traffico

    Questo metodo dà la priorità alla riduzione al minimo delle interruzioni, in quanto invierai gradualmente il traffico al nuovo gateway Istio, consentendoti di monitorarne le prestazioni su una piccola percentuale di richieste e di ripristinare rapidamente la versione precedente, se necessario. Tieni presente che la configurazione della suddivisione del traffico di livello 7 può essere difficile per alcune applicazioni, quindi devi gestire contemporaneamente entrambi i sistemi gateway durante la transizione. Per i passaggi, vedi Migrazione in più fasi con suddivisione del traffico.

  2. Migrazione diretta

    Questo metodo prevede il reindirizzamento simultaneo di tutto il traffico al nuovo gateway Istio una volta completati i test. Il vantaggio di questo approccio è la completa separazione dall'infrastruttura del vecchio gateway, che consente una configurazione adattabile del nuovo gateway senza i vincoli della configurazione esistente. Tuttavia, in caso di problemi imprevisti con il nuovo gateway durante la transizione, il rischio di tempi di inattività è maggiore. Per i passaggi, vedi 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 all'interno dello spazio dei nomi default.
  • L'applicazione httpbin è accessibile utilizzando l'IP esterno 34.57.246.68.

Diagramma di base del gateway

Migrazione graduale con suddivisione del traffico

Esegui il provisioning di un nuovo gateway in entrata Istio

  1. Esegui il deployment di un nuovo gateway Ingress 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 pensati per il deployment di un servizio LoadBalancer istio-ingressgateway e dei pod ingress-gateway corrispondenti.

    Risorsa gateway di esempio (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 del 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 l'etichetta istio=ingressgateway.

Configura il routing iniziale per il nuovo gateway

  1. Definisci le regole di routing iniziali per la tua applicazione utilizzando un VirtualService 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 Ingress di Istio appena implementato

  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

Flusso di richieste con il nuovo gateway in entrata Istio

Modificare l'ingresso esistente per la suddivisione del traffico

Dopo aver confermato la configurazione corretta del nuovo gateway (ad es. istio-api-gateway), puoi iniziare a instradare una parte del traffico attraverso di esso. Per farlo, aggiorna l'attuale HTTPRoute per 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 punta al servizio di bilanciamento del carico del nuovo Ingress Gateway con un peso iniziale del 10% e aggiorna il peso del backend del vecchio gateway.

    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 il riferimento tra spazi dei nomi con la concessione del riferimento.

    Per consentire al tuo 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 in modo esplicito quali riferimenti tra spazi dei nomi sono consentiti.

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

    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 del 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 vanno in errore. Il seguente check-traffic-flow.sh descrive uno script per controllare gli errori di richiesta:

    # 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

Flusso di richieste con suddivisione del traffico tra il gateway esistente e il nuovo gateway di ingresso Istio

Aumenta lentamente la percentuale di traffico

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

Utilizza il seguente comando per aggiornare il tuo HTTPRoute esistente:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migrazione completa del traffico e rimozione del vecchio gateway

  1. Quando il nuovo Istio Ingress Gateway dimostra prestazioni stabili e gestione delle richieste riuscita, sposta tutto il traffico su di esso. Aggiorna il tuo HTTPRoute per impostare il peso del backend del vecchio gateway su 0 e quello del nuovo gateway su 100.

  2. Una volta che il traffico è completamente instradato al 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 di bilanciamento del carico creato in Provisioning di un nuovo gateway in entrata Istio.

  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 gateway in entrata Istio

  1. Esegui il deployment di un nuovo gateway Ingress 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 pensati per il deployment di un servizio LoadBalancer istio-ingressgateway e dei pod ingress-gateway corrispondenti.

    Risorsa gateway di esempio (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 del 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 l'etichetta istio=ingressgateway.

Configura il routing iniziale per il nuovo gateway

  1. Definisci le regole di routing iniziali per la tua applicazione utilizzando un VirtualService 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 Ingress di Istio appena implementato

  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

Flusso di richieste con il nuovo gateway in entrata Istio

Testare e monitorare il nuovo gateway

  1. Testa tutte le regole di routing, 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 della tua applicazione (ad esempio httpbin.example.com) in modo che puntino all'indirizzo IP esterno del servizio di bilanciamento del carico creato in Provisioning di un nuovo gateway in entrata Istio.

  3. Monitora le metriche chiave, come il tasso di successo delle richieste, la latenza, i tassi di errore e l'utilizzo delle risorse dei pod della tua applicazione per verificare la stabilità con il nuovo Istio Ingress Gateway. Una volta stabilita la stabilità, puoi eliminare il vecchio gateway e le relative risorse.

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

Considerazioni importanti: assicurati che i certificati e le configurazioni TLS siano configurati correttamente sul nuovo gateway in entrata Istio se la tua applicazione richiede HTTPS. Per ulteriori dettagli, consulta Configurare 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 corrisponda 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 sulle nuove versioni di mesh nel canale rapido prima che diventino disponibili nel canale stabile o regolare, devi utilizzare due cluster diversi, ognuno 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 del tuo abbonamento. Se questo avviso non viene visualizzato, non sei interessato e puoi saltare la lettura di questa sezione.

  1. Esegui questo comando per verificare se il cluster ha più canali del piano di controllo:

    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/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 è visualizzata 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, sono stati sottoposti a provisioning tutti e tre i canali:

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

    Se viene visualizzato un solo risultato, nel tuo cluster viene eseguito il provisioning di un solo canale 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.

Consolidare i carichi di lavoro 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 normale.

    Se tutti i tuoi workload utilizzano già lo stesso canale, puoi passare 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:

    • In alcuni casi, i pod possono 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 conservare, prova a scegliere quello uguale al canale del cluster GKE. Se questo canale non esiste, seleziona uno dei canali attivi.
    • Il canale che selezioni non ha importanza. Il canale del cluster GKE determina la versione di mesh che ottieni, non il canale mesh.
    • Controlla la configurazione di meshconfig tra i canali attivi in uso per assicurarti che non ci siano differenze. Ogni canale utilizza una configmap separata per la configurazione, quindi il consolidamento di due canali in uno solo 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 spazio dei nomi.

    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 per uno spazio dei nomi / 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 tuoi workload vengono eseguiti su un unico canale, puoi rimuovere i canali aggiuntivi inutilizzati. Se sono stati sottoposti a provisioning 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

Abilitare la gestione automatica

  1. Esegui questo comando per abilitare 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.
    • MEMBERSHIP_LOCATION è la posizione del tuo abbonamento (una regione o global). Puoi controllare la posizione del tuo abbonamento con gcloud container fleet memberships list --project PROJECT_ID.

  2. Verifica che la gestione automatica sia attivata:

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

Modernizzare 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 Modernizzare le configurazioni del compressore EnvoyFilter.

Abilitazione di una policy dell'organizzazione obbligatoria

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

Norme 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 verso servizi al di fuori di Google Cloud.

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

Se questo criterio dell'organizzazione viene applicato al tuo progetto, alla tua cartella o alla tua organizzazione, Cloud Service Mesh non funzionerà correttamente con il control plane di Traffic Director. In questo modo, la migrazione o il funzionamento corretto di questa configurazione di Cloud Service Mesh non sarà possibile.

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 Google Cloud CLI:

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

Se il criterio mostra il valore enforced: true, sei interessato.

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

Se il criterio mostra un valore diverso o è vuoto, non sei interessato.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy: {}

Risoluzione del problema

Se il criterio è applicato, dovrai disattivare questo vincolo (impostato su false) a livello di organizzazione, cartella o progetto.

Istruzioni dettagliate su come modificare le policy dell'organizzazione, inclusi i vincoli booleani come questo, sono disponibili nella guida Creazione e gestione delle policy dell'organizzazione. In genere, per apportare queste modifiche devi disporre del 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 il service agent Cloud Service Mesh nel progetto fleet.

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 il corretto controllo dell'integrità e la funzionalità di rete. Questo non era richiesto per il control plane ISTIOD precedente.

Come faccio a sapere se il problema mi riguarda?

Sei interessato se:

  1. I tuoi 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. Il service agent Cloud Service Mesh del progetto Fleet non ha l'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 Comprendere i 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 Google Kubernetes Engine Fleet per impostare il campo Management su AUTOMATIC. Ciò fornisce la gestione completamente automatica di molte funzionalità del mesh, come i webhook e il piano di controllo. Inoltre, configura il cluster in modo che riceva automaticamente nuovi aggiornamenti e funzionalità man mano che vengono rilasciati. Alcuni metodi di installazione precedenti 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 cluster è presente un ControlPlaneRevision:

kubectl get controlplanerevisions -n istio-system

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

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

Procedura di modernizzazione

Segui questi passaggi per determinare cosa devi 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 a 1. Attiva la funzionalità mesh.
... resourceState: state: ACTIVE ... Vai al passaggio 2. Registra il cluster nel parco risorse.

1. Attivare la funzionalità Mesh

L'attivazione della funzionalità mesh può essere eseguita utilizzando il seguente comando. In questo modo, Cloud Service Mesh può essere eseguito nel tuo progetto. Per maggiori dettagli e potenziali effetti collaterali, consulta 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 cluster non è elencato, 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.

3. Determinare il canale mesh

Cloud Service Mesh dipende dal canale Google Kubernetes Engine del 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 ancora avere riferimenti a questi canali nella configurazione della mesh.

Per prima cosa, determina quali canali stai utilizzando. Se utilizzi più canali, segui le istruzioni riportate in Correggere più piani di controllo 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 iniezione specificamente sui workload. Il seguente comando controlla tutti i carichi di lavoro nel cluster e filtra l'output per mostrare i piani di controllo e i tag di inserimento utilizzati per questi carichi di lavoro.

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 Correggere più piani di controllo per ridurre a un singolo canale:

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

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

4. Crea una risorsa ControlPlaneRevision per il canale mesh

Se il canale mesh corrisponde al canale del cluster Google Kubernetes Engine, puoi saltare questo passaggio. Se abiliti la gestione automatica del control plane, questa risorsa ControlPlaneRevision verrà creata automaticamente se il canale corrisponde a quello 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

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

Per disattivare il data plane gestito, segui le istruzioni riportate in Disattivare il data plane gestito.

Per abilitare la gestione automatica, esegui questo 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 abbonamento del tuo parco risorse ha una specifica separata. Assicurati che per ogni membro la gestione sia impostata correttamente su MANAGEMENT_AUTOMATIC.
  2. A ogni abbonamento è 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 data plane. Ti consigliamo di attivare questa opzione.