SupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 2. Service Mesh 1.x

2.1. Service Mesh - Notes de mise à jour

Avertissement

You are viewing documentation for a Red Hat OpenShift Service Mesh release that is no longer supported.

Les plans de contrôle Service Mesh version 1.0 et 1.1 ne sont plus pris en charge. Pour plus d'informations sur la mise à niveau de votre plan de contrôle Service Mesh, voir Mise à niveau de Service Mesh.

Pour plus d'informations sur l'état de l'assistance d'une version particulière de Red Hat OpenShift Service Mesh, consultez la page Cycle de vie du produit.

2.1.1. Rendre l'open source plus inclusif

Red Hat s'engage à remplacer les termes problématiques dans son code, sa documentation et ses propriétés Web. Nous commençons par ces quatre termes : master, slave, blacklist et whitelist. En raison de l'ampleur de cette entreprise, ces changements seront mis en œuvre progressivement au cours de plusieurs versions à venir. Pour plus de détails, voir le message de notre directeur technique Chris Wright.

2.1.2. Introduction à Red Hat OpenShift Service Mesh

Red Hat OpenShift Service Mesh répond à une variété de problèmes dans une architecture de microservices en créant un point de contrôle centralisé dans une application. Il ajoute une couche transparente sur les applications distribuées existantes sans nécessiter de modifications du code de l'application.

Les architectures de microservices divisent le travail des applications d'entreprise en services modulaires, ce qui peut faciliter la mise à l'échelle et la maintenance. Cependant, lorsqu'une application d'entreprise construite sur une architecture de microservices augmente en taille et en complexité, elle devient difficile à comprendre et à gérer. Le Service Mesh peut résoudre ces problèmes d'architecture en capturant ou en interceptant le trafic entre les services et peut modifier, rediriger ou créer de nouvelles requêtes vers d'autres services.

Service Mesh, qui est basé sur le projet open source Istio, permet de créer facilement un réseau de services déployés qui assure la découverte, l'équilibrage de charge, l'authentification de service à service, la reprise sur panne, les mesures et la surveillance. Un maillage de services offre également des fonctionnalités opérationnelles plus complexes, notamment les tests A/B, les versions canary, le contrôle d'accès et l'authentification de bout en bout.

2.1.3. Obtenir de l'aide

Si vous rencontrez des difficultés avec une procédure décrite dans cette documentation, ou avec OpenShift Container Platform en général, visitez le portail client de Red Hat. À partir du portail client, vous pouvez :

  • Recherchez ou parcourez la base de connaissances de Red Hat qui contient des articles et des solutions relatifs aux produits Red Hat.
  • Soumettre un cas d'assistance à Red Hat Support.
  • Accéder à d'autres documents sur les produits.

Pour identifier les problèmes liés à votre cluster, vous pouvez utiliser Insights dans OpenShift Cluster Manager Hybrid Cloud Console. Insights fournit des détails sur les problèmes et, le cas échéant, des informations sur la manière de les résoudre.

Si vous avez une suggestion pour améliorer cette documentation ou si vous avez trouvé une erreur, soumettez un problème Jira pour le composant de documentation le plus pertinent. Veuillez fournir des détails spécifiques, tels que le nom de la section et la version d'OpenShift Container Platform.

Lorsque vous ouvrez un dossier d'assistance, il est utile de fournir des informations de débogage sur votre cluster à l'équipe d'assistance de Red Hat.

L'outil must-gather vous permet de collecter des informations de diagnostic sur votre cluster OpenShift Container Platform, y compris les machines virtuelles et d'autres données liées à Red Hat OpenShift Service Mesh.

Pour une assistance rapide, fournissez des informations de diagnostic pour OpenShift Container Platform et Red Hat OpenShift Service Mesh.

2.1.3.1. À propos de l'outil de collecte obligatoire

La commande CLI oc adm must-gather recueille les informations de votre cluster les plus susceptibles d'être nécessaires au débogage des problèmes, notamment

  • Définitions des ressources
  • Journaux de service

Par défaut, la commande oc adm must-gather utilise l'image du plugin par défaut et écrit dans ./must-gather.local.

Vous pouvez également recueillir des informations spécifiques en exécutant la commande avec les arguments appropriés, comme décrit dans les sections suivantes :

  • Pour collecter des données relatives à une ou plusieurs caractéristiques spécifiques, utilisez l'argument --image avec une image, comme indiqué dans la section suivante.

    Par exemple : 

    $ oc adm must-gather  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.0

  • Pour collecter les journaux d'audit, utilisez l'argument -- /usr/bin/gather_audit_logs, comme décrit dans la section suivante.

    Par exemple : 

    $ oc adm must-gather -- /usr/bin/gather_audit_logs
    Note

    Les journaux d'audit ne sont pas collectés dans le cadre de l'ensemble d'informations par défaut afin de réduire la taille des fichiers.

