Migrer Istio ServiceEntry vers GCPBackend pour Cloud Run

Cette page explique comment migrer de ServiceEntry vers GCPBackend. Elle montre comment les fonctionnalités de gestion du trafic d'Istio peuvent assurer une transition fluide et sûre.

La migration vers GCPBackend offre les avantages suivants :

  1. Code d'application simplifié : vous pouvez éliminer le besoin d'injection manuelle de jetons JWT IAM dans l'application, ce qui réduit la complexité et les erreurs potentielles.
  2. Sécurité améliorée : profitez de l'injection automatique de jetons JWT IAM pour une communication plus sécurisée entre GKE et Cloud Run.
  3. Migration fluide : utilisez la répartition et la mise en miroir du trafic pour migrer le trafic en toute sécurité sans perturber l'application.
  4. Gestion améliorée : bénéficiez d'une configuration et d'une gestion simplifiées.

Avant de commencer

Les sections suivantes supposent que vous avez :

  1. Un cluster GKE avec Cloud Service Mesh activé.
  2. Entrée de service Istio.
  3. Ressource GCPBackend configurée pour le service Cloud Run.

Créez ou modifiez le VirtualService existant pour inclure à la fois ServiceEntry et GCPBackend en tant que destinations.

Vous pouvez utiliser la répartition du trafic pour transférer progressivement le trafic de ServiceEntry vers GCPBackend. Vous devez commencer par diriger un petit pourcentage de trafic vers le GCPBackend, puis l'augmenter progressivement tout en surveillant les éventuels problèmes.

L'exemple suivant décrit la migration de 10 % des requêtes vers le 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

Où :

  • NAMESPACE est le nom de l'espace de noms.

Dans cet exemple :

  • VIRTUAL_SERVICE est gcpbackend-migration.
  • SERVICE_ENTRY_HOSTNAME est service-entry.com.
  • GCP_BACKEND_HOSTNAME est gcpbackend.com.

(Facultatif) Configurer VirtualService pour la mise en miroir du trafic

Pour assurer une transition fluide, vous pouvez configurer la mise en miroir du trafic afin d'envoyer une copie du trafic à GCPBackend tout en continuant à diriger principalement le trafic vers ServiceEntry. Cela permet de tester et de valider la configuration GCPBackend sans affecter le flux de trafic principal. Pour en savoir plus, consultez l'API Istio Virtual Service.

Valider la fonctionnalité

Consultez les journaux de votre application ou les métriques Cloud Service Mesh pour vérifier le taux d'erreur des requêtes adressées à $SERVICE_ENTRY_HOSTNAME. Il ne devrait y avoir aucune erreur.

Pour effectuer des tests en dehors de votre application, vous pouvez déployer un client curl. Si la requête est routée vers Cloud Run à l'aide de l'API GCPBackend, il n'est pas nécessaire d'y joindre explicitement un jeton IAM, car Cloud Service Mesh l'y joint automatiquement.

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"

La sortie doit être une réponse HTTP 200 valide.