kubeadm 部署的 Kubernetes 集群，所有控制平面的 TLS 证书默认存放在 /etc/kubernetes/pki 目录下。理解证书体系的第一步，是区分 CA 根证书与服务端、客户端证书的用途和有效期。很多运维人员直到一年后组件报错才意识到证书会过期，其实 kubeadm 已经把管理入口集成在 certs 子命令里。下面从目录结构、命令能力和实际操作三个层面展开，把证书管理中容易踩的坑一次说清。
一、kubeadm 证书体系与存储目录
kubeadm 签发的证书可以分为两类：一类是 CA 根证书，默认有效期为十年，负责给其他服务证书签名；另一类是组件实际使用的服务端或客户端证书，默认有效期通常是一年。进入 /etc/kubernetes/pki 目录后能看到 apiserver.crt、apiserver.key、ca.crt、ca.key 等文件，其中 ca.crt 与 ca.key 就是整个 Kubernetes 控制平面的根证书。etcd 相关的 CA 和证书则单独放在 /etc/kubernetes/pki/etcd 子目录中，这种目录隔离有助于对 etcd 证书单独轮换而不影响 Kubernetes 自身的 CA。
服务证书的到期并不是统一时间，但它们大多会在集群初始化一年后集中失效。例如 apiserver.crt 用于 kube-apiserver 的 TLS 服务端认证，apiserver-kubelet-client.crt 用于 apiserver 访问 kubelet 时的客户端认证，admin.conf 中内嵌的客户端证书用于 kubectl 访问集群。只要其中一个证书过期，就可能出现 TLS handshake 失败、kubectl 无法连接、控制平面组件反复重启等现象。因此，定期检查证书剩余有效期应当是集群运维的固定动作。
检查证书有效期最直接的方式是使用 kubeadm 自带的 certs 子命令，它会读取本地证书文件并计算剩余时间，不依赖 API Server 在线。执行结果会列出证书名称、过期时间、剩余天数、所属 CA 以及是否由外部管理。这个输出对快速定位问题非常有用，尤其是当 etcd 或 apiserver 已经无法启动时，kubectl 用不了，但 kubeadm certs 仍然可以正常工作。
sudo kubeadm certs check-expiration
输出内容大致如下，每一行对应一个证书文件或 kubeconfig 内嵌证书。剩余时间小于 30 天时建议尽快处理，小于 7 天则应当立即续期，否则组件一旦重启就可能无法恢复。
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Jan 01, 2027 10:00 UTC 364d ca no apiserver Jan 01, 2027 10:00 UTC 364d ca no apiserver-etcd-client Jan 01, 2027 10:00 UTC 364d etcd-ca no etcd-server Jan 01, 2027 10:00 UTC 364d etcd-ca no
二、功能亮点：check-expiration、renew 与自动轮换
kubeadm certs 子命令最大的优势是简单直接。check-expiration 可以用普通文本形式给出证书清单，不需要手动解析 openssl 输出。renew 命令则支持按名称续期，也支持用 all 一次性续期所有服务证书。执行 renew 时，kubeadm 会使用现有 CA 重新签发对应证书，但不会改动 CA 本身。也就是说，如果 CA 快到期了，renew 命令无法解决，需要单独规划 CA 轮换。
续期操作本身不会自动重启控制平面组件。kubeadm 生成新证书文件后，已经运行的 kube-apiserver、kube-controller-manager、kube-scheduler 以及 etcd 仍然在内存中持有旧证书，必须重启这些静态 Pod 才能让新证书生效。比较稳妥的做法是执行 systemctl restart kubelet，让 kubelet 重新拉起所有静态 Pod。虽然这会造成控制平面短暂不可用，但对多数集群来说是可以接受的。
sudo kubeadm certs renew all sudo systemctl restart kubelet
renew 命令是幂等的，重复执行不会缩短 CA 有效期，也不会产生新的 CA。它只是基于同一个 CA 重新生成服务证书，因此客户端证书和 kubeconfig 文件都能继续使用原有信任链。kubeadm 1.15 之前的版本中，证书管理还属于 alpha 阶段，需要执行 kubeadm alpha certs renew，现在已经稳定为 kubeadm certs 命令，使用门槛大幅降低。
另一个容易被忽略的亮点是升级时的自动续期。kubeadm upgrade apply 会在升级前检查证书是否即将过期，如果到期时间不足则会自动执行续期操作。这个机制可以把证书管理与版本升级合并到同一次维护窗口里，减少单独操作带来的风险。不过仍然建议在升级前手动执行一次 check-expiration，确认证书状态符合预期，避免升级过程中出现非预期变化。
三、常见问题与注意事项
第一个常见问题是 kubectl 突然无法连接，报错中带有 x509: certificate has expired。这种情况通常是 admin.conf 中内嵌的客户端证书过期。由于 kubeadm certs renew 不依赖 API Server 在线，可以直接在控制平面节点执行 kubeadm certs renew admin.conf。命令会更新 /etc/kubernetes/admin.conf 中的证书数据，执行完成后重新使用该 kubeconfig 即可恢复访问。如果使用了自定义 kubeconfig 路径，需要手动将新的 admin.conf 内容复制过去。
第二个常见问题是新增负载均衡器或域名后，访问 apiserver 出现证书不匹配。kubeadm 默认签发的 apiserver 证书只包含主机名、节点 IP 以及 Cluster IP，如果后续增加了外部负载均衡域名，就需要重新生成证书并加入 SAN。做法是先编辑 kubeadm-config ConfigMap，在 certSANs 字段中补充新地址，然后执行 kubeadm certs renew apiserver。仅执行 renew 不会读取新的 certSANs，必须同步更新配置文件再续期，否则生成出来的证书仍然缺少所需域名。
第三个需要注意的点是 etcd 证书。很多集群的 etcd 证书放在 /etc/kubernetes/pki/etcd 下，由独立的 etcd-ca 签名。如果只执行 kubeadm certs renew all，通常会包含 etcd 相关证书，但续期后如果不重启 etcd 静态 Pod，etcd 成员之间会继续使用旧证书通信，可能导致健康检查失败。正确顺序是先执行 renew all，再重启 kubelet，然后观察 etcd 日志确认所有成员恢复。
第四个注意事项是 CA 证书不要轻易轮换。kubeadm 生成的 CA 默认十年有效期，正常情况下不会先过期。但如果企业安全策略要求轮换 CA，需要谨慎处理，因为 CA 一旦更换，所有由旧 CA 签发的服务证书和客户端证书都会失效，必须同步完成全量证书重新签发和组件重启。对生产集群而言，这种操作风险很高，建议在变更窗口内做好 /etc/kubernetes 目录的完整备份。
四、实操：检查、续期并验证完整流程
在执行任何证书操作前，第一件事永远是备份。证书文件通常不大，但一旦损坏或丢失，恢复成本极高。可以用 cp -a 保留权限和软链接，将整个 /etc/kubernetes/pki 目录复制到带日期的备份目录。备份完成后，先执行 check-expiration 确认剩余时间，再决定是续期全部证书还是只续期某个证书。
sudo cp -a /etc/kubernetes/pki /etc/kubernetes/pki.bak.$(date +%F) sudo kubeadm certs check-expiration
如果确认需要续期，可以直接执行 kubeadm certs renew all。这条命令会遍历 kubeadm 已知的所有服务证书并重新签发，同时更新 /etc/kubernetes 下相关 kubeconfig 文件。对于控制平面节点较多的集群，需要在每个控制平面节点上分别执行续期，因为证书文件是各节点独立存放的。续期完成后重启 kubelet，使静态 Pod 重新加载新证书。
sudo kubeadm certs renew all sudo systemctl restart kubelet kubectl get nodes
重启之后可以通过 openssl 命令查看 apiserver.crt 的起止时间，确认新证书已经替换了旧证书。还可以再次执行 kubeadm certs check-expiration，对比续期前后的剩余天数是否发生变化。如果输出中仍有某个证书剩余时间很短，说明该证书可能未被 renew all 覆盖，或者该证书由外部系统管理，需要单独处理。
sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates sudo kubeadm certs check-expiration
对于 kubelet 证书，kubeadm 1.22 之后默认启用了客户端证书自动轮换，kubelet 会在证书接近过期时主动向 apiserver 申请新证书。如果节点长时间未接入集群，或者 kubelet 配置关闭了自动轮换，就需要通过 kubeadm 或其他引导机制重新签发节点证书。日常运维中应当同时关注控制平面证书和节点证书两个层面，才能避免证书问题演变成大规模节点失联。
总结来说，kubeadm 的证书管理能力已经足够覆盖大多数集群的日常需求。它把原本分散在 openssl、cfssl、kubeconfig 中的操作收拢到一组命令里，配合升级时的自动检查机制，可以显著降低证书过期的风险。只要运维团队养成定期检查、提前续期、操作前备份的习惯，证书问题就不会成为集群稳定的短板。
Kuberneteskubeadm证书管理证书续期修改时间：2026-10-04 11:13:36