1.7. Red Hat OpenShift 分布式追踪问题
- OSSM-1910 因为版本 2.6 中引入了问题，所以无法在 OpenShift Container Platform Service Mesh 中建立 TLS 连接。在这个版本中，通过更改服务端口名称以匹配 OpenShift Container Platform Service Mesh 和 Istio 所使用的约定解决了这个问题。
- OBSDA-208 在更新之前，默认的 200m CPU 和 256Mi 内存资源限制可能会导致分布式追踪数据收集在大型集群中持续重启。在这个版本中，通过删除这些资源限值解决了这个问题。
- OBSDA-222 在此更新之前，可以在 OpenShift Container Platform 分布式追踪平台中丢弃 span。为了帮助防止这个问题发生，这个版本会更新版本依赖项。
TRACING-2337 Jaeger 在 Jaeger 日志中记录一个重复的警告信息，如下所示：
{"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}这个问题已通过只公开查询服务的 HTTP(S)端口而不是 gRPC 端口来解决。
- TRACING-2009 已更新 Jaeger Operator，使其包含对 Strimzi Kafka Operator 0.23.0 的支持。
-
TRACING-1907 Jaeger 代理 sidecar 注入失败，因为应用程序命名空间中缺少配置映射。因为
OwnerReference字段设置不正确，配置映射会被自动删除，因此应用程序 pod 不会超过 "ContainerCreating" 阶段。已删除不正确的设置。 - TRACING-1725 转入到 TRACING-1631。额外的程序漏洞修复，可确保当存在多个生产环境的 Jaeger 实例，它们使用相同的名称但在不同的命名空间中时，Elasticsearch 证书可以被正确协调。另请参阅 BZ-1918920。
- TRACING-1631 多 Jaeger 生产环境实例使用相同的名称但在不同命名空间中，因此会导致 Elasticsearch 证书问题。安装多个服务网格时，所有 Jaeger Elasticsearch 实例都有相同的 Elasticsearch secret 而不是单独的 secret，这导致 OpenShift Elasticsearch Operator 无法与所有 Elasticsearch 集群通信。
- 在使用 Istio sidecar 时，在 Agent 和 Collector 间的连接会出现 TRACING-1300 失败。对 Jaeger Operator 的更新默认启用了 Jaeger sidecar 代理和 Jaeger Collector 之间的 TLS 通信。
-
TRACING-1208 访问 Jaeger UI 时的身份验证 "500 Internal Error" 错误。当尝试使用 OAuth 验证 UI 时，会得到 500 错误，因为 oauth-proxy sidecar 不信任安装时使用
additionalTrustBundle定义的自定义 CA 捆绑包。 -
TRACING-1166 目前无法在断开网络连接的环境中使用 Jaeger 流策略。当一个 Kafka 集群被置备时，它会产生一个错误：
Failed to pull image registry.redhat.io/amq7/amq-streams-kafka-24-rhel7@sha256:f9ceca004f1b7DCCB3b82d9a8027961f9fe4104e0ed69752c0bdd8078b4a1076。 - TRACING-809 Jaeger Ingester 与 Kafka 2.3 不兼容。当存在两个或多个 Jaeger Ingester 实例时，它会不断在日志中生成重新平衡信息。这是由于在 Kafka 2.3 里存在一个程序错误，它已在 Kafka 2.3.1 中修复。如需更多信息，请参阅 Jaegertracing-1819。
BZ-1918920/LOG-1619 / LOG-1619，Elasticsearch Pod 在更新后不会自动重启。
临时解决方案：手动重启 pod。
