Harvester项目中使用自定义CA证书导致节点加入失败的解决方案

问题背景

在Harvester v1.4.0版本中，当管理员配置了自定义CA证书后，尝试向集群添加额外节点时会出现加入失败的情况。这一问题主要源于Rancher v2.9.x版本引入的严格TLS验证机制与Harvester现有证书管理机制之间的不兼容性。

技术原理分析

Harvester作为基于Rancher的轻量级超融合基础设施(HCI)解决方案，其节点加入过程依赖于Rancher System Agent组件。在v1.4.0版本中，该组件默认启用了严格TLS验证模式(CATTLE_AGENT_STRICT_VERIFY=true)，导致以下问题链：

1. 主节点配置自定义CA证书后，会将这些证书正确安装到系统证书存储中
2. 但在生成节点加入配置时，rancher2_connection_info.json文件中仍包含默认的"dynamiclistener" CA证书
3. 加入节点尝试连接时，由于严格验证模式，会拒绝使用系统证书存储中的证书，而强制使用连接信息中指定的证书
4. 最终导致TLS握手失败，错误信息为"x509: certificate signed by unknown authority"

解决方案详解

临时解决方案

对于已经部署的环境，可以通过以下步骤临时解决问题：

1. 登录已部署的主节点
2. 修改agent-tls-mode设置为"system-store"
3. 执行kubectl命令更新设置：

kubectl patch settings.management.cattle.io agent-tls-mode --type merge -p '{"value":"system-store"}'

根本解决方案

Harvester团队已在后续版本中修复此问题，具体措施包括：

1. 默认将agent-tls-mode设置为"system-store"
2. 确保节点加入流程正确识别和使用系统证书存储中的自定义CA证书
3. 优化证书传递机制，保证加入节点能获取正确的CA证书链

版本影响范围

• 受影响版本：Harvester v1.4.0至v1.4.1
• 已修复版本：v1.4.2及后续版本
• 不涉及版本：v1.3.x系列（因使用旧版Rancher未引入此机制）

最佳实践建议

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

1. 直接使用v1.4.2或更高版本
2. 如需使用v1.4.0/1.4.1，应在部署主节点后立即修改agent-tls-mode设置
3. 确保证书配置包含管理VIP的SAN(Subject Alternative Name)条目
4. 定期检查系统证书存储状态，确保证书链完整

技术深度解析

该问题的本质是Kubernetes集群组件间证书信任链的建立机制。在严格模式下，Rancher System Agent仅信任显式提供的CA证书，而忽略系统证书存储。修复方案通过以下方式确保兼容性：

1. 保留严格验证的安全优势
2. 同时允许系统证书存储作为可信源
3. 维持向后兼容性，不影响现有部署

这种设计既保证了安全性，又提供了部署灵活性，是云原生基础设施证书管理的典型实践。