1.5. Différences entre Service Mesh et Istio

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.

Red Hat OpenShift Service Mesh ne prend pas en charge les profils d'installation Istio.

Red Hat OpenShift Service Mesh ne prend pas en charge les mises à niveau canari du maillage de services.

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 devez 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 Container Platform telles que les pods de construction. Pour activer l'injection automatique, spécifiez l'étiquette sidecar.istio.io/inject, ou l'annotation, comme décrit dans la section Automatic sidecar injection.

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: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-usernamepolicy
spec:
  action: ALLOW
  rules:
    - when:
        - key: 'request.regex.headers[username]'
          values:
            - "allowed.*"
  selector:
    matchLabels:
      app: httpbin

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 ne prend pas en charge les charges de travail externes, telles que les machines virtuelles exécutées en dehors d'OpenShift sur des serveurs bare metal.

Vous pouvez déployer des machines virtuelles sur OpenShift en utilisant OpenShift Virtualization. Ensuite, vous pouvez appliquer une politique de maillage, telle que mTLS ou AuthorizationPolicy, à ces machines virtuelles, comme n'importe quel autre pod faisant partie d'un maillage.

Red Hat OpenShift Service Mesh ne prend pas en charge la configuration EnvoyFilter, sauf lorsqu'elle est explicitement documentée. En raison du couplage étroit avec les API Envoy sous-jacentes, la compatibilité ascendante ne peut pas être maintenue. Les correctifs EnvoyFilter sont très sensibles au format de la configuration Envoy qui est générée par Istio. Si la configuration générée par Istio change, il est possible que l'application du correctif EnvoyFilter soit interrompue.

Red Hat OpenShift Service Mesh ne prend pas en charge les services basés sur QUIC.

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.

Red Hat OpenShift Service Mesh crée une ressource PeerAuthentication qui active ou désactive l'authentification mutuelle TLS (mTLS) au sein du maillage.

Red Hat OpenShift Service Mesh installe des passerelles d'entrée et de sortie par défaut. Vous pouvez désactiver l'installation des passerelles dans la ressource ServiceMeshControlPlane (SMCP) en utilisant les paramètres suivants :

La prise en charge de Red Hat OpenShift Service Mesh pour les configurations multicluster est limitée à la fédération de maillages de services sur plusieurs clusters.

Vous ne pouvez pas configurer Red Hat OpenShift Service Mesh pour traiter les CSR via l'autorité de certification (CA) de Kubernetes.

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.

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.