0


K8S集群中Pod资源处于CrashLoopBackOff状态排查思路

K8S集群中Pod资源处于CrashLoopBackOff状态排查思路

文章目录

1.Pod资源处于CrashLoopBackOff状态的原因

CrashLoopBackOff状态一般都是Pod资源中的容器出现了问题,可以有以下几点原因:

  • 容器中部署的程序存在Bug,无法正常启动,就会出现此状态,可以查询容器的启动日志,从日志中获取重要线索,逐个进行排查。
  • 定义Pod资源时,对于Pod中的容器进行了资源限额,可能限额的资源不够容器使用,就会导致Pod处于此状态。

CrashLoopBackOff状态存在偶发性,可能上一秒还是Running状态,下一秒就成了CrashLoopBackOff状态了。

一般Pod资源处于CrashLoopBackOff状态都是和容器有关,通过排查容器输出的日志即可解决问题。

2.Pod资源处于CrashLoopBackOff状态的排查思路

1)首先查看Pod的运行状态

# kubectl get pod

NAME                           READY   STATUS              RESTARTS   AGE    IP               NODE        NOMINATED NODE   READINESS GATES
know-system-76cf9f56b4-m69dm   0/1     CrashLoopBackOff    1          43s    100.64.169.165   k8s-node2   <none>           <none>

可以看到Pod已经处于CrashLoopBackOff状态了,在处于此状态之前,首先处于Error状态,接下来我们进一步进行排查。

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

# kubectl describe pod know-system-76cf9f56b4-m69dm

在这里插入图片描述

可以看到Pod上一秒还是启动成功的状态,下一秒就成了Back-off。

在这里貌似并不能看出什么有利的信息,我们下面来查看一下Pod中容器的运行日志。

3)查看Pod中容器的运行日志

# kubectl logs -f know-system-76cf9f56b4-m69dm

nginx: [emerg] unknown directive "asldjlasjdlkasjdlkasjdlkjl" in /data/nginx/conf/conf.d/know-system.conf:4

查看了容器的运行日志,我们就可以从中得到有利的线索,可以从日志中判断出,是容器中的服务出现了故障,才导致Pod没有启动成功。

4)问题解决过程

根据容器的日志提示,可以看到是Nginx的配置文件有配置参数写错了,进入到容器中,观察是那一部分配置有问题,便可解决问题。

该问题的原因是容器中的服务出现了问题,我们可以手动使用

docker run

命令在本地将这个容器启动起来,看看有没有问题,如果有问题,说明就是Dockerfile制作的时候就出现了问题,镜像都无法启动,那么放到K8S集群必然是无法启动的。

3.资源限制问题导致Pod处于CrashLoopBackOff状态

除了由于服务问题导致Pod处于CrashLoopBackOff状态外,还有一种原因也可能会导致Pod处于CrashLoopBackOff状态。

我们在部署Pod的时候会给容器的CPU、内存使用进行限制,一开始的限制没有问题,但是随着业务量的增大,超出了当时的设置,此时Pod就会重启,启动时资源的配置还是无法满足容器的使用,那么Pod就会一直处于CrashLoopBackOff状态。

如果是资源限制问题导致Pod处于CrashLoopBackOff状态,在查询日志时就会看到如下报错信息。

failed to write 1026 to cpu.cfs_quota_us

解决思路就是先将资源限制的配置取消,观察是否能正常启动,如果可以,那么久重新分配容器的资源限制即可。


本文转载自: https://blog.csdn.net/weixin_44953658/article/details/125455319
版权归原作者 Jiangxl~ 所有, 如有侵权,请联系我们删除。

“K8S集群中Pod资源处于CrashLoopBackOff状态排查思路”的评论:

还没有评论