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 knowsystem
NAME READY STATUS RESTARTS AGE IP NODE
knowsystem-v1-96d57f6c-zbmgj 0/1 ContainerCreateing 0 180s 100.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 reset
2.停止docker和kubelet服务
systemctl stop docker
systemctl stop kubelet
3.删除cni和kubelet产生的数据文件
rm -rf /var/lib/cni/
rm -rf /var/lib/kubelet/*
4.把相关网卡关掉
ifconfig cni0 down
ifconfig flannel.1 down
ifconfig docker0 down
5.把产生问题的网卡删掉
ip link delete cni0
ip link delete flannel1.1
6.重启docker和kubelet
systemctl start docker
systemctl start kubelet
最后再把该节点重新加入到K8S集群中
注意：在执行
kubeadm reset
命令时，首先将该节点中的所有Pod资源驱逐，然后在释放。
3.持久化存储卷或存储服务器异常导致Pod长时间处于无法创建问题排查过程
1）查看Pod的运行状态
kubectl get pod -o wide | grep knowsystem
NAME READY STATUS RESTARTS AGE IP NODE
knowsystem-v1-96d57f6c-zbmgj 0/1 ContainerCreateing 0 180s 100.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 pod
k8s-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_name>
查看Pod的详细信息
kubectl describe pod <pod_name>
查看Pod资源的日志
kubectl logs -f <pod_name> -c <containers_name>
查看kubelet组件的状态
systemctl status kub
版权归原作者 Jiangxl~ 所有， 如有侵权，请联系我们删除。