1. K8s 证书体系概述
Kubernetes 集群的安全通信完全建立在 PKI（公钥基础设施） 之上。每个组件之间的 TLS 握手、身份验证与授权决策，都依赖由集群 CA 签发的 X.509 证书。理解证书体系是进行证书轮换、兼容性排查与节点通信验证的前提。
核心原则：K8s 不依赖外部 CA（除非显式配置），默认使用自建的双层 PKI 结构——根 CA 签发中间 CA 或直接签发各组件证书，所有证书在集群初始化时由
kubeadm 或手动工具生成。
1.1 K8s PKI 架构
K8s PKI 采用 分层信任模型，主要包含两类 CA：
- 集群 CA（Cluster CA）： 签发 API Server 的 Server 证书、kubelet 的 Client 证书、以及 kubeconfig 中的用户证书。
- etcd CA： 独立于集群 CA，专门签发 etcd 成员间通信及 etcd 与 API Server 之间的证书。
这种分离设计允许 etcd 集群在证书轮换时不影响控制面组件，反之亦然，降低了轮换风险。
1.2 证书类型与用途
K8s 集群中主要存在以下四类证书，每类证书的 Key Usage 和 Extended Key Usage 决定了其允许的通信角色：
| 证书类型 | 签发对象 | 关键用途（Key Usage） | 典型文件路径（kubeadm） |
|---|---|---|---|
| CA 证书 | 集群 CA / etcd CA | Certificate Sign, CRL Sign | /etc/kubernetes/pki/ca.crt/etc/kubernetes/pki/etcd/ca.crt |
| Server 证书 | API Server, kubelet, etcd 成员 | Server Auth (TLS Web Server Authentication) | apiserver.crt, kubelet.crt, etcd/server.crt |
| Client 证书 | kubelet, kube-controller-manager, scheduler, admin | Client Auth (TLS Web Client Authentication) | kubelet-client.crt, admin.crt, controller-manager.crt |
| etcd 证书 | etcd 成员间通信、etcd 客户端 | Server Auth + Client Auth（通常组合使用） | /etc/kubernetes/pki/etcd/server.crt/etc/kubernetes/pki/etcd/peer.crt |
关键检查点：证书轮换时最容易遗漏的是 Extended Key Usage 字段。例如，kubelet 的 Server 证书必须同时包含
serverAuth 和 clientAuth，否则 kubelet 无法向 API Server 发起心跳。
1.3 证书生命周期管理
K8s 证书的生命周期包含 生成 → 分发 → 使用 → 监控 → 轮换 五个阶段。kubeadm 管理的集群默认证书有效期为 1 年，etcd 证书同样为 1 年。手动管理的集群可能使用更长的有效期（如 5 年或 10 年），但这会增大私钥泄露的风险。
1.4 证书轮换的关键时间窗口
证书轮换不是一次性操作，而是需要规划时间窗口的工程活动。以下表格列出了不同证书的轮换优先级与影响范围：
| 证书 | 默认有效期 | 轮换影响 | 推荐轮换策略 |
|---|---|---|---|
| 集群 CA 证书 | 10 年 | 所有子证书需重新签发，影响最大 | 提前 6 个月规划，分阶段替换 |
| API Server Server 证书 | 1 年 | kubectl 及外部客户端连接中断 | 到期前 30 天轮换，配合 kubeconfig 更新 |
| kubelet 证书 | 1 年 | 节点心跳、Pod 日志/exec 功能失效 | 启用 RotateKubeletServerCertificate 特性 |
| etcd 证书 | 1 年 | etcd 集群分裂、控制面不可用 | 滚动轮换，一次一个成员 |
常见陷阱：很多运维人员只轮换了 API Server 证书，却忽略了
/etc/kubernetes/pki/etcd/ 下的 etcd 证书。etcd 证书过期会导致 API Server 无法连接 etcd，整个集群进入只读或不可用状态。务必在轮换清单中同时包含 etcd 证书。