Cloud Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiornamenti della configurazione per la modernizzazione

Questo documento descrive gli aggiornamenti di configurazione che potresti dover apportare a Cloud Service Mesh gestito prima di eseguire la modernizzazione del tuo mesh al piano di controllo TRAFFIC_DIRECTOR dal piano di controllo ISTIOD.

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

Multi-cluster
Abilita Workload Identity Federation per GKE
Attiva CNI gestita
Utilizzo di file binari non standard in Sidecar
Eseguire la migrazione a Istio Ingress Gateway

Per ulteriori informazioni sul flusso di lavoro di modernizzazione, consulta la pagina Modernizzazione del piano di controllo gestito.

Esegui la migrazione dai secret Istio a multicluster_mode

I secret multi-cluster non sono supportati quando un cluster utilizza il control planeTRAFFIC_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 Istio rispetto alle API dichiarative

Il rilevamento degli endpoint di Istio multi-cluster 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 su un altro cluster nel mesh. Il piano di controllo ISTIOD legge quindi questo segreto e inizia a instradare il traffico verso l'altro cluster.

Cloud Service Mesh dispone di un'API dichiarativa per controllare il traffico multi-cluster 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 utilizzarle direttamente con i secret Istio. L'API dichiarativa è l'unico percorso supportato per il futuro.

Se utilizzi Istio Secrets, esegui la migrazione all'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 del mesh. L'utilizzo dei secret consente una configurazione più flessibile, in quanto ti consente 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 i secret Istio, consulta Funzionalità supportate mediante le API Istio.

Esegui la migrazione dagli API secret di Istio all'API dichiarativa

Se hai eseguito il provisioning di Cloud Service Mesh utilizzando la gestione automatica con l'API di funzionalità di flotta, 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 rimandano a un cluster. Durante questa procedura, gli endpoint vengono rimossi e poi aggiunti di nuovo. Tra gli endpoint che vengono rimossi e aggiunti, il traffico riprenderà brevemente il routing locale anziché il bilanciamento del carico verso altri cluster. Per ulteriori informazioni, 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:

