1.4. Modèles de déploiement du maillage de services
Red Hat OpenShift Service Mesh prend en charge plusieurs modèles de déploiement différents qui peuvent être combinés de différentes manières pour répondre au mieux aux exigences de votre entreprise.
1.4.1. Modèle de déploiement à une seule maille
Le modèle de déploiement Istio le plus simple est un maillage unique.
Les noms de service au sein d'un maillage doivent être uniques car Kubernetes n'autorise qu'un seul service à être nommé myservice dans l'espace de noms mynamespace. Cependant, les instances de charge de travail peuvent partager une identité commune puisque les noms de compte de service peuvent être partagés entre les charges de travail dans le même espace de noms
1.4.2. Modèle de déploiement en mode "single tenancy
Dans Istio, un locataire est un groupe d'utilisateurs qui partagent un accès et des privilèges communs pour un ensemble de charges de travail déployées. Vous pouvez utiliser les locataires pour fournir un niveau d'isolation entre différentes équipes. Vous pouvez séparer l'accès aux différents locataires en utilisant les annotations NetworkPolicies, AuthorizationPolicies, et exportTo sur istio.io ou les ressources de service.
Les configurations de plan de contrôle Service Mesh à un seul locataire et à l'échelle d'un cluster sont obsolètes à partir de la version 1.0 de Red Hat OpenShift Service Mesh. Red Hat OpenShift Service Mesh utilise par défaut un modèle multilocataire.
1.4.3. Modèle de déploiement multilocataire
Red Hat OpenShift Service Mesh installe un site ServiceMeshControlPlane qui est configuré pour le multitenant par défaut. Red Hat OpenShift Service Mesh utilise un opérateur multitenant pour gérer le cycle de vie du plan de contrôle de Service Mesh. Au sein d'un maillage, les espaces de noms sont utilisés pour la location.
Red Hat OpenShift Service Mesh utilise les ressources ServiceMeshControlPlane pour gérer les installations de maillage, dont la portée est limitée par défaut à l'espace de noms qui contient la ressource. Vous utilisez les ressources ServiceMeshMemberRoll et ServiceMeshMember pour inclure des espaces de noms supplémentaires dans le maillage. Un espace de noms ne peut être inclus que dans un seul maillage, et plusieurs maillages peuvent être installés dans un seul cluster OpenShift.
Les déploiements typiques de service mesh utilisent un seul plan de contrôle Service Mesh pour configurer la communication entre les services dans le maillage. Red Hat OpenShift Service Mesh prend en charge le "soft multitenancy", où il y a un plan de contrôle et un maillage par locataire, et il peut y avoir plusieurs plans de contrôle indépendants au sein du cluster. Les déploiements multitenant spécifient les projets qui peuvent accéder au Service Mesh et isolent le Service Mesh des autres instances de plan de contrôle.
L'administrateur du cluster a le contrôle et la visibilité sur tous les plans de contrôle Istio, tandis que l'administrateur du locataire n'a le contrôle que sur ses instances Service Mesh, Kiali et Jaeger.
Vous pouvez autoriser une équipe à déployer ses charges de travail uniquement dans un espace de noms donné ou dans un ensemble d'espaces de noms. Si l'administrateur du maillage de services leur accorde le rôle mesh-user, les utilisateurs peuvent créer une ressource ServiceMeshMember pour ajouter des espaces de noms à l'espace de noms ServiceMeshMemberRoll.
1.4.4. Modèle de déploiement multi-méthodes ou fédéré
Federation est un modèle de déploiement qui vous permet de partager des services et des charges de travail entre des mailles séparées gérées dans des domaines administratifs distincts.
Le modèle multi-cluster d'Istio nécessite un niveau élevé de confiance entre les mailles et un accès à distance à tous les serveurs API Kubernetes sur lesquels résident les mailles individuelles. La fédération Red Hat OpenShift Service Mesh adopte une approche fondée sur l'opinion pour une mise en œuvre multi-clusters de Service Mesh qui suppose minimal la confiance entre les mailles.
Un site federated mesh est un groupe de mailles se comportant comme une seule maille. Les services de chaque maille peuvent être des services uniques, par exemple une maille ajoutant des services en les important d'une autre maille, peut fournir des charges de travail supplémentaires pour les mêmes services à travers les mailles, fournissant une haute disponibilité, ou une combinaison des deux. Toutes les mailles qui sont jointes à une maille fédérée restent gérées individuellement, et vous devez configurer explicitement les services qui sont exportés et importés depuis d'autres mailles de la fédération. Les fonctions de support telles que la génération de certificats, les métriques et la collecte de traces restent locales dans leurs mailles respectives.
