Init:Error: An init container exited with a non-zero status

Init:Error means one of the pod's init containers ran and failed. Because init containers must all succeed before the app starts, a single failure blocks the entire pod, and the reason is in that container's logs.

Applies to: All Kubernetes versions

What it means

Every init container must exit with status 0 before the next one runs and before any app container starts. When one exits non-zero, the pod reports Init:Error. Under the default restartPolicy: Always the kubelet retries the failed init container, so this status often flips quickly to Init:CrashLoopBackOff; with restartPolicy: Never the whole pod moves to Failed and stops. The important structural point is that this is not an application error in the usual sense — the app never ran. Reading kubectl logs POD without naming the init container returns nothing useful, which is why this state is often harder to diagnose than it should be.

Most common causes

• The init container's script exited non-zero because the thing it was checking for was not there.
• A migration or schema setup step failed — bad credentials, an unreachable database, a conflicting migration.
• A file the init container was meant to write could not be written, usually a read-only or wrongly-owned volume.
• The init container's command does not exist in its image, producing exit code 127.
• A permissions problem — the init container runs as a user without access to the mounted volume.
• A network call inside the init container failed because cluster DNS was not ready on that node yet.

How to diagnose it

1. Identify which init container failed: kubectl describe pod POD and read the Init Containers block, which shows each one's state, reason, and exit code.
2. Read its logs by name: kubectl logs POD -c INIT_CONTAINER. Add --previous if it has already restarted.
3. Check the exit code. 127 means the command was not found, 1 or 2 usually means the script itself failed, and 137 means it was killed.
4. If the init container writes to a volume, check ownership and permissions — a mismatch between runAsUser and fsGroup is a frequent cause.
5. Reproduce the command locally with the same image to see the full error output.

How to fix it

1. Fix whatever the init container was checking or doing, then delete the pod so the sequence runs again.
2. Make the init container's failure message explicit. An init container that exits 1 with no output is the worst case to debug and is entirely avoidable.
3. Correct volume ownership with fsGroup, or run the init container as a user that can write the mount.
4. If the init container is a dependency gate, ensure it retries with a bounded backoff instead of failing on the first attempt while the dependency is still starting.

Notes

Init containers that fail are retried according to the pod's restartPolicy, not their own — there is no per-init-container restart policy. A pod with restartPolicy: Never and a failing init container is terminal and will not recover on its own.

Related

• PodInitializing — An init container is still running
• Init:CrashLoopBackOff — An init container keeps failing and restarting

Sources

• Kubernetes documentation — Init Containers
• Kubernetes documentation — Debug Init Containers
• Kubernetes documentation — Pod Lifecycle: restart policy