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

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

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

Les charges de travail Kubernetes sans service Kubernetes ne sont pas affichées

Si vous voyez le message "Les charges de travail Kubernetes sans service Kubernetes ne sont pas affichées. Créez un service Kubernetes pour chaque charge de travail afin de les afficher ci-dessous", vous devez migrer manuellement vers les services canoniques.

Deux causes principales peuvent être à l'origine de ce problème :

  1. Les clusters de votre maillage exécutent une ancienne version d'Anthos Service Mesh (< 1.6.8).
  2. Un service ayant des SLO définis ne présente pas un mappage 1:1 avec un service canonique.

Les clusters de votre maillage exécutent une ancienne version d'Anthos Service Mesh

Si l'un de vos clusters exécute une ancienne version d'ASM (< 1.6.8), vous ne pouvez pas utiliser les tableaux de bord basés sur les services canoniques. Pour utiliser les services canoniques, vous devez mettre à niveau tous les clusters vers Anthos Service Mesh en version 1.6.8 ou ultérieure. Pour en savoir plus, consultez la page Mettre à niveau Anthos Service Mesh vers la dernière version si vos clusters fonctionnent sur GKE ou la page Mettre à niveau Anthos Service Mesh sur site si vos clusters sont sur site.

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

Avant le passage aux services canoniques, Anthos Service Mesh présentait 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 :

  1. Le libellé service.istio.io/canonical-name a déjà été défini explicitement. Aucune action supplémentaire n'est effectuée.
  2. Sinon, le libellé service.istio.io/canonical-name est ajouté et sa valeur est définie sur celle du libellé app.kubernetes.io/name.
  3. Sinon, le libellé service.istio.io/canonical-name est ajouté et sa valeur est définie sur celle du libellé app.
  4. 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.

Dans certains cas d'utilisation plus personnalisés ou plus complexes, les méthodes par défaut ne capturent pas correctement votre service. De ce fait, le tableau de bord Anthos Service Mesh 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.