Jaeger项目Kafka TLS连接问题分析与修复

在Jaeger v1.64.0版本中，一个关于Kafka TLS连接的重要变更导致了部分用户无法正常连接到使用TLS认证的Kafka集群。这个问题主要影响了Jaeger Collector和Ingester组件与Kafka的通信能力。

问题背景

Jaeger作为分布式追踪系统，使用Kafka作为消息中间件时支持TLS加密连接。在v1.64.0版本中，项目团队重构了TLS配置的实现方式，将原有的TLS配置结构迁移到了OpenTelemetry的TLS配置结构。这一变更虽然带来了代码统一性的提升，但意外引入了一个关键问题。

问题分析

新版本的TLS配置结构中，默认将IncludeSystemCACertsPool参数设置为false，这意味着系统默认不会包含操作系统信任的CA证书。对于使用公共CA签名的Kafka服务证书的场景，这一变更导致了TLS握手失败。

具体表现为：

1. Collector和Ingester组件启动时无法建立Kafka连接
2. 日志中显示大量"unexpected EOF"错误
3. 最终报错"client has run out of available brokers to talk to"

技术细节

在旧版本中，Jaeger的Kafka TLS配置允许直接使用系统CA证书池验证服务端证书。而新版本中，这一行为需要显式配置。对于以下两种常见场景影响较大：

1. 使用公共CA(如Let's Encrypt)签名的Kafka服务证书
2. 使用企业内部CA签名但证书已加入系统信任库的情况

解决方案

项目团队迅速响应，在发现问题后立即提交了修复代码。修复方案的核心是：

1. 恢复系统CA证书池的默认包含行为
2. 确保向后兼容性
3. 保持新配置结构的优势

用户建议

对于遇到此问题的用户，建议：

1. 升级到包含修复的版本
2. 如果暂时无法升级，可以尝试在配置中显式设置IncludeSystemCACertsPool: true
3. 检查Kafka服务端证书链是否完整

总结

这次事件展示了开源项目中配置变更可能带来的连锁反应，也体现了Jaeger项目团队对用户反馈的快速响应能力。对于分布式系统而言，中间件连接配置的稳定性至关重要，特别是在安全通信方面的小变更可能产生较大影响。