Esegui la migrazione di Istio ServiceEntry a GCPBackend per le VM Compute Engine
Questa pagina mostra come eseguire la migrazione da ServiceEntry a GCPBackend, dimostrando come le funzionalità di gestione del traffico di Istio possono garantire una transizione scorrevole e sicura.
La migrazione a GCPBackend offre i seguenti vantaggi:
- Rilevamento endpoint: gli endpoint VM nel servizio di backend vengono aggiornati automaticamente quando le istanze VM vengono aggiunte o rimosse.
- Controllo di integrità centralizzato: gli endpoint VM vengono sottoposti a controllo di integrità e il traffico viene reindirizzato automaticamente dai backend non integri a quelli integri.
- Bilanciamento del carico globale e algoritmi di bilanciamento del carico avanzati: gli endpoint VM possono essere implementati in più regioni. Utilizza i nostri algoritmi di bilanciamento del carico per configurare il comportamento del bilanciamento del carico in queste regioni. Per ulteriori informazioni, consulta https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview e https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview.
- Migrazione senza interruzioni: utilizza la suddivisione e il mirroring del traffico per eseguire la migrazione del traffico in modo sicuro senza interrompere l'applicazione.
- Maggiore gestibilità: sfrutta la configurazione e la gestione semplificate.
Prima di iniziare
Le seguenti sezioni presuppongono che tu disponga di quanto segue:
- Un cluster GKE con Cloud Service Mesh abilitato.
- Un elemento Istio Service Entry.
- Risorsa GCPBackend configurata per la VM Compute Engine.
Crea o modifica il VirtualService esistente in modo da includere sia ServiceEntry che GCPBackend come destinazioni
Puoi utilizzare la suddivisione del traffico per spostare gradualmente il traffico da ServiceEntry a GCPBackend. Dovresti iniziare con una piccola percentuale di traffico indirizzato a GCPBackend e aumentarla gradualmente durante il monitoraggio di eventuali problemi.
L'esempio seguente descrive la migrazione del 10% delle richieste a GCPBackend.
cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: gcpbackend-migration
namespace: NAMESPACE
spec:
hosts:
- service-entry.com
http:
- route:
- destination:
host: gcpbackend.com
weight: 10 # 10% traffic to gcp backend.
- destination:
host: service-entry.com
weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml
Dove:
- NAMESPACE è il nome dello spazio dei nomi.
In questo esempio:
- VIRTUAL_SERVICE è pari a
gcpbackend-migration. - SERVICE_ENTRY_HOSTNAME è pari a
service-entry.com. - GCP_BACKEND_HOSTNAME è pari a
gcpbackend.com.
(Facoltativo) Configura VirtualService per il mirroring del traffico
Per garantire ulteriormente una transizione senza problemi, puoi configurare il mirroring del traffico per inviare una copia del traffico a GCPBackend, continuando a indirizzare principalmente il traffico a ServiceEntry. In questo modo, è possibile testare e convalidare la configurazione di GCPBackend senza influire sul flusso di traffico principale. Per ulteriori informazioni, consulta l'API Istio Virtual Service.
Convalida la funzionalità
Consulta i log dell'applicazione o le metriche di Cloud Service Mesh per controllare il tasso di errore delle richieste a $SERVICE_ENTRY_HOSTNAME. Non devono essere presenti errori.
Per eseguire test esterni all'applicazione, puoi implementare un client curl. Se la richiesta viene inoltrata utilizzando l'API GCPBackend, non è necessario un token IAM esplicitamente associato alla richiesta perché Cloud Service Mesh lo associa automaticamente.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: testcurl
namespace: default
spec:
containers:
- name: curl
image: curlimages/curl
command: ["sleep", "3000"]
EOF
kubectl exec testcurl -c curl -- curl "$SERVICE_ENTRY_HOSTNAME"
L'output dovrebbe essere una risposta HTTP 200 valida.