kubeadm证书过期是必然事件，需手动检查并更新三类证书：控制平面（/etc/kubernetes/pki/）、kubelet.conf、kube-proxy kubeconfig；更新后须重启kubelet、静态Pod和kube-proxy。
证书过期不是“会不会发生”的问题，而是“什么时候发生”的问题——kubeadm 默认生成的大部分证书有效期仅 1 年，而生产集群往往运行远超此周期。不提前干预，2026 年 8 月起大量 2025 年初部署的集群已进入高风险窗口。
为什么 kubeadm certs renew 不总是管用
该命令只更新 kubeadm 管理的证书（如 apiserver.crt、etcd-server.crt），但以下两类证书它完全不碰：
-
kubelet.conf中嵌入的 bootstrap client 证书（由kubelet自动轮换机制管理，过期后 kubelet 直接 crash） -
kube-proxy使用的kubeconfig（若未启用自动轮换，其 client cert 会静默过期，导致 443 端口 TLS 握手失败）
典型现象是：执行 kubeadm certs renew all 后 kubectl get nodes 仍返回 NotReady，且 journalctl -u kubelet 明确报 bootstrap client certificate is expired。
检查所有关键证书的完整路径
不能只信 kubeadm certs check-expiration 的输出，它不覆盖非 kubeadm 管理项。必须手动验证三类位置：
- 控制平面证书：
/etc/kubernetes/pki/下的apiserver.crt、apiserver-kubelet-client.crt、etcd/server.crt - 节点本地凭证：
/etc/kubernetes/kubelet.conf（查看其中client-certificate-data对应的 cert 是否过期） - kube-proxy 配置：
/var/lib/kube-proxy/kubeconfig.conf（同上，解码client-certificate-data检查）
快速验证单个证书有效期的命令：openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep "Not After"。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
更新后必须重启的组件不止 kubelet
证书更新 ≠ 立即生效。以下组件需显式重启才能加载新证书：
-
kubelet：必须systemctl restart kubelet，否则继续用旧 bootstrap cert 尝试连接 - 控制平面静态 Pod：需临时移走
/etc/kubernetes/manifests/*.yaml，等对应容器退出后再放回（Kubelet 会自动重建） -
kube-proxyDaemonSet：需kubectl delete pod -n kube-system -l k8s-app=kube-proxy强制滚动更新
漏掉任一环节，都可能出现“证书已更新但节点仍是 NotReady”的假象。
预防比抢救更关键的三个动作
把证书过期变成可预测、可调度的维护项，而不是凌晨告警的救火任务：
- 初始化集群时就延长有效期：在
kubeadm init命令中加入--certificate-validity 3650（10 年），或通过配置文件指定certificatesDir+ 自定义 CA - 为 kubelet 启用自动轮换：
serverTLSBootstrap: true+rotateCertificates: true（写入/var/lib/kubelet/config.yaml） - 在监控系统中埋点：用
kubeadm certs check-expiration --output json提取residualTime，对<90d的证书触发企业微信/钉钉告警
最常被忽略的是 kubelet 轮换开关——它默认关闭，且一旦集群运行起来再开启，需手动清理旧证书并重启，代价远高于初始化时设对。
