ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

解决Harvester部署RKE2集群时的私有CA证书信任问题

2026/8/11 5:31:41 拓冰建站 浏览量
解决Harvester部署RKE2集群时的私有CA证书信任问题

1. 问题现象与背景分析

最近在Harvester平台上部署RKE2集群时遇到一个典型问题：当Rancher使用私有CA（Certificate Authority）时，集群配置会失败。这个错误在日志中通常表现为x509证书验证失败，具体报错可能是"x509: certificate signed by unknown authority"。

这种情况在企业内部环境中特别常见，因为很多组织都会使用私有CA来签发内部证书。Harvester作为新兴的HCI（超融合基础设施）平台，与Rancher的集成越来越紧密，但私有CA的配置细节却容易成为绊脚石。

注意：这个问题不仅限于Harvester平台，任何使用私有CA的Rancher环境在配置RKE2集群时都可能遇到类似问题。

2. 核心问题拆解

2.1 证书链信任机制解析

问题的根源在于RKE2节点不信任Rancher使用的私有CA。在TLS通信中，客户端需要验证服务器证书的有效性，这依赖于证书链的完整性和可信度。当使用公开CA（如Let's Encrypt）时，操作系统通常预置了这些CA的根证书。但私有CA的根证书不会自动被信任。

2.2 RKE2集群启动流程中的证书验证

RKE2集群启动时，会从Rancher获取bootstrap配置，这个过程中涉及多个HTTPS请求：

  1. 节点向Rancher API请求集群配置
  2. 下载必要的镜像和charts
  3. 建立与Rancher的持续通信通道

如果其中任何一个环节的证书验证失败，整个流程就会中断。

3. 解决方案与实操步骤

3.1 准备私有CA证书

首先需要获取你的私有CA的根证书（通常是.crt或.pem格式）。如果你不确定如何获取，可以咨询你的安全团队或查看内部PKI文档。

# 示例：查看证书内容 openssl x509 -in ca.crt -text -noout

3.2 在Harvester节点上配置CA信任

对于基于openSUSE的Harvester节点，需要将CA证书添加到系统信任库：

# 将CA证书复制到系统证书目录 sudo cp ca.crt /etc/pki/trust/anchors/ # 更新证书信任库 sudo update-ca-certificates

验证是否添加成功：

openssl verify -CApath /etc/ssl/certs/ ca.crt

3.3 配置RKE2信任私有CA

有两种主要方法可以让RKE2信任私有CA：

方法一：通过RKE2配置文件

创建或编辑RKE2的配置文件（通常是/etc/rancher/rke2/config.yaml）：

tls-san: - rancher.yourdomain.com cni: "cilium" private-registry: "/etc/rancher/rke2/registries.yaml" # 添加以下内容 cloud-provider-name: "harvester" kubelet-arg: - "volume-plugin-dir=/var/lib/kubelet/volumeplugins" # 关键配置：指定额外信任的证书目录 additional-trust-bundle: "/etc/ssl/certs/ca-certificates.crt"
方法二：通过Rancher UI配置
  1. 登录Rancher管理界面
  2. 导航到集群管理 -> 驱动 -> RKE2
  3. 在集群模板中，找到"高级选项"
  4. 在"Additional Trusted CA"字段上传你的CA证书

3.4 验证配置

部署后，检查RKE2节点的证书信任情况：

# 检查kubelet日志 journalctl -u rke2-server -f # 验证API服务器证书 curl -v --cacert /etc/ssl/certs/ca-certificates.crt https://rancher.yourdomain.com

4. 常见问题与排查技巧

4.1 证书链不完整

如果私有CA使用了中间证书，必须确保完整的证书链被配置。可以通过以下命令检查：

openssl s_client -showcerts -connect rancher.yourdomain.com:443

如果发现证书链不完整，需要将中间证书与根证书合并：

cat intermediate.crt root.crt > fullchain.crt

4.2 证书过期或时间不同步

节点时间不同步会导致证书验证失败，即使证书本身是有效的。确保所有节点时间同步：

sudo chronyc sources sudo timedatectl set-ntp true

4.3 容器运行时证书信任

即使主机系统信任了CA，容器内部可能仍然不信任。对于Docker，需要额外配置：

sudo mkdir -p /etc/docker/certs.d/rancher.yourdomain.com sudo cp ca.crt /etc/docker/certs.d/rancher.yourdomain.com/ca.crt sudo systemctl restart docker

对于containerd，配置略有不同：

