Kubernetes 使用大量 TLS 证书完成组件间身份认证和加密通信。对于 kubeadm 管理的集群，证书到期可能导致 kubectl 无法连接、控制面组件通信失败，甚至影响集群恢复。因此，证书管理应当是一项提前规划的运维工作，而不是到期后的临时抢修。
本文只讨论 kubeadm 本地 CA 管理的控制平面证书。使用外部 CA、托管 Kubernetes 或其他安装工具的集群，流程可能完全不同。
一、Kubernetes 中有哪些重要证书
kubeadm 通常把大部分 PKI 文件放在 /etc/kubernetes/pki，把控制面组件使用的 kubeconfig 放在 /etc/kubernetes。
常见文件包括：
1. API Server 服务端证书。
2. API Server 访问 kubelet 和 etcd 的客户端证书。
3. etcd 服务端、节点间和健康检查证书。
4. front-proxy 客户端证书。
5. admin.conf、controller-manager.conf 和 scheduler.conf 中嵌入的客户端证书。
ca.key、etcd/ca.key、front-proxy-ca.key 以及 sa.key 都属于高度敏感的私钥。它们不应出现在博客、聊天记录、普通备份目录或代码仓库中。
二、先检查证书有效期
在控制平面节点执行：
sudo kubeadm certs check-expiration
输出会显示证书到期时间、剩余有效期、签发 CA，以及证书是否由外部系统管理。
也可以检查单个证书：
sudo openssl x509 \
-in /etc/kubernetes/pki/apiserver.crt \
-noout -subject -issuer -dates
建议把剩余有效期接入监控，在到期前数月告警。不要等到只剩几天才安排维护。
三、续签前必须做的准备
1. 确认集群确实由 kubeadm 管理，并记录 kubeadm 与 Kubernetes 版本。
2. 检查所有节点和控制面组件当前是否健康。
3. 安排维护窗口，并准备回滚方案。
4. 安全备份 /etc/kubernetes，严格保护其中的私钥和 kubeconfig。
5. 按当前 etcd 部署方式完成一致性快照，不要仅在运行中直接复制 /var/lib/etcd 目录来代替可靠备份。
6. 多控制平面集群应逐台操作，不要同时重启所有控制面节点。
备份文件应加密保存、限制访问，并验证恢复流程。拥有 admin.conf 或 CA 私钥的人，可能获得极高的集群权限。
四、使用 kubeadm 续签证书
再次确认到期情况：
sudo kubeadm certs check-expiration
续签所有由 kubeadm 管理的已知控制面证书：
sudo kubeadm certs renew all
这个命令会无条件续签相关证书，而不只是续签即将到期的证书。也可以按需续签单个项目，例如：
sudo kubeadm certs renew apiserver
sudo kubeadm certs renew admin.conf
续签使用现有证书中的属性，包括 Common Name、组织和 SAN。它不会自动帮你解决新增域名或新增 IP 的需求；修改 API Server SAN 属于重新配置证书的场景，需要准备正确的 kubeadm 配置。
如果 check-expiration 显示证书由外部系统管理，kubeadm 无法替你完成续签，应按外部 CA 的流程生成、签发和部署证书。
五、为什么续签后还要重启控制面组件
并非所有组件都会动态重新加载证书。完成 kubeadm certs renew 后，需要让 kube-apiserver、kube-controller-manager、kube-scheduler，以及本地 etcd 在适用时重新启动，才能使用新证书。
kubeadm 管理的控制面组件通常是静态 Pod，清单位于 /etc/kubernetes/manifests。静态 Pod 由本机 kubelet 管理，不能把它们当作普通 Deployment，简单使用 kubectl delete 就认为完成重启。
官方流程可以通过临时移出某个静态 Pod 清单、等待 kubelet 停止组件，再把清单恢复的方式触发重建。操作时必须：
1. 一次只处理一个组件或一台控制平面节点。
2. 确认清单备份完整且路径正确。
3. 等待组件恢复健康后再继续下一项。
4. 多控制平面集群逐台滚动处理，始终保留可用控制面。
错误移动或丢失 manifests 文件会导致控制面组件无法启动，生产环境应使用经过验证的操作手册执行。
六、更新管理员 kubeconfig
如果日常 kubectl 使用的 $HOME/.kube/config 是从 admin.conf 复制出来的，续签 admin.conf 后，还需要更新该副本：
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
如果管理员从其他工作站访问集群，也要通过安全渠道更新相应 kubeconfig。不要通过公开网盘、即时聊天明文或代码仓库分发。
super-admin.conf 可以绕过常规 RBAC，属于应急级别凭据，不应作为日常 kubeconfig 使用。
七、续签后的验证
重新检查有效期：
sudo kubeadm certs check-expiration
验证 API Server 和集群资源：
kubectl get --raw='/readyz?verbose'
kubectl get nodes
kubectl get pods -A
检查控制面静态 Pod、etcd、CoreDNS 和关键业务工作负载是否恢复正常，并查看异常事件和组件日志。
如果 HA 集群还有其他控制平面节点，需要在每台节点上按官方说明续签其本地证书，并逐台完成重启与验证。
八、给用户颁发访问凭据的正确思路
不要把共享 admin.conf 发给普通用户。每个人或自动化系统都应使用独立身份，并通过 RBAC 授予最小权限。
一个只读 Pod 的 Role 可以只允许 get、list、watch，然后用 RoleBinding 绑定到特定用户。授权前后可以验证：
kubectl auth can-i list pods \
--namespace=default \
--as=<USER_NAME>
用户证书的有效期不应随意设成十年。短期凭据、独立身份、定期轮换和可审计的签发流程，比长期共享证书更安全。
九、常见误区
1. 只续签 apiserver.crt，却忽略 kubeconfig 中嵌入的客户端证书。
2. 续签完成后没有重启静态 Pod。
3. 覆盖 kubeconfig 时写错路径或覆盖了错误用户的配置。
4. 把 admin.conf、CA 私钥或完整 /etc/kubernetes 备份上传到不安全位置。
5. 多控制平面节点同时操作，导致整个控制面不可用。
6. 把证书续签当作 CA 轮换；CA 轮换是复杂程度更高的独立工作。
总结
可靠的证书续签流程是：提前监控 → 确认管理方式 → 安全备份 → 续签 → 滚动重启 → 更新 kubeconfig → 全面验证。命令本身很短，真正重要的是备份、权限保护、维护窗口和回滚能力。
参考资料：
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-certs/
https://kubernetes.io/docs/setup/best-practices/certificates/