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.
I
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.
M
- TLS mutuel
- Anthos Service Mesh utilise le protocole TLS mutuel (mTLS) pour l'authentification et le chiffrement des pairs. mTLS permet aux charges de travail de valider leurs identités respectives et de s'authentifier mutuellement.
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.
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é à
istiodafin 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évisionistiodparticuliè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
- 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.
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.