Glossaire

Cette page fournit de brèves définitions et des liens vers des informations supplémentaires concernant les termes utilisés dans la documentation d'Anthos Service Mesh.

C

Plan de contrôle

Un plan de contrôle est un ensemble de services système qui configurent le maillage ou un sous-ensemble du maillage pour gérer la communication entre les instances de charge de travail qu'il contient. Anthos Service Mesh 1.9 et versions ultérieures fournissent deux plans de contrôle :

Plan de contrôle géré par Google (Aperçu) : il s'agit d'un service Google Cloud entièrement géré que vous n'avez qu'à configurer, pendant que Google en gère la fiabilité, les mises à niveau, le scaling et la sécurité.
Plan de contrôle dans le cluster : il s'agit d'une distribution de istiod prise en charge par Google que vous installez sur votre cluster. Lorsque vous installez Anthos Service Mesh avec istiod, vous êtes responsable de la mise à niveau et de la configuration de la sécurité et du scaling.

Bien que le plan de contrôle distribue sa configuration aux proxys side-car, il ne participe pas directement à la gestion du trafic pour les charges de travail dans le maillage.

D

Plan de données: Le plan de données est la partie du maillage qui contrôle directement la communication entre les instances de charge de travail. Le plan de données d'Anthos Service Mesh utilise des proxys déployés comme side-cars pour arbitrer et contrôler l'ensemble du trafic TCP envoyé et reçu par les services de votre maillage.

F

Fleet: Une Fleet (anciennement appelée Environ) vous permet d'organiser les clusters pour faciliter la gestion multicluster. L'enregistrement de vos clusters dans une Fleet permet de simplifier la gestion d'un maillage multi-cluster, en appliquant le concept d'uniformité aux identités, aux espaces de noms et aux services. Si vos clusters se trouvent dans différents projets, vous devez les enregistrer auprès du projet hôte de Fleet, plutôt que du projet dans lequel ils ont été créés. Pour en savoir plus sur les parcs (Fleets), consultez la section Présentation des parcs.

I

identity

L'identité est un concept fondamental de l'infrastructure de sécurité. Le modèle d'identité d'Anthos Service Mesh est basé sur une identité de charge de travail de première classe. Au début de la communication de service à service, les deux parties échangent les identifiants avec leurs informations d'identité à des fins d'authentification mutuelle.

Les clients vérifient l'identité du serveur par rapport à leurs informations de dénomination sécurisées pour déterminer si le serveur est autorisé à exécuter le service.

Les serveurs vérifient l'identité du client pour déterminer les informations auxquelles il peut accéder. Les serveurs décident d'autoriser ou non l'accès en fonction des règles d'autorisation configurées.

À l'aide de l'identité, les serveurs peuvent contrôler l'heure d'accès aux informations et les informations consultées par un client spécifique. Ils peuvent également facturer les clients en fonction des services qu'ils utilisent et rejeter ceux qui n'ont pas payé leur facture d'accès aux services.

Le modèle d'identité d'Anthos Service Mesh est flexible et suffisamment précis pour représenter un utilisateur humain, un service individuel ou un groupe de services. Sur les plates-formes sans identité de service de première classe, Anthos Service Mesh peut utiliser d'autres identités pouvant regrouper des instances de service, comme des noms de services.

Anthos Service Mesh est compatible avec les identités de service suivantes sur différentes plates-formes :

Kubernetes : compte de service Kubernetes
Google Kubernetes Engine : compte de service Google Cloud
Google Cloud : compte de service Google Cloud

istiod

Istiod est le binaire monolithique consolidé qui fournit des services du plan de contrôle. Avant Anthos Service Mesh 1.5, les services du plan de contrôle étaient fournis par des composants distincts appelés Pilot, Citadel, Mixer et Galley.

IstioOperator

Une ressource personnalisée qui vous permet de configurer le plan de contrôle. Pour en savoir plus, consultez la page consacrée à IstioOperator dans la documentation Istio.

M

TLS mutuel: Anthos Service Mesh utilise le protocole TLS mutuel (mTLS) pour l'authentification et le chiffrement entre les services du maillage. mTLS permet aux charges de travail de valider leurs identités et de s'authentifier entre elles. Vous connaissez peut-être déjà le protocole TLS simple utilisé avec HTTPS pour permettre aux navigateurs d'approuver des serveurs Web et de chiffrer les données échangées. Lorsque le protocole TLS simple est utilisé, le client établit que le serveur est digne de confiance en validant son certificat. mTLS est une mise en œuvre de TLS dans laquelle le client et le serveur se présentent des certificats et vérifient leurs identités respectives.

