node节点状态NotReady
排查日志发现pleg超时
pleg超时-----》 kubelet不健康 -----》 node not ready
那么问题来了？ pleg是什么？
pleg是pod生命周期事件生成器"pod lifecycle event generator", 的缩写。pleg会记录Pod生命周期中的各种事件，如容器的启动、终止等，这些事件会写入缓存中，同时他检测到container异常退出时，他会通知kubelet，然后重启创建该container。
PLEG is not healthy 如何发生？
Kubelet 在一个同步循环（SyncLoop() 函数）中会定期（默认是 10s）调用 Healthy() 函数。Healthy() 函数会检查 relist 进程（PLEG 的关键任务，重新列出节点上的所有容器（例如 docker ps），并与上一次的容器列表进行对比，以此来判断容器状态的变化）是否在 3 分钟内完成。如果 relist 进程的完成时间超过了 3 分钟，就会报告 PLEG is not healthy。一般而言当节点上运行有大量的Pod，亦或者负载过高性能下降，或者出现Bug时，PLEG便无法在3分钟内完成所有这些操作。
所以，原因有可能是docker ps和docker inspect很慢，以至于pleg在检查过程中超时
我们执行下docker ps，发现卡住了。
vmstat和top，查看cpu和内存占用，无异常
Kubelet的PLEG问题出现的原因包括但不限于：
RPC 调用过程中容器运行时响应超时（有可能是性能下降，死锁或者出现了 bug）。
节点上的 Pod 数量太多，导致 relist操作无法在 3 分钟内完成。事件数量和延时与 Pod 数量成正比，与节点资源无关。
relist 出现了死锁，该 bug 已在 Kubernetes 1.14 中修复。
获取 Pod 的网络堆栈信息时CNI插件出现了bug（简而言之即容器管理系统和网络插件之间通过 JSON 格式的文件进行通信，实现容器的网络功能）。
由此，问题原因即每台K8s Worker节点运行的Pod数量过多（80+）导致系统负载过高性能下降（机器配置8核32GB），Docker守护程序无法及时响应，relist 进程无法在 3 分钟内完成，进而导致Kubelet节点Notready，Pod反复创建又导致数量攀升（节点达到了110个pod），进一步加剧了服务的崩溃。(也有可能是Bug诱发导致) 。
在 Kubernetes 社区中，PLEG is not healthy 成名已久，只要出现这个报错就有很大概率造成 Node 状态变成 NotReady。GitHub上相关Issue，请见：
https://github.com/kubernetes/kubernetes/issues/45419
故障原因一：
其中说明了原因是systemd的一个bug导致。
临时解决办法是：
在故障节点上执行 systemctl daemon-reexec。执行后故障确实恢复，但是这只是临时解决办法。
根本解决是：将systemd升级到 v242-rc2，或者更高；升级后需要重启操作系统。
systemd下载链接： https://github.com/systemd/systemd/releases
查看systemd版本
systemctl --version
systemd 219
故障原因二：
参考文章：https://zhanghaiyang.blog.csdn.net/article/details/100221388
可能是docker版本的问题
docker卡死导致节点NotReady
内核版本和docker版本不兼容
00:00:01 docker-runc --systemd-cgroup=true start c3b699a641158d6116387c414216557737cdaf4da4cca96f9c99265850011d11
通过分析trace， 一个启动的容器造成了docker死锁，这个问题是老版本的1706上的问题
升级docker版本到18.06以上