MetalLB CI 测试中遇到的 WebSocket 流 ID 问题分析与解决

问题背景

在 MetalLB 项目的持续集成(CI)测试中，开发团队发现了一个间歇性出现的测试失败问题。测试过程中，当通过 vtysh 工具查询 BGP 路由信息时，系统会随机出现"Unknown stream id 1, discarding message"的错误信息，导致测试失败。

问题现象

测试失败时的典型错误日志显示，kubectl exec 命令执行 vtysh 时，虽然命令本身执行成功并返回了有效的 JSON 格式路由信息，但标准错误输出(stderr)中混入了 WebSocket 相关的警告信息："E0910 18:08:54.853077 339136 websocket.go:296] Unknown stream id 1, discarding message"。

由于测试代码将 stdout 和 stderr 合并处理，导致 JSON 解析器在解析响应时遇到了非法字符'E'（来自错误信息的开头），从而引发了 JSON 语法错误。

根本原因分析

这个问题与 Kubernetes 1.31 版本中引入的 WebSocket 传输协议变更有关。Kubernetes 从 1.31 版本开始，将流式传输协议从 SPDY 逐步过渡到 WebSockets。MetalLB 的 CI 环境在升级到 kubectl 1.31 版本后开始出现这个问题。

在底层实现上，kubectl exec 命令使用 WebSocket 协议与容器通信时，偶尔会出现无法识别的流 ID 消息。虽然这只是一个警告信息，不影响命令的实际执行结果，但由于它被输出到 stderr，而测试代码又合并处理 stdout 和 stderr，最终导致了 JSON 解析失败。

解决方案

针对这个问题，开发团队提出了两种解决方案：

1. 分离处理 stdout 和 stderr：修改测试代码，只处理命令的标准输出(stdout)，忽略标准错误(stderr)。这样可以确保 JSON 解析器只处理有效的路由信息，不受警告信息的干扰。

2. 增加重试机制：在命令执行失败时自动重试几次，利用概率方法规避间歇性问题。这种方法虽然简单，但不够优雅，且可能延长测试时间。

经过讨论，团队最终选择了第一种方案，因为它更直接地解决了问题的根源，且代码更清晰可靠。这种方案不需要依赖重试机制，能够稳定地获取正确的路由信息。

技术启示

这个案例为我们提供了几个重要的技术启示：

1. 命令输出处理：在编写测试代码时，应该根据实际情况合理处理命令的标准输出和标准错误。不是所有情况下都需要合并处理两者。

2. Kubernetes 版本兼容性：Kubernetes 的协议变更可能会影响周边工具的行为，特别是在涉及流式传输的场景下。保持对 Kubernetes 变更日志的关注非常重要。

3. 错误处理策略：面对间歇性错误时，应该首先分析错误的性质和根源，而不是简单地增加重试机制。找到根本原因往往能带来更优雅的解决方案。

4. 测试健壮性：测试代码应该能够容忍一定程度的非致命性警告信息，特别是来自底层系统的无害警告。

总结

通过分析 MetalLB CI 测试中的 WebSocket 流 ID 问题，我们不仅解决了具体的测试失败问题，还加深了对 Kubernetes 流式传输协议变更的理解。这个案例展示了在面对复杂系统问题时，深入分析底层原因的重要性，以及如何设计更健壮的测试代码来应对底层系统的变化。