1.7. 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
OwnerReferenceincorrect 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.
