Esegui la migrazione di Istio ServiceEntry a GCPBackend per Cloud Run

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:

  1. Codice dell'applicazione semplificato: puoi eliminare la necessità di eseguire l'iniezione manuale di JWT IAM nell'applicazione, riducendo la complessità e i potenziali errori.
  2. Sicurezza migliorata: sfrutta l'iniezione automatica di JWT IAM per una comunicazione più sicura tra GKE e Cloud Run.
  3. Migrazione senza interruzioni: utilizza la suddivisione e il mirroring del traffico per eseguire la migrazione del traffico in modo sicuro senza interrompere l'applicazione.
  4. Maggiore gestibilità: sfrutta la configurazione e la gestione semplificate.

Prima di iniziare

Le seguenti sezioni presuppongono che tu disponga di quanto segue:

  1. Un cluster GKE con Cloud Service Mesh abilitato.
  2. Un servizio Cloud Run come voce di servizio Istio.
  3. Risorsa GCPBackend configurata.

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: cr-gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - cr-service-entry.com
  http:
  - route:
    - destination:
        host: cr-gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: cr-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_SERVICEE è pari a cr-gcpbackend-migration.
  • SERVICE_ENTRY_HOSTNAME è pari a cr-service-entry.com.
  • GCP_BACKEND_HOSTNAME è pari a =cr-gcpbackend.com.

(Facoltativo) Configura VirtualService per il mirroring del traffico

Per garantire ulteriormente una transizione senza problemi, puoi configurare il mirroring del traffico in modo da 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 instradata a Cloud Run 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.