kubernetes的pod状态更新延迟比较久：

`
导语：不知道我这样形容恰不恰当，其实就是describe 查看pod发现明明镜像都下好了，pod已经start了，但是get pods的时候发现pod还在containercreating状态，并且最终到达running的时间也是其他环境的好几倍。
现象出问题的环境containercreating持续40s以上，更新为running的话可能需要10分钟，正常环境containercreating持续7-8s，删除pod的时候 明明deployment已经删除了，但是pod还存在，需要使用–grace-period=0 删除才可以。
为此中间有重启过kubelet，结果一重启kubelet所有pod都变成pending状态(pending状态这里无法演示）
如图

异常情况

`

环境状况：

k8s版本 ：1.22
docker版本：20.10.7

场景分析：

按道理describe就能找到原因，这个环境很奇怪，describe出来的结果是正常的。就是状态更新很慢。排查过etcd，apiserver，flannel，kube-proxy均无果。与此情况一致的全网仅一篇文章，加上本人这篇，就2篇了。经过本人分析得出问题原因：1.大致就是kubelet调用docker超时了，然后kubelet一直报pleg的错误。因为是回忆，具体报错截图这里不显示。2.docker对systemd的版本要求，在centos7环境下，systemd好像是219版本，我出问题的环境也是219版本。

解决方案：

临时解决：
1.重启docker
2.重启kubelet
3.注意：不要先重启kubelet，先重启kubelet会导致所有的pod处于pending状态！
永久解决：
1.第一种思路是升级systemd版本。这一步本人还没验证，毕竟全网文章太少。也懒得折腾了。帮大家找到原因和解决思路了，剩下的兄弟们自行验证升级的过程吧！
2.第二种思路是通过kubectl get node找到处于notready状态的node结点，而后封锁，驱逐他。或者直接将该结点剔除集群。这里不具体演示操作步骤，网上一大把的东西本文不演示。
3.重搭k8s集群，这个是参考文章的老哥的做法，这里不具体演示操作步骤，网上一大把的东西本文不演示。我的这篇文章只是在他的文章基础上做了原因补充及解决思路的多样化补充。

点评：

以上解决思路是参考网上多篇文章及亲身实践得出的结论。全网此现象的文章仅2篇。我的这篇及以下这篇：参考文章