I keep getting the 'CrashLoopBackOff' status on my new deployment. The pod starts, stays "Running" for 5 seconds, and then crashes and restarts repeatedly. I’ve checked the basic YAML, and everything looks fine. What are the logical steps a professional would take to find the root cause of this without wasting hours on guesswork?
3 answers
CrashLoopBackOff just means your container is exiting immediately after starting. Step one is always kubectl logs <pod-name> --previous. This is key—if the pod crashed, the current logs might be empty, so you need the logs from the previous failed instance. Most of the time, it's a missing environment variable, a failed database connection, or a file permission issue. If the logs are empty, use kubectl describe pod <pod-name> and look at the "Events" section at the bottom. It might show that the Liveness Probe is failing because the app is taking too long to start, causing K8s to kill it prematurely.
What if the container doesn't even have enough time to write a log before it gets terminated by the system?
I usually check the ImagePullPolicy first. Sometimes the pod crashes because it's trying to run an old version of the code with new config settings.
Good call, Karen. Using the :latest tag is a frequent culprit for these types of "it worked on my machine" deployment failures.
If it's crashing that fast, Larry, it’s often a "Resource Limit" issue. Check your describe output for an OOMKilled status. This means the container tried to use more memory than the limit you set in the YAML, and the Linux kernel killed it instantly. Another possibility is a bad entrypoint command in your Dockerfile. You can debug this by overriding the command in your YAML to ["sleep", "3600"]. This keeps the pod alive so you can kubectl exec into it and manually run your app to see exactly where it fails.