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

{version_1.0.1 d

Ce document est destiné à vous si vous êtes un client Anthos Service Mesh existant qui utilise le plan de contrôle géré ou le plan de contrôle du cluster. Ce document aborde la mise en œuvre de votre plan de contrôle et la migration possible de ce dernier.

Si vous êtes un client Traffic Director permanent 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 assure la gestion du trafic, la gestion du proxy 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é s'appelle l'implémentation Traffic Director (TD). Que signifie le nouveau plan de contrôle 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 mutualisé.

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 identiques et que la configuration xDS envoyée aux side-cars soit compatible sans différence de comportement, les différences du plan de contrôle se traduisent par quelques caractéristiques visibles par vous, en tant qu'utilisateur final.

• Délai 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 passages à des fins de fiabilité. La première passe effectue des validations pour vérifier si la configuration est correcte. La phase suivante propage la configuration de manière globale dans vos déploiements de services. Pour permettre l'utilisation des services Google Cloud, tels que l'équilibrage de charge global interzone ou interrégional, la vérification d'état centralisée, l'autoscaling basé sur le trafic et la limitation du débit géré, la configuration est propagée à ces systèmes et validée de manière indépendante pour vérifier son exactitude. La configuration est également stockée en interne de manière à permettre à l'ingénierie de la fiabilité des sites de Google d'effectuer les opérations produit de manière fiable et efficace en cas d'urgence liée à la 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.
  • Avec le nouveau plan de contrôle, la latence permettant à tout nouveau pod de récupérer la configuration existante est légèrement supérieure. Le transfert de configuration lente concerne la propagation initiale de tout nouveau service créé ou de toute nouvelle règle transmise pour le service. Les latences de propagation des points de terminaison sont similaires sur le plan fonctionnel.
• Vitesse des événements de scaling et des autres modifications apportées aux points de terminaison Celles-ci 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 suite à leur déplacement vers un autre nœud du cluster.
• Scaling du nombre de points de terminaison Avec le nouveau plan de contrôle global, 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 Istio 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 au plan de contrôle global. Cela améliore la fiabilité et les performances dans les maillages comportant un grand nombre de points de terminaison, et leur permet 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 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 les API Google Cloud.
• Si vous utilisez Anthos Service Mesh, les étapes suivantes pour le plan de contrôle dans votre déploiement existant varient selon que vous utilisez le plan de contrôle géré ou le plan de contrôle interne au 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 en tant que plan de contrôle géré (implémentation de Traffic Director ou TD). Lisez la section suivante, Migration du plan de contrôle pour les réseaux maillés et les parcs existants. Si vous utilisez une fonctionnalité qui n'est pas compatible avec la mise en œuvre 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 interne au 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 organisation Google Cloud et que vous utilisez le plan de contrôle géré dans un projet sans organisation, vous recevrez le plan de contrôle TD.
• Si vous êtes un client Anthos Service Mesh et que vous créez des parcs, vous recevrez l'implémentation du plan de contrôle Traffic Director. Continuez la lecture de ce guide.
  • Vous serez informé de la date à laquelle les nouveaux parcs recevront le plan de contrôle TD.

Migration du plan de contrôle pour les réseaux maillés et les parcs existants

À partir du 22 juillet 2024, Google mettra progressivement à jour les clusters existants afin qu'ils utilisent le plan de contrôle géré avec l'implémentation TD. Vous serez averti avant que nous ne mettions à jour vos réseaux maillés.

Vous pouvez examiner les capacités des plans de contrôle Istiod et Traffic Director sur la page qui décrit les fonctionnalités compatibles avec les API Istio (plan de contrôle géré).

Vous devriez recevoir une notification indiquant qu'un cluster est programmé pour être mis à jour au moins deux semaines avant la mise à jour. Les notifications sont disponibles dans les conditions d'état des caractéristiques au niveau du cluster.

Utilisez la commande Google Cloud CLI suivante pour vérifier la notification:

gcloud container hub mesh describe --project=[PROJECT_ID]

Un résultat semblable aux lignes suivantes doit s'afficher :

membershipStates:
  projects/656460026795/locations/us-central1/memberships/cluster:
    servicemesh:
      conditions:
      - code: MODERNIZATION_SCHEDULED
        details: This cluster has been scheduled for modernization on or after (date ~ at least 2 weeks).
        documentationLink: 
        severity: INFO

Tous les anciens clusters de plan de contrôle géré qui ont été intégrés à l'aide de l'API meshconfig.googleapis.com seront automatiquement enregistrés dans le parc dans le projet du cluster avec l'API Membership gkehub.googleapis.com. Si une automatisation annule l'enregistrement d'un cluster, vous devez le supprimer avant la migration, sans quoi celle-ci rencontrera des problèmes. Pour que le produit géré fonctionne correctement, il doit être enregistré dans un parc avec la fonctionnalité de maillage activée.

Contactez l'assistance si vous devez personnaliser votre migration ou si vous ne savez pas si vous utilisez des fonctionnalités non compatibles.

Au cours de la migration, de manière sécurisée et contrôlée, les modifications suivantes sont effectuées:

• Pour activer la vérification de l'état, le daemonset snk est créé dans l'espace de noms kube-system du cluster, et une règle de pare-feu est créée pour chaque cluster.
• Pour activer l'ingestion de groupes de points de terminaison du réseau (NEG), l'annotation cloud.google.com/neg est ajoutée à tous les services Kubernetes.
• De nouvelles ressources Google Cloud telles que Mesh, Routes, les services de backend et les vérifications d'état sont créées dans le cluster.
• Les pods gérés par des déploiements Kubernetes sont redémarrés pour se reconnecter au plan de contrôle Traffic Director.

Certaines des nouvelles ressources sont limitées en termes de quota. Vous pouvez afficher les quotas et en demander plus si nécessaire.

Plan de contrôle pour les nouveaux réseaux maillés

À partir du 22 juin 2024, tous les parcs pour lesquels vous provisionnez un nouveau maillage reçoivent le plan de contrôle géré mis à jour avec l'implémentation de Google disponible dans le monde entier : le plan de contrôle Traffic Director (TD).

Si vous intégrez un nouveau parc à Cloud Service Mesh géré et que ce parc ne fait pas partie d'une organisation Google Cloud ou se trouve 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 toujours client 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 toujours client Traffic Director, vous trouverez la documentation sous Configurer le maillage de services avec les API Google Cloud.