RKE2/K3s证书检查命令的现状与问题分析

1. RKE2/K3s 证书检查命令的现状与问题分析

最近在维护 Rancher 管理的 RKE2/K3s 集群时，我发现一个值得注意的现象：在 2025 年 5 月版本发布之前，rke2 certificate check 和 k3s certificate check 命令不会检查 kube-controller-manager 和 kube-scheduler 组件的证书状态。这个现象在独立部署的集群和 Rancher 托管的集群中表现不同，可能会给集群运维带来潜在风险。

1.1 问题具体表现

当你在 Rancher 托管的 RKE2/K3s 集群上执行证书检查命令时（版本低于 v1.30.13+rke2r1/v1.30.13+k3s1 等指定版本），输出结果中会明显缺少 kube-controller-manager 和 kube-scheduler 的证书信息。以下是典型输出示例的对比：

bash复制# 独立集群的完整输出（包含所有组件）
$ rke2 certificate check
INFO[0000] Checking certificates for controller-manager
INFO[0000] /var/lib/rancher/rke2/server/tls/client-controller.crt: certificate CN=system:kube-controller-manager is ok...
INFO[0000] Checking certificates for scheduler
INFO[0000] /var/lib/rancher/rke2/server/tls/client-scheduler.crt: certificate CN=system:kube-scheduler is ok...

# Rancher托管集群的输出（缺少上述两部分）
$ rke2 certificate check
INFO[0000] Server detected, checking agent and server certificates
INFO[0000] Checking certificates for kube-proxy
...
# 注意：没有controller-manager和scheduler的检查结果

这种差异可能导致管理员误以为集群所有证书都健康，而实际上两个关键组件的证书状态未被验证。

1.2 受影响的版本范围

根据官方说明，此问题影响以下版本的 RKE2/K3s 集群：

• RKE2:

  • 所有低于 v1.30.13+rke2r1 的 1.30.x 版本
  • 所有低于 v1.31.9+rke2r1 的 1.31.x 版本
  • 所有低于 v1.32.5+rke2r1 的 1.32.x 版本
  • 所有低于 v1.33.1+rke2r1 的 1.33.x 版本

• K3s:

  • 所有低于 v1.30.13+k3s1 的 1.30.x 版本
  • 所有低于 v1.31.9+k3s1 的 1.31.x 版本
  • 所有低于 v1.32.5+k3s1 的 1.32.x 版本
  • 所有低于 v1.33.1+k3s1 的 1.33.x 版本

重要提示：即使你的集群运行的是上述版本范围内的最新补丁版本，只要未达到指定的最小版本号，仍然会受此问题影响。

2. 问题根源与技术背景

2.1 证书生成机制的差异

问题的本质在于证书生成方式的不同。在早期版本中：

• 独立集群：RKE2/K3s 的 supervisor 进程统一生成所有组件证书
• Rancher托管集群：
  • kube-scheduler 和 kube-controller-manager 证书由组件自身生成
  • 证书存储在 --cert-dir 指定的子目录中（默认为 /var/lib/rancher/rke2/server/tls/kube-scheduler 和 /var/lib/rancher/rke2/server/tls/kube-controller-manager）

mermaid复制graph LR
    A[独立集群] --> B[Supervisor生成所有证书]
    C[Rancher集群] --> D[Supervisor生成大部分证书]
    C --> E[组件自生成scheduler/controller-manager证书]

2.2 证书检查命令的工作逻辑

certificate check 命令原本设计只检查特定目录下的证书文件：

1. 扫描 /var/lib/rancher/rke2/server/tls/ 下的主证书文件
2. 检查 /var/lib/rancher/rke2/agent/ 下的客户端证书
3. 不递归检查子目录（因此遗漏组件自生成的证书）

这种设计在早期版本中没有问题，因为所有证书都在同一目录。但随着架构变化，检查逻辑未相应更新。

2.3 2025年5月版本的改进

新版本进行了以下架构调整：

1. Supervisor 进程统一接管所有证书生成
2. 证书全部存储在标准位置（不再有组件专属子目录）
3. 检查命令现在会验证所有核心组件证书

bash复制# 新版本中的证书位置示例
/var/lib/rancher/rke2/server/tls/client-kube-scheduler.crt
/var/lib/rancher/rke2/server/tls/client-kube-controller-manager.crt

3. 影响评估与风险分析

3.1 潜在风险场景

虽然组件能自动生成证书，但缺少监控仍可能引发问题：

1. 证书过期风险：

   • 自动生成的证书默认有效期通常为1年
   • 若无监控，过期可能导致控制器或调度器突然停止工作

2. 配置不一致风险：

   • 手动修改的证书参数可能不会应用到自动生成的证书
   • 导致安全策略执行不一致

3. 故障排查盲区：

   • 当出现控制器/调度器连接问题时，无法快速确认是否证书相关

3.2 实际影响案例

某客户集群曾出现以下故障模式：

1. kube-controller-manager 证书过期（但未被检测到）
2. 控制器无法连接 API Server
3. Deployment 滚动更新卡死，Pod 无法创建
4. 故障持续2小时后才发现证书问题

经验教训：关键组件证书缺失监控可能导致级联故障，且排查耗时。

4. 解决方案与实施指南

4.1 官方推荐方案

最彻底的解决方案是升级到2025年5月或之后发布的版本：

• RKE2 升级目标版本：

  • v1.30.13+rke2r1 或更高
  • v1.31.9+rke2r1 或更高
  • v1.32.5+rke2r1 或更高
  • v1.33.1+rke2r1 或更高

