PLEG报错

一、PLEG工作原理

在 Kubernetes 中，kubelet 是运行在工作节点（work node）上的主要节点代理，负责维护 Pod 的生命周期和底层容器的运行。

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

PLEG 通过以下步骤执行其工作：

1. 定期的轮询：PLEG 会定期轮询容器运行时（例如 Docker）获取每个 Pod 的状态。这是一个全量操作，即每次轮询都会检查所有的容器。

2. 状态比较与事件生成：每次轮询后，PLEG 会将获取的最新状态与上一次的状态进行比较，任何状态的改变都会生成一个事件。

3. 事件传递：生成的事件会被传递给 kubelet 的 sync loop，这些事件将触发 sync loop 进行相应的操作，比如根据 Pod 的期望状态和当前状态，来决定是否需要启动或者停止容器。

在整个过程中，PLEG 与容器运行时之间的通信是必不可少的，所以任何可能影响这种通信的因素（比如网络问题，容器运行时问题等）都可能导致 PLEG 的不正常工作。例如，如果你看到"PLEG is not healthy: pleg was last seen active 3m"的错误信息，就说明 PLEG 最近3分钟内没有成功地从容器运行时获取状态，这可能会导致 kubelet 无法准确地管理 Pod 的生命周期。

 

百度原理：

Kubelet中的NodeStatus机制会定期检查集群节点状况，并把节点状况同步到API Server。而NodeStatus判断节点就绪状况的一个主要依据，就是PLEG。

PLEG定期检查节点上Pod运行情况，并且会把pod 的变化包装成Event发送给Kubelet的主同步机制syncLoop去处理。但是，在PLEG的Pod检查机制不能定期执行的时候，NodeStatus机制就会认为这个节点的状况是不对的，从而把这种状况同步到API Server，我们就会看到 not ready

PLEG有两个关键的时间参数，一个是检查的执行间隔，另外一个是检查的超时时间。以默认情况为准，PLEG检查会间隔一秒，换句话说，每一次检查过程执行之后，PLEG会等待一秒钟，然后进行下一次检查；而每一次检查的超时时间是三分钟，如果一次PLEG检查操作不能在三分钟内完成，那么这个状况，会被NodeStatus机制当做集群节点NotReady的凭据，同步给API Server。

如下图，上

二、解决方案

简单来说就是kubelet无法调用docker了，现象就是无法创建pod也无法删除pod，但是对已经运行的pod 没有太大影响。 

 

处理方式一、某个docker进程夯死导致的

for c in `docker ps -aq`; do echo $c; docker inspect $c 1>/dev/null 2>&1; done

将该容器删除即可

 

 处理方式二、重启服务器或者重启docker和containerd

处理方式三、升级containerd

 

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

• 容器运行时无响应或响应超时，如 docker进程响应超时（比较常见）
• 该节点上容器数量过多，导致 relist 的过程无法在 3 分钟内完成
• relist 出现了死锁，该 bug 已在 Kubernetes 1.14 中修复。
• 网络

docker进程hang 死导致 pleg遇到过很多次，一般是由于 docker 版本过旧，或者机器负载过高导致，可以把 kubelet和 docker 的日志等级调到最高，对比日志定位后进行处理