Bonnes pratiques concernant les services canoniques

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

Les services canoniques vous permettent de gérer de nombreuses configurations différentes. Pour une expérience optimale avec les tableaux de bord de services de Cloud Service Mesh, tenez compte des pratiques standards suivantes lors de la configuration de vos services:

  • Réservez un élément [espace de noms, nom] unique au service sur l'ensemble du maillage.
  • Définissez une application logicielle par service canonique.
    • Ne regroupez pas les services canoniques à travers plusieurs environnements (par exemple, production/préproduction/développement).
    • Utilisez les tableaux de bord Cloud Monitoring pour obtenir une vue d'ensemble de plusieurs services.
  • Tablez sur une longue durée de vie pour les services canoniques.

Réservez un élément [espace de noms, nom] unique au service sur l'ensemble du maillage

Si un service canonique déployé dans un cluster ou dans une région possède le même espace de noms Kubernetes et le même nom de service canonique qu'un service déployé dans un autre cluster ou une autre région, Cloud Service Mesh part du principe qu'il s'agit du même service logique.

Ce comportement est conforme au principe d'uniformité des parcs, selon lequel un espace de noms doit avoir la même signification et représenter la même entité sur l'intégralité du parc.

Une application logicielle par service canonique

Les services canoniques sont conçus pour représenter un unique service ou microservice logique. Ils sont destinés à couvrir des binaires ou des charges de travail homogènes représentant la même application logicielle et la même fonction métier.

Bien que vous puissiez définir un service canonique pour regrouper plusieurs microservices conceptuellement différents, les tableaux de bord de service n'en fourniront pas toute la valeur.Ils afficheront une agrégation de composants dissemblables qui peuvent fonctionner et être configurés de manière très différente individuellement. Il serait difficile, voire impossible, de comprendre l'état, les performances et la configuration de l'ensemble.

Les pratiques suivantes ne sont pas nécessairement mauvaises, mais votre service canonique peut être trop étendu si :

  • il existe du trafic réseau entre différentes charges de travail au sein d'un même service canonique ;
  • un service canonique comprend plusieurs charges de travail déployées suivant différents calendriers de versions ;
  • différentes équipes au sein de votre organisation sont responsables du fonctionnement des différents éléments d'un même service canonique.

Ne regroupez pas un service canonique à travers plusieurs environnements

De nombreuses organisations du secteur des technologies exploitent plusieurs environnements de déploiement afin de garantir la qualité des logiciels et de limiter les risques. Ces environnements incluent le plus souvent des environnements de développement, de test, de préproduction et de production, ou un sous-ensemble de ces environnements.

Même si vous déployez le même service conceptuel dans chacun des différents environnements, il est déconseillé de les regrouper au sein d'un même service canonique. Ces services ne sont pas identiques et ne représentent pas le même niveau de suivi de fonctionnement ou d'attention pour votre organisation.

Par exemple, une défaillance sur un service de production critique peut provoquer le déclenchement d'alertes et un dépannage d'urgence à 3 h du matin. Vous ne voulez sans doute pas déclencher d'alerte si le déploiement de développement subit une défaillance en pleine nuit. Il en va de même pour la compréhension des performances, des capacités et de la sécurité des versions.

De la solution la plus simple mais la moins rigoureuse, à la solution la plus puissante, qui demande le plus d'efforts, il existe trois manières de séparer les services de différents environnements:

  1. Séparez-les en utilisant plusieurs noms de service, par exemple payments-prod et payments-test.
  2. Séparez-les en utilisant plusieurs espaces de noms, par exemple billing-team et billing-team-test.
  3. Séparez-les en utilisant plusieurs parcs, un pour chaque environnement.

Préférez les tableaux de bord personnalisés Cloud Monitoring pour créer des agrégations arbitraires

Plutôt que d'augmenter artificiellement et à l'excès le champ d'application des services canoniques pour agréger leurs données, utilisez des tableaux de bord Cloud Monitoring afin de créer des vues d'ensemble pour plusieurs services logiques à la fois.

Les services canoniques sont destinés à durer longtemps

En dehors des cas d'utilisation de développement, d'exploration et de test, les services canoniques doivent représenter des services logiques globaux de haut niveau. Ces services évoluent lentement et ont tendance à avoir une longue durée de vie. Cette longévité implique de ne pas modifier les noms des services. Bien que vous puissiez modifier leur nom, cette action a une incidence sur les métriques, les SLO et les journaux. Cependant, vous pouvez ajuster librement le champ Display name sans que cela n'occasionne d'interruption.

L'apparition d'un nouveau service canonique coïncide fréquemment avec un nouveau logiciel ou une mise à jour, tandis que la disparition d'un service canonique correspond souvent à l'abandon d'un service. Votre capacité à consulter l'historique des performances de votre service, de votre plan et de la capacité de votre projet, dépend entièrement de la préservation d'une notion unique correspondant à ce service dans Cloud Service Mesh et ce, durant toute sa vie.

Notez que ce principe diffère des ressources de niveau inférieur telles que les instances de VM, les pods/déploiements Kubernetes et même les clusters entiers, qui sont souvent créés et supprimés dans le cadre de la mise à jour et de la maintenance des systèmes de production.

Étapes suivantes