Retina项目中Hubble-relay与Retina-agent的TLS连接问题分析

问题背景

在Retina项目的最新部署中，发现Hubble-relay组件无法与Retina-agent建立连接，特别是在启用了TLS加密通信的情况下。Hubble-relay是Cilium生态中负责聚合Hubble观测数据的关键组件，而Retina-agent则是微软Retina项目中的监控代理。两者之间的通信中断会导致整个可观测性系统的功能缺失。

现象表现

从日志中可以观察到以下关键现象：

1. Hubble-relay持续报错"Failed to create peer client for peers synchronization"
2. 连接尝试最终因超时而失败，错误信息显示"context deadline exceeded"
3. 服务最终停止运行，提示"Server stopped"

根本原因

经过技术团队的深入调查，发现问题源于一个特定的代码提交(0dc47e0)。该提交修改了Hubble-relay与Retina-agent之间的gRPC通信协议实现，虽然TLS认证文件生成和验证过程都正常，但在实际的gRPC协议层出现了兼容性问题。

值得注意的是，Hubble的peer服务协议(protobuf定义)自2022年以来就没有变更过，因此可以排除上游协议变更导致的可能性。

技术细节分析

Hubble-relay与Retina-agent的通信涉及多个关键配置点：

1. 探针配置差异：

   • Cilium原生实现使用固定端口4222进行健康检查
   • Retina实现则使用动态配置的.Values.hubble.relay.listenPort
   • 探针参数(超时时间、检查间隔等)也存在差异

2. TLS配置路径：

   • 启用TLS时使用标准的gRPC端口配置
   • 禁用TLS时则回退到基于命令的检查方式

3. 协议兼容性：

   • 虽然TLS握手成功，但gRPC协议层出现不兼容
   • 这表明认证文件和加密通道建立正常，但应用层协议无法正确协商

解决方案

技术团队采用了以下方法定位和解决问题：

1. 使用git bisect方法进行问题定位

   • 标记当前HEAD为bad状态
   • 选择6个月前的一个已知正常版本标记为good
   • 通过二分法逐步缩小问题范围
   • 经过7-8次构建和部署验证后定位到问题提交

2. 实施修复方案：

   • 回退导致问题的代码变更
   • 确保gRPC协议实现与Hubble peer服务保持兼容
   • 验证TLS和非TLS两种模式下的通信正常

经验总结

这个案例提供了几个重要的技术经验：

1. 协议兼容性测试的重要性：即使加密通道建立成功，仍需验证应用层协议的正确性。

2. 变更追踪的价值：通过系统化的版本控制和方法论(如git bisect)可以高效定位问题源头。

3. 配置一致性的必要性：关键组件(如健康检查探针)的配置应当保持与上游实现的一致性，除非有明确的技术理由进行修改。

4. 端到端验证的不可替代性：在安全相关变更后，需要进行完整的通信链路验证，而不仅限于部分环节的检查。