CA证书过期必须执行CA轮换而非kubeadm renew：先用原ca.key签发新ca.crt，再重签全部组件证书，逐节点滚动重启控制平面并更新kubeconfig，全程需备份、验证与客户端同步。
注意：CA证书（ca.crt 和 ca.key）本身无法用 kubeadm certs renew 更新——它是整个集群信任链的根。一旦 CA 过期，kubeadm certs renew all 会直接失败，所有依赖它的子证书（如 apiserver、etcd-server 等）也无法续签。所谓“一键无缝更新底层CA证书”在标准 kubeadm 流程中并不存在，强行操作极易导致集群不可恢复。
但生产环境多主高可用集群确实可能面临 CA 过期风险（默认有效期10年，但部分早期部署或自定义配置可能设为1年）。若已确认 ca.crt 过期（例如 openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -dates 显示 notAfter 已过），必须走CA轮换（CA Rotation）流程，而非简单 renew。
以下是面向生产环境、兼顾安全与可用性的可行路径：
一、先确认是否真为CA过期，而非普通证书
运行命令验证根源：
kubeadm certs check-expiration | grep -E '^(CERTIFICATE|ca\.crt)'
如果输出中 `ca.crt` 行的 `EXPIRES` 是过去时间，且 `kubeadm certs renew all` 报错类似 x509: certificate has expired or is not yet valid 或 failed to load ca key，则确认是 CA 过期。
⚠️ 注意：仅 `admin.conf`、`apiserver.crt` 等过期，而 `ca.crt` 仍有效 → 直接执行 `kubeadm certs renew all` 即可，无需 CA 轮换。
二、CA轮换核心原则：旧CA签发新CA，平滑过渡
不能删除旧 CA，否则所有现存 kubeconfig、静态 Pod 证书立即失效。正确做法是：
- 用旧 CA 私钥（`ca.key`）签发一张新的、长期有效的 CA 证书（`ca-new.crt`）
- 用新 CA 签发全套控制平面证书（apiserver、etcd-server、front-proxy 等）和 kubeconfig 文件
- 逐节点滚动替换证书 + 重启组件，确保任一时刻至少一个 master 可用
- 最后将新 CA 分发给所有客户端（kubectl、CI/CD、监控系统等）并更新其信任链
三、关键操作步骤（master 节点逐台执行）
1. 备份全部原始材料（执行前必做）
sudo cp -a /etc/kubernetes/pki /etc/kubernetes/pki.backup-$(date +%Y%m%d-%H%M%S) sudo cp -a /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.backup
2. 生成新 CA 证书（使用原 ca.key 签发）
openssl req -x509 -new -nodes -key /etc/kubernetes/pki/ca.key \ -sha256 -days 3650 -out /tmp/ca-new.crt \ -subj "/CN=kubernetes-ca" \ -addext "subjectAltName = DNS:kubernetes,DNS:kubernetes.default,DNS:kubernetes.default.svc,DNS:kubernetes.default.svc.cluster.local,IP:127.0.0.1"
3. 用新 CA 批量重签所有证书（需 kubeadm v1.22+）
sudo kubeadm init phase certs all --cert-dir /tmp/new-pki --config /etc/kubernetes/kubeadm-config.yaml # 将新证书复制到正式目录（保留旧 ca.key） sudo cp /tmp/new-pki/*.crt /etc/kubernetes/pki/ sudo cp /tmp/new-pki/etcd/*.crt /etc/kubernetes/pki/etcd/
4. 更新所有 kubeconfig 文件
sudo kubeadm init phase kubeconfig all --config /etc/kubernetes/kubeadm-config.yaml sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
5. 滚动重启控制平面组件（按顺序，每步验证）
- 临时移走该 master 的 manifests：
sudo mv /etc/kubernetes/manifests/*.yaml /tmp/ - 等待 30 秒，确认 `crictl ps | grep -E 'apiserver|controller|scheduler'` 无输出
- 移回 manifests：
sudo mv /tmp/*.yaml /etc/kubernetes/manifests/ - 等待 45 秒，检查 `kubectl get nodes` 是否重新 Ready
- 确认无误后，再操作下一台 master
四、收尾与验证
全部 master 完成后：
- 在任一 master 执行：
kubeadm certs check-expiration，确认所有 `EXPIRES` 时间已更新为未来日期 - 检查 etcd 健康：
ETCD_POD=$(kubectl -n kube-system get pod -l component=etcd -o name | head -1); kubectl -n kube-system exec $ETCD_POD -- etcdctl endpoint health - 从外部客户端（如 JumpServer）用新 `admin.conf` 测试：
kubectl get pods -A - 更新所有工作节点上的 `/etc/kubernetes/kubelet.conf`（需手动替换 client-certificate-data 字段或重新生成）
CA轮换不是“一键”，但它是唯一安全路径。跳过备份、跳过滚动、或试图用新私钥签新CA，都会让集群瞬间瘫痪。生产环境务必在低峰期操作，并提前演练。
