Init:CrashLoopBackOff: An init container keeps failing, so the kubelet is backing off between retries

Init:CrashLoopBackOff is CrashLoopBackOff applied to an init container. The pod's app containers have never run, and the failure is in the init container's logs — which you must ask for by name.

Applies to: All Kubernetes versions

What it means

When an init container exits non-zero under restartPolicy: Always, the kubelet restarts it. Repeated failures trigger the same exponential back-off used for app containers, and the pod reports Init:CrashLoopBackOff. The practical difference from ordinary CrashLoopBackOff is where to look: kubectl logs POD targets the first app container, which has never started, so it returns an error rather than the failure you want. You have to name the init container. This one detail accounts for a large share of the time people spend stuck on this status.

Most common causes

• A dependency gate that will never pass — waiting for a service that is not deployed, or polling a hostname that does not exist.
• Credentials that are wrong or not yet mounted, so a setup step fails every attempt.
• A migration that fails deterministically, for example against a schema that is already partially applied.
• A missing command or interpreter in the init container's image.
• A volume permission problem that is identical on every retry.
• The init container being OOM-killed, which shows as reason OOMKilled and exit code 137 in its status.

How to diagnose it

1. Read the failing init container's logs by name: kubectl logs POD -c INIT_CONTAINER --previous.
2. Get the exit code and reason from kubectl describe pod POD under Init Containers → Last State.
3. If the logs are empty, the process is dying before it writes anything. Run the same image manually with an overridden command to see what happens.
4. Check whether the dependency the init container waits for actually exists: kubectl get svc,endpoints -n NAMESPACE.

How to fix it

1. Fix the underlying failure — the status clears on its own once the init container exits 0.
2. If the init container is waiting for a dependency that legitimately takes time, ensure it retries internally rather than exiting, so the pod shows PodInitializing instead of a crash loop.
3. Correct the image, command, credentials, or volume permissions as the exit code indicates.
4. If the init container is being OOM-killed, give it its own memory limit — init containers have their own resource block and do not inherit the app container's.

Notes

Init container resource requests are evaluated differently from app containers when scheduling: the effective request for the pod is the larger of the highest init container request and the sum of app container requests. A large init container request can therefore make a pod unschedulable for reasons that are invisible in the app containers.

Related

• Init:Error — An init container exited non-zero
• CrashLoopBackOff — Repeated restarts with increasing delay

Sources

• Kubernetes documentation — Init Containers
• Kubernetes documentation — Debug Init Containers
• Kubernetes documentation — Pod Lifecycle