现象

业务组在更新容器镜像的时候，经常遇到遇到pod一直卡住在containerCreating状态，检查该pod的事件信息，显示pod一直在pulling镜像，即pod的创建阻塞在拉取镜像到节点的过程中。

出现上述问题的pod，在uat测试环境和prod生产环境2个集群都有出现。

调查过程

1. 初次出现此问题在prod生产集群，通过systemctl restart containerd方式重启了containerd进程后，业务pod拉取镜像成功，变成running状态。收集节点containerd日志分析，未发现拉取镜像异常点。

2. 后8月4日uat集群也出现pod同样的现象。uat集群5个节点，测试建立分散在5个节点的pod，发现一个没有变成running失败的pod。检查pod有关事件，发现该pod从调度成功到报错ErrImagePull,中间有2个多小时，且事件显示**Failed to pull image xxx,pull QPS exceed**
   

如上图，失败的pod 12:26分调度成功，和其他4个正常运行的pod一样，但是14:31分该pod报错镜像拉取异常和QPS excedd错误。

3. 分析**pull QPS exceed**代码，判断kubelet默认串行拉取镜像的（现在的默认策略），串行也会走到 pull QPS exceeded 这个报错，也就是只有可能有其它镜像拉取的时候卡住了，才导致这么慢的。

即kubelet拉取镜像是串行的，上一个拉取任务未结束不会继续下一个，目前怀疑如下可能：
1、拉取镜像慢，即可能网络带宽很慢，造成长时间阻塞。
2、有任务阻塞了拉取队列，造成新建的pod的拉取任务阻塞在队列。
3、containerd自身卡在了拉取状态而阻塞队列，即pod的镜像拉取任务其实已经开始运行，但是未知原因，造成拉取阻塞。

重启containerd 后，队列后的请求马上就全部失败清空了

调查发现10.28.2.X节点有异常pod反复拉起，拉起的过程中会反复pulling镜像，可能阻塞了镜像拉取队列，造成正常运行的pod也无法拉取镜像。

如上图，nginx-demo的pod反复被拉取，拉取过程中有pulling行为。

怀疑是异常pod反复拉起pulling阻塞了镜像队列，通过先清理nginx-demo等异常的pod，重启containerd后，短期问题未复现。

4. 8月11日，大量pod出现上述现象，且在uat和prod两个集群同时出现。调查中发现，使用ctr image pull命令，拉取**10.8.2.X:9083**节点的镜像时，命令始终无法返回结果，拉取的镜像无任何进度，在多个节点执行拉取命令，均是如此。
   如上图，大量pod卡住在containerCreating状态。
   
   如上图，集群使用了10.8.14.X 的镜像仓库和10.8.2.X的镜像仓库，使用2个地址的pod，都有拉取镜像失败。
   
   如上图，从10.8.2.X节点，拉取ais-platform镜像，任务已经有6分钟以上，拉取执行命令不终止，无任何信息(包括错误信息)返回，也无任何实质进度。但是手动拉取10.2.14.X的地址的镜像，拉取速度很快，2秒就拉取完成。

结合上面结果，判断是从**10.8.2.X**拉取镜像阻塞了队列。同时，在终止ais-platform的pod后，重启containerd后，其他使用10.8.14.X的镜像源的pod，都马上变成running状态了。

解决办法

总结调查过程，故障原因为使用了2个上游镜像仓库源，其中一个镜像镜像仓库异常（拉取任务不即刻返回客户端失败），结合kubelet默认串行拉取镜像的策略综合导致。且kubelet拉取任务是同步任务，即拉取任务会一直等待镜像仓库返回，否则会一直阻塞在队列。在上游镜像仓库异常无返回时，会造成镜像拉取的阻塞。解决办法是优先保证上游镜像仓库的稳定，第二是修改kublet拉取策略为并行缓解。并行只是缓解了在使用了多个上游镜像仓库源时，一个镜像仓库源异常不会造成拉取其他镜像仓库源阻塞。在pod全部使用一个镜像仓库源且该源异常时，并行拉取反而会额外增加系统负载。

1. 修改kubelet拉取镜像为并行方式

• 编辑kubelet配置文件，增加serializeImagePulls: false配置

vim  /etc/kubernetes/kubelet-config.yaml

• 重启节点kubelet并检查成功运行

service kubelet restart
systemctl is-active kubelet