• K3s 升级目标版本：

  • v1.30.13+k3s1 或更高
  • v1.31.9+k3s1 或更高
  • v1.32.5+k3s1 或更高
  • v1.33.1+k3s1 或更高

升级步骤示例：

bash复制# 对于RKE2
curl -sfL https://get.rke2.io | INSTALL_RKE2_VERSION="v1.32.5+rke2r1" sh -
systemctl restart rke2-server

# 对于K3s
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="v1.32.5+k3s1" sh -
systemctl restart k3s

4.2 临时监控方案（无法立即升级时）

如果无法立即升级，可以手动实现证书检查：

1. 创建自定义检查脚本 /usr/local/bin/check_k8s_certs.sh：

bash复制#!/bin/bash

check_cert() {
  local component=$1
  local cert_dir="/var/lib/rancher/rke2/server/tls/${component}"
  
  if [ -d "${cert_dir}" ]; then
    for cert in $(find "${cert_dir}" -name "*.crt"); do
      echo "Checking ${component} certificate: ${cert}"
      openssl x509 -in "${cert}" -noout -dates
    done
  else
    echo "WARN: ${component} cert directory not found at ${cert_dir}"
  fi
}

check_cert "kube-scheduler"
check_cert "kube-controller-manager"

2. 设置定期执行（如通过cron）：

bash复制# 每天检查一次并记录
0 0 * * * /usr/local/bin/check_k8s_certs.sh >> /var/log/k8s_cert_check.log

4.3 验证升级效果

升级后，确认证书检查命令现在包含所有组件：

bash复制$ rke2 certificate check | grep -E 'controller-manager|scheduler'
INFO[0000] Checking certificates for controller-manager
INFO[0000] Checking certificates for scheduler

同时检查证书位置是否已变更：

bash复制ls /var/lib/rancher/rke2/server/tls/client-kube-{scheduler,controller-manager}.crt

5. 运维建议与最佳实践

5.1 证书管理策略

1. 统一监控所有证书：

   • 即使部分证书自动轮转，也应纳入监控范围
   • 建议使用Prometheus等工具监控证书过期时间

2. 文档记录：

   • 明确记录各组件证书位置和生成方式
   • 更新运维手册中的证书检查流程

3. 定期演练：

   • 模拟证书过期场景测试恢复流程
   • 验证监控告警是否及时触发

5.2 升级注意事项

1. 备份关键数据：

   bash复制# 备份证书目录
   tar czvf /backup/rke2_tls_$(date +%F).tar.gz /var/lib/rancher/rke2/server/tls
   

2. 变更窗口选择：

   • 在业务低峰期执行升级
   • 预留回滚时间窗口

3. 验证顺序：

   • 先在一个节点上升级验证
   • 确认无问题后再滚动更新其他节点

5.3 长期架构建议

1. 考虑证书集中管理：

   • 使用外部CA（如Vault）统一签发所有证书
   • 避免组件自生成证书带来的不一致性

2. 基础设施即代码：

   • 将证书管理纳入集群部署配置
   • 使用工具如Ansible/Terraform确保一致性

3. 建立证书清单：

   markdown复制| 组件                 | 证书位置                                  | 生成方式       | 默认有效期 |
   |----------------------|------------------------------------------|----------------|------------|
   | kube-apiserver       | /var/lib/rancher/rke2/server/tls/...     | Supervisor生成 | 1年        |
   | kube-controller-manager | /var/lib/rancher/rke2/server/tls/...  | 组件生成(*)    | 1年        |
   (*)2025.05版本后将改为Supervisor生成
   

6. 故障排查与常见问题

6.1 典型问题排查流程

当控制器或调度器出现连接问题时：

1. 检查组件日志：

   bash复制journalctl -u rke2-server -n 100 | grep -i cert
   

2. 手动验证证书：

   bash复制openssl x509 -in /var/lib/rancher/rke2/server/tls/kube-controller-manager/client.crt -noout -text
   

3. 检查证书链：

   bash复制openssl verify -CAfile /var/lib/rancher/rke2/server/tls/server-ca.crt \
     /var/lib/rancher/rke2/server/tls/kube-controller-manager/client.crt
   

6.2 已知问题与解决

1. 证书续期失败：

   • 现象：组件日志报"x509: certificate has expired or is not yet valid"
   • 解决：重启对应组件强制重新生成证书

     bash复制systemctl restart rke2-server
     

2. 权限问题：

   • 现象：组件无法写入证书目录
   • 解决：确保目录权限正确

     bash复制chown -R root:root /var/lib/rancher/rke2/server/tls
     chmod 755 /var/lib/rancher/rke2/server/tls
     

3. 版本兼容性问题：

   • 现象：升级后组件无法识别新证书格式
   • 解决：确保所有节点同时升级，避免版本混用

6.3 诊断工具推荐

1. 证书检查工具增强版：

   bash复制# 扩展版检查脚本
   curl -sL https://example.com/check_certs.sh | bash -s -- --all
   

2. Kubernetes健康检查工具：

   bash复制kubectl get --raw='/readyz?verbose' | jq .
   

3. 证书过期监控：

   bash复制# 使用kubelet证书管理器检查
   /var/lib/rancher/rke2/bin/kubelet --certificate-manager-inspect
   

在实际运维中，我们团队发现这个问题通常会在两种情况下暴露：一是执行安全审计时发现证书检查不完整，二是证书实际过期导致故障。因此建议即使暂时无法升级，也至少要通过手动方式监控这些"隐藏"证书的状态。