K8s集群(kubeadm)CA证书过期的解决过程

更新时间：2026年01月24日 10:40:20 作者：云计算-Security

在K8s集群中,CA证书和Token都会过期,导致新节点无法加入集群,需要备份旧证书,重新生成新证书和配置文件,更新kubectl配置,重启kubelet,重新加入工作节点,验证集群节点状态和健康状况,确保K8s集群正常运行

一、现象描述

之前有篇文章《K8s Token 过期解决方案（Kubeadm）》提到了默认生成的 Token 有效期只有 24 小时，过期后 Token 将不可用，如果想新的 Node 节点加入 K8s 集群，则需重新生成新的 Token。

今天无意间打开我虚拟机部署的 K8s 集群（通过 kubeadm 方式部署），发现 CA 证书过期了（如下图）：

kubectl get pods

于是查看我的 K8s 集群证书，显示证书都过期了（如下图）：

# 查看证书过期时间 => k8s1.15+版本的查看方法
kubeadm certs check-expiration

字段说明：

字段	解释
CERTIFICATE	证书的名称
EXPIRES	证书过期的时间点
RESIDUAL TIME	当前时间距离证书过期的剩余时间
CERTIFICATE AUTHORITY	证书的颁发机构
EXTERNALLY MANAGED	证书是否由外部系统管理

证书字段详解：

CERTIFICATE	EXPIRES	CERTIFICATE AUTHORITY	EXTERNALLY MANAGED	备注
admin.conf	Dec 12, 2023 03:36 UTC	ca	no	Kubeconfig 文件，包含集群访问的配置
apiserver	Dec 12, 2023 03:36 UTC	ca	no	Kubernetes API 服务器的证书
apiserver-etcd-client	Dec 12, 2023 03:36 UTC	etcd-ca	no	API 服务器与 ETCD 之间的客户端证书
apiserver-kubelet-client	Dec 12, 2023 03:36 UTC	ca	no	API 服务器与 Kubelet 之间的客户端证书
controller-manager.conf	Dec 12, 2023 03:36 UTC	ca	no	Kubernetes 控制器管理器的 Kubeconfig 文件
etcd-healthcheck-client	Dec 12, 2023 03:36 UTC	etcd-ca	no	用于 ETCD 健康检查的客户端证书
etcd-peer	Dec 12, 2023 03:36 UTC	etcd-ca	no	ETCD 节点间的对等通信证书
etcd-server	Dec 12, 2023 03:36 UTC	etcd-ca	no	ETCD 服务器的证书
front-proxy-client	Dec 12, 2023 03:36 UTC	front-proxy-ca	no	前端代理的客户端证书
scheduler.conf	Dec 12, 2023 03:36 UTC	ca	no	Kubernetes 调度器的 Kubeconfig 文件

显然，上表中的这些证书在 2023 年 12 月 12 日 03:36 UTC 就已经过期，且剩余时间为<invalid>，表示这些证书已过期（无效），需要重新生成。

证书颁发机构字段解释：

CERTIFICATE AUTHORITY	EXPIRES	RESIDUAL TIME	EXTERNALLY MANAGED	备注
ca	Dec 09, 2032 03:36 UTC	8年	no	Kubernetes 的主证书颁发机构
etcd-ca	Dec 09, 2032 03:36 UTC	8年	no	ETCD 的证书颁发机构
front-proxy-ca	Dec 09, 2032 03:36 UTC	8年	no	前端代理的证书颁发机构

二、解决方案

1、对过期证书进行备份，并删除旧的证书

# 备份证书
cp -rp /etc/kubernetes /etc/kubernetes.bak

# 删除旧的证书（使用新版本的新命令生成证书时可以忽略这一步，即可以不用删除）
# rm -f /etc/kubernetes/pki/apiserver*
# rm -f /etc/kubernetes/pki/front-proxy-client.*
# rm -rf /etc/kubernetes/pki/etcd/healthcheck-client.*
# rm -rf /etc/kubernetes/pki/etcd/server.*
# rm -rf /etc/kubernetes/pki/etcd/peer.*

2、重新生成证书

# 新版本(1.15+) - - 使用该命令不用提前删除过期证书
kubeadm certs renew all

# 老版本
# kubeadm alpha certs renew all

3、备份旧的配置文件，并重新生成新的配置文件

