Plan de contrôle géré

Attention : L'implémentation du plan de contrôle ISTIOD pour Cloud Service Mesh géré est obsolète. Vous devez moderniser tous les parcs ISTIOD gérés pour l'implémentation TRAFFIC_DIRECTOR.

Ce document explique les différences architecturales entre l'implémentation du plan de contrôle ISTIOD obsolète et l'implémentation du plan de contrôle TRAFFIC_DIRECTOR moderne de Google. Il décrit également les prochaines étapes à suivre si vos clusters utilisent toujours un plan de contrôle obsolète.

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.

Cloud Service Mesh utilisant les API Istio sur les clusters GKE fournit une implémentation entièrement compatible des API Istio. Les API sont implémentées et compatibles avec le plan de contrôle TRAFFIC_DIRECTOR entièrement géré et intégré à Cloud Networking. Auparavant, deux autres implémentations du plan de contrôle étaient acceptées :

• L'implémentation gérée ISTIOD, qui exécute un plan de contrôle dédié à un seul cluster.
• L'implémentation obsolète dans le cluster ISTIOD, qui exécute les composants du plan de contrôle gérés par le client dans votre cluster.

Caractéristiques opérationnelles du plan de contrôle TRAFFIC_DIRECTOR

Cloud Service Mesh avec le plan de contrôle TRAFFIC_DIRECTOR utilise l'infrastructure réseau gérée de Google Cloudplutôt que des instances de plan de contrôle par cluster.

Les API Istio (CRD) et la configuration xDS envoyée aux side-cars Envoy restent compatibles, mais vous devez vous attendre aux caractéristiques opérationnelles suivantes :

• Propagation de la configuration des règles et des services : lorsque vous créez des services ou que vous mettez à jour des règles de routage et de sécurité, la configuration est validée et propagée dans les systèmes Google Cloud avant de prendre effet sur les side-cars. Par conséquent, la propagation initiale des règles et des services prend plus de temps qu'avec les plans de contrôle ISTIOD ou dans le cluster. Pour obtenir des conseils sur l'optimisation des workflows de déploiement, consultez Propagation de la configuration.
• Scaling des pods et mises à jour des points de terminaison : les modifications apportées aux points de terminaison des charges de travail (par exemple, les nouveaux pods créés par l'autoscaling horizontal des pods ou les pods redémarrant avec de nouvelles adresses IP) sont propagées directement par le plan de contrôle, sans la latence associée aux mises à jour des règles. Les pods existants qui récupèrent la configuration existante démarrent sans délai.
• Découverte des points de terminaison multicluster : dans les mailles multiclusters, les clusters partagent leurs points de terminaison directement via Google Cloud plutôt que de les synchroniser point à point entre chaque combinaison de clusters. Cela garantit que l'état des points de terminaison multicluster converge plus rapidement et de manière plus cohérente à mesure que votre maillage évolue.

Qu'est-ce que cela signifie pour vous ?

Les étapes suivantes dépendent de l'implémentation du plan de contrôle Cloud Service Mesh utilisée par vos clusters :

• Plan de contrôle géré (implémentation TRAFFIC_DIRECTOR) :
  • Vous utilisez déjà l'architecture actuelle et évolutive à l'échelle mondiale (qu'elle soit configurée à l'aide des API Istio, de l'API Gateway ou des API Google Cloud).
  • Aucune action n'est requise.
• Plan de contrôle géré (implémentation ISTIOD) :
  • Cette implémentation est obsolète.
  • Vous devez prendre des mesures pour vérifier si votre parc présente des problèmes de compatibilité, mettre à jour votre configuration et effectuer la modernisation du plan de contrôle géré ou désinstaller Cloud Service Mesh géré.
• Plan de contrôle dans le cluster :
  • Le plan de contrôle dans le cluster sur GKE est obsolète.
  • Les installations dans le cluster ne peuvent pas être modernisées sur place. Vous devez migrer du plan de contrôle intégré au cluster vers le plan de contrôle géré sur un nouveau cluster ou désinstaller Cloud Service Mesh.

Modernisation du plan de contrôle pour Cloud Service Mesh géré avec l'implémentation ISTIOD

Toutes les flottes gérées exécutant l'implémentation ISTIOD obsolète doivent effectuer la modernisation vers l'implémentation TRAFFIC_DIRECTOR avant la date limite de fin de prise en charge spécifiée dans l'avis d'obsolescence. Vous pouvez moderniser votre parc à l'aide de la modernisation déclenchée par le client (recommandée pour le contrôle par cluster et le transfert progressif du trafic) ou de la modernisation pilotée par Google (déploiements automatisés pour les parcs éligibles).

Pour obtenir des instructions détaillées, consultez Modernisation du plan de contrôle géré.

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

Pour évaluer votre parc par rapport aux fonctionnalités compatibles et identifier les bloqueurs de configuration avant la modernisation, consultez :

• Comprendre la compatibilité de Cloud Service Mesh
• Mises à jour de la configuration pour la modernisation

Annexe : Calendrier de déploiement et d'abandon du plan de contrôle

La transition des plans de contrôle ISTIOD vers l'implémentation du plan de contrôle TRAFFIC_DIRECTOR géré a suivi le calendrier suivant :

• 23 mai 2024 : Anthos Service Mesh et Traffic Director ont été fusionnés dans Cloud Service Mesh, ce qui a entraîné l'introduction de l'implémentation du plan de contrôle TRAFFIC_DIRECTOR pour les API Istio.
• 1er juillet 2024 : les nouvelles flottes intégrées à Cloud Service Mesh géré ont commencé à recevoir l'implémentation TRAFFIC_DIRECTOR par défaut.
• 8 septembre 2024 : le provisionnement de l'implémentation ISTIOD pour les nouvelles flottes a pris fin pour la disponibilité générale (avec des exceptions temporaires pour certaines organisations figurant sur une liste d'autorisation).
• 28 septembre 2026 : annonce de l'arrêt formel de l'implémentation du plan de contrôle ISTIOD géré et du plan de contrôle dans le cluster sur GKE.