RKE2 集群中 secrets-encrypt 功能在分离式 etcd/控制平面架构下的重启问题解析

问题背景

在 RKE2 1.33.1 版本中，当集群采用 etcd 节点与控制平面节点分离部署的架构时，执行 secrets-encrypt 加密准备操作后重启 rke2-server 服务会出现 panic 崩溃现象。这是一个影响集群稳定性的关键问题，特别是在生产环境中需要定期轮换加密密钥的场景下。

技术原理分析

RKE2 的 secrets-encrypt 功能基于 Kubernetes 的数据加密机制，通过以下流程工作：

1. 加密准备阶段：当执行 secrets-encrypt prepare 命令时，系统会生成新的加密密钥但不会立即使用，而是等待所有组件准备好后才切换。

2. 密钥轮换流程：涉及多个阶段(start→prepare→rotate→reencrypt→restart→reencrypt_request→reencrypt_active→reencrypt_finished)，每个阶段都需要集群组件间的协调配合。

3. 分离架构挑战：在 etcd 与控制平面分离的部署中，组件间的协调更为复杂，原有的代码逻辑未能充分考虑这种架构下的通信时序问题。

问题表现

在分离式架构下，当管理员执行以下操作序列时会出现问题：

1. 正常部署分离式 etcd 和控制平面的 RKE2 集群
2. 执行 secrets-encrypt prepare 命令
3. 重启 rke2-server 服务
4. 服务启动时出现 panic 崩溃

解决方案

开发团队通过修复代码中的协调逻辑解决了此问题，主要改进包括：

1. 增强状态检查：在服务启动时增加了对加密状态的完整性检查
2. 改进错误处理：优化了异常情况下的处理流程，避免直接 panic
3. 时序协调：确保 etcd 和控制平面组件在加密状态变更时的正确时序

验证结果

在修复后的 v1.33.1-rc2+rke2r1 版本中，验证团队确认：

1. 成功部署 3 个 etcd 节点和 2 个控制平面节点的分离式集群
2. secrets-encrypt prepare 命令正常执行
3. 服务重启后无 panic 错误
4. 所有节点和 Pod 保持正常运行
5. 加密状态正确显示为 prepare 阶段

最佳实践建议

对于使用 RKE2 分离式架构的用户，建议：

1. 升级到修复版本：确保使用 v1.33.1 或更高版本
2. 操作顺序：执行加密操作时，先准备再重启，最后完成轮换
3. 监控验证：每次加密操作后检查 Encryption Status 和节点状态
4. 备份策略：重要加密操作前确保有 etcd 数据备份

总结

RKE2 团队通过这次修复，增强了 secrets-encrypt 功能在复杂架构下的稳定性，为用户提供了更可靠的密钥管理能力。这体现了 RKE2 项目对生产环境需求的持续关注和改进。