Service Mesh

• Ajout d'une option à l'outil de collecte de données must-gather qui recueille des informations à partir d'un espace de noms de plan de contrôle Service Mesh spécifié. Pour plus d'informations, voir OSSM-351.
• Amélioration des performances pour les plans de contrôle Service Mesh comportant des centaines d'espaces de noms

• Simplifie l'installation, les mises à jour et la gestion du plan de contrôle Service Mesh.
• Réduit l'utilisation des ressources et le temps de démarrage du plan de contrôle du Service Mesh.

• Améliore les performances en réduisant la communication entre les plans de contrôle sur le réseau.

  • Ajout de la prise en charge du Secret Discovery Service (SDS) d'Envoy. Le SDS est un mécanisme plus sûr et plus efficace pour délivrer des secrets aux mandataires Envoy side car.
• Supprime la nécessité d'utiliser les Secrets Kubernetes, qui présentent des risques de sécurité bien connus.

• Amélioration des performances lors de la rotation des certificats, les proxys n'ayant plus besoin d'être redémarrés pour reconnaître les nouveaux certificats.

  • Ajout de la prise en charge de l'architecture Telemetry v2 d'Istio, qui est construite à l'aide d'extensions WebAssembly. Cette nouvelle architecture apporte des améliorations significatives en termes de performances.
  • Mise à jour de la ressource ServiceMeshControlPlane en v2 avec une configuration simplifiée pour faciliter la gestion du Service Mesh Control Plane.
  • Introduction des extensions WebAssembly en tant que fonctionnalité de l'aperçu technologique.

• ECDHE-ECDSA-AES128-SHA
• ECDHE-RSA-AES128-SHA
• AES128-GCM-SHA256
• AES128-SHA
• ECDHE-ECDSA-AES256-SHA
• ECDHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA

• Policy (authentication.istio.io/v1alpha1) n'est plus pris en charge. En fonction de la configuration spécifique de votre ressource Policy, vous devrez peut-être configurer plusieurs ressources pour obtenir le même effet.

  • Utiliser RequestAuthentication (security.istio.io/v1beta1)
  • Utiliser PeerAuthentication (security.istio.io/v1beta1)

• ServiceMeshPolicy (maistra.io/v1) n'est plus supporté.

  • Utilisez RequestAuthentication ou PeerAuthentication, comme indiqué ci-dessus, mais placez-les dans l'espace de noms du plan de contrôle Service Mesh.

• RbacConfig (rbac.istio.io/v1alpha1) n'est plus supporté.

  • Remplacé par AuthorizationPolicy (security.istio.io/v1beta1), qui englobe les comportements de RbacConfig, ServiceRole, et ServiceRoleBinding.

• ServiceMeshRbacConfig (maistra.io/v1) n'est plus supporté.

  • Utiliser AuthorizationPolicy comme ci-dessus, mais le placer dans l'espace de noms du plan de contrôle Service Mesh.
• ServiceRole (rbac.istio.io/v1alpha1) n'est plus supporté.
• ServiceRoleBinding (rbac.istio.io/v1alpha1) n'est plus supporté.
• Dans Kiali, les stratégies login et LDAP sont obsolètes. Une prochaine version introduira l'authentification à l'aide des fournisseurs OpenID.

• OSSM-2221 L'injection de passerelle ne fonctionne pas dans l'espace de noms du plan de contrôle. Si vous utilisez la fonctionnalité d'injection de passerelle pour créer une passerelle au même endroit que le plan de contrôle, l'injection échoue et OpenShift génère ce message :

  Warning Failed 10s kubelet, ocp-wide-vh8fd-worker-vhqm9 Failed to pull image "auto": rpc error: code = Unknown desc = reading manifest latest in docker.io/library/auto: errors

  Pour créer une passerelle dans l'espace de noms du plan de contrôle, utilisez le paramètre gateways dans la spécification SMCP afin de configurer les passerelles d'entrée et de sortie pour le maillage.

