Migrer une ressource Istio ServiceEntry vers une ressource GCPBackend pour des VM Compute Engine
Cette page explique comment migrer de ServiceEntry vers GCPBackend, en montrant comment les fonctionnalités de gestion du trafic d'Istio peuvent assurer une transition fluide et sécurisée.
La migration vers GCPBackend présente les avantages suivants :
- 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.
- Vérification d'état centralisée : l'état des points de terminaison de VM est vérifié et le trafic est automatiquement acheminé des backends non opérationnels vers les backends opérationnels.
- É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 de l'é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.
- 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.
- 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 disposez des éléments suivants :
- Un cluster GKE avec Cloud Service Mesh activé.
- Une entrée de service Istio.
- Une ressource GCPBackend configurée pour une VM Compute Engine.
Créer ou modifier le VirtualService existant pour inclure ServiceEntry et GCPBackend comme destinations
Vous pouvez utiliser la répartition du trafic pour transférer progressivement le trafic de ServiceEntry vers GCPBackend. Vous devez commencer par un petit pourcentage de trafic dirigé vers GCPBackend et l'augmenter progressivement tout en surveillant les éventuels problèmes.
L'exemple suivant décrit la migration de 10 % des requêtes vers 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 correspond au 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 encore plus fluide, vous pouvez configurer la mise en miroir du trafic afin d'envoyer une copie du trafic à GCPBackend tout en dirigeant principalement le trafic vers ServiceEntry. Cela permet de tester et de valider la configuration de 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 acheminé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.