2.3. Différences entre Service Mesh et Istio

La principale différence entre une installation multitenant et une installation à l'échelle d'un cluster est l'étendue des privilèges utilisés par istod. Les composants n'utilisent plus les ressources du contrôle d'accès basé sur les rôles (RBAC) à l'échelle du cluster ClusterRoleBinding.

Chaque projet de la liste ServiceMeshMemberRoll members aura un RoleBinding pour chaque compte de service associé au déploiement du plan de contrôle et chaque déploiement du plan de contrôle ne surveillera que ces projets membres. Chaque projet membre se voit ajouter une étiquette maistra.io/member-of, où la valeur member-of correspond au projet contenant l'installation du plan de contrôle.

Red Hat OpenShift Service Mesh configure chaque projet membre pour assurer l'accès au réseau entre lui-même, le plan de contrôle et les autres projets membres. La configuration exacte diffère en fonction de la façon dont le réseau défini par logiciel (SDN) de OpenShift Container Platform est configuré. Voir À propos d'OpenShift SDN pour plus de détails.

Si le cluster OpenShift Container Platform est configuré pour utiliser le plugin SDN :

Upstream Istio dispose de deux ressources de type " cluster scoped " sur lesquelles il s'appuie. Les ressources MeshPolicy et ClusterRbacConfig ne sont pas compatibles avec un cluster multitenant et ont été remplacées comme décrit ci-dessous.

L'outil de ligne de commande pour Red Hat OpenShift Service Mesh est oc. Red Hat OpenShift Service Mesh ne prend pas en charge istioctl.

L'installation de la communauté Istio en amont injecte automatiquement le sidecar dans les pods des projets que vous avez étiquetés.

Red Hat OpenShift Service Mesh n'injecte pas automatiquement le sidecar dans les pods, mais vous demande d'opter pour l'injection à l'aide d'une annotation sans étiqueter les projets. Cette méthode nécessite moins de privilèges et n'entre pas en conflit avec d'autres capacités d'OpenShift telles que les pods de construction. Pour activer l'injection automatique, vous devez spécifier l'annotation sidecar.istio.io/inject comme décrit dans la section Injection automatique du sidecar.

Le contrôle d'accès basé sur les rôles (RBAC) d'Istio fournit un mécanisme que vous pouvez utiliser pour contrôler l'accès à un service. Vous pouvez identifier les sujets par nom d'utilisateur ou en spécifiant un ensemble de propriétés et appliquer les contrôles d'accès en conséquence.

L'installation de la communauté Istio en amont inclut des options pour effectuer des correspondances exactes d'en-tête, des correspondances de caractères génériques dans les en-têtes, ou pour vérifier un en-tête contenant un préfixe ou un suffixe spécifique.

Red Hat OpenShift Service Mesh étend la capacité de faire correspondre les en-têtes de requête en utilisant une expression régulière. Spécifiez une clé de propriété de request.regex.headers avec une expression régulière.

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin-client-binding
  namespace: httpbin
spec:
  subjects:
  - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    properties:
      request.headers[<header>]: "value"

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin-client-binding
  namespace: httpbin
spec:
  subjects:
  - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    properties:
      request.regex.headers[<header>]: "<regular expression>"

Red Hat OpenShift Service Mesh remplace BoringSSL par OpenSSL. OpenSSL est une bibliothèque logicielle qui contient une implémentation open source des protocoles Secure Sockets Layer (SSL) et Transport Layer Security (TLS). Le binaire Red Hat OpenShift Service Mesh Proxy lie dynamiquement les bibliothèques OpenSSL (libssl et libcrypto) à partir du système d'exploitation Red Hat Enterprise Linux sous-jacent.

Red Hat OpenShift Service Mesh inclut le plugin CNI, qui vous offre une autre façon de configurer la mise en réseau des pods d'application. Le plugin CNI remplace la configuration du réseau init-container, ce qui élimine la nécessité d'accorder aux comptes de service et aux projets l'accès aux contraintes de contexte de sécurité (SCC) avec des privilèges élevés.

Les routes OpenShift pour les passerelles Istio sont automatiquement gérées dans Red Hat OpenShift Service Mesh. Chaque fois qu'une passerelle Istio est créée, mise à jour ou supprimée dans le service mesh, une route OpenShift est créée, mise à jour ou supprimée.

Un composant du plan de contrôle de Red Hat OpenShift Service Mesh appelé Istio OpenShift Routing (IOR) synchronise l'itinéraire de la passerelle. Pour plus d'informations, voir Création automatique d'itinéraires.