Lorsque vous exécutez oc adm must-gather, un nouveau module portant un nom aléatoire est créé dans un nouveau projet sur le cluster. Les données sont collectées sur ce module et enregistrées dans un nouveau répertoire commençant par must-gather.local. Ce répertoire est créé dans le répertoire de travail actuel.

Par exemple : 

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
...
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...

2.1.3.2. Conditions préalables

  • Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • L'OpenShift Container Platform CLI (oc) est installé.

2.1.3.3. A propos de la collecte de données sur le maillage des services

Vous pouvez utiliser la commande CLI oc adm must-gather pour collecter des informations sur votre cluster, y compris les fonctionnalités et les objets associés à Red Hat OpenShift Service Mesh.

Conditions préalables

  • Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • L'OpenShift Container Platform CLI (oc) est installé.

Précédent

  1. Pour collecter les données Red Hat OpenShift Service Mesh avec must-gather, vous devez spécifier l'image Red Hat OpenShift Service Mesh. 

    $ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8:2.3

  2. Pour collecter les données Red Hat OpenShift Service Mesh pour un espace de noms de plan de contrôle Service Mesh spécifique avec must-gather, vous devez spécifier l'image Red Hat OpenShift Service Mesh et l'espace de noms. Dans cet exemple, remplacez <namespace> par votre espace de noms de plan de contrôle Service Mesh, tel que istio-system. 

    $ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8:2.3 gather <namespace>

2.1.4. Configurations prises en charge par Red Hat OpenShift Service Mesh

Les configurations suivantes sont les seules prises en charge pour le Red Hat OpenShift Service Mesh :

  • OpenShift Container Platform version 4.6 ou ultérieure.
Note

OpenShift Online et Red Hat OpenShift Dedicated ne sont pas pris en charge pour Red Hat OpenShift Service Mesh.

  • Le déploiement doit être contenu dans un seul cluster OpenShift Container Platform qui n'est pas fédéré.
  • Cette version de Red Hat OpenShift Service Mesh est uniquement disponible sur OpenShift Container Platform x86_64.
  • Cette version ne prend en charge que les configurations dans lesquelles tous les composants Service Mesh sont contenus dans le cluster OpenShift Container Platform dans lequel il fonctionne. Elle ne prend pas en charge la gestion des microservices qui résident en dehors du cluster, ou dans un scénario multi-clusters.
  • Cette version ne prend en charge que les configurations qui n'intègrent pas de services externes tels que des machines virtuelles.

Pour plus d'informations sur le cycle de vie de Red Hat OpenShift Service Mesh et les configurations prises en charge, reportez-vous à la Politique d'assistance.

2.1.4.1. Configurations prises en charge pour Kiali sur Red Hat OpenShift Service Mesh

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

2.1.4.2. Adaptateurs de mélangeur pris en charge

  • Cette version ne prend en charge que l'adaptateur Mixer suivant :

    • adaptateur 3scale Istio

2.1.5. Nouvelles fonctionnalités

Red Hat OpenShift Service Mesh fournit un certain nombre de capacités clés de manière uniforme à travers un réseau de services :

  • Traffic Management - Contrôler le flux de trafic et les appels API entre les services, rendre les appels plus fiables et rendre le réseau plus robuste face à des conditions défavorables.
  • Service Identity and Security - Fournir aux services du réseau maillé une identité vérifiable et offrir la possibilité de protéger le trafic des services lorsqu'il circule sur des réseaux plus ou moins fiables.
  • Policy Enforcement - Appliquer la politique de l'organisation à l'interaction entre les services, veiller à ce que les politiques d'accès soient appliquées et que les ressources soient équitablement réparties entre les consommateurs. Les changements de politique se font en configurant le maillage, et non en modifiant le code de l'application.
  • Telemetry - Comprendre les dépendances entre les services ainsi que la nature et le flux du trafic entre eux, ce qui permet d'identifier rapidement les problèmes.

2.1.5.1. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.18.2

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE).

2.1.5.1.1. Versions de composants incluses dans la version 1.1.18.2 de Red Hat OpenShift Service Mesh
ComposantVersion

Istio

1.4.10

Jaeger

1.30.2

Kiali

1.12.21.1

adaptateur 3scale Istio

1.0.0

2.1.5.2. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.18.1

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE).

2.1.5.2.1. Versions de composants incluses dans Red Hat OpenShift Service Mesh version 1.1.18.1
ComposantVersion

Istio

1.4.10

Jaeger

