k8s和rancher疑难问题记录 - 文章 - 开发者社区

0.前言

今天k8s开发环境有同事反馈rancher集群不可用了，整个排查过程涉及的知识点还挺多的，在此记录一下。

1.问题

问题的主要表现形式为rancher无法正常使用，rancher集群中的项目和命名空间无法正常访问，如下图所示：

picture.image 可以看到rancher无法正常调用k8s的接口获取k8s集群的数据信息。

2.k8s集群问题排查

通过报错"Get http://10,96,0.1:443/api/v1/namespaces/kube-system?timeout=45s": context deadline exceeded"可以发现，rancher无法调用kube-system命名空间中的信息超时了，所以初步推测k8s集群的master节点异常了，于是到master节点所在服务器检查k8s运行情况，命令如下：

kubectl get node -o wide

picture.image 发现master节点确实处于NotReady状态，那么我们就来看下为何master节点处于NotReady状态，命令如下：

kubectl describe node k8s-master

看到了以下关键信息：

.............
Ready                False   Wed, 15 Oct 2025 13:42:19 +0800   Wed, 15 Oct 2025 13:38:49 +0800   KubeletNotReady              PLEG is not healthy: pleg was last seen active 
.............

"PLEG is not healthy" 也就是PLEG处于不健康的状态。

2.1 什么是PLEG

Pod Lifecycle Event Generator（PLEG）是 kubelet 的一个重要模块，它专门负责跟踪每个节点上的容器状态，并生成相应的事件。这些事件会反馈给 kubelet 的主循环（sync loop），然后由主循环根据事件类型来决定具体的操作（如启动或停止容器）。这是 Kubernetes 实现容器生命周期管理的一种机制。
PLEG 通过以下步骤执行其工作：

定期的轮询：PLEG 会定期轮询容器运行时（例如 Docker）获取每个 Pod 的状态。这是一个全量操作，即每次轮询都会检查所有的容器。
状态比较与事件生成：每次轮询后，PLEG 会将获取的最新状态与上一次的状态进行比较，任何状态的改变都会生成一个事件。
事件传递：生成的事件会被传递给 kubelet 的 sync loop，这些事件将触发 sync loop 进行相应的操作，比如根据 Pod 的期望状态和当前状态，来决定是否需要启动或者停止容器。

2.2 PLEG出问题原因

出现 pleg not healthy，一般有以下几种可能：

容器运行时无响应或响应超时，如 docker进程响应超时（比较常见）
该节点上容器数量过多，导致 relist 的过程无法在 3 分钟内完成
网络我们检查下服务器资源呢使用情况：
(1)CPU负载情况：

top

top - 13:43:34 up 137 days,  4:46,  1 user,  load average: 1.16, 0.40, 0.30

(2)内存使用情况：

free -h

              total        used        free      shared  buff/cache   available
Mem:            31G        8.8G        340M        1.5G         22G         21G
Swap:            0B          0B          0B

可以看到CPU和内存负载都不高，另外集群中存在的服务都是正常运行，集群节点之间网络也都正常，所以最后确定是docker服务异常导致的。

2.3 重启docker服务

systemctl stop docker
systemctl stop docker.socket

有时候停止docker.socket服务的时候，会夯死，只需要找到和docker相关的进程，并且kill掉即可，具体命令如下：

ps -ef |grep docker

picture.image

kill -9 <pid1> <pid2>...

2.4 检查k8s集群

重启完docker之后，我们检查一下k8s集群的状态，命令如下：

kubectl get node

picture.image 可以看到master节点的状态已经恢复了，但是登上rancher之后会发现报错依旧存在。

3.rancher问题排查

既然k8s集群没有问题了，那么现在的问题应该存在于rancher服务，rancher是以容器的形式运行的，首先查看下rancher的运行状态，命令如下：

docker ps -a |grep rancher

007d02c3b3f3   rancher/rancher:v2.5.14   "entrypoint.sh"          12 months ago    Up 16 seconds                0.0.0.0:1080->80/tcp, 0.0.0.0:1443->443/tcp   xenodochial_engelbart

单纯看容器的话，rancher是正常运行的，然后看一下rancher同k8s集群通信的agent服务运行情况，注意agent是运行在k8s集群的cattle-system命令空间的，查看agent的命令如下：

kubectl get pod -n cattle-system

NAME                                    READY   STATUS             RESTARTS   AGE
cattle-cluster-agent-59b4788464-zshkh   0/1     CrashLoopBackOff   123        26d

可以看到rancher的agent服务确实没有正常运行，接下来就需要看下pod的日志，命令如下：

kubectl logs cattle-cluster-agent-59b4788464-zshkh -n cattle-system

可以看到如下报错：

ERROR: https://192.168.0.18:1443/ping is not accessible (Failed to connect to 192.168.0.18 port 1443: Connection refused)

可以看到agent无法正常与k8s master节点进行同行，推测是master节点之前异常导致的，我们重启下pod，命令如下：

kubectl delete pod cattle-cluster-agent-59b4788464-zshkh -n cattle-system
kubectl get pod -n cattle-system -o wide

NAME                                    READY   STATUS             RESTARTS   AGE     IP             NODE             NOMINATED NODE   READINESS GATES
cattle-cluster-agent-6bd7fd9cd6-mbj68   0/1     CrashLoopBackOff   2          31s     10.244.3.198   k8s-node03       <none>           <none>

可以看到重启后的pod运行依旧不正常，只能再次查看日志分析原因了，命令如下：

kubectl logs cattle-cluster-agent-6bd7fd9cd6-mbj68 -n cattle-system

看到如下关键报错：

...........
level=fatal msg="Server certificate is not valid, please check if the host has the correct time configured and if the server certificate has a notAfter date and time in the future. Certificate information is displayed above. error: Get \"https://172.30.198.18:1443\": x509: certificate has expired or is not yet valid: current time 2025-10-15T06:42:27Z is after 2025-10-08T09:34:32Z"

这个报错说明rancher同k8s通信的证书过期了，或者是agent所在服务器的时间异常，我们检查下agent所在服务器，发现时间并没有问题，那就是证书过期了，需要更新rancher证书，步骤如下：
(1)进入rancher容器，命令如下：

docker exec -it <rancher-server-id> /bin/bash

(2)删除k3s相关证书，命令如下：

kubectl --insecure-skip-tls-verify -n kube-system delete secrets k3s-serving
kubectl --insecure-skip-tls-verify delete secret serving-cert -n cattle-system
rm -f /var/lib/rancher/k3s/server/tls/dynamic-cert.json

(3)rancher的IP注入到证书中，命令如下：

curl --insecure -sfL https://ip:port/v3

(4)重启rancher容器退出rancher容器，然后重启，命令如下：

docker restart <rancher_id>

现在重启下agent pod,命令如下：

kubectl delete pod cattle-cluster-agent-59b4738474-ziwkj -n cattle-system
kubectl get pod -n cattle-system -o wide

NAME                                    READY   STATUS    RESTARTS   AGE   IP             NODE         NOMINATED NODE   READINESS GATES
cattle-cluster-agent-6bd7fd9cd6-zrj4l   1/1     Running   1          16s   10.244.3.199   k8s-node03   <none>           <none>

可以看到agent已经正常运行了，再看下rancher，也可以正常访问了。

4.总结

整个排查过程涉及到rancher、k8s集群很多方面的内容，主要还是要多分析日志，查找导致问题的原因。