-1

My question is highly related to Back-off restarting failed container - Error syncing pod in Minikube. I came across the same issue. My question is:

Why does "Competed" container result in "CrashLoopBackOff" pod? Per https://sysdig.com/blog/debug-kubernetes-crashloopbackoff/, "CrashLoopBackOff" means "you have a pod starting, crashing, starting again, and then crashing again." But my pod is not crashing at all because the container in it exits without any error. The "starting again" is expected because the default restart policy is Always.

lotterier
  • 1

2 Answers2

1

A Deployment is supposed to keep on running performing something, responding to user request, etc. It's not supposed to end, until told to. If you want to run something to completion, you have to deploy a Job. You can use a Job if you want to run it once for example, or a CronJob if you want to run it on schedule.

As per the comment, you created a Pod without a controller. The API documentation clearly stipulates:

It is recommended that users create Pods only through a Controller, and not directly. See Controllers: Deployment, Job, or StatefulSet.

In essence, this isn't a standard way to deploy.

ETL
  • 6,613
  • 1
  • 30
  • 49
  • Thanks! But in my use case, I actually created a Pod instead of a Deployment. What I expect is that the pod will be Succeeded once the container is Completed. But the Pod still shows "CrashLoopBackOff", and then becomes "Running" because of the container restart policy. So the Pod status is like Running-->CrashLoopBackOff-->Running-->CrashLoopBackOff-->... – lotterier Sep 27 '19 at 18:23
0

I guess you hit the confusion of another community contributors, as so far output of kubectl get pod command doesn't show Pod phase in the corresponded STATUS column, but it actually retrieves the state from particular container inside the Pod, you can find relevant information under containerStatuses: field from within a Pod description, I was answering the same behavior here.

Find the related Github issue addressed #76619 and relevant pull requests #13840, #12397.

Nick_Kh
  • 578