N

network: Anthos Service Mesh utilise une définition simplifiée du réseau basée sur la connectivité générale. Les instances de charge de travail se trouvent sur le même réseau si elles peuvent communiquer directement, sans passerelle.

fichier de superposition: Un fichier YAML contenant une ressource personnalisée IstioOperator. Vous utilisez des fichiers de superposition pour configurer le plan de contrôle. Vous pouvez remplacer la configuration par défaut du plan de contrôle et activer les fonctionnalités facultatives compatibles dans un fichier YAML que vous transmettez à istioctl install ou au script install_asm. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes. Consultez la section Activer les fonctionnalités facultatives afin de découvrir les instructions YAML que vous pouvez utiliser pour activer des fonctionnalités non activées par défaut.

P

cluster principal: Un cluster principal est un cluster avec un plan de contrôle. Un seul maillage peut disposer de plusieurs clusters principaux pour assurer une haute disponibilité ou réduire la latence. Dans la documentation d'Istio 1.7, plusieurs déploiements principaux sont appelés "plan de contrôle répliqué".

R

cluster distant: Un cluster distant est un cluster qui se connecte à un plan de contrôle situé en dehors du cluster. Un cluster distant peut se connecter à un plan de contrôle exécuté dans un cluster principal ou à un plan de contrôle externe.
Révision: Une révision représente un instantané de la version du code d'application et de la configuration. Lorsque vous installez ou mettez à niveau Anthos Service Mesh, un libellé de révision est ajouté à istiod afin d'identifier la version. Pour activer l'injection side-car automatique, ajoutez le libellé de révision à vos espaces de noms, puis redémarrez vos pods. Utilisez le libellé de révision pour associer les pods d'un espace de noms à une révision istiod particulière, afin de pouvoir passer en toute sécurité à un nouveau plan de contrôle et revenir à la révision d'origine en cas de problèmes.

S

dénomination sécurisée: Les identités des serveurs sont encodées dans les certificats, mais les noms des services sont récupérés via le service de découverte ou le DNS. Les informations de dénomination sécurisée mappent les identités des serveurs aux noms des services. Un mappage de l'identité A au nom de service B signifie que "A est autorisé à exécuter le service B". Le plan de contrôle surveille apiserver, génère les mappages de dénomination sécurisés, puis les distribue aux proxys side-car en toute sécurité.
maillage de services: Un maillage de services, ou simplement maillage, est une couche d'infrastructure qui permet une communication gérée, observable et sécurisée entre les instances de charge de travail.
side-car: Modèle permettant d'exécuter un utilitaire ou un outil d'aide avec une charge de travail. Si vous utilisez Kubernetes, les side-cars s'exécutent parallèlement au conteneur de la charge de travail d'un pod. Lorsqu'il est question de maillage de services, le mot "side-car" est souvent utilisé pour faire référence au proxy.

T

domaine de confiance

Le domaine de confiance correspond à la racine de confiance d'un système et fait partie de l'identité d'une charge de travail.

Anthos Service Mesh utilise un domaine de confiance pour créer toutes les identités au sein d'un maillage. Par exemple, dans l'ID SPIFFE spiffe://mytrustdomain.com/ns/default/sa/myname, la sous-chaîne mytrustdomain.com indique que la charge de travail provient d'un domaine de confiance appelé mytrustdomain.com

Lorsque vous utilisez l'autorité de certification Mesh, le domaine d'approbation est automatiquement généré par Anthos Service Mesh. Celui-ci est basé sur le pool de charges de travail du cluster sous la forme project-id.svc.id.goog ou project-id.hub.id.goog.

Vous pouvez disposer d'un ou plusieurs domaines de confiance dans un maillage multi-cluster, à condition que les clusters partagent la même racine de confiance.

W

charge de travail: Une charge de travail est une application conteneurisée, un service ou un autre programme, tel qu'une tâche par lot ou un daemon exécuté sur une plate-forme. Il peut s'agir d'un cluster Kubernetes, d'une machine virtuelle ou d'un autre environnement tel que Google Distributed Cloud Virtual pour Bare Metal. Les charges de travail ont des noms, des espaces de noms et des identifiants uniques. Sur Kubernetes, une charge de travail correspond généralement à un déploiement, mais il existe d'autres types de charges de travail, tels qu'un objet StatefulSet.