3. Kubernetes 证书体系：各组件的证书用途与生命周期

聊证书轮换，得先搞清楚 K8s 里到底有哪些证书在干活。我见过不少团队，一上来就写脚本轮换，结果漏了 etcd 的证书，集群直接挂了。嗯，咱们先把家底摸清楚。

3.1 核心组件的证书全景

一个生产级 K8s 集群，至少有四个组件需要证书通信。我习惯把它们分成两类：控制面内部通信和节点与 apiserver 通信。

3.2 kube-apiserver：证书体系的中心

apiserver 是整个集群的入口。它需要两套证书：

• 服务端证书：给客户端（kubectl、kubelet、controller-manager 等）验证 apiserver 的身份。
• CA 证书：用来签发其他组件的客户端证书。

说白了，apiserver 既是服务端，也是信任锚点。我遇到过一个问题：有人把 apiserver 的证书 SAN 只配了 IP，没配域名，结果内部组件用 Service 域名访问时直接 TLS 握手失败。

3.3 etcd：数据安全的核心

etcd 存储了集群所有状态，它的证书要求最严格。etcd 需要：

• 服务端证书：给 apiserver 连接 etcd 时验证。
• 客户端证书：etcd 集群成员之间互相验证（peer 通信）。
• CA 证书：etcd 自己的 CA，用于签发上述证书。

我记得有一次排查 etcd 证书过期，发现 etcd 的 peer 证书和 client 证书用的是同一个 CA，但过期时间不同。结果 client 证书还没过期，peer 证书先过期了，集群直接脑裂。

3.4 kubelet：节点身份的凭证

kubelet 的证书体系比较特殊。它有两类证书：

1. 服务端证书：kubelet 的 HTTPS 端口（10250）用，apiserver 通过它来获取 Pod 日志、执行 exec。
2. 客户端证书：kubelet 主动连接 apiserver 时使用，比如上报节点状态。

K8s 1.8 之后引入了 --rotate-certificates 特性，kubelet 可以自动轮换客户端证书。但服务端证书的轮换，嗯，还是得靠我们手动或工具来做。

3.5 其他组件的证书

组件	证书用途	签发方	默认有效期
kube-controller-manager	连接 apiserver 的客户端证书	apiserver CA	1 年
kube-scheduler	连接 apiserver 的客户端证书	apiserver CA	1 年
kube-proxy	连接 apiserver 的客户端证书	apiserver CA	1 年
kubectl（管理员）	用户认证客户端证书	apiserver CA	自定义

你想想看，这些组件的证书都依赖同一个 CA。一旦 CA 证书过期，整个集群的 TLS 通信就全断了。所以证书轮换的核心，其实是 CA 证书的轮换策略。

3.6 证书生命周期管理

K8s 1.8 之前，证书默认有效期是 1 年。1.8 之后，kubeadm 签发的证书默认是 10 年。但生产环境我建议不要依赖默认值。

我个人习惯的做法：

• apiserver CA 证书：5 年有效期，提前 6 个月开始规划轮换。
• etcd 证书：3 年有效期，因为 etcd 证书轮换风险最高。
• kubelet 证书：1 年有效期，配合自动轮换机制。
• 管理员证书：6 个月，甚至更短。

3.7 证书轮换的难点在哪

单集群证书轮换已经够复杂了，多集群更是噩梦。我总结几个常见问题：

1. 依赖关系复杂：apiserver 证书过期，所有组件都连不上。
2. etcd 证书轮换风险高：顺序错了，集群直接不可用。
3. kubelet 证书数量多：几百个节点，手动换不现实。
4. CA 证书轮换：需要同时信任新旧 CA，否则集群会断连。

说白了，证书轮换不是换个文件重启服务那么简单。你得考虑信任链、顺序、回滚方案。后面几章我会详细讲每个组件的轮换步骤和自动化方案。