K8S部分节点无法启动Pod资源-Pod处于ContainerCreating状态

1.Pod长时间处于ContainerCreating状态的原因

在日常运维中可能会遇到Pod资源长时间处于ContainerCreateing正在创建的状态，Pod维持这种状态在1-2分钟内还可以接受，如果在10分钟以上甚至更长，那么可能就是出问题了，遇到Pod资源处于非Running状态时，首先需要使用kubectl describe命令查看Pod的详情信息，从中获取报错信息。

Pod长时间处于ContainerCreateing状态的原因有很多种，大致细分为如下几类：

• 网络原因无法为容器分配地址，从而导致Pod处于ContainerCreateing状态。
• 持久化存储卷或者远程存储端问题，从而导致Pod处于ContainerCreateing状态。
• 存储卷PVC所提供的远程存储无法连接，从而导致Pod处于ContainerCreateing状态。

2.网络原因导致Pod长时间无法创建问题排查过程

1）查看Pod的运行状态

kubectl get pod -o wide | grep knowsystemNAME READY STATUSRESTARTS AGE IP NODEknowsystem-v1-96d57f6c-zbmgj 0/1 ContainerCreateing 0180s100.64.169.129 k8s-node2 

可以看到Pod已经创建180s了还是处于创建中的一个状态。

2）查看Pod运行的详细信息

我们可以通过查看Pod运行的详细信息，从中得到一些有利排查的关键点。

kubectl describe pod knowsystem-v1-96d57f6c-zbmgj

3）输出的报错信息

error: code = Unknown desc = failed to set up sandbox container "1b4e405bcc8b5c4708b617aec3642f8563e357dcf496d48d2f3f0f75cfcdc8a0" network for pod "knowsystem-v1-96d57f6c-zbmgj": NetworkPlugincni failed to set up pod "knowsystem-v1-96d57f6c-zbmgj" network: failed to set bridge addr: "cni0" already has an IP address different from 100.64.169.129/24

4）排查过程

我们主要看describe命令输出的最后部分，主要观察error相关的信息，实在读不懂英文的可以拿有道词典翻一下：

大致的意思就是说Pod被调度的节点k8s-node2中，容器的网络未能给容器分配一个IP地址，该网络已经含有100.64.169.129/24这个IP了。

如何去看这个报错日志？

首先看到这句话network for pod一眼就可以定位到该报错是由于网络的问题导致的。

然后接着往后面看，肯定会有详细的提示信息network: failed to set bridge addr: "cni0" already has an IP address different from 100.64.169.129/24，从这句话中就可以看到cni0这个网络接口产生的故障，从而进一步的去排查。

虽然到这一步就已经知道了是网络的问题，但是也可以在启动一个Pod资源也调度到此Node节点，观察是否会包同样的错，如果还是报错，那么就是该节点产生了问题，如果新的Pod启动成功了，那么就可能是该Pod出现了问题，可以重新部署进行排查。

5）问题解决

故障既然已经定位了，就是k8s-node2节点的网络问题导致的，那么如何解决呢？可以执行下面的命令。

1.将k8s-node2节点从集群中删除kubeadm reset2.停止docker和kubelet服务systemctl stop dockersystemctl stop kubelet3.删除cni和kubelet产生的数据文件rm -rf /var/lib/cni/rm -rf /var/lib/kubelet/*4.把相关网卡关掉ifconfig cni0 downifconfig flannel.1 downifconfig docker0 down5.把产生问题的网卡删掉ip link delete cni0ip link delete flannel1.16.重启docker和kubeletsystemctl start dockersystemctl start kubelet最后再把该节点重新加入到K8S集群中

注意：在执行kubeadm reset命令时，首先将该节点中的所有Pod资源驱逐，然后在释放。

3.持久化存储卷或存储服务器异常导致Pod长时间处于无法创建问题排查过程

1）查看Pod的运行状态

kubectl get pod -o wide | grep knowsystemNAME READY STATUSRESTARTS AGE IP NODEknowsystem-v1-96d57f6c-zbmgj 0/1 ContainerCreateing 0180s100.64.169.129 k8s-node2 

可以看到Pod已经创建180s了还是处于创建中的一个状态。

2）查看Pod运行的详细信息

我们可以通过查看Pod运行的详细信息，从中得到一些有利排查的关键点。

kubectl describe pod knowsystem-v1-96d57f6c-zbmgj

3）输出的报错信息

Kubelet(k8s-node2) Error syncing pod, skipping: timeout expired waiting for volumes toattach/mount for pod "knowsystem-v1-96d57f6c-zbmgj"/"default". list of unattached/unmounted volumes=[ceph-pv]

4）排查过程

根据报错信息，首先可以看到由k8s-node2节点的Kubelet返回了报错信息，大概的意思就是说knowsystem-v1-96d57f6c-zbmgj该Pod资源长时间无法成功挂载ceph-pv这个存储卷，导致超时，从而使Pod一直处于创建中的状态，既然是由Kubelet反馈的报错内容，我们可以去k8s-node2节点查看Kubelet的详细报错日志。

Unable to mount volumes for pod "knowsystem-v1-96d57f6c-zbmgj_default: timeout expired waiting for volumes to attach/mount for pod "knowsystem-v1-96d57f6c-zbmgj"/"default". list of unattached/unmounted volumes=[ceph-pv]; skipping podk8s-node2 kubelet[5167]: Error syncing pod, skipping: timeout expired waiting for volumes toattach/mount for pod "knowsystem-v1-96d57f6c-zbmgj"/"default". list of unattached/unmounted volumes=[ceph-pv]

根据这些反馈的报错内容，我们就可以判断是确实是由于无法挂载存储卷导致的。

5）解决过程

• 我们可以先在Node节点上尝试挂载远程存储卷，首先排查出不是存储端的问题，如果确实无法挂载，那就需要进一步排查存储端的问题了。

• 如果Node节点都不可用挂载远程存储，那么也可以检查一下连接存储的客户端工具有没有安装，不同的远程存储所需的客户端工具也不相同，ceph存储需要在服务器中安装ceph-common命令才可以连接ceph的存储，nfs存储则需要安装nfs-utils工具才可以连接。

• 确保宿主机和远程存储端都没有问题后，可以排查Pod挂载的pvc存储卷是否存在，如果不存在则去创建，从而解决该问题，也可以去排查资源编排文件中关于挂载的信息是否配置正确。

• 如果以上几点原因都不存在，那我们就去排查一下PVC存储卷有没有被其他的Pod所挂载，如果被其他Pod使用，那么也会导致启动不成功。

4.常用的故障排查命令

查看Pod的状态

kubectl get pod 

查看Pod的详细信息

kubectl describe pod 

查看Pod资源的日志

kubectl logs -f  -c 

查看kubelet组件的状态

systemctl status kub