Migra Istio ServiceEntry a GCPBackend per le VM di Compute Engine

Questa pagina mostra come eseguire la migrazione da ServiceEntry a GCPBackend, dimostrando come le funzionalità di gestione del traffico di Istio possano garantire una transizione fluida e sicura.

La migrazione a GCPBackend offre i seguenti vantaggi:

Rilevamento endpoint: gli endpoint VM nel servizio di backend vengono aggiornati automaticamente quando vengono aggiunte o rimosse istanze VM.
Controllo di integrità centralizzato: gli endpoint VM vengono controllati e il traffico viene automaticamente indirizzato 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 saperne di più, visita le pagine https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview e https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview.
Migrazione senza interruzioni: utilizza la suddivisione e il mirroring del traffico per eseguire la migrazione in sicurezza del traffico senza interrompere l'applicazione.
Gestibilità avanzata: usufruisci della configurazione e della gestione semplificate.

Prima di iniziare

Le seguenti sezioni presuppongono che tu disponga di quanto segue:

Un cluster GKE con Cloud Service Mesh abilitato.
Una voce di servizio Istio.
Risorsa GCPBackend configurata per la VM di Compute Engine.

Crea o modifica il VirtualService esistente in modo che includa sia ServiceEntry che GCPBackend come destinazioni

Puoi utilizzare la suddivisione del traffico per spostare gradualmente il traffico da ServiceEntry a GCPBackend. Devi iniziare con una piccola percentuale di traffico indirizzato a GCPBackend e aumentarla gradualmente monitorando 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, indirizzando comunque principalmente il traffico a ServiceEntry. Ciò consente di testare e convalidare la configurazione di GCPBackend senza influire sul flusso di traffico principale. Per ulteriori informazioni, consulta l'API Istio Virtual Service.

Convalidare la funzionalità

Fai riferimento ai log dell'applicazione o alle metriche di Cloud Service Mesh per verificare il tasso di errori delle richieste a $SERVICE_ENTRY_HOSTNAME. Non dovrebbero essere presenti errori.

Per eseguire test al di fuori dell'applicazione, puoi eseguire il deployment di un client curl. Se la richiesta viene indirizzata all'utilizzo dell'API GCPBackend, non è necessario allegare esplicitamente un token IAM alla richiesta perché Cloud Service Mesh lo allega 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 deve essere una risposta HTTP 200 valida.