3. kubelet 证书工作原理：TLS Bootstrapping 与自动轮换机制
在 Kubernetes 集群中，kubelet 作为每个节点的核心代理，需要与 API Server 进行双向 TLS 通信。为了在规模化集群中避免手动签发和管理节点证书，Kubernetes 设计了 TLS Bootstrapping（TLS 引导） 和 证书自动轮换 机制。本章将深入剖析这两个关键流程的工作原理。
3.1 TLS Bootstrapping：从零到可信的首次握手
TLS Bootstrapping 允许 kubelet 在首次启动时，使用一个预先共享的 Bootstrap 向 API Server 发起证书签名请求（CSR），从而自动获取一个由集群 CA 签发的 kubelet 客户端证书。整个过程无需管理员手动为每个节点生成证书。
核心前提： 集群必须预先配置 Bootstrap （通常存储在
kube-system 命名空间的 Secret 中），并且 API Server 需要启用 --enable-bootstrap--auth 认证器。
3.1.1 引导流程详解
下图展示了 kubelet 从无证书状态到获取正式客户端证书的完整引导流程：
3.1.2 引导过程中的关键组件
| 组件/概念 | 角色与说明 |
|---|---|
| Bootstrap | 一个预共享的 Secret，格式为 [-id].[-secret]，用于 kubelet 的初始身份认证。 |
| CertificateSigningRequest (CSR) | kubelet 提交的证书签名请求对象，包含公钥和身份信息。 |
| CSR Approving Controller | 集群内置的控制器，根据 RBAC 规则自动审批来自 system:bootstrappers 组的 CSR。 |
| kubelet 客户端证书 | 由集群 CA 签发的正式证书，默认路径为 /var/lib/kubelet/pki/kubelet-client-current.pem。 |
3.2 证书自动轮换机制：无中断的证书续期
kubelet 客户端证书具有有效期（通常为 1 年）。证书自动轮换机制允许 kubelet 在证书即将过期时，自动发起新的 CSR 并获取新证书，而无需重启 kubelet 或手动干预。此机制由 --rotate-certificates 和 --rotate-server-certificates 两个 kubelet 参数控制。
最佳实践： 在集群升级后，务必确认 kubelet 的
--rotate-certificates=true 参数已启用。证书轮换失败是导致节点在升级后失联的常见原因之一。
3.2.1 自动轮换流程
下图展示了 kubelet 在证书过期前自动发起轮换的完整生命周期：
3.2.2 证书轮换的关键参数与行为
| kubelet 参数 | 默认值 | 作用 |
|---|---|---|
--rotate-certificates |
true | 启用客户端证书的自动轮换。kubelet 会在证书过期前自动发起 CSR。 |
--rotate-server-certificates |
false | 启用 kubelet 服务端证书（用于 kubelet API）的自动轮换。通常需要结合 --cert-dir 使用。 |
--cert-dir |
/var/lib/kubelet/pki | 指定 kubelet 证书和密钥的存储目录。 |
3.3 证书轮换后的节点通信验证要点
在集群升级后，证书轮换作业的成功与否直接决定了 kubelet 能否与 API Server 恢复通信。以下是验证证书轮换是否正常的关键检查点：
- 检查证书文件时间戳： 查看
/var/lib/kubelet/pki/kubelet-client-current.pem的修改时间，确认是否在升级后更新。 - 检查 kubelet 日志： 搜索
Certificate rotation或CSR关键字，确认轮换流程是否触发。 - 检查 CSR 对象： 使用
kubectl get csr查看是否有Pending或Approved状态的 CSR。 - 验证节点状态： 使用
kubectl get nodes确认节点状态是否为Ready。
常见故障场景： 如果集群升级后 CA 证书发生变更（例如使用了新的 CA 密钥对），旧的 kubelet 证书将无法通过验证。此时需要手动清理旧的证书文件并重启 kubelet，使其重新执行 TLS Bootstrapping 流程。