• OSSM-2042 Le déploiement du SMCP nommé default échoue. Si vous créez un objet SMCP et que vous définissez son champ de version sur v2.3, le nom de l'objet ne peut pas être default. Si le nom est default, alors le plan de contrôle échoue à se déployer, et OpenShift génère un événement Warning avec le message suivant :

  Error processing component mesh-config: error: [mesh-config/templates/telemetryv2_1.6.yaml: Internal error occurred: failed calling webhook "rev.validation.istio.io": Post "https://istiod-default.istio-system.svc:443/validate?timeout=10s": x509: certificate is valid for istiod.istio-system.svc, istiod-remote.istio-system.svc, istio-pilot.istio-system.svc, not istiod-default.istio-system.svc, mesh-config/templates/enable-mesh-permissive.yaml

• OSSM-1655 Le tableau de bord de Kiali affiche une erreur après l'activation de mTLS dans SMCP.

  Après avoir activé le paramètre spec.security.controlPlane.mtls dans le SMCP, la console Kiali affiche le message d'erreur suivant : No subsets defined.

• OSSM-1505 Ce problème se produit uniquement lors de l'utilisation de la ressource ServiceMeshExtension sur OpenShift Container Platform 4.11. Lorsque vous utilisez ServiceMeshExtension sur OpenShift Container Platform 4.11, la ressource n'est jamais prête. Si vous inspectez le problème en utilisant oc describe ServiceMeshExtension, vous verrez l'erreur suivante : stderr: Error creating mount namespace before pivot: function not implemented.

  Solution : ServiceMeshExtension a été supprimé dans Service Mesh 2.2. Migrez de ServiceMeshExtension vers la ressource WasmPlugin. Pour plus d'informations, voir Migration des ressources ServiceMeshExtension vers WasmPlugin.

• OSSM-1396 Si une ressource passerelle contient le paramètre spec.externalIPs, au lieu d'être recréée lors de la mise à jour de ServiceMeshControlPlane, la passerelle est supprimée et n'est jamais recréée.
• OSSM-1168 Lorsque les ressources de maillage de services sont créées en tant que fichier YAML unique, le sidecar de proxy Envoy n'est pas injecté de manière fiable dans les pods. Lorsque les ressources SMCP, SMMR et Deployment sont créées individuellement, le déploiement fonctionne comme prévu.

• OSSM-1115 Le champ concurrency de l'API spec.proxy ne s'est pas propagé à l'istio-proxy. Le champ concurrency fonctionne lorsqu'il est défini avec ProxyConfig. Le champ concurrency spécifie le nombre de threads de travailleur à exécuter. Si le champ est défini sur 0, le nombre de threads de travailleur disponibles est égal au nombre de cœurs de l'unité centrale. Si le champ n'est pas défini, le nombre de threads travailleurs disponibles est par défaut de 2.

  Dans l'exemple suivant, le champ concurrency est défini comme 0.

  apiVersion: networking.istio.io/v1beta1
  kind: ProxyConfig
  metadata:
    name: mesh-wide-concurrency
    namespace: <istiod-namespace>
  spec:
    concurrency: 0

  Copy to Clipboard Toggle word wrap

• OSSM-1052 Lors de la configuration d'un service ExternalIP pour l'ingressgateway dans le plan de contrôle Service Mesh, le service n'est pas créé. Le schéma du SMCP ne contient pas le paramètre du service.

  Solution : Désactiver la création de la passerelle dans la spécification SMCP et gérer le déploiement de la passerelle entièrement manuellement (y compris le service, le rôle et le RoleBinding).

• OSSM-882 Ceci s'applique à Service Mesh 2.1 et aux versions antérieures. L'espace de noms est dans la liste accessible_namespace mais n'apparaît pas dans l'interface utilisateur de Kiali. Par défaut, Kiali n'affiche pas les espaces de noms commençant par "kube" car ces espaces de noms sont généralement à usage interne et ne font pas partie d'un maillage.

  Par exemple, si vous créez un espace de noms appelé "akube-a" et que vous l'ajoutez à la liste des membres du Service Mesh, l'interface utilisateur de Kiali n'affiche pas l'espace de noms. Pour les motifs d'exclusion définis, le logiciel exclut les espaces de noms qui commencent par le motif ou qui le contiennent.

  Solution : Modifiez le paramètre de la ressource personnalisée de Kiali de manière à ce que le paramètre soit précédé d'un carat (^). Par exemple :

  api:
    namespaces:
      exclude:
      - "^istio-operator"
      - "^kube-.*"
      - "^openshift.*"
      - "^ibm.*"
      - "^kiali-operator"

  Copy to Clipboard Toggle word wrap
• MAISTRA-2692 Avec la suppression de Mixer, les métriques personnalisées qui ont été définies dans Service Mesh 2.0.x ne peuvent pas être utilisées dans 2.1. Les métriques personnalisées peuvent être configurées en utilisant EnvoyFilter. Red Hat n'est pas en mesure de prendre en charge la configuration de EnvoyFilter, sauf lorsqu'elle est explicitement documentée. Ceci est dû à un couplage étroit avec les API sous-jacentes d'Envoy, ce qui signifie que la compatibilité ascendante ne peut pas être maintenue.
• MAISTRA-2648 ServiceMeshExtensions n'est actuellement pas compatible avec les mailles déployées sur les systèmes IBM Z.

• MAISTRA-1959 Migration to 2.0 Le grattage Prometheus (spec.addons.prometheus.scrape défini sur true) ne fonctionne pas lorsque mTLS est activé. De plus, Kiali affiche des données graphiques superflues lorsque mTLS est désactivé.

  Ce problème peut être résolu en excluant le port 15020 de la configuration du proxy, par exemple,

  spec:
    proxy:
      networking:
        trafficControl:
          inbound:
            excludedPorts:
            - 15020

  Copy to Clipboard Toggle word wrap
• MAISTRA-1314 Red Hat OpenShift Service Mesh ne prend pas encore en charge IPv6.
• MAISTRA-453 Si vous créez un nouveau projet et déployez des modules immédiatement, l'injection de sidecar ne se produit pas. L'opérateur ne parvient pas à ajouter le site maistra.io/member-of avant la création des nacelles. Les nacelles doivent donc être supprimées et recréées pour que l'injection de sidecar se produise.
• MAISTRA-158 L'application de plusieurs passerelles référençant le même nom d'hôte entraîne l'arrêt du fonctionnement de toutes les passerelles.

• KIALI-2206 Lorsque vous accédez à la console Kiali pour la première fois, et qu'il n'y a pas de données de navigation mises en cache pour Kiali, le lien "View in Grafana" sur l'onglet Metrics de la page Kiali Service Details redirige vers le mauvais emplacement. La seule façon de rencontrer ce problème est d'accéder à Kiali pour la première fois.
• KIALI-507 Kiali ne supporte pas Internet Explorer 11. Ceci est dû au fait que les frameworks sous-jacents ne supportent pas Internet Explorer. Pour accéder à la console Kiali, utilisez l'une des deux versions les plus récentes des navigateurs Chrome, Edge, Firefox ou Safari.

• Apache Spark n'est pas pris en charge.
• Le déploiement en continu via AMQ/Kafka n'est pas pris en charge sur les systèmes IBM Z et IBM Power.

• OBSDA-220 Dans certains cas, si vous essayez d'extraire une image à l'aide de la collecte de données de traçage distribuées, l'extraction de l'image échoue et un message d'erreur Failed to pull image s'affiche. Il n'y a pas de solution à ce problème.

• TRACING-2057 L'API Kafka a été mise à jour sur v1beta2 pour prendre en charge le Strimzi Kafka Operator 0.23.0. Cependant, cette version de l'API n'est pas prise en charge par AMQ Streams 1.6.3. Si vous avez l'environnement suivant, vos services Jaeger ne seront pas mis à niveau et vous ne pourrez pas créer de nouveaux services Jaeger ou modifier des services Jaeger existants :

  • Canal de l'opérateur Jaeger : 1.17.x stable ou 1.20.x stable

  • Canal de l'opérateur AMQ Streams : amq-streams-1.6.x

    Pour résoudre ce problème, changez le canal d'abonnement de votre opérateur AMQ Streams sur amq-streams-1.7.x ou stable.

• OSSM-3644 Auparavant, la passerelle egress de la fédération recevait la mauvaise mise à jour des points d'extrémité de la passerelle réseau, ce qui entraînait des entrées de points d'extrémité supplémentaires. Maintenant, la passerelle federation-egress a été mise à jour du côté du serveur afin qu'elle reçoive les bons points de terminaison de la passerelle réseau.
• OSSM-3595 Auparavant, le plugin istio-cni échouait parfois sur RHEL parce que SELinux n'autorisait pas l'utilitaire iptables-restore à ouvrir des fichiers dans le répertoire /tmp. Désormais, SELinux transmet iptables-restore via le flux d'entrée stdin au lieu d'un fichier.
• OSSM-3025 Istiod ne parvient parfois pas à se préparer. Parfois, lorsqu'un maillage contenait de nombreux espaces de noms membres, le module Istiod n'était pas prêt en raison d'un blocage au sein d'Istiod. Le blocage est maintenant résolu et le pod démarre comme prévu.
• OSSM-2493 Les nodeSelector et tolerations par défaut dans SMCP ne sont pas transmis à Kiali. Les nodeSelector et tolerations que vous ajoutez à SMCP.spec.runtime.defaults sont maintenant transmis à la ressource Kiali.
• OSSM-2492 Les tolérances par défaut dans le SMCP ne sont pas transmises à Jaeger. Les nodeSelector et tolerations que vous ajoutez à SMCP.spec.runtime.defaults sont maintenant transmis à la ressource Jaeger.
• OSSM-2374 Si vous avez supprimé l'une des ressources ServiceMeshMember, l'opérateur du Service Mesh a supprimé la ressource ServiceMeshMemberRoll. Bien que ce comportement soit attendu lorsque vous supprimez la dernière ressource ServiceMeshMember, l'opérateur ne doit pas supprimer la ressource ServiceMeshMemberRoll si elle contient des membres en plus de celui qui a été supprimé. Ce problème est maintenant résolu et l'opérateur ne supprime le ServiceMeshMemberRoll que lorsque la dernière ressource ServiceMeshMember est supprimée.

• OSSM-2373 Error trying to get OAuth metadata when logging in. Pour récupérer la version du cluster, le compte system:anonymous est utilisé. Avec les ClusterRoles et ClusterRoleBinding intégrés par défaut au cluster, le compte anonyme peut récupérer la version correctement. Si le compte system:anonymous perd ses privilèges pour récupérer la version du cluster, l'authentification OpenShift devient inutilisable.

  Ce problème est résolu par l'utilisation de Kiali SA pour récupérer la version du cluster. Cela permet également d'améliorer la sécurité sur le cluster.

• OSSM-2371 Bien que Kiali soit configuré en "vue seule", un utilisateur peut modifier le niveau de journalisation du proxy via le menu kebab de l'onglet Logs des détails de la charge de travail. Ce problème a été corrigé afin que les options sous "Set Proxy Log Level" soient désactivées lorsque Kiali est configuré en "view-only"
• OSSM-2344 Le redémarrage d'Istiod amène Kiali à inonder CRI-O de demandes de transfert de port. Ce problème se produisait lorsque Kiali ne pouvait pas se connecter à Istiod et que Kiali envoyait simultanément un grand nombre de requêtes à istiod. Kiali limite désormais le nombre de requêtes qu'il envoie à istiod.
• OSSM-2335 En faisant glisser le pointeur de la souris sur le diagramme de dispersion Traces, la console Kiali cessait parfois de répondre en raison des demandes simultanées du backend.

• OSSM-2053 En utilisant Red Hat OpenShift Service Mesh Operator 2.2 ou 2.3, pendant le rapprochement SMCP, le contrôleur SMMR a supprimé les espaces de noms membres de SMMR.status.configuredMembers. Cela a entraîné l'indisponibilité des services dans les espaces de noms membres pendant quelques instants.

  En utilisant Red Hat OpenShift Service Mesh Operator 2.2 ou 2.3, le contrôleur SMMR ne supprime plus les espaces de noms de SMMR.status.configuredMembers. Au lieu de cela, le contrôleur ajoute les espaces de noms à SMMR.status.pendingMembers pour indiquer qu'ils ne sont pas à jour. Pendant la réconciliation, lorsque chaque espace de noms se synchronise avec le SMCP, l'espace de noms est automatiquement supprimé de SMMR.status.pendingMembers.

• OSSM-1962 Utiliser EndpointSlices dans le contrôleur de fédération. Le contrôleur de fédération utilise désormais EndpointSlices, ce qui améliore l'évolutivité et les performances dans les grands déploiements. L'indicateur PILOT_USE_ENDPOINT_SLICE est activé par défaut. La désactivation de cet indicateur empêche l'utilisation des déploiements de fédération.
• OSSM-1668 Un nouveau champ spec.security.jwksResolverCA a été ajouté à la version 2.1 SMCP mais était absent des versions 2.2.0 et 2.2.1. Lors de la mise à niveau d'une version de l'opérateur où ce champ était présent vers une version de l'opérateur où ce champ manquait, le champ .spec.security.jwksResolverCA n'était pas disponible dans la base de données SMCP.
• OSSM-1325 Le pod istiod se bloque et affiche le message d'erreur suivant : fatal error: concurrent map iteration and map write.

• OSSM-1211 La configuration des mailles de services fédérés pour le basculement ne fonctionne pas comme prévu.

  Le journal du pilote Istiod affiche l'erreur suivante : envoy connection [C289] TLS error: 337047686:SSL routines:tls_process_server_certificate:certificate verify failed

• OSSM-1099 La console Kiali affiche le message suivant Sorry, there was a problem. Try a refresh or navigate to a different page.
• OSSM-1074 Les annotations de pods définies dans SMCP ne sont pas injectées dans les pods.
• OSSM-999 Kiali retention n'a pas fonctionné comme prévu. Les heures du calendrier étaient grisées dans le graphique du tableau de bord.
• OSSM-797 Kiali Operator pod génère CreateContainerConfigError lors de l'installation ou de la mise à jour de l'opérateur.
• OSSM-722 Les espaces de noms commençant par kube sont cachés à Kiali.
• OSSM-569 Il n'y a pas de limite de mémoire CPU pour le conteneur Prometheus istio-proxy. Le sidecar Prometheus istio-proxy utilise désormais les limites de ressources définies dans spec.proxy.runtime.container.
• OSSM-535 Prise en charge des validationMessages dans SMCP. Le champ ValidationMessages dans le plan de contrôle de la maille de service peut maintenant être défini sur True. Cela écrit un journal pour l'état des ressources, ce qui peut être utile lors de la résolution des problèmes.
• OSSM-449 VirtualService and Service causes an error "Only unique values for domains are permitted. Duplicate entry of domain."
• OSSM-419 Les espaces de noms avec des noms similaires apparaîtront tous dans la liste des espaces de noms de Kiali, même si les espaces de noms ne sont pas définis dans le rôle de membre du maillage de services.
• OSSM-296 Lors de l'ajout d'une configuration de santé à la ressource personnalisée (CR) de Kiali, celle-ci n'est pas répliquée dans la carte de configuration de Kiali.
• OSSM-291 Dans la console Kiali, sur les pages Applications, Services et Workloads, la fonction "Remove Label from Filters" ne fonctionne pas.
• OSSM-289 Dans la console Kiali, sur les pages de détails des services "istio-ingressgateway" et "jaeger-query", aucune trace n'est affichée. Les traces existent dans Jaeger.
• OSSM-287 Dans la console Kiali, aucune trace n'est affichée sur le service graphique.

• OSSM-285 En essayant d'accéder à la console Kiali, on reçoit le message d'erreur suivant : "Error trying to get OAuth Metadata".

  Solution : Redémarrer le pod Kiali.

• MAISTRA-2735 Les ressources que l'opérateur de Service Mesh supprime lors de la réconciliation du SMCP ont changé dans Red Hat OpenShift Service Mesh version 2.1. Auparavant, l'Opérateur supprimait une ressource avec les étiquettes suivantes :

  • maistra.io/owner
  • app.kubernetes.io/version

  Désormais, l'opérateur ignore les ressources qui n'incluent pas le label app.kubernetes.io/managed-by=maistra-istio-operator. Si vous créez vos propres ressources, vous ne devez pas y ajouter le label app.kubernetes.io/managed-by=maistra-istio-operator.

• MAISTRA-2687 La passerelle de fédération Red Hat OpenShift Service Mesh 2.1 n'envoie pas la chaîne de certificats complète lors de l'utilisation de certificats externes. La passerelle de sortie de la fédération Service Mesh n'envoie que le certificat du client. Étant donné que la passerelle d'entrée de la fédération ne connaît que le certificat racine, elle ne peut pas vérifier le certificat client à moins que vous n'ajoutiez le certificat racine à l'importation de la fédération ConfigMap.
• MAISTRA-2635 Remplacer l'API Kubernetes obsolète. Pour rester compatible avec OpenShift Container Platform 4.8, l'API apiextensions.k8s.io/v1beta1 est obsolète depuis Red Hat OpenShift Service Mesh 2.0.8.
• MAISTRA-2631 La fonctionnalité WASM ne fonctionne pas car podman échoue en raison de l'absence du binaire nsenter. Red Hat OpenShift Service Mesh génère le message d'erreur suivant : Error: error configuring CNI network plugin exec: "nsenter": executable file not found in $PATH. L'image du conteneur contient maintenant nsenter et WASM fonctionne comme prévu.
• MAISTRA-2534 Lorsque istiod tente de récupérer le JWKS pour un émetteur spécifié dans une règle JWT, le service de l'émetteur répond avec un 502. Cela empêchait le conteneur proxy d'être prêt et provoquait l'arrêt des déploiements. La correction du bogue de la communauté a été incluse dans la version 2.0.7 de Service Mesh.

• MAISTRA-2411 Lorsque l'opérateur crée une nouvelle passerelle d'entrée en utilisant spec.gateways.additionaIngress dans ServiceMeshControlPlane, il ne crée pas de NetworkPolicy pour la passerelle d'entrée supplémentaire comme il le fait pour la passerelle d'entrée par défaut. Cela provoque une réponse 503 de la route de la nouvelle passerelle.

  Solution de contournement : Créez manuellement le site NetworkPolicy dans l'espace de noms <istio-system>.

• MAISTRA-2401 CVE-2021-3586 servicemesh-operator : Les ressources NetworkPolicy spécifient incorrectement les ports pour les ressources entrantes. Les ressources NetworkPolicy installées pour Red Hat OpenShift Service Mesh ne spécifiaient pas correctement les ports auxquels il était possible d'accéder. Cela permettait d'accéder à tous les ports de ces ressources à partir de n'importe quel pod. Les politiques de réseau appliquées aux ressources suivantes sont affectées :

  • Cuisine
  • Grafana
  • Istiod
  • Jaeger
  • Kiali
  • Prometheus
  • Injecteur Sidecar
• MAISTRA-2378 Lorsque le cluster est configuré pour utiliser OpenShift SDN avec ovs-multitenant et que le maillage contient un grand nombre d'espaces de noms (200 ), le plugin de mise en réseau d'OpenShift Container Platform est incapable de configurer les espaces de noms rapidement. Service Mesh s'interrompt, ce qui fait que les espaces de noms sont continuellement supprimés du maillage de services, puis réinscrits.
• MAISTRA-2370 Gestion des pierres tombales dans listerInformer. Le code de base du cache mis à jour ne gérait pas les pierres tombales lors de la traduction des événements des caches d'espace de noms vers le cache agrégé, ce qui entraînait une panique dans la routine go.

• MAISTRA-2117 Ajout du montage optionnel ConfigMap à l'opérateur. Le CSV contient maintenant un montage optionnel du volume ConfigMap, qui monte le répertoire smcp-templates ConfigMap s'il existe. Si smcp-templates ConfigMap n'existe pas, le répertoire monté est vide. Lorsque vous créez ConfigMap, le répertoire est rempli avec les entrées de ConfigMap et peut être référencé dans SMCP.spec.profiles. Aucun redémarrage de l'opérateur Service Mesh n'est nécessaire.

  Les clients qui utilisent l'opérateur 2.0 avec un CSV modifié pour monter le ConfigMap smcp-templates peuvent mettre à niveau vers Red Hat OpenShift Service Mesh 2.1. Après la mise à niveau, vous pouvez continuer à utiliser un ConfigMap existant, et les profils qu'il contient, sans modifier le CSV. Les clients qui utilisaient précédemment ConfigMap avec un nom différent devront soit renommer le ConfigMap, soit mettre à jour le CSV après la mise à niveau.

• MAISTRA-2010 AuthorizationPolicy ne prend pas en charge le champ request.regex.headers. Le site validatingwebhook rejette toute AuthorizationPolicy contenant ce champ, et même si vous le désactivez, Pilot essaie de le valider en utilisant le même code, et cela ne fonctionne pas.

• MAISTRA-1979 Migration to 2.0 Le webhook de conversion supprime les champs importants suivants lors de la conversion de SMCP.status de v2 à v1 :

  • conditions
  • composants
  • observéGénération

  • annotations

    La mise à jour de l'opérateur vers la version 2.0 pourrait interrompre les outils clients qui lisent l'état du SMCP en utilisant la version maistra.io/v1 de la ressource.

    Cela signifie également que les colonnes READY et STATUS sont vides lorsque vous exécutez oc get servicemeshcontrolplanes.v1.maistra.io.

• MAISTRA-1947 Technology Preview Les mises à jour de ServiceMeshExtensions ne sont pas appliquées.

  Solution de contournement : Supprimez et recréez le site ServiceMeshExtensions.

• MAISTRA-1983 Migration to 2.0 La mise à jour vers la version 2.0.0 avec un site ServiceMeshControlPlane invalide ne peut pas être facilement réparée. Les éléments non valides de la ressource ServiceMeshControlPlane ont provoqué une erreur irrécupérable. Le correctif permet de récupérer les erreurs. Vous pouvez supprimer la ressource non valide et la remplacer par une nouvelle ou modifier la ressource pour corriger les erreurs. Pour plus d'informations sur l'édition de votre ressource, consultez [Configuration de l'installation de Red Hat OpenShift Service Mesh].
• MAISTRA-1502 Suite à la correction des CVEs dans la version 1.0.10, les tableaux de bord Istio ne sont pas disponibles à partir du menu Home Dashboard dans Grafana. Pour accéder aux tableaux de bord Istio, cliquez sur le menu Dashboard dans le panneau de navigation et sélectionnez l'onglet Manage.
• MAISTRA-1399 Red Hat OpenShift Service Mesh ne vous empêche plus d'installer des protocoles CNI non pris en charge. Les configurations réseau prises en charge n'ont pas changé.
• MAISTRA-1089 Migration to 2.0 Les passerelles créées dans un espace de noms qui n'est pas un plan de contrôle sont automatiquement supprimées. Après avoir supprimé la définition de la passerelle de la spécification SMCP, vous devez supprimer manuellement ces ressources.

• MAISTRA-858 Les messages de journal Envoy suivants décrivant les options et configurations obsolètes associées à Istio 1.1.x sont attendus :

  • [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] Utilisation de l'option obsolète 'envoy.api.v2.listener.Filter.config'. Cette configuration sera bientôt supprimée d'Envoy.
  • [2019-08-12 22:12:59.001][13][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Utilisation de l'option obsolète 'envoy.api.v2.Listener.use_original_dst' du fichier lds.proto. Cette configuration sera bientôt supprimée d'Envoy.

• MAISTRA-806 L'éviction du pod opérateur Istio entraîne le non-déploiement du maillage et de la CNI.

  Solution de contournement : Si le pod istio-operator est expulsé lors du déploiement du volet de contrôle, supprimez le pod istio-operator expulsé.

• MAISTRA-681 Lorsque le plan de contrôle du Service Mesh comporte de nombreux espaces de noms, il peut en résulter des problèmes de performance.
• MAISTRA-193 Des messages d'information inattendus de la console sont visibles lorsque la vérification de l'état de santé est activée pour citadel.
• Bugzilla 1821432 Les contrôles à bascule dans la page de détails des ressources personnalisées d'OpenShift Container Platform ne mettent pas à jour le CR correctement. Les contrôles UI Toggle dans la page Service Mesh Control Plane (SMCP) Overview de la console web d'OpenShift Container Platform mettent parfois à jour le mauvais champ de la ressource. Pour mettre à jour un SMCP, modifiez le contenu YAML directement ou mettez à jour la ressource à partir de la ligne de commande au lieu de cliquer sur les contrôles à bascule.

• OSSM-1910 En raison d'un problème introduit dans la version 2.6, les connexions TLS ne pouvaient pas être établies avec OpenShift Container Platform Service Mesh. Cette mise à jour résout le problème en changeant les noms des ports de service pour qu'ils correspondent aux conventions utilisées par OpenShift Container Platform Service Mesh et Istio.
• OBSDA-208 Avant cette mise à jour, les limites de ressources par défaut de 200 m de CPU et 256 m de mémoire pouvaient entraîner un redémarrage continu de la collecte des données de traçage distribué sur les grands clusters. Cette mise à jour résout le problème en supprimant ces limites de ressources.
• OBSDA-222 Avant cette mise à jour, des spans pouvaient être abandonnés dans la plateforme de traçage distribuée OpenShift Container Platform. Pour aider à prévenir ce problème, cette version met à jour les dépendances de version.

• TRACING-2337 Jaeger enregistre un message d'avertissement répétitif dans les journaux de Jaeger, similaire à ce qui suit :

  {"level":"warn","ts":1642438880.918793,"caller":"channelz/logging.go:62","msg":"[core]grpc: Server.Serve failed to create ServerTransport: connection error: desc = \"transport: http2Server.HandleStreams received bogus greeting from client: \\\"\\\\x16\\\\x03\\\\x01\\\\x02\\\\x00\\\\x01\\\\x00\\\\x01\\\\xfc\\\\x03\\\\x03vw\\\\x1a\\\\xc9T\\\\xe7\\\\xdaCj\\\\xb7\\\\x8dK\\\\xa6\\\"\"","system":"grpc","grpc_log":true}

  Copy to Clipboard Toggle word wrap

  Ce problème a été résolu en exposant uniquement le port HTTP(S) du service de requête, et non le port gRPC.

• TRACING-2009 L'opérateur Jaeger a été mis à jour pour inclure le support de l'opérateur Strimzi Kafka 0.23.0.
• TRACING-1907 L'injection du sidecar de l'agent Jaeger échouait en raison de l'absence de cartes de configuration dans l'espace de noms de l'application. Les cartes de configuration étaient automatiquement supprimées en raison d'un paramètre de champ OwnerReference incorrect et, par conséquent, les pods d'application ne dépassaient pas l'étape "ContainerCreating". Les paramètres incorrects ont été supprimés.
• TRACING-1725 Suivi de TRACING-1631. Correction supplémentaire pour s'assurer que les certificats Elasticsearch sont correctement réconciliés lorsqu'il y a plusieurs instances de production Jaeger, utilisant le même nom mais dans des espaces de noms différents. Voir aussi BZ-1918920.
• TRACING-1631 Plusieurs instances de production Jaeger, utilisant le même nom mais dans des espaces de noms différents, causant un problème de certificat Elasticsearch. Lorsque plusieurs maillages de services étaient installés, toutes les instances Elasticsearch de Jaeger avaient le même secret Elasticsearch au lieu de secrets individuels, ce qui empêchait l'opérateur Elasticsearch d'OpenShift de communiquer avec tous les clusters Elasticsearch.
• TRACING-1300 Échec de la connexion entre l'agent et le collecteur lors de l'utilisation d'Istio sidecar. Une mise à jour de l'opérateur Jaeger a activé la communication TLS par défaut entre un agent Jaeger sidecar et le collecteur Jaeger.
• TRACING-1208 Authentification "500 Internal Error" lors de l'accès à l'interface utilisateur de Jaeger. Lorsque j'essaie de m'authentifier à l'interface utilisateur en utilisant OAuth, j'obtiens une erreur 500 parce que le sidecar oauth-proxy ne fait pas confiance à l'ensemble d'autorités de certification personnalisées défini lors de l'installation avec l'adresse additionalTrustBundle.
• TRACING-1166 Il n'est actuellement pas possible d'utiliser la stratégie de streaming Jaeger dans un environnement déconnecté. Lorsqu'un cluster Kafka est en cours de provisionnement, il en résulte une erreur : Failed to pull image registry.redhat.io/amq7/amq-streams-kafka-24-rhel7@sha256:f9ceca004f1b7dccb3b82d9a8027961f9fe4104e0ed69752c0bdd8078b4a1076.
• TRACING-809 Jaeger Ingester est incompatible avec Kafka 2.3. Lorsqu'il y a deux ou plusieurs instances de Jaeger Ingester et un trafic suffisant, il génère continuellement des messages de rééquilibrage dans les journaux. Ceci est dû à une régression dans Kafka 2.3 qui a été corrigée dans Kafka 2.3.1. Pour plus d'informations, voir Jaegertracing-1819.

• BZ-1918920/LOG-1619 Les pods Elasticsearch ne sont pas redémarrés automatiquement après une mise à jour.

  Solution : Redémarrer les pods manuellement.

• Kiali application (back end) - Ce composant s'exécute dans la plateforme d'application conteneurisée et communique avec les composants du maillage de services, récupère et traite les données, et expose ces données à la console. L'application Kiali n'a pas besoin de stockage. Lors du déploiement de l'application sur un cluster, les configurations sont définies dans des ConfigMaps et des secrets.
• Kiali console (front end) - La console Kiali est une application web. L'application Kiali sert la console Kiali, qui interroge ensuite le back-end pour obtenir des données et les présenter à l'utilisateur.

• Red Hat Service Mesh (Istio) - Istio est une exigence de Kiali. Istio est le composant qui fournit et contrôle le maillage de services. Bien que Kiali et Istio puissent être installés séparément, Kiali dépend d'Istio et ne fonctionnera pas s'il n'est pas présent. Kiali doit récupérer les données et les configurations d'Istio, qui sont exposées via Prometheus et l'API du cluster.
• Prometheus - Une instance Prometheus dédiée est incluse dans l'installation de Red Hat OpenShift Service Mesh. Lorsque la télémétrie Istio est activée, les données de métriques sont stockées dans Prometheus. Kiali utilise ces données Prometheus pour déterminer la topologie du maillage, afficher les métriques, calculer la santé, montrer les problèmes éventuels, etc. Kiali communique directement avec Prometheus et assume le schéma de données utilisé par Istio Telemetry. Prometheus est une dépendance d'Istio et une dépendance dure pour Kiali, et de nombreuses fonctionnalités de Kiali ne fonctionneront pas sans Prometheus.
• Cluster API - Kiali utilise l'API de OpenShift Container Platform (cluster API) pour récupérer et résoudre les configurations de maillage de services. Kiali interroge l'API de cluster pour récupérer, par exemple, les définitions des espaces de noms, des services, des déploiements, des pods et d'autres entités. Kiali effectue également des requêtes pour résoudre les relations entre les différentes entités du cluster. L'API de cluster est également interrogée pour récupérer les configurations Istio comme les services virtuels, les règles de destination, les règles de routage, les passerelles, les quotas, etc.
• Jaeger - Jaeger est optionnel, mais est installé par défaut dans le cadre de l'installation de Red Hat OpenShift Service Mesh. Lorsque vous installez la plateforme de traçage distribué dans le cadre de l'installation par défaut de Red Hat OpenShift Service Mesh, la console Kiali comprend un onglet permettant d'afficher les données de traçage distribué. Notez que les données de traçage ne seront pas disponibles si vous désactivez la fonctionnalité de traçage distribué d'Istio. Notez également que l'utilisateur doit avoir accès à l'espace de noms où le plan de contrôle Service Mesh est installé pour afficher les données de traçage.
• Grafana - Grafana est optionnel, mais est installé par défaut dans le cadre de l'installation de Red Hat OpenShift Service Mesh. Lorsqu'elles sont disponibles, les pages de métriques de Kiali affichent des liens pour diriger l'utilisateur vers la même métrique dans Grafana. Notez que l'utilisateur doit avoir accès à l'espace de noms où le plan de contrôle Service Mesh est installé pour afficher les liens vers le tableau de bord Grafana et visualiser les données Grafana.

• Health - Identifier rapidement les problèmes liés aux applications, aux services ou aux charges de travail.
• Topology - Visualisez la façon dont vos applications, services ou charges de travail communiquent via le graphe Kiali.
• Metrics - Des tableaux de bord prédéfinis vous permettent de visualiser le maillage des services et les performances des applications pour Go, Node.js, Quarkus, Spring Boot, Thorntail et Vert.x. Vous pouvez également créer vos propres tableaux de bord personnalisés. Quarkus, Spring Boot, Thorntail et Vert.x. Vous pouvez également créer vos propres tableaux de bord.
• Tracing - L'intégration avec Jaeger permet de suivre le parcours d'une requête à travers les différents microservices qui composent une application.
• Validations - Effectuer des validations avancées sur les objets Istio les plus courants (règles de destination, entrées de service, services virtuels, etc.)
• Configuration - Possibilité optionnelle de créer, mettre à jour et supprimer la configuration du routage Istio en utilisant des assistants ou directement dans l'éditeur YAML de la console Kiali.

• Contrôler les transactions distribuées
• Optimiser les performances et la latence
• Effectuer une analyse des causes profondes

• Red Hat OpenShift distributed tracing platform - Ce composant est basé sur le projet open source Jaeger.
• Red Hat OpenShift distributed tracing data collection - Ce composant est basé sur le projet open source OpenTelemetry.

• Red Hat OpenShift distributed tracing platform - Ce composant est basé sur le projet open source Jaeger.

  • Client (Client Jaeger, Tracer, Reporter, application instrumentée, bibliothèques clientes) - Les clients de la plateforme de traçage distribué sont des implémentations de l'API OpenTracing spécifiques à chaque langue. Ils peuvent être utilisés pour instrumenter des applications pour le traçage distribué, soit manuellement, soit avec une variété de frameworks open source existants, tels que Camel (Fuse), Spring Boot (RHOAR), MicroProfile (RHOAR/Thorntail), Wildfly (EAP), et bien d'autres, qui sont déjà intégrés à OpenTracing.
  • Agent (Agent Jaeger, file d'attente du serveur, travailleurs du processeur) - L'agent de la plate-forme de traçage distribuée est un démon de réseau qui écoute les données envoyées via le protocole UDP (User Datagram Protocol), qu'il met en lots et envoie au collecteur. L'agent est censé être placé sur le même hôte que l'application instrumentée. Cela se fait généralement en ayant un sidecar dans les environnements de conteneurs tels que Kubernetes.
  • Jaeger Collector (Collecteur, file d'attente, travailleurs) - Comme l'agent Jaeger, le collecteur Jaeger reçoit les travées et les place dans une file d'attente interne en vue de leur traitement. Cela permet au collecteur Jaeger de retourner immédiatement au client/à l'agent au lieu d'attendre que la travée se rende au stockage.
  • Storage (Magasin de données) - Les collecteurs ont besoin d'un backend de stockage persistant. La plateforme de traçage distribuée Red Hat OpenShift dispose d'un mécanisme enfichable pour le stockage de la portée. Notez que pour cette version, le seul stockage pris en charge est Elasticsearch.
  • Query (Service d'interrogation) - L'interrogation est un service qui permet d'extraire des traces du stockage.
  • Ingester (Ingester Service) - Le traçage distribué Red Hat OpenShift peut utiliser Apache Kafka comme tampon entre le collecteur et le stockage Elasticsearch. Ingester est un service qui lit les données de Kafka et les écrit dans le backend de stockage Elasticsearch.
  • Jaeger Console - L'interface utilisateur de la plateforme de traçage distribué Red Hat OpenShift vous permet de visualiser vos données de traçage distribué. Sur la page Recherche, vous pouvez trouver des traces et explorer les détails des portées qui composent une trace individuelle.

• Red Hat OpenShift distributed tracing data collection - Ce composant est basé sur le projet open source OpenTelemetry.

  • OpenTelemetry Collector - Le collecteur OpenTelemetry permet de recevoir, de traiter et d'exporter des données de télémétrie sans tenir compte des fournisseurs. Le collecteur OpenTelemetry prend en charge les formats de données d'observabilité open-source, par exemple Jaeger et Prometheus, en les envoyant à un ou plusieurs back-ends open-source ou commerciaux. Le collecteur est l'emplacement par défaut où les bibliothèques d'instrumentation exportent leurs données de télémétrie.

• Intégration avec Kiali - Lorsque la configuration est correcte, vous pouvez visualiser les données de traçage distribuées à partir de la console Kiali.
• Grande évolutivité - Le back-end de traçage distribué est conçu pour ne pas avoir de point de défaillance unique et pour s'adapter aux besoins de l'entreprise.
• Propagation du contexte distribué - Permet de relier des données provenant de différents composants afin de créer une trace complète de bout en bout.
• Compatibilité ascendante avec Zipkin - Le traçage distribué Red Hat OpenShift possède des API qui lui permettent d'être utilisé comme un remplacement direct de Zipkin, mais Red Hat ne prend pas en charge la compatibilité avec Zipkin dans cette version.

• Une étiquette maistra-version a été ajoutée à toutes les ressources.
• Toutes les ressources Ingress ont été converties en ressources OpenShift Route.
• Grafana, le traçage distribué (Jaeger) et Kiali sont activés par défaut et exposés à travers les routes OpenShift.
• Godebug a été supprimé de tous les modèles
• Les liens istio-multi ServiceAccount et ClusterRoleBinding ont été supprimés, ainsi que le lien istio-reader ClusterRole.

• spec.gateways.enabled=false pour désactiver les passerelles d'entrée et de sortie.
• spec.gateways.ingress.enabled=false pour désactiver les passerelles d'entrée.
• spec.gateways.egress.enabled=false pour désactiver les passerelles de sortie.

• NetworkPolicy: Red Hat OpenShift Service Mesh crée une ressource NetworkPolicy dans chaque projet membre permettant l'entrée de tous les pods depuis les autres membres et le plan de contrôle. Si vous supprimez un membre de Service Mesh, cette ressource NetworkPolicy est supprimée du projet.

  Note

  Cela limite également les entrées aux seuls projets membres. Si vous avez besoin de l'entrée de projets non membres, vous devez créer un site NetworkPolicy pour permettre le passage de ce trafic.

• Multitenant: Red Hat OpenShift Service Mesh joint le NetNamespace de chaque projet membre au NetNamespace du projet du plan de contrôle (l'équivalent de l'exécution de oc adm pod-network join-projects --to control-plane-project member-project). Si vous retirez un membre du Service Mesh, son NetNamespace est isolé du plan de contrôle (l'équivalent de l'exécution de oc adm pod-network isolate-projects member-project).
• Subnet: Aucune configuration supplémentaire n'est effectuée.

• ServiceMeshPolicy remplace MeshPolicy pour la configuration des politiques d'authentification à l'échelle du plan de contrôle. Elle doit être créée dans le même projet que le plan de contrôle.
• ServicemeshRbacConfig remplace ClusterRbacConfig pour la configuration du contrôle d'accès basé sur les rôles à l'échelle du plan de contrôle. Il doit être créé dans le même projet que le plan de contrôle.

• Red Hat OpenShift Container Platform version 4.9 ou ultérieure.
• Red Hat OpenShift Dedicated version 4.
• Azure Red Hat OpenShift (ARO) version 4.
• Red Hat OpenShift Service on AWS (ROSA).

• OpenShift Online n'est pas pris en charge pour Red Hat OpenShift Service Mesh.
• Red Hat OpenShift Service Mesh ne prend pas en charge la gestion des microservices en dehors du cluster où Service Mesh est exécuté.

• OpenShift-SDN
• OVN-Kubernetes est pris en charge sur OpenShift Container Platform 4.7.32 , OpenShift Container Platform 4.8.12 , et OpenShift Container Platform 4.9 .
• Plugins CNI (Container Network Interface) tiers qui ont été certifiés sur OpenShift Container Platform et qui ont passé les tests de conformité Service Mesh. Voir Plugins CNI OpenShift certifiés pour plus d'informations.

• Cette version de Red Hat OpenShift Service Mesh est uniquement disponible sur OpenShift Container Platform x86_64, IBM zSystems et IBM Power.

  • IBM zSystems n'est pris en charge que sur OpenShift Container Platform 4.6 et plus.
  • IBM Power n'est pris en charge que sur OpenShift Container Platform 4.6 et plus.
• Configurations dans lesquelles tous les composants Service Mesh sont contenus dans un seul cluster OpenShift Container Platform.
• Configurations qui n'intègrent pas de services externes tels que des machines virtuelles.
• Red Hat OpenShift Service Mesh ne prend pas en charge la configuration EnvoyFilter, sauf lorsqu'elle est explicitement documentée.

• La console Kiali n'est compatible qu'avec les deux versions les plus récentes des navigateurs Chrome, Edge, Firefox ou Safari.

• L'agent Jaeger en tant que sidecar est la seule configuration supportée pour Jaeger. Jaeger en tant que daemonset n'est pas pris en charge pour les installations multitenant ou OpenShift Dedicated.

• 3scale WebAssembly est le seul module WebAssembly fourni. Vous pouvez créer des modules WebAssembly personnalisés.

• ['**'] (tous les espaces nominatifs)
• default
• codeready-*
• openshift-*
• redhat-*

Conditions préalables

• Un opérateur Red Hat OpenShift Service Mesh installé et vérifié.
• Liste des projets existants à ajouter au maillage des services.

Conditions préalables

• Un opérateur Red Hat OpenShift Service Mesh installé et vérifié.
• Liste des projets à ajouter au maillage des services.
• Accès à la CLI OpenShift (oc).

Conditions préalables

• Un opérateur Red Hat OpenShift Service Mesh installé et vérifié.
• Une ressource existante ServiceMeshMemberRoll.
• Nom du projet contenant la ressource ServiceMeshMemberRoll.
• Noms des projets que vous souhaitez ajouter ou supprimer du maillage.

Conditions préalables

• Un opérateur Red Hat OpenShift Service Mesh installé et vérifié.
• Une ressource existante ServiceMeshMemberRoll.
• Nom du projet contenant la ressource ServiceMeshMemberRoll.
• Noms des projets que vous souhaitez ajouter ou supprimer du maillage.
• Accès à la CLI OpenShift (oc).

Prérequis :

• OpenShift Container Platform 4.1 ou supérieur installé.
• Red Hat OpenShift Service Mesh 2.3.3 installé.
• Accès à la CLI OpenShift (oc).
• Un compte avec le rôle cluster-admin.