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

Kubernetes集群证书续期100年？操作前必须了解的关键限制

证书过期是导致Kubernetes集群意外中断的常见原因。默认情况下，kubeadm签发的组件证书有效期仅为一年，一旦apiserver或etcd等核心证书失效，集群将立即陷入瘫痪。面对每年续期的繁琐操作，许多工程师自然会考虑：能否直接将证书有效期修改为100年，实现一劳永逸？本文将深入解析这一操作的具体步骤，并揭示一个至关重要的限制条件，忽视它可能导致所有努力付诸东流。

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

下图展示了修改前集群证书的默认过期时间：

我们的目标，是将证书有效期延长至如下状态：

1. 修改证书有效期为100年的步骤

以下操作基于一个由kubeadm部署的Kubernetes 1.33.5集群。请严格遵循步骤执行。

第一步：导出kubeadm集群配置。

从ConfigMap中获取当前的集群配置并导出为YAML文件：

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

第二步：调整证书有效期参数。

编辑导出的kubeadm-new.yaml文件，定位并修改以下两个核心参数：

• caCertificateValidityPeriod：用于设置根CA证书的有效期。
• certificateValidityPeriod：用于设置由CA签发的组件证书的有效期。

将两者的值均设置为876000h0m0s（即100年）。请注意区分这两个参数的作用，后续将详细解释其差异。

第三步：更新证书并重启服务。

执行证书更新命令，并重启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

第五步：验证证书有效期。

使用以下命令检查所有证书的过期时间，确认操作是否成功：

kubeadm certs check-expiration

2. 关键发现：根CA证书并未被更新

仔细观察上一步的检查结果，你会发现一个关键问题：所有组件证书的有效期已成功延长，但根CA证书的过期时间仍然停留在约9年后。为什么在配置中明确设置了caCertificateValidityPeriod为100年，却未生效？

这触及了kubeadm证书管理机制的一个核心设计：

kubeadm certs renew命令仅能更新由根CA签发的“子证书”（即组件证书），而无法更新根CA证书本身。

这意味着，上述操作只是利用现有的、即将过期的根CA，重新签发了一批有效期更长的子证书。我们并未，也几乎无法通过常规方法，去替换或延长集群中已存在的根CA证书。

3. kubeadm限制根CA更新的设计逻辑

这一限制源于安全架构的考量。根CA证书是整个Kubernetes集群信任链的基石，所有组件间的TLS认证都依赖于它。替换根CA等同于动摇整个集群的安全基础，操作风险极高。

强制更换根CA可能导致灾难性的连锁反应：kubelet与apiserver之间的双向TLS认证中断、控制器管理器无法通信、etcd集群成员身份失效，最终致使整个集群不可用。kubeadm团队通过限制此操作，实质上是一种主动的风险规避策略：

设计上更倾向于让证书过期问题通过明确的告警暴露出来，并提供安全的续期流程，而非开放一个可能直接导致集群瘫痪的高风险操作入口。

4. CA证书有效期参数的实际生效时机

那么，配置文件中的caCertificateValidityPeriod参数何时才会真正起作用？该参数仅在集群初始化阶段，即执行kubeadm init创建全新根CA证书的那一刻生效。对于已投入运行的集群，此参数在后续的证书更新操作中不会被读取或应用。

5. 生产环境证书管理的最佳实践

追求“永久有效”并非运维的最佳路径。真正的目标应是建立可靠、自动化的证书生命周期管理流程，消除因遗忘导致的服务中断风险。

方案一：实施自动化证书轮转（推荐）

这是最符合安全规范和生产要求的策略。核心思想是变被动为主动，实现证书的“无感”更新。

• 基础手动轮转：建立日历提醒，定期（如每年）执行kubeadm certs renew all命令。
• 全自动轮转：通过Kubernetes CronJob或系统级定时任务（如crontab），在证书过期前自动完成续期。例如，设置每半年执行一次：

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

自动化流程确保了证书始终处于有效状态，从根本上避免了过期风险。

方案二：初始化时设定合理的长有效期（适用于新集群）

对于新建的、变更周期较长的测试环境或边缘集群，可以在执行kubeadm init时，通过配置文件将certificateValidityPeriod设置为一个更长的合理值（例如5年或10年）。这能在不牺牲安全性的前提下，显著减少维护频率。

稳健的Kubernetes运维体系建立在可预测、可重复的自动化流程之上，而非寻找脆变的“捷径”。妥善管理证书生命周期，是保障集群长期稳定运行的基础。