Plan de contrôle géré pour les clients existants

Ce document s'adresse aux clients Anthos Service Mesh qui utilisent le plan de contrôle géré ou le plan de contrôle au sein du cluster. Ce document traite de l'implémentation de votre plan de contrôle et de la modernisation possible de votre plan de contrôle.

Si vous êtes un client Traffic Director existant ou nouveau, 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 fournit la gestion du trafic, la gestion des proxys lorsque le proxy Envoy est utilisé, ainsi que 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 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 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 mondial et 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 au niveau du plan de contrôle entraînent quelques caractéristiques visibles pour vous, l'utilisateur final.

  • Temps de réponse aux modifications de configuration. Les déploiements de nouveaux 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 pour des raisons 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 de manière globale aux déploiements de votre service. Pour permettre l'utilisation des services Google Cloud , tels que l'équilibrage de charge mondial multizone ou multirégion, 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 de manière à permettre à l'équipe Google d'ingénierie en fiabilité des sites d'effectuer des opérations produit de manière fiable et efficace en cas d'urgence en production.
    • Ces opérations offrent une fiabilité accrue, mais entraînent un push de configuration plus lent que la latence observée par les utilisateurs actuels d'Anthos Service Mesh.
    • La latence pour tout nouveau pod permettant d'extraire la configuration existante est légèrement meilleure avec le nouveau plan de contrôle. La configuration lente est utilisée pour 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. Elles sont traitées 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 de pods avec de nouvelles adresses IP, car ils ont été déplacés vers un autre nœud du cluster.
  • Gérer le 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 depuis chaque cluster au plan de contrôle de tous les clusters du maillage. Cette approche est 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 se traduit par une fiabilité et des performances améliorées dans les mailles comportant un grand nombre de points de terminaison, et permet aux mailles de s'adapter à un plus grand nombre de points de terminaison.

Quelles sont les conséquences du nouveau plan de contrôle pour 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 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 sur votre implémentation Cloud Service Mesh se trouve sous Configurer avec les APIGoogle Cloud .
  • Si vous êtes un utilisateur Anthos Service Mesh, les prochaines étapes 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, à quelques exceptions près. Dans Cloud Service Mesh, il s'agit du plan de contrôle géré (implémentation de Traffic Director, ou TD). Consultez la section suivante, Modernisation du plan de contrôle pour les mailles et les parcs existants. Si vous utilisez une fonctionnalité qui n'est pas 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 n'avez pas d'organisation Google Cloud 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 continuer à lire ce guide.
    • Vous recevrez une notification concernant la date à laquelle les nouvelles flottes recevront le plan de contrôle TD.

Modernisation du plan de contrôle pour les mailles et les parcs existants

Consultez Modernisation du plan de contrôle géré.

Vérifier la compatibilité du plan de contrôle

Consultez les différences entre les fonctionnalités compatibles avec les implémentations de 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, à savoir le plan de contrôle Traffic Director (TD), dans de 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é à bénéficier de l'implémentation istiod jusqu'au 8 septembre 2024.

Un petit nombre d'utilisateurs ont été ajoutés à la liste pour continuer à bénéficier de l'implémentation du plan de contrôle istiod dans les nouvelles flottes. 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 organisation Google Cloud ou dans une nouvelle organisation Google Cloud , vous obtiendrez le nouveau plan de contrôle géré avec l'implémentation TD à partir de la date de lancement de Cloud Service Mesh.

Étapes suivantes

  • Si vous êtes un client Anthos Service Mesh existant, 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 Traffic Director existant, votre documentation se trouve sous Configurer un maillage de services avec les API Google Cloud .