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 :
- 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 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.
- É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.
- 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 : profitez d'une configuration et d'une gestion simplifiées.
Avant de commencer
Les sections suivantes supposent que vous avez :
- Un cluster GKE avec Cloud Service Mesh activé.
- Entrée de service Istio.
- 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 et 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 au 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 la documentation de 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. Aucune erreur ne devrait apparaître.
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.