Pod状态异常排查问题集-CrashLoopBackOff状态排查思路

镜像代码有问题：在使用dockerbuild的构建玩镜像，先在本地基于这个镜像docker run先启动容器看看是否可以正常启动，如果能够启动那说明这个镜像是没问题的，如果启动不了说明构建的这个镜像是有问题的。

然后可以去查看dockerfile的语法有没有问题，或者编译打包的时候这个代码有没有编译完全，有没有遗漏的地方需要去排查。

当docker run可以正常运行容器，说明代码没问题，然后可以去看看环境变量是否有问题。因为放在k8s里面不能运行，看看k8s资源清单文件，涉及到env环境变量这些配置有没有问题。

如果这些都没问题，那可能和资源的限额有关系了，比如上面logs看到的信息，可能是设置的不合理，比如说分配的资源少导致pod容器启动的时候超过这个内存，比如超过limit限制那么超过1G的容量那么pod里面容器就会被杀掉，那么pod里面容器重启就会导致CrashLoopBackOff状态。

所以说很有可能在资源配额的时候，最高资源限制的有点小，比如pod里面部署了es，es启动的时候就要占用最少800M的内存，那么es在工作存储数据的时候那么内存肯定要超过800M，那么超过限制1G，pod里面的容器就会重启一下就会出现这个状态，为了验证是不是这个问题，那么就可以将resource字段修改一下，然后apply一下，这样避免删除pod，或者修改了清单配置，一个一个删除pod。然后看看会不会再次出现上面现象。如果很长时间没有出现上面这种现象将内存调大一些。（如果不加会造成内存泄露，必须做限制）

[root@master k8s]# kubectl apply -f eureka.yaml 
ingress.extensions/eureka configured
service/eureka unchanged
statefulset.apps/eureka configured



        resources:
          requests:
            cpu: 0.5
            memory: 512Mi
          limits:
            cpu: 1
            memory: 1300Mi   由1G调整为1300M

标签：容器,eureka,问题,排查,内存,镜像,CrashLoopBackOff,Pod,pod
来源： https://blog.csdn.net/qq_34556414/article/details/118244512