程序员最近都爱上了这个网站  程序员们快来瞅瞅吧!  it98k网:it98k.com

本站消息

站长简介/公众号

  出租广告位,需要合作请联系站长

+关注
已关注

分类  

暂无分类

标签  

暂无标签

日期归档  

原力计划K8S故障排查指南:部分节点无法启动Pod资源-Pod处于ContainerCreating状态

发布于2022-06-02 06:52     阅读(735)     评论(0)     点赞(8)     收藏(5)


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

原文链接:https://blog.csdn.net/weixin_44953658/article/details/124920442



所属网站分类: 技术文章 > 博客

作者:hhbnn

链接:http://www.phpheidong.com/blog/article/337651/7eab61510abf1dd7d8ba/

来源:php黑洞网

任何形式的转载都请注明出处,如有侵权 一经发现 必将追究其法律责任

8 0
收藏该文
已收藏

评论内容:(最多支持255个字符)