3. 证书轮换机制：kubelet 自动轮换证书的工作原理与 kube-controller-manager 的角色
在 Kubernetes 集群中，TLS 证书是节点与控制平面之间通信的信任基石。kubelet 作为每个节点上的核心代理，其客户端证书（用于向 API Server 发起请求）默认有效期为 1 年。如果证书过期且未自动轮换，kubelet 将无法通过 API Server 的身份验证，导致节点状态变为 NotReady，进而引发 Pod 调度失败。本节深入剖析 kubelet 自动证书轮换的完整链路，以及 kube-controller-manager 在其中扮演的关键角色。
3.1 证书轮换的触发条件与核心流程
kubelet 的证书轮换并非定时任务，而是基于证书剩余有效期的百分比触发。默认配置下，当证书剩余有效期低于总有效期的 80% 时，kubelet 会启动轮换流程。整个流程分为四个阶段：
- 检查阶段：kubelet 定期（默认每 5 分钟）检查本地客户端证书的剩余有效期。
- 生成 CSR：当触发条件满足时，kubelet 生成一个新的私钥和证书签名请求（CSR），并通过 API Server 提交。
- 签名与批准：kube-controller-manager 中的
csrapproving控制器自动验证 CSR 的合法性并批准。 - 证书下发与生效：kubelet 轮询已批准的 CSR 获取签名后的证书，替换本地证书文件并重启 TLS 监听。
关键参数：
--rotate-certificates：kubelet 启动参数，默认true，启用自动轮换。--cert-dir：kubelet 证书存储目录，默认为/var/lib/kubelet/pki。--csr-duration：kube-controller-manager 参数，控制签名证书的有效期，默认8760h（1 年）。
3.2 kube-controller-manager 的 csrapproving 控制器
kube-controller-manager 中的 csrapproving 控制器是证书轮换的“自动审批官”。它监听 CertificateSigningRequest 资源，对 kubelet 提交的 CSR 进行自动验证和批准。其核心逻辑包括：
- 身份验证：验证 CSR 的
spec.username是否为system:node:<nodeName>格式，确保请求来自合法的 kubelet。 - 签名者验证：检查 CSR 的
spec.signerName是否为kubernetes.io/kubelet-client，确保是 kubelet 客户端证书请求。 - 密钥验证：验证 CSR 中的公钥与请求者身份匹配，防止伪造。
- 自动批准：通过所有验证后，控制器自动将 CSR 状态标记为
Approved，并触发签名流程。
排障提示：如果证书轮换失败，首先检查
kubectl get csr 查看 CSR 状态。若 CSR 处于 Pending 状态，说明 csrapproving 控制器未自动批准，常见原因包括 kube-controller-manager 未启用 --controllers=csrapproving，或节点身份与 CSR 中的 username 不匹配。
3.3 证书轮换失败对 Pod 调度的影响
当证书轮换失败时，kubelet 与 API Server 之间的 TLS 握手会失败，导致以下连锁反应：
| 阶段 | 现象 | 对 Pod 调度的影响 |
|---|---|---|
| 证书过期 | kubelet 无法向 API Server 上报心跳 | 节点状态变为 NotReady，调度器跳过该节点 |
| CSR 提交失败 | kubelet 日志报错 failed to create CSR |
证书无法更新，节点持续处于 NotReady |
| CSR 被拒绝 | CSR 状态为 Denied 或 Failed |
证书无法获取，节点不可调度 |
| 证书替换失败 | kubelet 无法加载新证书，TLS 监听失败 | kubelet 无法启动，节点完全离线 |
3.4 证书轮换的配置与验证
在生产环境中，建议通过以下方式确保证书轮换机制正常工作：
- 启用自动轮换：确认 kubelet 启动参数包含
--rotate-certificates=true（默认值）。 - 检查 CSR 控制器：确认 kube-controller-manager 的
--controllers参数包含csrapproving。 - 监控证书有效期：使用
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep "Not After"查看证书过期时间。 - 模拟轮换测试：在测试环境中，通过缩短
--csr-duration参数（如设置为1h）验证轮换流程是否正常。
常见陷阱：
- 如果集群使用自签名 CA，且 CA 证书未在 kubelet 的
--root-ca-file中配置，CSR 签名会失败。 - kubelet 的
--client-ca-file必须指向正确的 CA 证书，否则 API Server 无法验证 kubelet 的新证书。 - 证书轮换不会自动重启 kubelet 进程，而是通过
SIGHUP信号重新加载证书，确保零停机。
3.5 证书轮换与节点生命周期管理
证书轮换是节点生命周期管理的重要组成部分。在节点重启、升级或网络分区恢复后，kubelet 需要重新建立与 API Server 的信任关系。如果证书轮换机制存在缺陷，节点可能长时间处于 NotReady 状态，导致其上运行的 Pod 被驱逐，进而触发调度器在其他节点上重新调度 Pod，造成集群负载不均或资源争抢。