4. Kubernetes 证书体系概述：集群内部证书类型与 CA 角色
Kubernetes 集群的安全通信建立在 双向 TLS（mTLS） 基础之上。集群内部所有组件之间的通信（如 kubelet 与 API Server、etcd 与 API Server、kube-scheduler 与 API Server）均通过 X.509 数字证书进行身份验证和加密。理解证书体系是掌握证书轮换作业流程的前提。
4.1 证书颁发机构（CA）角色
Kubernetes 集群通常维护 两个独立的 CA，分别用于集群内部通信和 etcd 数据存储层。CA 是整个信任链的根，负责签发和验证所有组件证书。
| CA 类型 | 用途 | 默认密钥文件 | 证书文件 |
|---|---|---|---|
| 集群 CA | 签发 API Server、kubelet、kube-controller-manager、kube-scheduler、kube-proxy、admin 用户等组件证书 | /etc/kubernetes/pki/ca.key |
/etc/kubernetes/pki/ca.crt |
| etcd CA | 签发 etcd 集群内部节点间通信证书、etcd 客户端证书（API Server 访问 etcd 使用） | /etc/kubernetes/pki/etcd/ca.key |
/etc/kubernetes/pki/etcd/ca.crt |
最佳实践：生产环境中建议将集群 CA 和 etcd CA 的私钥离线存储或使用硬件安全模块（HSM）保护。CA 私钥泄露意味着整个集群信任体系被攻破。
4.2 集群内部核心证书类型
Kubernetes 集群中主要存在以下五类证书，每类证书对应不同的组件身份和通信场景。
4.2.1 API Server 证书
- 用途：客户端（kubectl、kubelet、scheduler、controller-manager）验证 API Server 的身份；API Server 对外提供 HTTPS 服务。
- 常见文件名：
apiserver.crt、apiserver.key - SAN（Subject Alternative Name）：必须包含 API Server 的 Service IP（通常为
10.96.0.1）、集群域名（kubernetes、kubernetes.default.svc）、Master 节点 IP 及 DNS 名称。 - 签发者：集群 CA
4.2.2 kubelet 证书
- 用途：kubelet 向 API Server 注册自身身份；API Server 与 kubelet 通信（如
kubectl logs、kubectl exec）时验证 kubelet 身份。 - 常见文件名：
kubelet.crt、kubelet.key（或由 kubelet 自动轮换的kubelet-client-current.pem） - 证书轮换机制：kubelet 支持 证书签名请求（CSR）自动轮换，通过
--rotate-certificates和--rotate-server-certificates参数控制。 - 签发者：集群 CA
4.2.3 etcd 证书
- 用途：etcd 集群成员间通信（peer 通信）、客户端（API Server）访问 etcd 数据存储。
- 常见文件名：
etcd/server.crt、etcd/server.key（服务端）；etcd/peer.crt、etcd/peer.key（节点间）；apiserver-etcd-client.crt、apiserver-etcd-client.key（API Server 客户端） - 签发者：etcd CA
4.2.4 控制平面组件证书
- kube-controller-manager：使用
controller-manager.crt与 API Server 通信。 - kube-scheduler：使用
scheduler.crt与 API Server 通信。 - kube-proxy：使用
kube-proxy.crt与 API Server 通信（通常以 ServiceAccount 方式运行，但传统部署仍使用证书）。 - 签发者：集群 CA
4.2.5 管理员与 ServiceAccount 证书
- admin 证书：用于 kubectl 命令行工具与 API Server 的初始认证，通常为
admin.crt、admin.key。 - ServiceAccount 证书：每个 ServiceAccount 自动挂载的 Secret 中包含 CA 证书，用于 Pod 内应用与 API Server 通信。
关键指标：一个典型生产集群中，证书数量通常在 20~50 个之间（取决于节点数、控制平面副本数、etcd 成员数）。证书轮换作业必须覆盖所有证书类型，遗漏任何一类都会导致集群通信中断。
4.3 证书体系架构图
下图展示了 Kubernetes 集群内部证书体系的分层结构，包括两个 CA 的信任链以及各组件证书的签发关系。
4.4 证书生命周期与轮换触发条件
Kubernetes 证书默认有效期因部署工具而异。以下为常见场景的证书有效期对比：
| 部署工具 | 默认证书有效期 | CA 有效期 | 轮换触发条件 |
|---|---|---|---|
| kubeadm | 1 年 | 10 年 | 证书到期前 3 个月（kubeadm 会发出警告） |
| Kops | 1 年 | 10 年 | 集群升级时自动轮换 |
| Kubespray | 5 年 | 10 年 | 手动触发或通过 Ansible playbook 轮换 |
| 二进制部署 | 自定义（通常 1~5 年） | 自定义 | 完全手动管理 |
常见故障：证书过期是 Kubernetes 集群故障的 Top 3 原因之一。证书过期后，kubelet 无法注册节点、API Server 无法访问 etcd、kubectl 命令全部失败。建议在证书到期前 60 天完成轮换，并建立证书到期监控告警。
4.5 证书文件分布与检查命令
证书文件通常存储在 Master 节点的 /etc/kubernetes/pki/ 目录下。以下为常用检查命令：
# 查看证书有效期（所有 .crt 文件）
for cert in /etc/kubernetes/pki/*.crt; do
echo "=== $cert ==="
openssl x509 -in "$cert" -noout -dates -subject
done
# 查看 etcd 证书
for cert in /etc/kubernetes/pki/etcd/*.crt; do
echo "=== $cert ==="
openssl x509 -in "$cert" -noout -dates -subject
done
# 检查证书是否由正确的 CA 签发
openssl verify -CAfile /etc/kubernetes/pki/ca.crt /etc/kubernetes/pki/apiserver.crt
自动化建议：将上述检查命令写入 CronJob，每周执行一次，并将结果发送到监控系统（如 Prometheus + Alertmanager），实现证书到期自动告警。
4.6 证书轮换的核心原则
- 先 CA、后组件：如果 CA 证书需要轮换（如 CA 私钥泄露），必须先轮换 CA 本身，再重新签发所有组件证书。
- 先 etcd、后 API Server：etcd 是集群的数据存储层，必须先确保 etcd 证书轮换完成且集群健康，再轮换 API Server 证书。
- 滚动而非同时：对于多副本组件（如 API Server、etcd），采用滚动方式逐个节点轮换，避免集群整体不可用。
- 保留旧证书至确认无误：轮换完成后，保留旧证书文件至少一个证书生命周期，以便回滚。