Attiva l'API dichiarativa per ogni cluster nel parco risorse in cui vuoi attivare il rilevamento di 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 la scoperta degli endpoint su più cluster in 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"}}'
```
Elimina i vecchi secret.

Dopo aver impostato multicluster_mode=connected sui cluster, per ogni cluster verrà generato un nuovo segreto 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 segreto verrà applicata anche l'etichetta istio.io/owned-by: mesh.googleapis.com.

Una volta creati i nuovi secret, puoi eliminare 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 inoltrate come previsto.

Abilita Workload Identity Federation per GKE

La federazione Workload Identity è il metodo sicuro consigliato per i carichi di lavoro di Google Kubernetes Engine. In questo modo puoi accedere a Google Cloud servizi come Compute Engine, BigQuery e API di machine learning. La federazione delle identità per i carichi di lavoro non richiede configurazione manuale o metodi meno sicuri come i file di chiavi degli account di servizio perché utilizza i criteri IAM. Per ulteriori dettagli su Workload Identity Federation, consulta Come funziona Workload Identity Federation per GKE.

La sezione seguente descrive come attivare la federazione di Workload Identity.

Abilita la federazione delle identità per i workload sui cluster

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

Utilizza il seguente comando per controllare il pool di identità di carico di lavoro 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 già specificato una zona o una regione predefinita per gcloud, potrebbe essere necessario specificare anche un flag --region o --zone quando esegui questo comando.
Se l'output è vuoto, segui le istruzioni riportate in Aggiornare un cluster esistente per abilitare Workload Identity nei cluster GKE esistenti.

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

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

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 già specificato una zona o una regione predefinita per gcloud, potrebbe essere necessario specificare anche un flag --region o --zone quando esegui questo comando.
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.
Se l'output non contiene GKE_METADATA, aggiorna il pool di nodi utilizzando la guida Aggiornare un pool di nodi esistente.

Abilita l'interfaccia di rete del contenitore (CNI) gestita

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

Panoramica di CNI gestito

L'interfaccia di rete del contenitore gestita (CNI) è un'implementazione gestita da Google di la CNI di Istio. Il plug-in CNI semplifica il networking dei pod configurando le regole iptables. In questo modo, viene abilitato il reindirizzamento del traffico tra le applicazioni e i proxy Envoy, eliminando la necessità di autorizzazioni privilegiate per il contenitore init necessarie per gestire iptables.

Il plug-in CNI Istio sostituisce il contenitore istio-init. In precedenza, il contenitore istio-init era 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 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, è necessaria la CNI gestita in tutti i deployment di Cloud Service Mesh gestito.

Impatto sui container di inizializzazione

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

La procedura di configurazione del pod con CNI gestito è la seguente:

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.
Tutti i container di inizializzazione vengono eseguiti e completati.
Il proxy sidecar di Istio si avvia insieme ai container dell'applicazione.

Pertanto, se un contenitore init tenta di effettuare connessioni di rete in uscita o di connettersi a servizi all'interno del mesh, le richieste di rete provenienti dai contenitori init potrebbero essere ignorate o reindirizzate in modo errato. Questo accade 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 nel tuo cluster.

Rimuovi le dipendenze di rete dal contenitore di inizializzazione. Valuta le seguenti alternative:
- Modifica la logica o i contenitori dell'applicazione:puoi modificare i servizi per rimuovere la dipendenza dai contenitori di inizializzazione che richiedono richieste di rete o eseguire operazioni di rete all'interno dei contenitori dell'applicazione dopo l'avvio del proxy sidecar.
- Utilizza i ConfigMap o i secret di Kubernetes: archivia i dati di configurazione recuperati dalla richiesta di rete nei ConfigMap o nei secret di Kubernetes e montali nei container dell'applicazione. Per soluzioni alternative, consulta la documentazione di Istio.
Abilita CNI gestito nel cluster:
1. Apporta le seguenti modifiche alla configurazione:
  1. Esegui il seguente comando per individuare il file controlPlaneRevision.
```
kubectl get controlplanerevision -n istio-system
```
  2. Nella risorsa personalizzata (RP) 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 NOME dell'output del passaggio precedente.
  3. Nel 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 (RP) ControlPlaneRevision (CPR), imposta l'etichetta mesh.cloud.google.com/force-reprovision su true. Questa azione attiva il riavvio del piano di controllo.
    
    Nota: questo metodo non è consigliato per riavviare il piano di controllo e deve essere utilizzato solo per le attività di modernizzazione di Cloud Service Mesh.
```
kubectl label 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 Fleet Host. In genere, FLEET_PROJECT_ID ha lo stesso nome del progetto.
  - Verifica che la condizione MANAGED_CNI_NOT_ENABLED sia rimossa da servicemesh.conditions.
  - Tieni presente che l'aggiornamento dello stato può richiedere fino a 15-20 minuti. Prova a 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 tuoi deployment compatibili con l'immagine del proxy di Envoy senza dipendenza dal gestore pacchetti.

Immagini sidecar del proxy Envoy senza distribuzione

Cloud Service Mesh utilizza due tipi di immagini sidecar del proxy Envoy in base alla configurazione del piano di controllo: un'immagine basata su Ubuntu contenente vari binari e un'immagine Distroless. Le immagini di base Distroless sono immagini container minime che danno la priorità alla sicurezza e all'ottimizzazione delle risorse includendo solo i componenti essenziali. La superficie di attacco viene 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 contenitore 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 senza distribuzione ha un insieme minimo di dipendenze, sprovvisto 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 contenitore.

Rendere i cluster compatibili con le immagini distroless

Rimuovi dalla configurazione i riferimenti a eventuali file binari non supportati (come bash o curl). In particolare, all'interno di probe di idoneità, avvio e attività e di 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 effimeri per collegarti a un pod di carico di lavoro in esecuzione. Puoi quindi ispezionarlo ed eseguire comandi personalizzati. Per un esempio, vedi Raccogliere i log di Cloud Service Mesh.

Se non riesci a trovare una soluzione per il tuo caso d'uso specifico, contatta Google Cloud l'assistenza alla pagina Ricevere assistenza.

Esegui la migrazione al gateway di ingresso Istio

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

Migrazione graduale con suddivisione del traffico

