Plan de contrôle géré pour les clients existants
Ce document s'adresse aux clients existants d'Anthos Service Mesh qui utilisent le plan de contrôle géré ou le plan de contrôle dans le cluster. Il aborde l'implémentation de votre plan de contrôle et sa modernisation éventuelle.
Si vous êtes un client existant de Traffic Director ou un nouveau client, vous disposez déjà du plan de contrôle modernisé. Vous n'avez donc pas besoin de lire ce document ni les autres de cette section.
Présentation du plan de contrôle
Dans les maillages de services, le plan de contrôle assure la gestion du trafic, la gestion des proxys lorsque le proxy Envoy est utilisé et d'autres fonctionnalités réseau.
Anthos Service Mesh proposait deux plans de contrôle : un plan de contrôle géré et un plan de contrôle dans le cluster. Seuls les proxys Envoy sont utilisés comme plan de données.
Nouveau plan de contrôle géré
Le nouveau plan de contrôle géré est appelé implémentation Traffic Director (TD). Qu'est-ce que le nouveau plan de contrôle signifie pour vous ?
L'un des changements les plus importants entre le produit Anthos Service Mesh et Cloud Service Mesh est le passage à un plan de contrôle mondial multitenant.
Le plan de contrôle géré utilisé dans Anthos Service Mesh est dédié à un seul cluster. Bien que les API (CRD Istio) utilisées pour GKE soient les mêmes et que la configuration xDS envoyée aux side-cars soit compatible sans différence de comportement, les différences de plan de contrôle entraînent quelques caractéristiques visibles pour vous, l'utilisateur final.
- Temps de réponse aux modifications de configuration. Les nouveaux déploiements de services ou les modifications apportées aux règles de service prennent un peu plus de temps avec le nouveau plan de contrôle.
- Le pipeline de configuration effectue un commit de configuration en deux passes à des fins de fiabilité. La première passe effectue des validations pour vérifier si la configuration est bien formée. La phase suivante propage la configuration à l'échelle mondiale à vos déploiements de services. Pour permettre l'utilisation de Google Cloud services tels que l'équilibrage de charge mondial inter-zones ou inter-régions, la vérification d'état centralisée, l'autoscaling basé sur le trafic et la limitation du débit gérée, la configuration est propagée à ces systèmes et validée indépendamment pour vérifier son exactitude. La configuration est également stockée en interne d'une manière qui permet à l'ingénierie de la fiabilité des sites de Google d'effectuer de manière fiable et efficace les opérations sur les produits en cas d'urgence en production.
- Ces opérations offrent une meilleure fiabilité, mais entraînent un push de configuration plus lent que la latence observée par les utilisateurs actuels d'Anthos Service Mesh.
- La latence de récupération de la configuration existante par un nouveau pod est légèrement meilleure avec le nouveau plan de contrôle. Le push de configuration lent concerne la première propagation de tout nouveau service créé ou de toute nouvelle règle appliquée au service. Les latences de propagation des points de terminaison sont fonctionnellement similaires.
- Vitesse des événements de scaling et autres modifications apportées aux points de terminaison. Ces événements sont gérés au moins aussi rapidement avec le nouveau plan de contrôle. Ces événements incluent le démarrage ou l'arrêt de nouveaux pods en raison de l'autoscaling horizontal des pods, ainsi que le redémarrage des pods avec de nouvelles adresses IP, car ils ont été déplacés vers un autre nœud du cluster.
- Scaling du nombre de points de terminaison. Avec le nouveau plan de contrôle mondial, les points de terminaison du maillage sont envoyés directement de chaque cluster au plan de contrôle à partir de tous les clusters du maillage. Il s'agit d'une approche plus simple, plus rapide et plus évolutive que celle utilisée par le plan de contrôle géré précédent. Dans l'ancien modèle de plan de contrôle géré (plan de contrôle dédié), chaque Istiod doit communiquer avec tous les autres clusters du maillage pour déterminer les points de terminaison disponibles dans chaque autre cluster. Avec le plan de contrôle mondial, les points de terminaison sont propagés directement au plan de contrôle mondial. Cela améliore la fiabilité et les performances dans les maillages comportant un grand nombre de points de terminaison, et permet aux maillages de s'adapter à un plus grand nombre de points de terminaison.
Quel est l'impact du nouveau plan de contrôle sur vous ?
L'impact du nouveau plan de contrôle sur vous dépend des API et du plan de contrôle que vous utilisez.
- Si vous êtes un utilisateur de Traffic Director, votre plan de contrôle reste le même. Vous n'avez pas besoin de lire le reste de ce guide. La documentation de votre implémentation de Cloud Service Mesh se trouve sous Configurer avec Google Cloud des API.
- Si vous êtes un utilisateur d'Anthos Service Mesh, les étapes suivantes pour le plan de contrôle de votre déploiement existant dépendent de l'utilisation du plan de contrôle géré ou du plan de contrôle dans le cluster.
- Si vous utilisez le plan de contrôle géré, à quelques exceptions près, vos parcs existants seront migrés vers le nouveau plan de contrôle, appelé dans Cloud Service Mesh plan de contrôle géré (implémentation Traffic Director, ou TD). Consultez la section suivante, Modernisation du plan de contrôle pour les maillages et les parcs existants. Si vous utilisez une fonctionnalité non compatible avec l'implémentation du plan de contrôle Traffic Director, vous restez temporairement sur le plan de contrôle précédent. Vous devez continuer à lire ce guide.
- Si vous utilisez le plan de contrôle dans le cluster, votre plan de contrôle reste le même. Vous n'avez pas besoin de lire le reste de ce guide.
- Si vous ne disposez pas d'une Google Cloud Organisation et que vous utilisez le plan de contrôle géré sur un projet sans organisation, vous recevrez le plan de contrôle TD.
- Si vous êtes un client d'Anthos Service Mesh et que vous créez des parcs, vous recevrez l'implémentation du plan de contrôle Traffic Director. Vous devez continuer à lire ce guide.
- Vous serez informé de la date à laquelle les nouveaux parcs recevront le plan de contrôle TD.
Modernisation du plan de contrôle pour les maillages et les parcs existants
Consultez la section Modernisation du plan de contrôle géré.
Vérifier la compatibilité du plan de contrôle
Pour évaluer automatiquement votre parc par rapport aux fonctionnalités compatibles et identifier les éventuels problèmes bloquants avant la modernisation, consultez Comprendre la compatibilité de Cloud Service Mesh.
Plan de contrôle pour les nouveaux maillages
À partir du 1er juillet 2024, la plupart des utilisateurs existants de l'implémentation du plan de contrôle istiod géré ont commencé à recevoir le plan de contrôle géré mis à jour avec l'implémentation disponible à l'échelle mondiale de Google : le plan de contrôle Traffic Director (TD), dans les nouveaux parcs.
Les utilisateurs dont l'utilisation existante de Cloud Service Mesh géré avec l'implémentation du plan de contrôle istiod n'était pas compatible avec l'implémentation Traffic Director sans modification ont continué à recevoir l'implémentation istiod jusqu'au 8 septembre 2024.
Un petit nombre d'utilisateurs ont été davantage isolés pour continuer à recevoir l'implémentation du plan de contrôle istiod dans les nouveaux parcs. Si cela s'applique à votre organisation, vous avez reçu une annonce de service.
Si vous intégrez un nouveau parc à Cloud Service Mesh géré et que ce parc ne se trouve pas dans une Google Cloud Organisation ou qu'il se trouve dans une nouvelle Google Cloud Organisation, vous recevrez le nouveau plan de contrôle géré avec l'implémentation TD à partir de la date de lancement de Cloud Service Mesh.
Étape suivante
- Si vous êtes un client existant d'Anthos Service Mesh, votre documentation se trouve dans la table des matières de gauche, sous Configurer le maillage de services avec les API Istio.
- Si vous êtes un client existant de Traffic Director, votre documentation se trouve sous Configurer le maillage de services avec Google Cloud des API.