Your container finished its job. Kubernetes thinks it crashed. Here, a script runs and prints hello, then exits with code 0, which means success. The Pod, Kubernetes' wrapper around your container, shows Completed. Then, strangely, the status flips to CrashLoopBackOff, even though nothing actually failed.

The cause is the Deployment itself. It's the Kubernetes object for always-on apps, so it expects its container to run forever. When your script ends, the process exits, and the Deployment sees that as a crash. It restarts the container, the script runs again, and the loop begins.

Follow the timeline. Kubernetes starts the container, and it exits with code zero. That's success, but Kubernetes restarts it anyway, after about ten seconds. It exits again. The next restart comes after about twenty seconds, and the wait after that is around forty. Same result every time, so the pauses keep growing.

Here's that waiting time as a chart. The first restart waits about ten seconds, then twenty, forty, eighty, and one hundred sixty. By the sixth try it levels off near three hundred seconds, about five minutes. These values are illustrative defaults, but the growing gap is the backoff.

CrashLoopBackOff isn't a special error. It's just Kubernetes restarting an exited container, and waiting a little longer between each attempt.

Here's the difference, side by side. A Deployment keeps a server process running, and when it stops, for any reason, Kubernetes restarts it. A Job is the object that runs something until it finishes. When the process exits successfully, the Job is marked Complete, and nothing restarts.

For an app, keep a long-lived process running in the foreground, like a web server. For your print-and-exit script, use a Job instead. And remember, real errors also cause CrashLoopBackOff, so when a Pod keeps restarting, check its logs.

Before choosing a Deployment, ask whether the process should ever finish. If it should, use a Job. Finishing is success for a script. For a Deployment, it's a crash.