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

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