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