Questo metodo dà la priorità alla minimizzazione delle interruzioni in cui invii gradualmente il traffico al nuovo gateway Istio, consentendoti di monitorarne le prestazioni su una piccola percentuale di richieste e di ripristinare rapidamente la situazione, se necessario. Tieni presente che la configurazione della suddivisione del traffico di livello 7 può essere complessa per alcune applicazioni, quindi devi gestire contemporaneamente entrambi i sistemi gateway durante la transizione. Per conoscere la procedura, consulta Migrazione graduale con suddivisione del traffico.
Migrazione diretta

Questo metodo prevede il reindirizzamento simultaneo di tutto il traffico al nuovo gateway Istio dopo aver eseguito test approfonditi. Il vantaggio di questo approccio è la separazione completa dall'infrastruttura del vecchio gateway, che consente di configurare il nuovo gateway in modo adattabile senza i vincoli della configurazione esistente. Tuttavia, esiste un rischio maggiore di tempi di riposo nel caso in cui si verifichino problemi imprevisti con il nuovo gateway durante la transizione. Per conoscere la procedura, consulta Migrazione diretta.

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

Gateway: k8-api-gateway (nel namespace istio-ingress), configurato per monitorare il traffico HTTP sulla porta 80 per qualsiasi nome host che termina con .example.com.
HTTPRoute: httpbin-route (nel namespace default) indirizza qualsiasi richiesta HTTP con il nome host httpbin.example.com e un percorso che inizia con /get al servizio httpbin all'interno del namespace 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 di ingresso Istio

Esegui il deployment di un nuovo Ingress Gateway seguendo i passaggi descritti nella sezione Esegui il deployment di un gateway di esempio e personalizza le configurazioni di esempio in base ai tuoi requisiti. I sample nel repository anthos-service-mesh sono destinati al 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"

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, la configurazione del gateway deve selezionare anche questa etichetta istio=ingressgateway.

Configura il routing iniziale per il nuovo gateway

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

Applica VirtualService:

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

Accedi al servizio di backend (httpbin) tramite il gateway Istio Ingress appena disegnato

Imposta la variabile di ambiente Ingress Host sull'indirizzo IP esterno associato al bilanciatore del carico istio-ingressgateway di cui è stato eseguito di recente il deployment:
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
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 di ingresso Istio

Modificare l'elemento Ingress esistente per la suddivisione del traffico

Dopo aver verificato la corretta configurazione del nuovo gateway (ad es. istio-api-gateway), puoi iniziare a instradare una parte del traffico. Per farlo, aggiorna HTTPRoute attuale per indirizzare una piccola percentuale di traffico al nuovo gateway, mentre la parte più grande continuerà a utilizzare il gateway esistente (k8-api-gateway).

Apri httproute per la modifica:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Aggiungi un nuovo riferimento di backend che rimandi al servizio di bilanciamento del carico del nuovo Ingress Gateway con un peso iniziale del 10% e aggiorna il peso per il 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

Concedi l'autorizzazione per i riferimenti tra spazi dei nomi con la concessione di riferimento.

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

Applica la sovvenzione di riferimento:

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

Verifica le richieste all'indirizzo IP esterno esistente (ad es. 34.57.246.68) non sono in stato di errore. Il seguente check-traffic-flow.sh descrive uno script per controllare i fallimenti 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

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 rilevati errori di richiesta per l'indirizzo IP esterno esistente (ad esempio 34.57.246.68), sposta gradualmente più traffico verso il nuovo Istio Ingress Gateway modificando i pesi del backend in HTTPRoute. Aumenta il valore del parametro per istio-ingressgateway e diminuisci il valore del parametro per il vecchio gateway in piccoli incrementi, ad esempio del 10%, del 20% e così via.

Utilizza il seguente comando per aggiornare HTTPRoute esistente:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migrazione completa del traffico e rimozione del vecchio gateway

Quando il nuovo Istio Ingress Gateway dimostra prestazioni stabili e gestione delle richieste riuscita, sposta tutto il traffico su di esso. Aggiorna HTTPRoute per impostare il peso del backend del vecchio gateway su 0 e quello del nuovo gateway su 100.
Una volta che il traffico è stato instradato completamente al nuovo gateway, aggiorna i record DNS esterni per il nome host della tua applicazione (ad esempio httpbin.example.com) in modo che rimandino all'indirizzo IP esterno del servizio di bilanciamento del carico creato in Provisioning di un nuovo gateway Istio Ingress.

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