sudo mkdir -p /etc/containerd/certs.d/rancher.yourdomain.com sudo cp ca.crt /etc/containerd/certs.d/rancher.yourdomain.com/ca.crt sudo systemctl restart containerd

5. 高级配置与优化

5.1 自动化证书分发

在大规模部署中，手动配置每个节点的证书不现实。可以考虑以下自动化方案：

  1. 使用Harvester的cloud-init功能在节点初始化时注入证书
  2. 通过配置管理工具（如Ansible）批量部署
  3. 创建自定义的Harvester镜像，预置CA证书

5.2 证书轮换策略

私有CA证书也有有效期，需要建立轮换机制：

  1. 监控证书过期时间（可以使用Prometheus的ssl_exporter）
  2. 提前部署新证书（保持旧证书直到所有节点更新完成）
  3. 使用证书管理工具（如Vault）自动化签发和部署

5.3 多集群统一证书管理

如果你管理多个Rancher环境，可以考虑：

  1. 使用相同的私有CA签发所有环境证书
  2. 在Harvester上创建全局的证书配置
  3. 通过Rancher的Fleet管理跨集群证书

6. 性能考量与最佳实践

6.1 证书类型选择

选择适当的证书类型可以提升性能：

  • ECDSA证书比RSA证书验证速度更快
  • 合理设置密钥长度（ECDSA P-256足够安全）
  • 避免过长的证书链（最好不超过3层）

6.2 TLS会话恢复

启用TLS会话恢复可以减少握手开销：

# 在RKE2配置中添加 kube-apiserver-arg: - "tls-min-version=VersionTLS12" - "tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"

6.3 监控与告警

建立完善的监控体系：

  1. 监控证书过期时间（提前30天告警）
  2. 监控TLS握手失败率
  3. 监控证书撤销状态（如果使用CRL）

7. 安全加固建议

7.1 证书吊销检查

如果私有CA支持CRL（证书吊销列表）或OCSP（在线证书状态协议），应该启用验证：

# 在RKE2配置中添加 kube-apiserver-arg: - "tls-cert-file=/etc/rancher/ssl/server.crt" - "tls-private-key-file=/etc/rancher/ssl/server.key" - "tls-ca-file=/etc/rancher/ssl/ca.crt" - "tls-crl-file=/etc/rancher/ssl/crl.pem" # 如果使用CRL

7.2 证书范围最小化

为不同服务使用不同的证书：

  1. Rancher UI使用独立证书
  2. Kubernetes API使用独立证书
  3. 每个集群使用不同的证书

7.3 证书透明度日志

考虑部署私有证书透明度日志（CT log），虽然这是高级话题，但对于严格的安全环境很有价值。

8. 故障排查手册

8.1 诊断证书问题

使用openssl进行详细诊断：

openssl s_client -connect rancher.yourdomain.com:443 -CAfile /etc/ssl/certs/ca-certificates.crt -status

8.2 日志分析要点

关键日志位置和内容：

  1. RKE2服务日志：journalctl -u rke2-server -f
  2. Kubelet日志：journalctl -u kubelet -f
  3. Containerd日志：journalctl -u containerd -f

查找关键词：x509, certificate, TLS, handshake, failed

8.3 网络抓包分析

当其他方法无法确定问题时，可以尝试抓包：

sudo tcpdump -i any -w rancher.pcap port 443

然后用Wireshark分析TLS握手过程。

9. 替代方案比较

9.1 使用公开CA

如果安全策略允许，可以考虑：

  1. 使用Let's Encrypt签发证书
  2. 通过DNS挑战验证所有权
  3. 配置自动续期

优点：无需管理CA，兼容性好 缺点：需要公共DNS记录，证书有效期短（90天）

9.2 使用服务网格管理证书

对于高级用户，可以考虑：

  1. 部署Istio或Linkerd服务网格
  2. 通过服务网格管理服务间TLS
  3. 使用mesh内部CA

优点：细粒度的证书管理 缺点：增加系统复杂度

10. 长期维护策略

10.1 文档化证书架构

建立详细的文档记录：

  1. CA层次结构
  2. 证书用途和范围
  3. 续期和吊销流程

10.2 定期审计

每季度进行：

  1. 证书清单核对
  2. 密钥存储检查
  3. 访问控制审查

10.3 灾难恢复计划

为CA准备灾难恢复方案：

  1. 安全备份CA密钥
  2. 定义恢复流程
  3. 定期测试恢复过程

在实际操作中，我发现证书问题往往不是技术本身复杂，而是组织流程不清晰导致的。建议建立一个跨团队的证书管理小组，包括安全、运维和开发代表，定期审查证书策略和实现。