Service canonique

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

Cette page explique ce qu'est un service canonique dans Cloud Service Mesh.

Qu'est-ce qu'un service canonique ?

Cloud Service Mesh 1.6.8 introduit la prise en charge des services canoniques, qui sont un modèle conceptuel et architectural permettant de représenter vos charges de travail de production sous la forme d'un service unique, plus facile à observer et à gérer. Ces charges de travail peuvent être réparties sur plusieurs clusters, des plates-formes de backend variées, et différents schémas et configurations.

Pour les utilisateurs de Kubernetes : le service canonique s'apparente plus ou moins au concept d'"application" Kubernetes et à l'objet CRD Application.

Pour les utilisateurs de systèmes sans serveur : le service canonique s'apparente plus ou moins aux concepts de service App Engine et de service CloudRun. La seule différence est que les services sans serveur de Google sont intrinsèquement régionaux, tandis que les services canoniques constituent une abstraction mondiale/multirégionale.

Par exemple, les scénarios suivants décrivent tous les moyens de faire référence à un service canonique :

  • Un service est interrompu.
  • Un service s'exécute à la fois sur site et sur un cloud public.
  • Déployer une nouvelle révision d'un service.
  • Le service Foo envoie trop de trafic et est susceptible de dépasser notre capacité.

Les services canoniques existent au sein d'un maillage unique, ce qui, dans Cloud Service Mesh, signifie qu'ils sont également uniques au sein d'un parc et d'un projet Google Cloud (tous étant dans une relation un à un avec le maillage).

Une charge de travail donnée ne peut faire partie que d'un seul service canonique.

Vous pouvez déterminer le champ d'application complet d'un service canonique à partir du groupe de charges de travail qui le définissent :

  • Noms d'hôte et adresses IP
  • Réseau(x)
  • Règles de réseau et de sécurité
  • Routage et équilibrage de charge
  • Images de VM et de conteneurs
  • Infrastructure physique ou virtuelle
  • Zone(s) géographique(s)
  • Système CI/CD
  • Provenance
  • Télémétrie
  • Objectifs de niveau de service et alertes

Vous pouvez consulter des tableaux de bord affichant ces informations opérationnelles pour chaque service sur la page "Services".

Conditions requises et limites des services canoniques

Les services canoniques ne sont disponibles que sur Cloud Service Mesh en version 1.6.8 et ultérieure.

Chaque service canonique existe au sein d'un espace de noms Kubernetes/Istio unique et ne peut pas dépasser les limites de cet espace de noms.

Vous devez attribuer à un service canonique un nom unique dans son espace de noms parent. Pour en savoir plus, consultez la section Définir un service canonique.

Les services canoniques peuvent exister sur plusieurs clusters et régions. Bien qu'il soit possible de répartir les ressources et la télémétrie par cluster et région, ce ne sont pas des facteurs déterminant le champ d'application ou l'unicité d'un service.

Ainsi, l'identité unique d'un service canonique est déterminée par :

mesh id + namespace + canonical name.

Révisions

Les révisions font référence à des modifications incrémentielles apportées à un service, que vous pouvez utiliser pour distinguer et identifier les différentes versions de ce service.

Différenciez les révisions d'un service canonique en attribuant la "révision canonique" comme libellé à une charge de travail individuelle. Ce libellé est une chaîne arbitraire que vous pouvez définir. Bien que le libellé puisse être défini automatiquement dans certains cas, c'est vous ou le système CI/CD déployant le service qui devez l'appliquer. Pour obtenir des conseils sur la définition de ce libellé, consultez la section Définir un service canonique.

Notez qu'il est possible d'avoir plusieurs révisions en production en même temps. L'exécution simultanée de plusieurs révisions sert généralement dans les cas suivants :

  • Le déploiement progressif d'un nouveau binaire, d'une nouvelle configuration, ou des deux à la fois, sur l'ensemble des instances d'un service. Dans ce cas, l'ancienne et la nouvelle révisions sont actives lors de la transition.
  • Un "test A/B" ou une "expérimentation en direct" : dans ce contexte, deux versions différentes du service sont exposées à des sous-ensembles d'appelants en aval afin de tester l'effet d'une modification.

Étape suivante