Résoudre les problèmes liés aux services canoniques dans Cloud Service Mesh

Remarque : Les services canoniques sont automatiquement pris en charge dans les versions 1.6.8 et ultérieures de Cloud Service Mesh.

Cette section explique les problèmes courants rencontrés avec Cloud Service Mesh et indique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Assistance.

Les clusters de votre maillage exécutent une ancienne version de Cloud Service Mesh

Si l'un de vos clusters exécute une version antérieure de Cloud Service Mesh (<1.6.8) ou si un cluster exécute Cloud Service Mesh avec le contrôleur de service canonique désactivé, ces clusters (et services exécutés dessus) n'apparaîtront pas dans l'UI de Service Mesh. Pour utiliser les services canoniques, vous devez mettre à niveau chaque cluster vers la version 1.6.8 ou ultérieure de Cloud Service Mesh, et utiliser l'option d'installation par défaut qui inclut le contrôleur de services canoniques. Pour en savoir plus, consultez la page Mettre à niveau Cloud Service Mesh vers la dernière version si vos clusters fonctionnent sur GKE ou la page Mettre à niveau Cloud Service Mesh sur site.

Si vous préférez ne pas installer le contrôleur dans vos clusters, vous pouvez également activer le contrôleur de service canonique géré (actuellement en version bêta) pour votre réseau maillé.

Pour en savoir plus sur l'activation du contrôleur de services canoniques, consultez la section Activer le contrôleur de services canoniques.

Cloud Service Mesh n'est pas installé sur le cluster

Si Cloud Service Mesh n'est installé sur aucun de vos clusters, ces clusters n'apparaîtront pas dans l'interface utilisateur de Service Mesh. Pour en savoir plus sur l'installation Cloud Service Mesh, consultez la documentation de Cloud Service Mesh.

Vous n'êtes pas connecté au cluster sur site

Si vous avez un cluster sur site dans le maillage et que vous n'êtes pas connecté au cluster, vous ne pourrez pas afficher les services correspondant à ce cluster. Pour afficher ces services dans le tableau de bord, vous devez vous connecter au cluster. Pour en savoir plus sur la connexion à un cluster, consultez Se connecter à un cluster depuis la console Cloud

Votre cluster sur site n'est pas accessible

Si vous disposez d'un cluster sur site dans le maillage et qu'il n'est pas accessible via l'agent de connexion, vous ne pourrez pas afficher les services correspondant à ce cluster. Pour afficher ces services dans le tableau de bord, assurez-vous que votre cluster est en cours d'exécution et connecté à Google Cloud. Pour plus d'informations sur la connexion de votre cluster à Google Cloud, consultez Présentation de Connect

Un service ayant des SLO définis ne présente pas un mappage 1:1 avec un service canonique

Avant le passage au service canonique, Cloud Service Mesh affiche des tableaux de bord pour les services Kubernetes. Bien que les services Kubernetes et les services canoniques par défaut se correspondent fréquemment, il est possible qu'un service Kubernetes ne puisse pas être associé automatiquement au service canonique correspondant ou que la limite par défaut du service canonique ne soit pas souhaitable.

Si vous avez défini des objectifs de niveau de service (SLO) sur des services existants qui ne peuvent pas être associés automatiquement à un service canonique par défaut, leur migration n'est pas possible. Pour commencer à utiliser les services canoniques, vous devez supprimer le ou les SLO du service qui pose problème. Si vous le souhaitez, vous pouvez créer des SLO pour les services canoniques qui correspondent le mieux à ce service avant de supprimer l'ancien SLO.

Mon tableau de bord ne présente pas le contenu attendu

Les tableaux de bord de services Service Mesh sont tous limités à un service canonique de votre maillage de services, où un service canonique est un concept de service logique de haut niveau qui couvre un ensemble pertinent de charges de travail, régions, etc.

Par défaut, les libellés existants de chaque instance de charge de travail (Pod ou WorkloadEntry) définissent les services canoniques et suivent les règles ci-dessous par ordre de priorité décroissante :

Le libellé service.istio.io/canonical-name a déjà été défini explicitement. Aucune action supplémentaire n'est effectuée.
Sinon, le libellé service.istio.io/canonical-name est ajouté et sa valeur est définie sur celle du libellé app.kubernetes.io/name.
Sinon, le libellé service.istio.io/canonical-name est ajouté et sa valeur est définie sur celle du libellé app.
Sinon, le libellé service.istio.io/canonical-name est ajouté et sa valeur est définie sur la valeur name de la charge de travail propriétaire. La "charge de travail propriétaire" dans ce cas est le pod si celui-ci est déployé en mode solo, ou le déploiement, StatefulSet, etc. si vous utilisez une orchestration de niveau supérieur.

Pour la plupart des utilisateurs idiomatiques de Kubernetes et de Kube Run/Knative, ces règles correspondent directement à la manière dont vous gérez déjà vos services et charges de travail.

Toutefois, dans certains cas d'utilisation plus personnalisés ou plus complexes, l'heuristique par défaut ne capturent pas votre service de manière appropriée, et donc le maillage de services le tableau de bord qui s'affiche n'inclut pas le contenu attendu.

Vous pouvez résoudre ce problème en définissant manuellement le champ d'application du service canonique.

Définir manuellement le champ d'application d'un service

Dans la mesure du possible, nous vous recommandons d'utiliser les mécanismes automatiques de regroupement par défaut. Toutefois, si vous souhaitez remplacer ces regroupements par défaut, vous pouvez pour cela appliquer le libellé Kubernetes service.istio.io/canonical-name à vos configurations de pod et de WorkloadEntry Kubernetes.

Pour en savoir plus, consultez la section Définir manuellement un service canonique.