CrashLoopBackOff - Back-off restarting failed container

Question

I have my image hosted on GCR. I want to create Kubernetes Cluster on my local system(mac).

Steps I followed :

1. Create a imagePullSecretKey
2. Create generic key to communicate with GCP. (kubectl create secret generic gcp-key --from-file=key.json)
3. I have deployment.yaml file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sv-premier
spec:
  selector:
    matchLabels:
      app: sv-premier
  template:
    metadata:
      labels:
        app: sv-premier
    spec:
      volumes:
      - name: google-cloud-key
        secret:
          secretName: gcp-key
      containers:
      - name: sv-premier
        image: gcr.io/proto/premiercore1:latest
        imagePullPolicy: Always
        command: ["echo", "Done deploying sv-premier"]
        volumeMounts:
        - name: google-cloud-key
          mountPath: /var/secrets/google
        env:
        - name: GOOGLE_APPLICATION_CREDENTIALS
          value: /var/secrets/google/key.json
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: imagepullsecretkey

When I execute the command - kubectl apply -f deployment.yaml , I get CrashLoopBackOff Error

Logs for -

kubectl describe pods podname

=======================

Name: sv-premier-6b77ddd747-cvdr5

Namespace: default

Priority: 0

Node: docker-desktop/192.168.65.3

Start Time: Tue, 04 Feb 2020 14:18:47 +0530

Labels: app=sv-premier

pod-template-hash=6b77ddd747

Annotations:

Status: Running

IP: 10.1.0.43

IPs:

Controlled By: ReplicaSet/sv-premier-6b77ddd747

Containers:

sv-premierleague:

Container ID:  docker://141126d732409427fe39b405865f88856ac4e1d8586112797fc5bf4fdfbe317c

Image:         gcr.io/proto/premiercore1:latest

Image ID:      docker-pullable://gcr.io/proto/premiercore1@sha256:b3800ccca3f30725d5c9235dd349548f0fcfe309f51883d8af16397aef2c3953

Port:          8080/TCP

Host Port:     0/TCP

Command:

  echo

  Done deploying sv-premier

State:          Waiting

  Reason:       CrashLoopBackOff

Last State:     Terminated

  Reason:       Completed

  Exit Code:    0

  Started:      Tue, 04 Feb 2020 15:00:51 +0530

  Finished:     Tue, 04 Feb 2020 15:00:51 +0530

Ready:          False

Restart Count:  13

Environment:

  GOOGLE_APPLICATION_CREDENTIALS:  /var/secrets/google/key.json

Mounts:

  /var/run/secrets/kubernetes.io/serviceaccount from default-token-s4jgd (ro)

  /var/secrets/google from google-cloud-key (rw)

Conditions:

Type Status

Initialized True

Ready False

ContainersReady False

PodScheduled True

Volumes:

google-cloud-key:

Type:        Secret (a volume populated by a Secret)

SecretName:  gcp-key

Optional:    false

default-token-s4jgd:

Type:        Secret (a volume populated by a Secret)

SecretName:  default-token-s4jgd

Optional:    false

QoS Class: BestEffort

Node-Selectors:

Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s

             node.kubernetes.io/unreachable:NoExecute for 300s

Events:

Type Reason Age From
Message

---- ------ ---- ----

Normal Scheduled 46m default-scheduler
Successfully assigned default/sv-premier-6b77ddd747-cvdr5 to docker-desktop

Normal Pulled 45m (x4 over 46m) kubelet, docker-desktop Successfully pulled image "gcr.io/proto/premiercore1:latest"

Normal Created 45m (x4 over 46m) kubelet, docker-desktop Created container sv-premier

Normal Started 45m (x4 over 46m) kubelet, docker-desktop Started container sv-premier

Normal Pulling 45m (x5 over 46m) kubelet, docker-desktop Pulling image "gcr.io/proto/premiercore1:latest"

Warning BackOff 92s (x207 over 46m) kubelet, docker-desktop Back-off restarting failed container

=======================

And output for -

kubectl logs podname --> Done Deploying sv-premier

I am confused why my container is exiting. not able to start.

Kindly guide please.

Answer 1

Update your deployment.yaml with a long running task example.

command: ["/bin/sh"]
args: ["-c", "while true; do echo Done Deploying sv-premier; sleep 3600;done"]

This will put your container to sleep after deployment and every hour it will log the message.

Read more about pod lifecycle container states here