1.30.2

Kiali

1.12.20.1

adaptateur 3scale Istio

1.0.0

2.1.5.3. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.18

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE).

2.1.5.3.1. Versions de composants incluses dans Red Hat OpenShift Service Mesh version 1.1.18
ComposantVersion

Istio

1.4.10

Jaeger

1.24.0

Kiali

1.12.18

adaptateur 3scale Istio

1.0.0

2.1.5.4. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.17.1

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE).

2.1.5.4.1. Changement dans la façon dont Red Hat OpenShift Service Mesh gère les fragments d'URI

Red Hat OpenShift Service Mesh contient une vulnérabilité exploitable à distance, CVE-2021-39156, où une requête HTTP avec un fragment (une section à la fin d'un URI qui commence par un caractère #) dans le chemin URI pourrait contourner les politiques d'autorisation basées sur le chemin URI d'Istio. Par exemple, une politique d'autorisation d'Istio refuse les requêtes envoyées au chemin URI /user/profile. Dans les versions vulnérables, une requête avec le chemin URI /user/profile#section1 contourne la politique de refus et se dirige vers le backend (avec l'URI normalisé path /user/profile#section1), ce qui peut conduire à un incident de sécurité.

Vous êtes concerné par cette vulnérabilité si vous utilisez des politiques d'autorisation avec des actions DENY et operation.paths, ou des actions ALLOW et operation.notPaths.

Avec l'atténuation, la partie fragmentaire de l'URI de la demande est supprimée avant l'autorisation et l'acheminement. Cela empêche une demande contenant un fragment dans son URI de contourner les politiques d'autorisation qui sont basées sur l'URI sans la partie fragment.

2.1.5.4.2. Mise à jour requise pour les politiques d'autorisation

Istio génère des noms d'hôtes à la fois pour le nom d'hôte lui-même et pour tous les ports correspondants. Par exemple, un service virtuel ou une passerelle pour un hôte de "httpbin.foo" génère une configuration correspondant à "httpbin.foo et httpbin.foo:*". Cependant, les politiques d'autorisation de correspondance exacte ne correspondent qu'à la chaîne exacte donnée pour les champs hosts ou notHosts.

Votre cluster est affecté si vous avez des ressources AuthorizationPolicy utilisant la comparaison de chaînes exactes pour la règle de détermination des hosts ou notHosts.

Vous devez mettre à jour les règles de votre politique d'autorisation pour utiliser la correspondance des préfixes au lieu de la correspondance exacte. Par exemple, en remplaçant hosts: ["httpbin.com"] par hosts: ["httpbin.com:*"] dans le premier exemple AuthorizationPolicy.

Premier exemple de politique d'autorisation utilisant la correspondance des préfixes

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        hosts: [“httpbin.com”,"httpbin.com:*"]

Deuxième exemple de politique d'autorisation utilisant la correspondance des préfixes

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: default
spec:
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["httpbin.example.com:*"]

2.1.5.5. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.17

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.6. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.16

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.7. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.15

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.8. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.14

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

Important

Des étapes manuelles doivent être effectuées pour résoudre les problèmes CVE-2021-29492 et CVE-2021-31920.

2.1.5.8.1. Mises à jour manuelles requises par CVE-2021-29492 et CVE-2021-31920

Istio contient une vulnérabilité exploitable à distance où un chemin de requête HTTP avec plusieurs barres obliques ou des caractères obliques échappés (/` or \`) pourrait potentiellement contourner une politique d'autorisation Istio lorsque des règles d'autorisation basées sur le chemin sont utilisées.

Par exemple, supposons qu'un administrateur de cluster Istio définisse une politique d'autorisation DENY pour rejeter la demande au chemin /admin. Une demande envoyée au chemin URL //admin ne sera PAS rejetée par la politique d'autorisation.

Selon la RFC 3986, le chemin //admin avec plusieurs barres obliques devrait techniquement être traité comme un chemin différent du chemin /admin. Cependant, certains services backend choisissent de normaliser les chemins URL en fusionnant les barres obliques multiples en une seule barre oblique. Cela peut entraîner un contournement de la politique d'autorisation (//admin ne correspond pas à /admin), et un utilisateur peut accéder à la ressource au chemin /admin dans le backend ; cela représenterait un incident de sécurité.

Votre cluster est concerné par cette vulnérabilité si vous avez des politiques d'autorisation qui utilisent les modèles ALLOW action notPaths field ou DENY action paths field. Ces modèles sont vulnérables à des contournements inattendus de la politique.

Votre cluster n'est PAS affecté par cette vulnérabilité si :

  • Vous n'avez pas de politique d'autorisation.
  • Vos politiques d'autorisation ne définissent pas les champs paths ou notPaths.
  • Vos politiques d'autorisation utilisent des modèles de champ ALLOW action paths ou DENY action notPaths. Ces motifs pourraient uniquement entraîner un rejet inattendu au lieu d'un contournement de la politique. La mise à niveau est facultative dans ces cas.
Note

L'emplacement de configuration de Red Hat OpenShift Service Mesh pour la normalisation des chemins est différent de la configuration d'Istio.

2.1.5.8.2. Mise à jour de la configuration de la normalisation des chemins

Les politiques d'autorisation d'Istio peuvent être basées sur les chemins d'URL dans la requête HTTP. La normalisation des chemins, également connue sous le nom de normalisation des URI, modifie et normalise les chemins des requêtes entrantes afin que les chemins normalisés puissent être traités de manière standard. Des chemins syntaxiquement différents peuvent être équivalents après la normalisation du chemin.

Istio prend en charge les schémas de normalisation suivants sur les chemins de requête avant de les évaluer par rapport aux politiques d'autorisation et d'acheminer les requêtes :

Tableau 2.1. Schémas de normalisation
OptionDescriptionExemple :Notes

NONE

Aucune normalisation n'est effectuée. Tout ce qui est reçu par Envoy est transmis tel quel à un service de backend.

..//a../b est évaluée par les politiques d'autorisation et envoyée à votre service.

Ce paramètre est vulnérable à la CVE-2021-31920.

BASE

C'est actuellement l'option utilisée dans l'installation d'Istio sur default. Elle applique l'option normalize_path sur les proxies Envoy, qui suit la RFC 3986 avec une normalisation supplémentaire pour convertir les barres obliques inverses en barres obliques inverses.

/a/../b est normalisé à /b. \da est normalisé à /da.

Ce paramètre est vulnérable à la CVE-2021-31920.

MERGE_SLASHES

Les barres obliques sont fusionnées après la normalisation BASE.

/a//b est normalisé à /a/b.

La mise à jour de ce paramètre permet d'atténuer la CVE-2021-31920.

DECODE_AND_MERGE_SLASHES

Le paramètre le plus strict lorsque vous autorisez tout le trafic par défaut. Ce paramètre est recommandé, à condition que vous testiez minutieusement les itinéraires de vos politiques d'autorisation. Les caractères barre oblique et barre oblique inverse codés en pourcentage (/, /, \ et \) sont décodés en / ou \, avant la normalisation MERGE_SLASHES.

/a/b est normalisé à /a/b.

Mettez à jour ce paramètre pour atténuer la CVE-2021-31920. Ce paramètre est plus sûr, mais il est également susceptible d'endommager les applications. Testez vos applications avant de les déployer en production.

Les algorithmes de normalisation sont exécutés dans l'ordre suivant :

  1. Décodez en pourcentage /, /, \ et \.
  2. La normalisation RFC 3986 et d'autres normalisations implémentées par l'option normalize_path dans Envoy.
  3. Fusionner les barres obliques.
Avertissement

Bien que ces options de normalisation représentent des recommandations issues des normes HTTP et des pratiques industrielles courantes, les applications peuvent interpréter une URL comme elles l'entendent. Lorsque vous utilisez des politiques de déni, assurez-vous de bien comprendre le comportement de votre application.

2.1.5.8.3. Exemples de configuration de la normalisation des chemins

S'assurer qu'Envoy normalise les chemins d'accès aux requêtes pour qu'ils correspondent aux attentes de vos services d'arrière-plan est essentiel pour la sécurité de votre système. Les exemples suivants peuvent vous servir de référence pour configurer votre système. Les chemins d'URL normalisés, ou les chemins d'URL originaux si NONE est sélectionné, seront les suivants :

  1. Utilisé pour vérifier les politiques d'autorisation.
  2. Transmis à l'application dorsale.
Tableau 2.2. Exemples de configuration
Si votre candidature..Choisissez..

S'appuie sur le proxy pour effectuer la normalisation

BASE, MERGE_SLASHES ou DECODE_AND_MERGE_SLASHES

Normalise les chemins d'accès aux requêtes sur la base de la RFC 3986 et ne fusionne pas les barres obliques.

BASE

Normalise les chemins d'accès aux requêtes sur la base de la RFC 3986 et fusionne les barres obliques, mais ne décode pas les barres obliques codées en pourcentage.

MERGE_SLASHES

Normalise les chemins de requête sur la base de la RFC 3986, décode les barres obliques codées en pourcentage et fusionne les barres obliques.

DECODE_AND_MERGE_SLASHES

Traite les chemins de requête d'une manière incompatible avec la RFC 3986.

NONE

2.1.5.8.4. Configuration de votre SMCP pour la normalisation des chemins d'accès

Pour configurer la normalisation des chemins pour Red Hat OpenShift Service Mesh, spécifiez ce qui suit dans votre ServiceMeshControlPlane. Utilisez les exemples de configuration pour vous aider à déterminer les paramètres de votre système.

SMCP v1 pathNormalization

spec:
  global:
    pathNormalization: <option>

2.1.5.9. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.13

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.10. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.12

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.11. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.11

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.12. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.10

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.13. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.9

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.14. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.8

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.15. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.7

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.16. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.6

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.17. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.5

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

Cette version a également ajouté la prise en charge de la configuration des suites de chiffrement.

2.1.5.18. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.4

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

Note

Il y a des étapes manuelles qui doivent être complétées pour traiter CVE-2020-8663.

2.1.5.18.1. Mises à jour manuelles requises par CVE-2020-8663

Le correctif pour CVE-2020-8663: envoy: Resource exhaustion when accepting too many connections a ajouté une limite configurable pour les connexions en aval. L'option de configuration de cette limite doit être configurée pour atténuer cette vulnérabilité.

Important

Ces étapes manuelles sont nécessaires pour atténuer cette CVE, que vous utilisiez la version 1.1 ou la version 1.0 de Red Hat OpenShift Service Mesh.

Cette nouvelle option de configuration s'appelle overload.global_downstream_max_connections et peut être configurée en tant que paramètre de proxy runtime. Effectuez les étapes suivantes pour configurer les limites au niveau de la passerelle d'entrée.

Procédure

  1. Créez un fichier nommé bootstrap-override.json avec le texte suivant pour forcer le proxy à remplacer le modèle de démarrage et à charger la configuration d'exécution à partir du disque : 

      {
    "runtime": {
      "symlink_root": "/var/lib/istio/envoy/runtime"
    }
  }

  2. Créez un secret à partir du fichier bootstrap-override.json, en remplaçant <SMCPnamespace> par l'espace de noms dans lequel vous avez créé le plan de contrôle du maillage de services (SMCP) : 

    $  oc create secret generic -n <SMCPnamespace> gateway-bootstrap --from-file=bootstrap-override.json

  3. Mettez à jour la configuration du SMCP pour activer la dérogation.

    Mise à jour de l'exemple de configuration SMCP n°1

    apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    gateways:
      istio-ingressgateway:
        env:
          ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
        secretVolumes:
        - mountPath: /var/lib/istio/envoy/custom-bootstrap
          name: custom-bootstrap
          secretName: gateway-bootstrap

  4. Pour définir la nouvelle option de configuration, créez un secret ayant la valeur souhaitée pour le paramètre overload.global_downstream_max_connections. L'exemple suivant utilise la valeur 10000: 

    $  oc create secret generic -n <SMCPnamespace> gateway-settings --from-literal=overload.global_downstream_max_connections=10000
  5. Mettez à nouveau à jour le SMCP pour monter le secret à l'endroit où Envoy recherche la configuration d'exécution :

Mise à jour de l'exemple de configuration SMCP n°2

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  template: default
#Change the version to "v1.0" if you are on the 1.0 stream.
  version: v1.1
  istio:
    gateways:
      istio-ingressgateway:
        env:
          ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
        secretVolumes:
        - mountPath: /var/lib/istio/envoy/custom-bootstrap
          name: custom-bootstrap
          secretName: gateway-bootstrap
        # below is the new secret mount
        - mountPath: /var/lib/istio/envoy/runtime
          name: gateway-settings
          secretName: gateway-settings

2.1.5.18.2. Mise à jour d'Elasticsearch 5 vers Elasticsearch 6

Lors de la mise à jour d'Elasticsearch 5 vers Elasticsearch 6, vous devez supprimer votre instance Jaeger, puis recréer l'instance Jaeger en raison d'un problème avec les certificats. La recréation de l'instance Jaeger entraîne la création d'un nouveau jeu de certificats. Si vous utilisez un stockage persistant, les mêmes volumes peuvent être montés pour la nouvelle instance Jaeger tant que le nom Jaeger et l'espace de noms de la nouvelle instance Jaeger sont les mêmes que ceux de l'instance Jaeger supprimée.

Procédure si Jaeger est installé dans le cadre de Red Hat Service Mesh

  1. Déterminez le nom de votre fichier de ressources personnalisées Jaeger : 

    $ oc get jaeger -n istio-system

    Vous devriez voir quelque chose comme ce qui suit : 

    NAME     AGE
jaeger   3d21h

  2. Copiez le fichier de ressources personnalisées généré dans un répertoire temporaire : 

    $ oc get jaeger jaeger -oyaml -n istio-system > /tmp/jaeger-cr.yaml

  3. Supprimer l'instance de Jaeger : 

    $ oc delete jaeger jaeger -n istio-system

  4. Recréez l'instance de Jaeger à partir de votre copie du fichier de ressources personnalisé : 

    $ oc create -f /tmp/jaeger-cr.yaml -n istio-system

  5. Supprimer la copie du fichier de ressources personnalisées généré : 

    $ rm /tmp/jaeger-cr.yaml

Procédure si Jaeger n'est pas installé dans le cadre du Service Mesh de Red Hat

Avant de commencer, créez une copie de votre fichier de ressources personnalisées Jaeger.

  1. Supprimez l'instance de Jaeger en supprimant le fichier de ressources personnalisé : 

    oc delete -f <jaeger-cr-file>

    Par exemple : 

    $ oc delete -f jaeger-prod-elasticsearch.yaml

  2. Recréez votre instance Jaeger à partir de la copie de sauvegarde de votre fichier de ressources personnalisé : 

    oc create -f <jaeger-cr-file>

  3. Validez que vos Pods ont redémarré : 

    $ oc get pods -n jaeger-system -w

2.1.5.19. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.3

Cette version de Red Hat OpenShift Service Mesh traite des vulnérabilités et expositions communes (CVE) et des corrections de bogues.

2.1.5.20. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.2

Cette version de Red Hat OpenShift Service Mesh corrige une vulnérabilité de sécurité.

2.1.5.21. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.1

Cette version de Red Hat OpenShift Service Mesh ajoute la prise en charge d'une installation déconnectée.

2.1.5.22. Nouvelles fonctionnalités Red Hat OpenShift Service Mesh 1.1.0

Cette version de Red Hat OpenShift Service Mesh ajoute la prise en charge d'Istio 1.4.6 et de Jaeger 1.17.1.

2.1.5.22.1. Mises à jour manuelles de 1.0 à 1.1

Si vous mettez à jour Red Hat OpenShift Service Mesh 1.0 vers 1.1, vous devez mettre à jour la ressource ServiceMeshControlPlane pour mettre à jour les composants du plan de contrôle vers la nouvelle version.

  1. Dans la console web, cliquez sur l'opérateur Red Hat OpenShift Service Mesh.
  2. Cliquez sur le menu Project et choisissez dans la liste le projet dans lequel votre ServiceMeshControlPlane est déployé, par exemple istio-system.
  3. Cliquez sur le nom de votre plan de contrôle, par exemple basic-install.
  4. Cliquez sur YAML et ajoutez un champ de version à l'adresse spec: de votre ressource ServiceMeshControlPlane. Par exemple, pour mettre à jour vers Red Hat OpenShift Service Mesh 1.1.0, ajoutez version: v1.1. 
spec:
  version: v1.1
  ...

Le champ "version" indique la version de Service Mesh à installer et prend par défaut la dernière version disponible.

Note

Notez que la prise en charge de Red Hat OpenShift Service Mesh v1.0 a pris fin en octobre 2020. Vous devez effectuer une mise à niveau vers v1.1 ou v2.0.

2.1.6. Fonctionnalités obsolètes

Certaines fonctionnalités disponibles dans les versions précédentes sont devenues obsolètes ou ont été supprimées.

Les fonctionnalités dépréciées sont toujours incluses dans OpenShift Container Platform et continuent d'être prises en charge ; cependant, elles seront supprimées dans une prochaine version de ce produit et ne sont pas recommandées pour les nouveaux déploiements.

2.1.6.1. Fonctionnalités obsolètes Red Hat OpenShift Service Mesh 1.1.5

Les ressources personnalisées suivantes étaient obsolètes dans la version 1.1.5 et ont été supprimées dans la version 1.1.12

  • Policy - La ressource Policy est obsolète et sera remplacée par la ressource PeerAuthentication dans une prochaine version.
  • MeshPolicy - La ressource MeshPolicy est obsolète et sera remplacée par la ressource PeerAuthentication dans une prochaine version.

  • v1alpha1 API RBAC - La politique RBAC v1alpha1 est dépassée par la politique v1beta1 AuthorizationPolicy. RBAC (Role Based Access Control) définit les objets ServiceRole et ServiceRoleBinding.

    • ServiceRole
    • ServiceRoleBinding

  • RbacConfig - RbacConfig met en œuvre la définition de ressource personnalisée pour contrôler le comportement RBAC d'Istio.

    • ClusterRbacConfig(versions antérieures à Red Hat OpenShift Service Mesh 1.0)
    • ServiceMeshRbacConfig (Red Hat OpenShift Service Mesh version 1.0 et ultérieure)
  • Dans Kiali, les stratégies login et LDAP sont obsolètes. Une prochaine version introduira l'authentification à l'aide des fournisseurs OpenID.

Les composants suivants sont également obsolètes dans cette version et seront remplacés par le composant Istiod dans une version ultérieure.

  • Mixer - le contrôle d'accès et les politiques d'utilisation
  • Pilot - découverte des services et configuration du proxy
  • Citadel - génération de certificats
  • Galley - validation et distribution de la configuration

2.1.7. Problèmes connus

Ces limitations existent dans Red Hat OpenShift Service Mesh :

  • Red Hat OpenShift Service Mesh ne prend pas en charge IPv6, car il n'est pas pris en charge par le projet Istio en amont, ni entièrement pris en charge par OpenShift Container Platform.
  • Disposition du graphe - La disposition du graphe Kiali peut être différente, selon l'architecture de votre application et les données à afficher (nombre de nœuds du graphe et leurs interactions). Parce qu'il est difficile, voire impossible, de créer une présentation unique qui rende bien dans toutes les situations, Kiali offre un choix de plusieurs présentations différentes. Pour choisir une autre présentation, vous pouvez choisir une autre Layout Schema dans le menu Graph Settings.
  • La première fois que vous accédez à des services connexes tels que Jaeger et Grafana, à partir de la console Kiali, vous devez accepter le certificat et vous authentifier à nouveau en utilisant vos identifiants de connexion à OpenShift Container Platform. Ceci est dû à un problème avec la façon dont le framework affiche les pages intégrées dans la console.

2.1.7.1. Problèmes connus du Service Mesh

Il s'agit des problèmes connus dans Red Hat OpenShift Service Mesh :

  • Mise à niveau de l'opérateur Jaeger/Kiali bloquée avec un opérateur en attente Lors de la mise à niveau des opérateurs Jaeger ou Kiali avec le Service Mesh 1.0.x installé, le statut de l'opérateur est indiqué comme étant en attente.

    Solution de contournement : Voir l'article de la base de connaissances pour plus d'informations.

  • Istio-14743 En raison de limitations dans la version d'Istio sur laquelle cette version de Red Hat OpenShift Service Mesh est basée, il y a plusieurs applications qui sont actuellement incompatibles avec Service Mesh. Voir le problème communautaire lié pour plus de détails.

  • 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 comporte de nombreux espaces de noms, il peut en résulter des problèmes de performance.
  • MAISTRA-465 L'opérateur Maistra ne parvient pas à créer un service pour les métriques de l'opérateur.
  • 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.

2.1.7.2. Problèmes connus de Kiali

Note

Les nouveaux problèmes pour Kiali doivent être créés dans le projet OpenShift Service Mesh avec l'adresse Component fixée à Kiali.

Voici les problèmes connus de Kiali :

  • 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.

2.1.7.3. Red Hat OpenShift distributed tracing known issues (problèmes connus)

Ces limitations existent dans le traçage distribué de Red Hat OpenShift :

  • 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.

Ce sont les problèmes connus pour Red Hat OpenShift distributed tracing :

  • 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.

2.1.8. Problèmes corrigés

Les problèmes suivants ont été résolus dans la version actuelle :

2.1.8.1. Le maillage de service a permis de résoudre des problèmes

  • MAISTRA-2371 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.
  • OSSM-542 Galley n'utilise pas le nouveau certificat après la rotation.
  • OSSM-99 Les charges de travail générées à partir d'un pod direct sans étiquette peuvent faire planter Kiali.
  • OSSM-93 IstioConfigList ne peut pas filtrer par deux noms ou plus.
  • OSSM-92 L'annulation de modifications non enregistrées sur la page d'édition YAML VS/DR n'annule pas les modifications.
  • OSSM-90 Traces non disponibles sur la page de détails du service.
  • MAISTRA-1649 Conflit entre les services sans tête dans différents espaces de noms. Lors du déploiement de services sans tête dans différents espaces de noms, la configuration des points d'extrémité est fusionnée et des configurations Envoy invalides sont poussées vers les sidecars.
  • MAISTRA-1541 Panique dans kubernetesenv lorsque le contrôleur n'est pas défini sur la référence propriétaire. Si un pod a une ownerReference qui ne spécifie pas le contrôleur, cela provoque une panique dans le code kubernetesenv cache.go.
  • MAISTRA-1352 Les définitions de ressources personnalisées (CRD) de Cert-manager de l'installation du plan de contrôle ont été supprimées pour cette version et les versions futures. Si vous avez déjà installé Red Hat OpenShift Service Mesh, les CRD doivent être supprimés manuellement si cert-manager n'est pas utilisé.
  • MAISTRA-1001 La fermeture de connexions HTTP/2 peut entraîner des erreurs de segmentation dans istio-proxy.
  • MAISTRA-932 Ajout des métadonnées requires pour ajouter une relation de dépendance entre Jaeger Operator et OpenShift Elasticsearch Operator. Assure que lorsque l'opérateur Jaeger est installé, il déploie automatiquement l'opérateur OpenShift Elasticsearch s'il n'est pas disponible.
  • MAISTRA-862 Galley a abandonné les montres et a cessé de fournir des configurations aux autres composants après de nombreuses suppressions et recréations d'espaces de noms.
  • MAISTRA-833 Pilot a cessé de fournir la configuration après de nombreuses suppressions et recréations d'espaces de noms.
  • MAISTRA-684 La version par défaut de Jaeger dans le site istio-operator est 1.12.0, ce qui ne correspond pas à la version 1.13.1 de Jaeger livrée dans Red Hat OpenShift Service Mesh 0.12.TechPreview.
  • MAISTRA-622 Dans Maistra 0.12.0/TP12, le mode permissif ne fonctionne pas. L'utilisateur a la possibilité d'utiliser le mode texte simple ou le mode TLS mutuel, mais pas le mode permissif.
  • MAISTRA-572 Jaeger ne peut pas être utilisé avec Kiali. Dans cette version, Jaeger est configuré pour utiliser le proxy OAuth, mais il est également configuré pour fonctionner uniquement via un navigateur et n'autorise pas l'accès aux services. Kiali ne peut pas communiquer correctement avec le point de terminaison Jaeger et considère que Jaeger est désactivé. Voir aussi TRACING-591.
  • MAISTRA-357 Dans OpenShift 4 Beta sur AWS, il n'est pas possible, par défaut, d'accéder à un service TCP ou HTTPS via la passerelle d'entrée sur un port autre que le port 80. L'équilibreur de charge AWS dispose d'un contrôle de santé qui vérifie si le port 80 sur le point de terminaison du service est actif. Si aucun service n'est exécuté sur le port 80, le contrôle de santé de l'équilibreur de charge échoue.
  • MAISTRA-348 OpenShift 4 Beta sur AWS ne prend pas en charge le trafic de la passerelle d'entrée sur des ports autres que 80 ou 443. Si vous configurez votre passerelle d'entrée pour gérer le trafic TCP avec un numéro de port autre que 80 ou 443, vous devez utiliser le nom d'hôte du service fourni par l'équilibreur de charge AWS plutôt que le routeur OpenShift comme solution de contournement.
  • 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.
  • Bug 1821432 Les contrôles à bascule dans la page de détails des ressources de contrôle d'OpenShift Container Platform ne mettent pas à jour le CR correctement. Les contrôles à bascule de l'interface utilisateur dans la page de présentation du Service Mesh Control Plane (SMCP) dans la console web d'OpenShift Container Platform mettent parfois à jour le mauvais champ de la ressource. Pour mettre à jour une ressource ServiceMeshControlPlane, 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.

2.1.8.2. Kiali a corrigé des problèmes

  • KIALI-3239 Si un pod Kiali Operator a échoué avec un statut "Evicted", cela bloque le déploiement de l'opérateur Kiali. La solution consiste à supprimer le pod évincé et à redéployer l'opérateur Kiali.
  • KIALI-3118 Après avoir modifié le ServiceMeshMemberRoll, par exemple en ajoutant ou en supprimant des projets, le pod Kiali redémarre et affiche des erreurs sur la page Graph pendant le redémarrage du pod Kiali.
  • KIALI-3096 Les métriques d'exécution échouent dans le Service Mesh. Il existe un filtre OAuth entre le Service Mesh et Prometheus, qui exige qu'un jeton de porteur soit transmis à Prometheus avant que l'accès ne soit accordé. Kiali a été mis à jour pour utiliser ce jeton lors de la communication avec le serveur Prometheus, mais les métriques de l'application échouent actuellement avec des erreurs 403.
  • KIALI-3070 Ce bogue n'affecte que les tableaux de bord personnalisés, et non les tableaux de bord par défaut. Lorsque vous sélectionnez des étiquettes dans les paramètres de mesure et que vous actualisez la page, vos sélections sont conservées dans le menu, mais elles ne s'affichent pas dans les graphiques.
  • KIALI-2686 Lorsque le plan de contrôle a de nombreux espaces de noms, cela peut entraîner des problèmes de performance.

2.1.8.3. Red Hat OpenShift a corrigé des problèmes de traçage distribué

  • 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}

    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.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.