2. Kubernetes证书体系概述：CA证书、服务端证书、客户端证书、kubelet证书的角色
Kubernetes 集群的安全通信建立在 双向 TLS（mTLS） 基础之上。集群内所有组件之间的通信——无论是控制平面组件之间的内部调用，还是 kubelet 与 API Server 之间的交互——都通过 X.509 证书进行身份验证和加密。理解证书体系中不同角色的划分，是掌握证书轮换与节点通信验证的前提。
2.1 证书体系的核心角色与分层结构
Kubernetes 证书体系采用 根 CA → 中间 CA（可选）→ 叶子证书 的分层信任模型。集群启动时，管理员或部署工具（如 kubeadm）会生成一个根证书颁发机构（Root CA），然后由该 CA 签发所有组件的服务端证书和客户端证书。
2.2 各类证书的角色与职责
下表详细列出了 Kubernetes 证书体系中各类证书的用途、持有者和验证方向：
| 证书类型 | 持有组件 | 用途 | 验证方向 | 轮换影响范围 |
|---|---|---|---|---|
| CA 证书 | 所有组件（预置） | 签发和验证所有叶子证书的信任锚点 | 双向：签发者 + 验证者 | 全局：所有叶子证书必须重新签发 |
| 服务端证书 | API Server、kubelet | 向客户端证明自身身份，建立 TLS 加密通道 | 客户端 → 服务端 | 影响所有连接该服务的客户端 |
| 客户端证书 | kubelet、kube-controller-manager、kube-scheduler、kube-proxy | 向服务端证明自身身份，获取授权访问 | 服务端 → 客户端 | 影响该组件对 API Server 的访问 |
| kubelet 证书 | kubelet（每个节点） | 同时作为服务端（接收 API Server 请求）和客户端（向 API Server 注册/上报状态） | 双向：API Server ↔ kubelet | 影响节点注册、Pod 调度、kubectl exec/logs |
2.3 CA 证书：信任的基石
CA 证书是整个集群安全通信的 根信任锚点。在集群初始化时，kubeadm 或其他部署工具会生成一个自签名的根 CA 证书（通常位于 /etc/kubernetes/pki/ca.crt 和 ca.key）。
- ca.crt：公钥证书，分发给所有组件，用于验证其他组件证书的合法性。
- ca.key：私钥，仅保存在控制平面节点，用于签发新的叶子证书。
2.4 服务端证书：证明“我是谁”
服务端证书由持有该服务的组件使用，在 TLS 握手阶段发送给客户端，用于证明自己的身份。Kubernetes 中主要使用服务端证书的组件包括：
- API Server：使用
apiserver.crt和apiserver.key，证书的 CN（Common Name）通常设置为kube-apiserver，SAN（Subject Alternative Name）包含 API Server 的 Service IP、Cluster IP、DNS 名称等。 - kubelet：使用
kubelet.crt和kubelet.key，证书的 CN 通常设置为节点名称，SAN 包含节点的各种 IP 地址和主机名。
服务端证书的 SAN 字段 至关重要。如果客户端通过某个域名或 IP 访问服务端，但该域名或 IP 不在服务端证书的 SAN 列表中，TLS 握手将失败。
2.5 客户端证书：证明“我有权限”
客户端证书由发起请求的组件持有，用于向服务端证明自己的身份，并获取相应的授权。Kubernetes 使用 证书中的 CN 字段映射到用户名，使用 Organization（O）字段映射到用户组，然后通过 RBAC 进行授权。
| 组件 | 证书文件 | CN（用户名） | O（用户组） | RBAC 绑定 |
|---|---|---|---|---|
| kube-controller-manager | controller-manager.crt | system:kube-controller-manager | system:masters | cluster-admin |
| kube-scheduler | scheduler.crt | system:kube-scheduler | system:masters | cluster-admin |
| kube-proxy | kube-proxy.crt | system:kube-proxy | system:node-proxier | system:node-proxier |
| kubelet（客户端模式） | kubelet-client.crt | system:node:<nodeName> | system:nodes | system:node |
2.6 kubelet 证书：双重角色的关键组件
kubelet 是 Kubernetes 证书体系中最特殊的组件，因为它同时扮演 服务端 和 客户端 两个角色：
- 服务端角色：kubelet 在节点上启动一个 HTTPS 服务（默认端口 10250），用于接收 API Server 的请求（如
kubectl exec、kubectl logs、Pod 状态查询）。此时 kubelet 使用kubelet.crt向 API Server 证明自己是合法的节点。 - 客户端角色：kubelet 需要主动向 API Server 注册节点、上报节点状态、更新 Pod 状态。此时 kubelet 使用
kubelet-client.crt向 API Server 证明自己的身份。
--rotate-certificates 和 --rotate-server-certificates 参数正确配置。
2.7 证书轮换的触发条件与影响
在集群升级场景中，证书轮换通常由以下原因触发：
- CA 证书变更：升级后使用了新的 CA 证书，所有叶子证书必须重新签发。
- 证书过期：kubelet 证书默认有效期为 1 年，到期后需要轮换。
- 节点加入/重建：新节点需要生成新的 kubelet 证书。
- 安全策略更新：证书算法升级（如从 RSA 2048 升级到 ECDSA P-384）。
kubeadm certs check-expiration 命令检查所有证书的过期时间。对于 kubelet 证书，可以通过 openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout 查看证书详情。升级后，务必验证 kubelet 的证书是否已成功轮换，以及节点通信是否正常。
2.8 证书验证流程（mTLS 握手）
当 kubelet 与 API Server 建立连接时，完整的双向 TLS 验证流程如下：
- TCP 连接建立：客户端（如 kubelet）向服务端（如 API Server）发起 TCP 连接。
- 服务端发送证书：API Server 将自己的服务端证书（apiserver.crt）发送给 kubelet。
- 客户端验证服务端：kubelet 使用预置的 CA 证书（ca.crt）验证 API Server 证书的签名链和 SAN 字段。
- 客户端发送证书：kubelet 将自己的客户端证书（kubelet-client.crt）发送给 API Server。
- 服务端验证客户端：API Server 使用预置的 CA 证书验证 kubelet 客户端证书的签名链和 CN 字段。
- RBAC 授权：API Server 根据客户端证书的 CN 和 O 字段，查询 RBAC 绑定，判断是否有权限执行请求的操作。
- 加密通信：验证通过后，双方使用协商的对称密钥进行加密通信。
如果上述任何一步验证失败，连接将被拒绝，并返回 TLS 握手错误。在集群升级后的证书轮换作业中，最常见的失败原因就是 CA 证书不匹配 或 证书 SAN 字段缺失。