Plan de contrôle géré pour les clients existants
Ce document s'adresse à vous si vous êtes un client Anthos Service Mesh qui utilise le plan de contrôle géré ou le plan de contrôle au sein du cluster. Ce document décrit l'implémentation de votre plan de contrôle et la modernisation possible de celui-ci.
Si vous êtes un client Traffic Director existant ou un nouveau client, vous n'avez pas besoin de lire ce document.
Présentation du plan de contrôle
Dans les maillages de services, le plan de contrôle fournit la gestion du trafic, la gestion des proxys lorsque le proxy Envoy est utilisé et d'autres fonctionnalités de mise en réseau.
Anthos Service Mesh proposait deux plans de contrôle: un plan de contrôle géré et un plan de contrôle intégré au 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 de Traffic Director (TD). Qu'est-ce que le nouveau plan de contrôle implique 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 global multi-tenant.
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 sidecars soit compatible sans différences de comportement, les différences de plan de contrôle entraînent quelques caractéristiques visibles par vous, l'utilisateur final.
- Temps de réponse de la modification de configuration. Les nouveaux déploiements de services ou les modifications des 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 étape effectue des validations pour vérifier si la configuration est bien structurée. La phase suivante propage la configuration de manière globale sur vos déploiements de services. Pour permettre l'utilisation des services Google Cloud , tels que l'équilibrage de charge interzonal ou interrégional, la vérification de l'état centralisée, l'autoscaling basé sur le trafic et la limitation de 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 de manière à permettre à l'équipe d'ingénierie de la fiabilité des sites de Google d'effectuer les opérations de produits de manière fiable et efficace en cas d'urgence de production.
- Ces opérations offrent une meilleure fiabilité, mais elles entraînent un transfert de configuration plus lent que la latence observée par les utilisateurs actuels d'Anthos Service Mesh.
- La latence pour qu'un nouveau pod récupère la configuration existante est légèrement meilleure avec le nouveau plan de contrôle. La propagation lente de la configuration est destinée à la première propagation de tout nouveau service créé ou de toute nouvelle règle transmise pour le service. Les latences de propagation des points de terminaison sont fonctionnellement similaires.
- Vitesse des événements de mise à l'échelle et autres modifications apportées aux points de terminaison. Ils 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.
- Évoluer le nombre de points de terminaison. Avec le nouveau plan de contrôle global, les points de terminaison du réseau maillé sont envoyés directement de chaque cluster au plan de contrôle à partir de tous les clusters du réseau maillé. Il s'agit d'une approche plus simple, plus rapide et plus évolutive que celle utilisée par le précédent plan de contrôle géré. 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 tous les autres clusters. Avec le plan de contrôle global, les points de terminaison sont propagés directement vers le plan de contrôle global. Cela se traduit par une meilleure fiabilité et des performances améliorées dans les maillages avec un grand nombre de points de terminaison, et permet aux maillages de s'adapter à un plus grand nombre de points de terminaison.
En quoi le nouveau plan de contrôle vous concerne-t-il ?
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 utilisez Traffic Director, votre plan de contrôle reste inchangé. 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 les APIGoogle Cloud .
- Si vous utilisez 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é, vos flottes existantes seront migrées vers le nouveau plan de contrôle, appelé plan de contrôle géré (implémentation de Traffic Director ou TD) dans Cloud Service Mesh. Consultez la section suivante, Modernisation du plan de contrôle pour les réseaux maillés 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 au sein du 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' 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 client Anthos Service Mesh et que vous créez des flottes, vous recevrez l'implémentation du plan de contrôle Traffic Director. Vous devez poursuivre la lecture de ce guide.
- Vous serez informé de la date à laquelle les nouvelles flottes recevront le plan de contrôle TD.
Modernisation du plan de contrôle pour les réseaux maillés et les parcs existants
Consultez la section Modernisation du plan de contrôle géré.
Vérifier la compatibilité du plan de contrôle
Consultez les différences de fonctionnalités compatibles entre les implémentations du plan de contrôle géré pour déterminer si votre utilisation actuelle de Cloud Service Mesh nécessitera des modifications.
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 dans le monde entier de Google : le plan de contrôle Traffic Director (TD), dans les nouvelles flottes.
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 de Traffic Director sans modification ont continué à recevoir l'implémentation istiod jusqu'au 8 septembre 2024.
Un petit nombre d'utilisateurs ont été sélectionnés pour continuer à implémenter le plan de contrôle istiod dans de nouvelles flottes. Si cela s'applique à votre organisation, vous avez reçu un communiqué de service.
Si vous intégrez un nouveau parc à Cloud Service Mesh géré et qu'il ne fait pas partie d'une Google Cloud organisation ou qu'il appartient à une nouvelle Google Cloud organisation, vous obtiendrez le nouveau plan de contrôle géré avec l'implémentation de TD à partir de la date de lancement de Cloud Service Mesh.
Étape suivante
- Si vous êtes un client Anthos Service Mesh, votre documentation se trouve dans la table des matières de gauche sous Configurer un service mesh avec les API Istio.
- Si vous êtes toujours client Traffic Director, votre documentation se trouve sous Configurer un maillage de services avec les API Google Cloud .