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 della configurazione che potresti dover apportare al tuo mesh di servizi Cloud gestito prima di modernizzare il mesh al piano di controllo TRAFFIC_DIRECTOR dal piano di controllo ISTIOD.

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

Multi-cluster
Abilita Workload Identity Federation for GKE
Abilita CNI gestito
Utilizzo di 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 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

L'individuazione 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 di 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.

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 nella mesh. Per un elenco completo delle differenze tra le funzionalità supportate dell'API dichiarativa e i 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 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 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:

Attiva l'API dichiarativa per ogni cluster nel parco risorse in cui vuoi attivare 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"}}'
```
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

Workload Identity Federation è il metodo sicuro consigliato per i carichi di lavoro 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 del account di servizio perché utilizza i criteri IAM. Per ulteriori dettagli sulla federazione delle identità per i carichi di lavoro, consulta Come funziona la federazione delle identità per i carichi di lavoro 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à per i carichi di lavoro sia abilitata per il tuo cluster. A questo scopo, 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 anche dover specificare un flag --region o --zone quando esegui questo comando.
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.

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 anche dover specificare 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 container (CNI) gestita

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

Panoramica di CNI gestito

L'interfaccia di rete dei container (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 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 CNI gestito in tutti i deployment di Managed Cloud Service Mesh.

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

Rimuovi le dipendenze di rete dal contenitore init. Prendi in considerazione 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.
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 (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 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 (RP) ControlPlaneRevision (CPR), imposta l'etichetta mesh.cloud.google.com/force-reprovision su true. Questa azione attiva il riavvio del control plane.
    
    Nota: questo metodo non è consigliato per il riavvio del piano di controllo e deve essere utilizzato solo per gli sforzi 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 host del parco veicoli. 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 può 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 delle funzionalità del cluster, riavvia i pod.

Allontanarsi dall'utilizzo di 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 senza distribuzione

Cloud Service Mesh utilizza due tipi di immagini sidecar del proxy Envoy in base alla configurazione del piano di controllo, all'immagine basata su Ubuntu contenente vari file binari e all'immagine Distroless. Le immagini di base distroless sono immagini container minimali che danno 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 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 sidecar Distroless 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

Rimuovi i riferimenti a eventuali binari non supportati (come bash o curl) dalla tua 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 effimeri per collegarti a un pod di carico di lavoro in esecuzione. Puoi quindi ispezionarlo ed eseguire comandi personalizzati. Per un esempio, vedi Raccolta dei log di Cloud Service Mesh.

Se non riesci a trovare una soluzione per il tuo caso d'uso specifico, contatta l' Google Cloud 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:

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 situazione precedente, 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, vedi Migrazione in più fasi con suddivisione del traffico.
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 la 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 Istio Ingress Gateway

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 ai tuoi requisiti. Gli esempi nel repository anthos-service-mesh sono pensati per il deployment di un servizio istio-ingressgateway LoadBalancer 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, anche la configurazione del gateway deve selezionare l'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 il VirtualService:

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

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

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}')
```
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 corretta configurazione 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).

Apri httproute per la modifica:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Aggiungi un nuovo riferimento backend che rimandi 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

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

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

Quando il nuovo Istio Ingress Gateway dimostra prestazioni stabili e una 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.
Una volta che il traffico è 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 di bilanciamento del carico creato in Provisioning di un nuovo gateway Ingress Istio.

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