Migrer Istio ServiceEntry vers GCPBackend pour les VM Compute Engine

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. Découverte des points de terminaison : les points de terminaison de VM dans le service de backend sont automatiquement mis à jour lorsque des instances de VM sont ajoutées ou supprimées.
  2. Vérification centralisée de l'état : l'état des points de terminaison des VM est vérifié et le trafic est automatiquement redirigé des backends non opérationnels vers les backends opérationnels.
  3. Équilibrage de charge global et algorithmes d'équilibrage de charge avancés : les points de terminaison de VM peuvent être déployés dans plusieurs régions. Utilisez nos algorithmes d'équilibrage de charge pour configurer le comportement d'équilibrage de charge dans ces régions. Pour en savoir plus, consultez https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview et https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview.
  4. 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.
  5. 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 la VM Compute Engine.

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 à l'aide de l'API GCPBackend, elle n'a pas besoin d'un jeton IAM explicitement associé, car Cloud Service Mesh l'associe 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.