2. Kubernetes 证书体系基础：CA证书、服务证书、kubelet证书、etcd证书的作用与生命周期
Kubernetes 集群的安全通信建立在多层 PKI（公钥基础设施）之上。理解各类证书的角色、签发关系及生命周期，是进行证书轮换与故障恢复的前提。本章从根 CA 出发，逐层拆解集群中四类核心证书的职责与时效特征。
2.1 证书体系全景：分层信任模型
Kubernetes 采用两级 CA 架构：集群根 CA 和前端代理 CA（可选），但生产环境通常共用同一根 CA 签发所有组件证书。下图展示了证书分层与通信关系：
2.2 四类证书的作用与签发关系
| 证书类型 | 持有组件 | 核心作用 | 签发者 | 常见文件 |
|---|---|---|---|---|
| CA 证书 | 所有组件（信任锚点） | 签发其他所有证书；验证对端身份 | 自签发（集群初始化时生成） | ca.crt, ca.key |
| API Server 服务证书 | kube-apiserver | 对外提供 HTTPS 服务；客户端（kubectl、kubelet、controller）验证服务端身份 | 集群 CA | apiserver.crt, apiserver.key |
| kubelet 证书 | kubelet（每个节点） | 服务端：kubelet 监听端口；客户端：向 API Server 注册并上报状态 | 集群 CA 或 kubelet 证书签名请求（CSR）自动签发 | kubelet.crt, kubelet.key |
| etcd 证书 | etcd 集群成员 | 服务端：etcd 节点间 gRPC 通信；客户端：API Server 访问 etcd | 集群 CA（通常独立 etcd CA 或共用） | etcd-server.crt, etcd-peer.crt, etcd-client.crt |
关键区别：API Server 服务证书仅用于服务端身份证明；kubelet 证书是唯一同时承担服务端（kubelet API）和客户端（向 API Server 发起请求）双重角色的证书；etcd 证书则分为 peer（节点间）、server（客户端访问）、client（API Server 访问）三种子类型。
2.3 证书生命周期与默认有效期
Kubernetes 各组件证书的默认有效期因签发方式和集群版本而异。下表汇总了常见场景下的生命周期参数：
| 证书类型 | 默认有效期 | 轮换触发条件 | 自动轮换支持 |
|---|---|---|---|
| 集群根 CA | 10 年（kubeadm 默认） | 手动轮换（极少操作） | 否（需手动更新所有子证书） |
| API Server 服务证书 | 1 年（kubeadm 默认） | 到期前 90 天（kubeadm 自动检查） | kubeadm 支持 kubeadm certs renew |
| kubelet 证书 | 1 年（kubeadm 默认） | 到期前 30 天（kubelet 自动发起 CSR） | 是（kubelet 证书轮换特性） |
| etcd 证书 | 1 年（kubeadm 默认） | 到期前 90 天（kubeadm 自动检查） | kubeadm 支持 kubeadm certs renew |
| kube-controller-manager / kube-scheduler 客户端证书 | 1 年（kubeadm 默认） | 到期前 90 天 | kubeadm 支持 |
生命周期管理要点：
- 根 CA 有效期最长（10 年），但一旦轮换，所有子证书必须重新签发，属于高风险操作。
- kubelet 证书是唯一支持自动 CSR 轮换的组件，但需在 kubelet 配置中启用
rotateCertificates: true。 - etcd 证书轮换需按节点逐个进行，且必须保证集群多数节点在线，否则可能导致 etcd 集群分裂。
- API Server 证书轮换后，所有客户端（kubectl、kubelet、controller）必须重新加载信任链，通常需要重启相关 Pod 或进程。
2.4 证书文件路径与命名规范
以 kubeadm 部署的集群为例，证书文件默认存放在各节点的 /etc/kubernetes/pki/ 目录下：
/etc/kubernetes/pki/
├── ca.crt # 集群根 CA 证书（公钥）
├── ca.key # 集群根 CA 私钥（⚠️ 最高机密）
├── apiserver.crt # API Server 服务证书
├── apiserver.key # API Server 服务私钥
├── apiserver-kubelet-client.crt # API Server 访问 kubelet 的客户端证书
├── apiserver-kubelet-client.key
├── front-proxy-ca.crt # 前端代理 CA（可选）
├── front-proxy-client.crt # 前端代理客户端证书
├── etcd/
│ ├── ca.crt # etcd CA 证书
│ ├── ca.key # etcd CA 私钥
│ ├── server.crt # etcd 服务端证书
│ ├── server.key
│ ├── peer.crt # etcd 节点间通信证书
│ ├── peer.key
│ ├── healthcheck-client.crt # etcd 健康检查客户端证书
│ └── healthcheck-client.key
└── sa.key / sa.pub # Service Account 密钥对（非证书，用于 JWT 签名）
⚠️ 安全警告：CA 私钥（ca.key、etcd/ca.key）是集群安全的根基。一旦泄露，攻击者可签发任意证书，完全接管集群。生产环境中应使用硬件安全模块（HSM）或密钥管理服务（KMS）保护，并严格限制文件权限为 0600。
2.5 证书过期对集群的影响
不同证书过期会导致不同的故障模式。理解这些模式有助于在升级前制定证书检查策略：
| 过期证书 | 故障表现 | 影响范围 | 恢复难度 |
|---|---|---|---|
| 根 CA | 所有组件 TLS 握手失败；kubectl 无法连接集群 | 全局 | 高（需重建信任链） |
| API Server 服务证书 | 客户端报 x509: certificate has expired or is not yet valid | 全局（所有 API 调用中断） | 中（kubeadm renew 后重启组件） |
| kubelet 证书 | 节点状态变为 NotReady；kubectl get nodes 显示节点不可达 | 单节点 | 低（自动 CSR 或手动签发） |
| etcd 证书 | etcd 集群脑裂；API Server 无法读写 etcd；Pod 调度异常 | 全局（数据面中断） | 高（需逐个节点轮换并验证成员关系） |
升级前检查建议：在集群升级前，使用 kubeadm certs check-expiration 检查所有证书剩余有效期。对于剩余不足 90 天的证书，优先执行轮换再启动升级流程，避免升级过程中证书过期导致回滚困难。
2.6 证书轮换的基本流程（概念层）
证书轮换的核心步骤不因组件而异，但不同证书的轮换顺序和重启要求不同。下图展示了通用轮换流程：
2.7 证书与 Pod 调度的隐性关联
证书状态直接影响 Pod 调度决策，这种关联在升级场景中尤为关键：
- kubelet 证书过期 → 节点 NotReady → 调度器将 Pod 驱逐：当 kubelet 证书过期，节点状态变为 NotReady，调度器会在
pod-eviction-timeout（默认 5 分钟）后将 Pod 标记为 Terminating，并调度到其他可用节点。 - etcd 证书过期 → API Server 不可用 → 调度器停止工作：etcd 是集群的持久化存储，证书过期导致 API Server 无法读写 etcd，调度器无法获取节点信息和 Pod 状态，所有调度决策暂停。
- API Server 证书过期 → 所有客户端连接失败 → 调度器无法注册：kube-scheduler 作为 API Server 的客户端，证书过期后无法通过 TLS 握手，调度器 Pod 会持续 CrashLoopBackOff。
升级协同策略：在集群升级前，先执行证书轮换并验证所有节点 Ready、etcd 集群健康，再启动控制面组件升级。这可以避免证书过期与版本不兼容问题叠加，降低故障恢复复杂度。