Search code examples
kubernetesgoogle-kubernetes-enginekubernetes-pod

Pod with Debian image is getting created but container is continuously crashing


Below is my Pod manifest:

apiVersion: v1
kind: Pod
metadata:
  name: pod-debian-container
spec:
      containers:
      - name: pi
        image: debian
        command: ["/bin/echo"]
        args: ["Hello, World."]

And below is the output of "describe" command for this Pod:

C:\Users\so.user\Desktop>kubectl describe pod/pod-debian-container
Name:         pod-debian-container
Namespace:    default
Priority:     0
Node:         minikube/192.168.49.2
Start Time:   Mon, 15 Feb 2021 21:47:43 +0530
Labels:       <none>
Annotations:  <none>
Status:       Running
IP:           10.244.0.21
IPs:
  IP:  10.244.0.21
Containers:
  pi:
    Container ID:  cri-o://f9081af183308f01bf1de6108b2c988e6bcd11ab2daedf983e99e1f4d862981c
    Image:         debian
    Image ID:      docker.io/library/debian@sha256:102ab2db1ad671545c0ace25463c4e3c45f9b15e319d3a00a1b2b085293c27fb
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/echo
    Args:
      Hello, World.
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Mon, 15 Feb 2021 21:56:49 +0530
      Finished:     Mon, 15 Feb 2021 21:56:49 +0530
    Ready:          False
    Restart Count:  6
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-sxlc9 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  default-token-sxlc9:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-sxlc9
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  15m                   default-scheduler  Successfully assigned default/pod-debian-container to minikube
  Normal   Pulled     15m                   kubelet            Successfully pulled image "debian" in 11.1633901s
  Normal   Pulled     15m                   kubelet            Successfully pulled image "debian" in 11.4271866s
  Normal   Pulled     14m                   kubelet            Successfully pulled image "debian" in 11.0252907s
  Normal   Pulled     14m                   kubelet            Successfully pulled image "debian" in 11.1897469s
  Normal   Started    14m (x4 over 15m)     kubelet            Started container pi
  Normal   Pulling    13m (x5 over 15m)     kubelet            Pulling image "debian"
  Normal   Created    13m (x5 over 15m)     kubelet            Created container pi
  Normal   Pulled     13m                   kubelet            Successfully pulled image "debian" in 9.1170801s
  Warning  BackOff    5m25s (x31 over 15m)  kubelet            Back-off restarting failed container
  Warning  Failed     10s                   kubelet            Error: ErrImagePull

And below is another output:

C:\Users\so.user\Desktop>kubectl get pod,job,deploy,rs
NAME                       READY   STATUS             RESTARTS   AGE
pod/pod-debian-container   0/1     CrashLoopBackOff   6          15m

Below are my question:

  • I can see that Pod is running but Container inside it is crashing. I can't understand "why" because I see that Debian image is successfully pulled
  • As you can see in "kubectl get pod,job,deploy,rs" output, RESTARTS is equal to 6, is it the Pod which has restarted 6 times or is it the container?
  • Why 6 restart happened, I didn't mention anything in my spec

Solution

  • This looks like a liveness problem related to the CrashLoopBackOff have you cosidered taking a look into this blog it explains very well how to debug the problem blog