RKE2控制平面节点间remotedialer隧道连接问题分析与解决方案

问题背景

在RKE2集群部署过程中，当控制平面节点（control-plane-only）同时加入集群时，会出现节点间remotedialer隧道连接异常的情况。具体表现为：节点间WebSocket隧道在初始建立后会立即断开，导致无法通过kubectl exec或kubectl logs命令访问其他控制平面节点上的Pod。

现象分析

通过日志分析可以发现，在初始启动阶段，控制平面节点间的remotedialer连接存在以下异常模式：

1. 节点首先建立到本地(127.0.0.1)的隧道连接
2. 随后尝试建立到其他控制平面节点的隧道连接
3. 但很快又会断开这些远程连接，重新建立本地连接
4. 最终导致节点间隧道无法维持稳定连接

相比之下，K3s在相同场景下表现正常，能够维持稳定的节点间隧道连接。

根本原因

经过深入分析，发现问题源于RKE2启动过程中的一个竞态条件：

1. RKE2启动时会从被加入的服务器获取API服务器地址列表
2. 由于RKE2启动序列较长，有时地址列表返回较晚
3. 当从被加入服务器获取的地址列表为空时，RKE2不会跳过同步过程
4. 这会导致所有端点被意外清除
5. 最终结果是节点间隧道连接被错误地断开

解决方案

目前有以下几种可行的解决方案：

1. 顺序加入控制平面节点：避免同时加入多个控制平面节点，采用逐个加入的方式

2. 服务重启：在所有控制平面节点加入完成后，重启rke2-server服务

3. 端点更新触发：通过修改kubernetes端点资源强制触发更新，例如：

   kubectl patch endpoints kubernetes --patch 'metadata: {annotations: {rke2.cattle.io/gh-issue-7899: ""}}'
   

技术细节对比

与K3s相比，RKE2在此场景下的不同表现主要源于：

1. 启动时序差异：RKE2的启动序列比K3s更长，导致地址列表同步时机不同
2. 空列表处理：RKE2在地址列表为空时仍会执行同步，而K3s可能有不同的处理逻辑
3. 日志记录时机：K3s会较早记录systemd启动完成消息，而RKE2较晚

最佳实践建议

对于生产环境部署RKE2集群，建议：

1. 采用顺序加入控制平面节点的方式部署
2. 部署完成后验证节点间隧道连接状态
3. 如发现问题，优先采用端点更新方法恢复
4. 考虑在自动化部署脚本中加入连接状态检查逻辑

此问题的根本修复需要在RKE2代码层面优化地址同步逻辑，特别是在处理空地址列表时的行为。目前提供的解决方案可以作为临时应对措施，确保生产环境的稳定运行。