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

migration dans un cluster canary
La migration dans un cluster Canary est une stratégie de migration courante, utilisée pour migrer d'Istio vers Anthos Service Mesh, dans laquelle vous activez Anthos Service Mesh sur un nouveau cluster distinct. La stratégie de migration dans un cluster Canary est décrite dans le tutoriel Effectuer une migration depuis Istio 1.11 ou une version ultérieure vers Anthos Service Mesh géré. La migration dans un cluster Canary peut également être utilisée lors de la migration d'Anthos Service Mesh intégré au cluster vers Anthos Service Mesh géré. L'autre stratégie de migration courante est la migration à base de plan de contrôle Canary.
Migration à base de plan de contrôle Canary
La migration à base de plan de contrôle Canary est une stratégie de migration courante, utilisée pour migrer d'Istio vers Anthos Service Mesh, dans laquelle Anthos Service Mesh est activé sur le cluster existant, sur lequel Istio est installé. La migration consiste à renommer les espaces de noms de sorte que le plan de données utilise Anthos Service Mesh. La migration dans un cluster Canary peut également être utilisée lors de la migration d'Anthos Service Mesh intégré au cluster vers Anthos Service Mesh géré. L'autre stratégie de migration courante est la migration dans un cluster Canary.
Mise à niveau Canary
Consultez la section Mise à niveau basée sur la révision.
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 service qui configure le maillage ou un sous-ensemble du maillage pour gérer la communication entre les instances de charge de travail. Anthos Service Mesh 1.9 et versions ultérieures fournissent deux plans de contrôle:

  • Plan de contrôle géré : 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é. Anthos Service Mesh géré se compose du plan de contrôle géré et du plan de données géré facultatif.

  • 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. Le service Anthos Service Mesh géré fournit un plan de données géré.

E

Passerelle de sortie
Une passerelle de sortie est un proxy Envoy qui vous permet de configurer un nœud de sortie dédié au trafic quittant le réseau maillé. Vous utilisez la ressource personnalisée de Passerelle pour configurer le proxy. Une passerelle de sortie vous permet de limiter les services pouvant ou non accéder aux réseaux externes. Pour en savoir plus, consultez la section Installer et mettre à niveau des passerelles.

F

parc
Un parc vous permet d'organiser les clusters pour faciliter la gestion multicluster. L'enregistrement de vos clusters dans un parc simplifie la gestion d'un maillage multicluster en introduisant le concept d'uniformité pour l'identité, les espaces de noms et les services. Si vous disposez de clusters dans différents projets, vous devez les enregistrer auprès du projet hôte du parc plutôt que dans le projet dans lequel le cluster a été créé. Pour en savoir plus sur les parcs, consultez la section Présentation des parcs.

H

Fichiers manifestes hydratés
Fichiers manifestes prêts à être déployés dans la cible. Pour hydrater un fichier manifeste, vous utilisez généralement un outil tel que Helm, Kustomize ou kpt pour définir les valeurs des variables dans le fichier manifeste.

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 est un proxy Envoy qui fonctionne comme un équilibreur de charge pour gérer le trafic entrant acheminé depuis l'extérieur du réseau maillé. Vous utilisez la ressource personnalisée de Passerelle 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. Pour en savoir plus, consultez la section Installer et mettre à niveau des passerelles.

Injection

L'injection, ou injection automatique, fait référence à l'utilisation de webhooks en mutation pour modifier les spécifications des pods au moment de leur création. Vous utilisez l'injection pour ajouter la configuration du proxy side-car Envoy pour vos services de réseau maillé ou pour configurer le proxy Envoy des passerelles.

Mise à niveau sur place

Une mise à niveau sur place remplace le plan de contrôle existant par une nouvelle révision. Nous vous recommandons d'utiliser les mises à niveau basées sur la révision.

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).
Fichier manifeste

Objet de configuration Kubernetes utilisé pour créer, modifier et supprimer des ressources Kubernetes telles que des pods, des déploiements, des services ou des entrées. Dans la documentation d'Anthos Service Mesh, le fichier manifeste que vous utilisez pour configurer le plan de contrôle est appelé fichier superposé.

Les fichiers manifestes existent dans l'un des deux états suivants : rendu (également appelé hydraté) ou non rendu. Un fichier manifeste non rendu n'est pas prêt pour le déploiement dans une cible. Le processus de rendu, qui inclut le remplissage de valeurs spécifiques dans le fichier manifeste, est souvent effectué à l'aide d'outils tels que Helm, Kustomize et kpt.

Mesh CA

Nom de l'autorité de certification gérée qui gère les certificats mTLS. Mesh CA est activé par défaut lorsque vous installez Anthos Service Mesh sur des clusters GKE sur Google Cloud. Vous pouvez éventuellement l'activer lorsque vous installez Anthos Service Mesh 1.10 ou une version ultérieure sur GKE sur VMware ou une solution Bare Metal. Pour en savoir plus, consultez la section Présentation de la sécurité.

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 au sein du cluster. Vous pouvez ignorer la configuration par défaut du plan de contrôle et activer des fonctionnalités facultatives compatibles dans un fichier YAML que vous transmettez à asmcli install. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes. Consultez la section Activer des 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 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. 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 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.
Workload Identity
un tuple de trust domain, namespace et service account. Son format d'identité SPIFFE est spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount> pour les certificats x509 de charge de travail. Pour les autres types d'identifiants (par exemple, (jetons OIDC), le format peut varier.
Pool Workload Identity
Limite de confiance, également appelée domaine de confiance d'un maillage de services Anthos Service Mesh.