Kubernetes 集群的各个控制平面组件依赖证书完成双向 TLS 认证。证书一旦过期，API Server 可能无法启动或反复重启，kubelet 无法向控制平面注册，kubectl 命令也会出现认证失败。很多情况下集群没有明显告警，直到证书到期才暴露问题。因此掌握证书过期排查和续期方法，是保障集群稳定运行的基本功。
一、认识 Kubernetes 证书目录与有效期
kubeadm 搭建的集群中，CA 和组件证书默认存放在 /etc/kubernetes/pki 目录下。CA 证书包括 ca.crt 和 ca.key，默认有效期为十年；服务端证书和客户端证书默认有效期通常为一年，例如 apiserver.crt、apiserver-kubelet-client.crt、front-proxy-client.crt 等。etcd 相关的证书则位于 /etc/kubernetes/pki/etcd 目录中，负责 etcd 集群内部的 TLS 通信。
这些证书可以分为服务端证书和客户端证书两类。API Server 使用 apiserver.crt 对外提供 HTTPS 服务，使用 apiserver-kubelet-client.crt 访问 kubelet；kubelet 则使用 kubelet.conf 中的客户端证书访问 API Server。任何一张证书过期，都可能导致部分链路不可用。尤其是 etcd 的 server.crt 过期后，etcd 节点之间无法建立 TLS 连接，控制平面可能完全瘫痪。
证书过期后的典型表现包括：kubectl 命令返回 x509: certificate has expired，节点状态变为 NotReady，kubelet 日志中反复出现证书过期错误，控制平面静态 Pod 频繁重启。理解这些证书的存放位置和作用后，下一步才能有针对性地定位问题。
二、通过命令和日志快速定位过期证书
最直接的排查命令是 kubeadm certs check-expiration。该命令能够读取当前 kubeadm 配置，列出所有证书的到期时间。如果集群仍然可以执行 kubectl 命令，应优先在控制平面节点上运行该命令。如果集群已经不可用，则需要通过 openssl 直接查看证书文件，确认具体过期时间。
kubeadm certs check-expiration # 直接查看 apiserver 证书到期时间 openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -enddate # 查看 etcd server 证书到期时间 openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -noout -enddate
日志排查同样重要。在控制平面节点上可以通过 journalctl -u kubelet 查看 kubelet 服务日志，搜索 certificate has expired 或 x509 关键字。对于容器化运行的控制平面组件，可以使用 crictl ps -a 找到 apiserver、etcd 等容器，再用 crictl logs 查看具体错误日志。如果容器运行时仍是 Docker，则相应使用 docker logs 命令。
排查时还要区分是 CA 证书过期还是组件证书过期。默认情况下 CA 有效期为十年，一般不会先过期，但如果系统时间被调乱，或使用自定义短期 CA，就可能出现 CA 先过期的情况。可以通过 openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -dates 查看 CA 证书有效期。如果 CA 已经过期，仅续期组件证书无法解决问题，需要重建 CA，影响范围更大，因此必须先确认 CA 状态。
三、续期证书的标准流程与注意事项
在执行续期操作前，必须先备份证书目录。可以使用 tar 命令将整个 /etc/kubernetes/pki 目录压缩保存，避免续期失败后无法回滚。高可用集群中，每个控制平面节点的 pki 目录可能不完全一致，因此在操作前需要明确当前节点角色和证书分布。
# 备份证书目录 sudo cp -r /etc/kubernetes/pki /etc/kubernetes/pki.bak.$(date +%F) # 批量续期所有可续期证书 sudo kubeadm certs renew all # 续期后查看结果 sudo kubeadm certs check-expiration
kubeadm certs renew all 会续期 apiserver、apiserver-etcd-client、apiserver-kubelet-client、front-proxy-client 以及 etcd 的 healthcheck-client、peer、server 等证书。如果只需要续期某一张证书，可以使用 kubeadm certs renew apiserver 这样的子命令。需要特别注意的是，如果集群使用自定义证书或外部 CA，不能直接使用 renew 命令，而必须按照原始证书签发方式进行处理。
续期完成后，必须让控制平面组件重新加载新证书。控制平面组件以静态 Pod 方式运行，kubelet 会在证书文件变化后自动重建 Pod，但在某些版本中仍需要手动重启 kubelet。可以执行 sudo systemctl restart kubelet，也可以删除 /etc/kubernetes/manifests 目录下对应的 YAML 文件，让 kubelet 重新拉起静态 Pod。不过删除 manifest 文件有一定风险，建议优先重启 kubelet。操作完成后，可再次运行 kubeadm certs check-expiration 和 kubectl get nodes 验证集群状态。
如果 admin.conf、controller-manager.conf、scheduler.conf 中的客户端证书被续期，需要同步更新用户目录下的 kubeconfig 文件。kubeadm certs renew all 默认会重写 /etc/kubernetes/admin.conf，但用户家目录下的 ~/.kube/config 可能仍是旧版本。可以通过以下命令更新配置文件，并确保文件权限正确。
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
高可用集群的续期操作需要额外谨慎。在堆叠 etcd 的多 master 环境中，如果证书目录不一致，续期后可能出现节点之间证书不匹配。比较稳妥的做法是先在单个控制平面节点上执行续期，确认集群恢复后，再将 /etc/kubernetes/pki 目录同步到其他控制平面节点，同时保持 CA 证书一致。如果使用外部 etcd 集群，则 etcd 证书需要在 etcd 节点上单独续签，不能通过 kubeadm 命令直接处理。操作前务必梳理当前集群拓扑，避免因证书不同步导致更大的故障。
四、构建证书过期监控与自动轮换机制
依靠人工排查终究是被动手段。为了避免证书再次突然过期，可以部署周期性检查机制。简单方案是在控制平面节点上创建 systemd timer 或 crontab 任务，定期执行 kubeadm certs check-expiration 或 openssl 命令，解析证书剩余天数，当小于阈值时发送告警。下面是一个简单的 shell 示例，用于检查证书剩余天数。
#!/bin/bash
# 检查 apiserver 证书剩余天数
DAYS=$(kubeadm certs check-expiration | awk '/apiserver/{print $NF}' | tail -1)
if [ "$DAYS" -lt 30 ]; then
echo "证书即将过期，剩余 ${DAYS} 天"
fi
更标准化的方式是使用证书监控工具，例如 cert-exporter 或 ssl-exporter。这些工具可以探测 TLS 端口，并将证书剩余有效天数输出为 Prometheus 指标。可以针对 apiserver 的 6443 端口、etcd 的 2379 端口分别配置监控，并设置 Prometheus 告警规则，在证书剩余天数小于 30 天时触发通知。这样可以将证书过期风险纳入现有监控体系，避免遗漏。
自动续期方面，kubelet 客户端证书支持自动轮换，通过配置 serverTLSBootstrap: true 并配合 RBAC 审批 CSR 实现。但 kubeadm 生成的控制平面证书不会自动续期，官方也没有内置的控制平面证书自动续期机制。可以编写 Kubernetes CronJob，挂载宿主机 /etc/kubernetes/pki 目录，定期执行 kubeadm certs renew all，但这种方式风险较高，建议只在测试环境中验证。生产环境更推荐将监控告警和人工运维流程结合，确保证书续期操作在可控范围内执行。
证书过期不是复杂的技术难题，却可能让整个集群陷入不可用状态。通过熟悉证书目录、掌握排查命令、规范续期流程并建立监控告警，可以显著降低证书问题带来的风险。建议至少每季度检查一次证书到期时间，并在到期前三十天设置提醒，给运维团队留出充足的处理时间。
Kubernetes证书证书过期续期修改时间：2026-08-22 17:42:03