K8S 证书又过期了，我一把给集群续了 100 年，一劳永逸

一次性将Kubernetes集群证书续期100年？先别急，小心这个“隐藏”的坑

相信不少运维同学都遇到过这样的头疼事：Kubernetes集群运行得好好的，突然某天就“失联”了。一查日志，证书过期。这事儿还真不是小概率事件，因为K8s默认颁发的组件证书有效期只有一年。一旦几个关键证书（比如apiserver、etcd）过期，整个集群瘫痪可不是开玩笑的——apiserver起不来，kubelet连不上，业务中断就在一瞬间。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

所以，一个很自然的想法就冒出来了：能不能一劳永逸，直接把证书有效期改成100年？今天我们就来详细拆解这个操作，过程看似简单，但里面有个关键反转，如果你没注意到，可能就白忙活一场。

这是修改前，证书的过期时间情况：

而我们的目标，是实现像下面这样的“百年大计”：

1. 将证书改为100年

假设我们手头有一个用kubeadm部署的K8s集群，版本是1.33.5，操作步骤如下。

第一步，导出kubeadm配置。

先通过ConfigMap把当前的集群配置导出来：

kubectl -n kube-system get cm kubeadm-config -o jsnotallow='{.data.ClusterConfiguration}' > kubeadm-new.yaml

第二步，修改证书有效期参数。

编辑刚才导出的 kubeadm-new.yaml 文件，找到并修改两个关键字段：

• caCertificateValidityPeriod：CA证书的有效期
• certificateValidityPeriod：普通组件证书的有效期

把它们都设置为 876000h0m0s。这里简单算一下，876000小时正好等于100年。两个参数分别针对CA证书和普通证书，这点很重要，后面我们会详细说。

第三步，更新所有证书并重启服务。

执行更新命令，并重启kubelet让更改生效：

kubeadm certs renew all --config kubeadm-new.yaml
systemctl restart kubelet

第四步，更新kubeconfig文件。

证书更新后，记得更新本地管理配置：

cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

第五步，检查成果。

最后，用命令确认一下证书是否真的续到了100年后：

kubeadm certs check-expiration

2. 反转来了：CA证书根本没变

仔细看上面检查结果的截图，是不是发现了问题？组件证书的有效期确实遥遥无期了，但CA证书的过期时间，怎么还是9年多以后？

明明在配置文件里把 caCertificateValidityPeriod 也设成了100年，为什么它没生效？

这里就触及了Kubernetes kubeadm工具一个不太为人所知的“隐藏机制”：

kubeadm certs renew 命令只会更新由CA签发的“子证书”，而不会去更新“CA证书”本身。

换句话说，刚才那一通操作，只是用那个“旧的CA”重新签发了一批“新的长期子证书”。我们并没有，实际上用常规方法也很难，去创建一个全新的“百年CA”。

3. 为什么 kubeadm 不让你改 CA？

原因其实很直接：CA证书是整个集群的“信任根”。所有的组件证书都由它签发，并被其他组件信任。这个根一旦被替换，就像给一座大楼突然换掉地基，风险极高。

贸然更换CA，很可能导致一连串的灾难性后果：kubelet全部掉线、apiserver拒绝请求、etcd集群通信失败，最终整个集群崩溃。这并非危言耸听，而是不少人在早期实践中踩过的真实大坑。

所以，kubeadm设计团队的选择显得非常谨慎，甚至可以说是一种“防御性哲学”：

宁可让你的证书过期报警，给你时间去处理，也绝不提供一个能一键把集群干翻的“危险捷径”。

4. 那这个参数到底什么时候生效？

你可能会问，配置文件里那个 caCertificateValidityPeriod: 876000h 难道是摆设吗？

当然不是。这个参数有它生效的严格时机：它只在创建CA的时候起作用，具体来说，就是在你执行 kubeadm init 初始化一个全新集群的那一刻。对于已经运行中的集群，这个参数在证书更新操作中是不会被读取的。

5. 真正的最佳实践

说到底，大家想改100年，核心诉求就是怕忘记，想省心，不愿意每年都提心吊胆地操作一次。

基于这个出发点，这里提供两个在生产环境中更常用、也更稳妥的策略。

方案一：自动轮转（强烈推荐）

这是最合规、也最安全的方式。我们不追求“永久”，而是追求“无感”。

• 基本操作：每年手动或自动执行一次 kubeadm certs renew all 来续期证书。
• 进阶自动化：配合CronJob或系统的定时任务，每半年或每9个月自动执行一次续期命令，并重启kubelet。例如，在crontab中加入：

0 3 1 */6 * kubeadm certs renew all && systemctl restart kubelet

这样，证书永远在过期前就被刷新，你几乎感觉不到它的存在。

方案二：合理延长（适用于新集群）

如果你正在部署一个全新的、对稳定性要求极高且变更不频繁的测试或边缘环境集群，可以在初始化时（kubeadm init）的配置文件中，就将证书有效期设置为一个较长的、合理的值，比如5年或10年。这能在保证安全的前提下，大幅降低维护频率。

话说回来，运维工作的精髓往往不在于寻找一劳永逸的“黑魔法”，而在于建立可靠、自动化的流程。处理好证书生命周期管理，你的K8s集群就向稳健运行迈出了一大步。