pod状态CrashLoopBackOff_pod crashloopbackoff_苍鹰蛟龙的博客

相关文章推荐
八块腹肌的小熊猫 · BottomNavigationView使用 ...· 5 月前 ·
深沉的创口贴 · 将字符串列转换为JSON并在PySpark中解析· 9 月前 ·
爱喝酒的白开水 · ubuntu - squid proxy ...· 1 年前 ·
健身的熊猫 · Django知识点笔记（2）-阿里云开发者社区· 1 年前 ·
强悍的鸡蛋面 · Oracle Critical Patch ...· 1 年前 ·
pod启动或者通过ReplicaSet等控制器启动pod后，pod的状态一瞬间呈现Completed状态，随后一直显示CrashLoopBackOff状态，导致pod一直重启失败，如下所示
[root@k8s-master01 sc_work]# kubectl create -f replica_set_example.yaml 
replicaset.extensions/nginx-relica created
[root@k8s-master01 sc_work]# kubectl get pod
NAME                 READY   STATUS      RESTARTS   AGE
nginx-relica-d6fhn   0/1     Completed   0          3s
nginx-relica-gqsbn   0/1     Completed   0          3s
nginx-relica-nvjk5   0/1     Completed   1          3s
[root@k8s-master01 sc_work]# kubectl get pod
NAME                 READY   STATUS             RESTARTS   AGE
nginx-relica-d6fhn   0/1     CrashLoopBackOff   1          6s
nginx-relica-gqsbn   0/1     CrashLoopBackOff   1          6s
nginx-relica-nvjk5   0/1     CrashLoopBackOff   1          6s
所用的yaml如下所示： 
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: nginx-relica
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-label
  template:
    metadata:
      labels:
        app: nginx-label
    spec:
      containers:
      - name: nginx-pod
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        command: ["/bin/sh", "-c", "echo hello world > /usr/share/nginx/html/hello.html"]
当ReplicaSet控制创建3个pod后，3个pod中分别启动了容器nginx-pod，启动容器后，以非常短的时间执行 ["/bin/sh", “-c”, “echo hello world > /usr/share/nginx/html/hello.html”]后，容器就要结束了，退出码为0，pod状态为completed状态。但ReplicaSet设置的副本数为3，导致3个pod要重启，但pod中容器只执行一个command命令就结束，导致pod的生命周期非常短，k8s都来不及启动就消亡了，导致pod出现CrashLoopBackOff状态。 
3、解决办法
 
延长pod的声明周期，比如yaml改成如下形式，在command中增加sleep延长pod的运行时间。 
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: nginx-relica
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-label
  template:
    metadata:
      labels:
        app: nginx-label
    spec:
      containers:
      - name: nginx-pod
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        #command中增加sleep，延长pod运行时间
        command: ["/bin/sh", "-c", "echo hello world > /usr/share/nginx/html/hello.html; sleep 60"]
删除原来的ReplicaSet后，再重新执行ReplicaSet，pod正常运行 
[root@k8s-master01 sc_work]# kubectl create -f replica_set_example.yaml 
replicaset.extensions/nginx-relica created
[root@k8s-master01 sc_work]# kubectl get pod
NAME                 READY   STATUS    RESTARTS   AGE
nginx-relica-4vjl9   1/1     Running   0          4s
nginx-relica-5l7w2   1/1     Running   0          4s
nginx-relica-t6qdc   1/1     Running   0          4s
[root@k8s-master01 sc_work]# kubectl get pod
NAME                 READY   STATUS    RESTARTS   AGE
nginx-relica-4vjl9   1/1     Running   0          16s
nginx-relica-5l7w2   1/1     Running   0          16s
nginx-relica-t6qdc   1/1     Running   0          16s
                                    使用kubectl get pod --all-namespaces查看pod运行情况，发现ks-controller-manage这个pod提示CrashLoopBackOff失败了。
开始排查.先查看pod的启动日志，使用命令
kubectl logs ks-controller-manager-ccd88d45f-jrg7r -n kubesphere-system ，发现有报错信息，
然后拿这个报错信息进行下一步排查即可。
$ kubectl run crasher --image=rosskukulinski/crashing-app
查看这个pod的状态：
$ kubectl get pods
NAME                       READY     STATUS             RESTARTS   AGE
crasher-2443551393-vuehs   0/1    ...
                                    CrashLoopBackOff状态一般都是Pod资源中的容器出现了问题，可以有以下几点原因：CrashLoopBackOff状态存在偶发性，可能上一秒还是Running状态，下一秒就成了CrashLoopBackOff状态了。一般Pod资源处于CrashLoopBackOff状态都是和容器有关，通过排查容器输出的日志即可解决问题。1）首先查看Pod的运行状态
可以看到Pod已经处于CrashLoopBackOff状态了，在处于此状态之前，首先处于Error状态，接下来我们进一步进行排查。2）查看Pod运行
                                    是一种 Kubernetes 状态，表示 Pod 中发生的重启循环：Pod 中的容器已启动，但一遍又一遍的崩溃然后又重新启动。Kubernetes 将在重新启动之间等待越来越长的BackOff时间，以便您有机会修复错误。因此，CrashLoopBackOff 本身并不是一个错误，而是表明发生了一个错误，导致 Pod 无法正常启动。Pod 在 Running、Failed 和 Waiting 之间循环请注意，它重新启动的原因是因为它设置为Always（默认情况下）或OnFailure。...
                                    这里记录下一次k8s里解决CrashLoopBackOff的思路和过程。
我是T型人小付，一位坚持终身学习的互联网从业者。喜欢我的博客欢迎在csdn上关注我，如果有问题欢迎在底下的评论区交流，谢谢。
文章目录问题现象问题分析问题解决拓展总结
在一次测试ConfigMap的过程中，我想起一个单容器的pod，简单的打印出容器内所有的环境变量，以验证ConfigMap的传递。结果pod起来以后一直出现CrashLoopBackOff的状态。
这里为了抽离出问题的本质，去掉干扰项，将pod的生成yam
                                    一、Pod一直处于Pending状态二、Pod一直处于Waiting 或 ContainerCreating状态三、Pod 一直处于CrashLoopBackOff状态四、Pod处于Error状态五、Pod 处于Terminating或 Unknown状态
一、Pod一直处于Pending状态
Pending状态意味着Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功(可以通过kubectl.
                                    1 问题描述使用命令kubectl create -f myubuntu_deploy.yaml --record生成pod，结果显示pod处于CrashLoopBackOff状态。CrashLoopBackOff 告诉我们，Kubernetes 正在尽力启动这个 Pod，但是一个或多个容器已经挂了，或者正被删除。This is what I keep getting:[root@centos-m...
这周一，新年后上班第一个完整周，年前一波需求已经评审过了，方案也已经制定好，所以年后就开始了如火如荼的写bug阶段，正在写go bug，突然企业微信，tapd弹出一条消息，提了一个缺陷单，处理人是我，顿时预感不妙，果然5秒后，测试同学那微笑的头像弹出来，嗯，完蛋，bug来了。测试同学告诉我，有一个node组件，使用chao注入故障，频繁杀掉主线程，大概会在第七轮杀掉主进程，pod会长时间处于crashloopbackoff阶段，很久才恢复正常。当时很疑惑，为什么第七轮会长时间处于crashloopba