You’ve deployed your application, but a quick check with kubectl get pods shows something is wrong. Instead of the reassuring Running status, you see ImagePullBackOff, CrashLoopBackOff, or Pending. Your pod is stuck, and it's time to find out why.

Your first step is always to gather more information. Kubernetes provides two essential commands for this initial investigation:

1. kubectl describe pod <pod-name>: This gives you a detailed overview of the pod's configuration and, most importantly, a chronological list of events related to its lifecycle. This is often the quickest way to find the root cause.
2. kubectl logs <pod-name>: If the container managed to start even briefly, this command shows you its standard output and error streams. It's the equivalent of looking at the console output of your application.

Think of it this way: describe tells you what Kubernetes tried to do, while logs tells you what your application actually did.

One of the most common initial hurdles is the ImagePullBackOff or ErrImagePull status. This message is straightforward: Kubernetes cannot fetch the container image you specified. The scheduler has assigned the pod to a node, and the kubelet on that node is trying to pull the image from a registry, but it's failing.

Running kubectl describe pod <pod-name> is the best way to diagnose this. If you scroll down to the Events section at the bottom of the output, you'll see messages that pinpoint the problem. Common causes include:

• A typo in the image name or tag.
• The image tag does not exist in the repository.
• You're trying to pull from a private repository without providing the correct credentials via an imagePullSecret.

The term BackOff in the error status indicates that Kubernetes won't hammer the registry relentlessly. It will try to pull the image, fail, wait for a short, exponentially increasing period, and then try again. This prevents a misconfigured deployment from overwhelming a container registry.

If you see the status CrashLoopBackOff, it means the container starts successfully but then exits almost immediately with an error. Kubernetes, doing its job, restarts the container, which then crashes again, creating a loop. Like with image pulls, Kubernetes applies an exponential back-off to the restart attempts to avoid creating a tight, resource-intensive loop.

A CrashLoopBackOff is almost always an application-level problem. Kubernetes has done its part—it pulled the image and started the container—but the code inside is failing. This is where kubectl logs becomes your primary tool.

Run kubectl logs <pod-name> to see the application's output. The error message that caused the crash will likely be one of the last lines in the log. If the pod is restarting very quickly, you might need to check the logs of the previous failed container instance using the --previous flag:

kubectl logs <pod-name> --previous

This shows you the logs from the last termination, which is invaluable for catching the fatal error before the logs are wiped by the restart.

Sometimes a pod gets stuck in a Pending state with the error CreateContainerConfigError. This status means Kubernetes understands how to create the container but is failing on a prerequisite configuration step. The container itself hasn't even been created yet, so kubectl logs won't help.

Once again, kubectl describe pod <pod-name> is your guide. The Events section will tell you exactly what's missing. Most often, this error points to a problem with a ConfigMap or a Secret that the pod is trying to mount or use as an environment variable.

Look for event messages like:

• ConfigMap "my-config" not found
• Secret "my-db-credentials" not found

These errors are explicit. The pod manifest references a configuration object by name, but no object with that name exists in the same namespace as the pod. The solution is simple: create the missing ConfigMap or Secret, or correct the name in your pod's definition.

Another, less common cause for CreateContainerConfigError can be an invalid command in the pod spec. If you try to override the container's entrypoint or command with a value that doesn't exist inside the container image, Kubernetes will fail with this error before starting it.

Lastly, health checks can cause pods to fail after they've started. If a pod's liveness probe fails repeatedly, the kubelet will kill the container and restart it. If a pod's readiness probe fails, the pod won't be killed, but it will be removed from the service endpoint, meaning it won't receive any traffic.

Probe failures are visible in the kubectl describe events. They often point to an application that is running but not healthy—perhaps it can't connect to its database or a required downstream service.

By following a methodical process—checking status, describing the pod for events, and then checking logs for application errors—you can quickly diagnose and resolve the most common pod lifecycle failures.