Vous consultez la documentation d'Anthos Service Mesh 1.6. Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

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.

A

Anthos Workload Identity
un tuple de trust domain, namespace et service account. Il dispose d'un format d'identité SPIFFE spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount> dans les certificats x509 de charge de travail Anthos. Pour les autres types d'identifiants (par exemple, tokens OIDC), le format peut varier.

C

Service canonique
Libellé appliqué aux charges de travail dans Anthos Service Mesh qui vous permet de regrouper une ou plusieurs charges de travail en tant que service logique dans le maillage de services. Une charge de travail appartient à un seul service canonique, alors qu'elle peut appartenir à plusieurs services Kubernetes. Un service canonique est identifié par un nom et un espace de noms, et peut être divisé en une ou plusieurs révisions canoniques.
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 : 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 du parc, 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

Passerelle d'entrée

Une passerelle d'entrée représente un équilibreur de charge pour gérer le trafic entrant provenant de l'extérieur du maillage. Vous utilisez des ressources de Passerelle Istio pour configurer l'équilibreur de charge, et vous créez des services virtuels et des règles d'authentification pour contrôler la manière dont le trafic entrant est sécurisé et acheminé vers vos charges de travail.

istiod

istiod (le "d" est pour "daemon") 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 intégré au cluster. Pour plus d'informations, consultez la page Activer les fonctionnalités facultatives.

M

Groupe d'instances géré (MIG)
Permet d'exploiter des applications sur plusieurs VM identiques, à commencer par une taille de groupe d'instances géré minimale d'une VM. Vous pouvez rendre vos charges de travail évolutives et hautement disponibles en tirant parti des services de MIG automatisés, comme l'autoscaling, l'autoréparation, le déploiement régional (multizone) et la mise à jour automatique. Pour en savoir plus, consultez la section Groupes d'instances gérés (MIG).
Mesh CA
Nom de l'autorité de certification gérée par Google qui gère les certificats mTLS. L'autorité de certification Mesh est installée par défaut lorsque vous installez Anthos Service Mesh.
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.

O

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é au plan de contrôle. Pour activer l'injection side-car automatique, ajoutez le libellé de révision à vos espaces de noms, puis redémarrez vos pods. Le libellé de révision associe les pods d'un espace de noms à une révision particulière du plan de contrôle.
mise à niveau basée sur la révision
Les migrations depuis OSS Istio et les mises à niveau suivent le processus de mise à niveau basé sur la révision (processus appelé "mises à niveau Canary" dans la documentation d'Istio). Avec une mise à niveau basée sur la révision, la nouvelle révision du plan de contrôle est installée en parallèle du plan de contrôle existant. Vous déplacez ensuite certaines de vos charges de travail vers la nouvelle révision, ce qui vous permet de surveiller l'effet de la mise à niveau avec un faible pourcentage des charges de travail avant de migrer tout le trafic vers la nouvelle révision.

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 un 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. Il est basé sur le pool de charges de travail du cluster.

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. La plate-forme peut être un cluster Kubernetes, une machine virtuelle ou un autre environnement tel qu'Anthos sur 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 que StatefulSet.
WorkloadEntry
vous permet de décrire les points de terminaison non-Kubernetes qui ne doivent pas faire partie du maillage, et de les traiter de la même manière qu'un pod Kubernetes. Dans notre cas, chaque VM est enregistrée en tant que WorkloadEntry dans le maillage. Pour en savoir plus, consultez la page https://istio.io/latest/blog/2020/workload-entry/
.
WorkloadGroup
décrit un ensemble d'instances de charge de travail. Voir WorkloadGroup.
Pool Workload Identity
Limite de confiance, également appelée domaine de confiance d'un maillage de services Anthos Service Mesh.