3. 证书轮换机制：kubeadm自动轮换、手动轮换、cert-manager集成、轮换触发条件
Kubernetes 集群的证书轮换机制决定了证书生命周期的管理方式与运维介入程度。根据集群初始化方式（kubeadm 或二进制部署）以及证书管理策略（原生或第三方工具），轮换路径可分为 自动轮换、手动轮换 和 cert-manager 集成轮换 三类。理解每种机制的触发条件与执行流程，是制定容量规划与资源预留策略的前提。
3.1 kubeadm 自动轮换
kubeadm 自 v1.15 起内置了控制平面证书的自动轮换能力，适用于由 kubeadm init/join 引导的集群。其核心机制基于 kube-controller-manager 中的 csrapproving controller 和 kubelet 的证书请求。
自动轮换适用证书范围： kubelet 客户端证书、kubelet 服务端证书、admin.conf、kubelet.conf、controller-manager.conf、scheduler.conf 中的客户端证书。CA 证书（ca.crt）不会自动轮换。
3.1.1 自动轮换流程
- 证书到期检测： kubelet 在证书剩余时间低于
--rotate-certificates阈值（默认 80% 生命周期）时，生成密钥对并构造 CertificateSigningRequest（CSR）。 - CSR 提交与审批： kubelet 通过 API Server 提交 CSR，csrapproving controller 自动审批符合节点身份规则的 CSR。
- 证书签发与分发： kube-controller-manager 使用集群 CA 签发新证书，kubelet 获取并更新本地证书文件。
- kubeconfig 更新： kubeadm 的
kubeadm certs renew命令或kubeadm upgrade流程会同步更新各控制平面组件的 kubeconfig 文件。
容量规划提示： 自动轮换期间，API Server 会承受额外的 CSR 审批与证书签发负载。在拥有 500+ 节点的大型集群中，建议将 kubelet 的
--rotate-certificates 间隔设置为 10 分钟以上，避免突发大量 CSR 请求导致 API Server 过载。
3.1.2 自动轮换触发条件
| 触发条件 | 说明 | 默认阈值 |
|---|---|---|
| 证书剩余时间 < 80% 总生命周期 | kubelet 客户端证书（1 年有效期）在剩余约 73 天时触发 | 80% |
| kubelet 重启或证书文件变更 | kubelet 检测到本地证书与期望状态不一致 | — |
| kubeadm upgrade 执行 | 升级过程中自动调用 kubeadm certs renew all |
— |
手动执行 kubeadm certs renew |
运维人员主动触发全部或指定证书轮换 | — |
3.2 手动轮换
对于非 kubeadm 部署的集群（如二进制部署、kops、kubespray 等），或需要精细控制轮换窗口的场景，运维人员需执行手动轮换。手动轮换通常包含以下步骤：
- 备份现有证书与密钥： 备份
/etc/kubernetes/pki/目录及所有 kubeconfig 文件。 - 生成新证书： 使用
openssl、cfssl或集群 CA 签发新证书，确保 SAN（Subject Alternative Name）包含所有控制平面节点 IP、ClusterIP、DNS 名称。 - 分发证书： 将新证书 scp 到所有控制平面节点，覆盖旧文件。
- 重启组件： 按顺序重启 kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy。
- 验证连通性： 使用
kubectl get nodes、kubectl get csr确认集群状态正常。
风险提示： 手动轮换期间，如果 CA 证书同时被轮换，所有依赖旧 CA 签发的组件（包括 kubelet、kube-proxy、CNI 插件、ingress controller）都需要更新信任链。建议在非生产环境演练至少 3 次后再执行生产轮换。
3.3 cert-manager 集成轮换
cert-manager 是 Kubernetes 原生的证书管理工具，通过 Issuer 和 Certificate 资源对象实现证书的自动签发与轮换。它支持自签名 CA、Let's Encrypt、Vault、Venafi 等多种签发源。
3.3.1 cert-manager 轮换架构
3.3.2 cert-manager 轮换触发条件
| 触发条件 | 配置字段 | 默认值 | 说明 |
|---|---|---|---|
| 证书到期前 N 天 | spec.renewBefore |
30 天 | 证书剩余时间低于此值时触发轮换 |
| 证书有效期变更 | spec.duration |
90 天 | 修改 duration 后，cert-manager 重新计算轮换时间 |
| Issuer 密钥更新 | — | — | Issuer 引用的 Secret 或外部 CA 密钥变更时触发重新签发 |
| 手动重新签发 | kubectl annotate certificate ... --overwrite |
— | 添加 cert-manager.io/issue-temporary-certificate: "true" 注解 |
3.4 三种轮换机制对比
| 维度 | kubeadm 自动轮换 | 手动轮换 | cert-manager 集成 |
|---|---|---|---|
| 适用集群 | kubeadm 引导的集群 | 所有集群（特别是非 kubeadm 部署） | 所有集群（需安装 cert-manager） |
| CA 轮换支持 | 不支持（需手动处理） | 支持（需手动更新信任链） | 支持（通过 CA 证书资源自动管理） |
| 轮换粒度 | 节点级别（kubelet 自动） | 组件级别（逐个文件替换） | 资源级别（Certificate CR 维度） |
| 运维复杂度 | 低（自动化程度高） | 高（需人工介入多个步骤） | 中（需维护 CR 与 Issuer 配置） |
| 对 API Server 压力 | 中等（CSR 批量提交） | 低（人工控制节奏） | 低到中（取决于轮换窗口配置） |
| 容量规划关注点 | CSR 并发数、kubelet 重启风暴 | 组件重启顺序、服务中断窗口 | Secret 更新频率、Ingress/网关证书热加载 |
3.5 轮换触发条件汇总
无论采用哪种机制，证书轮换的触发条件可归纳为以下三类：
- 时间驱动： 证书剩余有效期低于预设阈值（如 80%、30 天、10% 生命周期）。这是最常见的触发方式。
- 事件驱动： 集群升级、CA 密钥泄露、证书被吊销、组件重启等外部事件触发轮换。
- 策略驱动： 安全合规要求缩短证书有效期（如从 1 年改为 90 天），或 GitOps 流程中修改 Certificate 资源触发重新签发。
容量规划建议： 在制定轮换计划时，建议将时间驱动轮换分散到不同时间窗口（例如按节点池分批、按证书类型错峰），避免所有证书在同一时刻到期引发大规模并发轮换。对于 cert-manager 管理的 ingress 证书，可设置
spec.renewBefore 为 45 天，预留充足的重试窗口。