mv /etc/kubernetes/*.conf /tmp/

# 新版本(1.15+)
kubeadm init phase kubeconfig all

# 老版本
# kubeadm alpha phase kubeconfig all

4、更新 kubectl 配置

# 备份配置文件
cp -rp ~/.kube/config ~/.kube/config.bak

# 更新配置文件
\cp /etc/kubernetes/admin.conf ~/.kube/config

# 修改权限
chown $(id -u):$(id -g) $HOME/.kube/config

5、证书过期时间确认

# 新版本(1.15+)查看方法
kubeadm certs check-expiration

# 单独查看（其他同理）
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text |grep 'Not'

# 老版本查看方法
# kubeadm alpha certs check-expiration

CA 证书时间已经更新，

6、重启 kubelet

所有 work 节点执行，如果你的 master 节点也作为 work 节点使用，那 master 节点也需要执行重启 kubelet 的操作。

systemctl restart kubelet
systemctl status kubelet

7、查看集群节点状态

发现 work 节点不健康，这个时候我们需要重新将work 节点加入 k8s 集群：

1）先查看集群中是否有 Token

kubeadm token list

2）没有则重新生成 Token

# 生成默认 24 小时 Token（推荐）
kubeadm token create

# 生成永久有效 Token
# kubeadm token create --ttl 0

3）获取 CA 证书 Hash 值

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

4）最后就是 work 节点加入 K8s 集群

以 work1 节点为例，work2 节点及其他 work 节点同理。

# 填入上图生成的 token、hash 值，并加入集群。
kubeadm join 192.168.56.160:6443 --token zlj5j5.3ezp1s8drj3jgept --discovery-token-ca-cert-hash sha256:3ed701329742f7549f73cb065a8677abe8b5b8a3e25bbca7bb26f317ffcf89d4

执行后报错：

报错原因：这些文件为旧文件（过期的文件），我们备份后清理即可

# 备份
cp -a /etc/kubernetes/kubelet.conf /tmp/kubelet.conf.back
cp -a /etc/kubernetes/pki/ca.crt /tmp/ca.crt.back

# 清理
rm -f /etc/kubernetes/kubelet.conf
rm -f /etc/kubernetes/pki/ca.crt

清理完成后，再次将 work 节点加入集群：

kubeadm join 192.168.56.160:6443 --token zlj5j5.3ezp1s8drj3jgept --discovery-token-ca-cert-hash sha256:3ed701329742f7549f73cb065a8677abe8b5b8a3e25bbca7bb26f317ffcf89d4

8、查看 k8s 集群节点健康状态

kubectl get nodes

9、最后再验证以下证书过期时间

kubeadm certs check-expiration

无误后，K8s 集群的 CA 证书更新完毕，此时打一个快照（因为我是虚拟机），方便后续实验所用。

三、集群验证

K8s 集群证书过期时间更新完毕后，且集群节点也是健康的状态，那接下来我们跑一个测试服务验证一下集群是否可用。

kubectl create deployment nginx --image=nginx   # 创建单副本作为测试即可
kubectl expose deployment nginx --port=80 --type=NodePort
kubectl get pod,svc

浏览器访问验证：http://192.168.56.160:31122/

再看看 pod 所在 work 节点：调度也是没问题的。

至此，K8s 集群验证完毕！

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

您可能感兴趣的文章:

k8s通过命令批量删除pod方式
文章介绍了如何在k8s中批量删除失败的pod,首先,通过查看所有pod的状态,筛选出非Running的记录,然后,针对特定命名空间（如kube-system）的记录进行筛选,并使用grep命令查找带有Evicted字段的pod,通过awk获取pod名称,并使用xargs循环删除这些失败的pod
2026-01-01
Kubernetes安全加固的一些实用建议
Kubernetes是一个自动化的容器编排平台,它负责应用的部署、应用的弹性以及应用的管理,这些都是基于容器的,下面这篇文章主要给大家介绍了关于Kubernetes安全加固的一些实用建议,需要的朋友可以参考下
2022-02-02
k8s创建启动、删除pod的实现过程
Kubernetes中Pod是管理容器的最小单元,包括创建、管理和删除过程,Pod状态包括Pending、Running、Succeeded、Failed和Unknown
2026-01-01
k8s平台本地数据迁移整改过程
文章主要介绍了对k8s平台默认数据存储位置进行优化,将数据统一管理并存至指定目录和云磁盘的整个过程,包括新磁盘的创建挂载、配置更改生效、环境检查、清理旧环境等步骤,强调在集群所有节点上进行优化,并提醒配置更改生效后建议重启机器以确保变更生效
2026-05-05
K8S Pod定向部署到指定节点的实现全过程
K8S Pod定向部署通过节点标签、亲和性和污点三种机制实现资源适配、业务隔离与节点专属化,适用于不同场景,选型建议为标签用于基础、亲和性用于弹性、污点用于资源保护
2025-08-08
K8S修改Pod时间方案详细代码实例
在Kubernetes中,修改Pod的时间通常指的是修改Pod的时区设置,因为Pod的时间戳（如创建时间）是由Kubernetes集群管理的,并且通常不建议直接修改,这篇文章主要介绍了K8S修改Pod时间方案的相关资料,需要的朋友可以参考下
2025-08-08
在K8S中实现会话保持的两种方案
这篇文章主要介绍了在K8S中实现会话保持的两种方案,每种方案结合示例代码给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下
2023-03-03
k8s中如何实现pod自动扩缩容详解
在实际生产系统中,经常会遇到某个服务需要扩容的场景,可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景,下面这篇文章主要给大家介绍了关于k8s中如何实现pod自动扩缩容的相关资料,需要的朋友可以参考下
2022-08-08
MinIO分布式文件存储(从入门到飞翔)
MinIO是一款高性能的分布式对象存储系统,兼容Amazon S3协议,具有轻量级、易部署、高可用和可扩展性等优势,它通过纠删码技术实现数据冗余与高容错性,适用于私有云存储、大数据分析和静态资源托管等场景,本文介绍MinIO分布式文件存储的相关知识,感兴趣的朋友一起看看吧
2025-03-03
如何使用Kubernetes自定义资源(CRD)详解
自定义资源定义(CRD)是Kubernetes API扩展,可以定义新的对象类型,下面这篇文章主要给大家介绍了关于如何使用Kubernetes自定义资源(CRD)的相关资料,需要的朋友可以参考下
2022-09-09