Kubernetes initContainer Blocks Pod Start - Fix Ordering in CI

Init containers run one after another, in order, before any app container starts. If one never exits 0 - it crashes, loops, or waits on a dependency that is not ready - the pod stays in Init: and the main containers never run.

What this error means

A pod sits in Init:0/2 or Init:CrashLoopBackOff. kubectl describe pod shows the app containers Waiting with reason PodInitializing while one init container is stuck or restarting.

NAME    READY   STATUS                  RESTARTS   AGE
api-0   0/1     Init:CrashLoopBackOff   3          2m
# describe: Init Containers: wait-for-db  State: Waiting (CrashLoopBackOff)

Common causes

An init container never exits 0

A wait-for-db/migration init container that loops or errors blocks every later init container and all app containers. Init runs are strictly sequential.

The dependency it waits on is not reachable

An init container that blocks on a database, secret, or service that is unavailable will keep retrying and never complete, holding the pod in Init.

How to fix it

Read the init container’s own logs

Logs must be requested for the specific init container by name - the default pod logs show the (not-yet-started) app container.

kubectl logs <pod> -c wait-for-db
kubectl describe pod <pod> | sed -n '/Init Containers/,/Containers/p'

Make the init step correct and ordered

1. Ensure the init command exits 0 on success and non-zero only on real failure.
2. Order init containers so each prerequisite truly precedes the step that needs it.
3. Give external waits a bounded retry so a missing dependency fails loudly instead of hanging.

How to prevent it

• Keep init containers small, idempotent, and guaranteed to exit 0 on success.
• Bound dependency waits so a missing service fails the pod instead of hanging in Init.
• Always pass -c <initContainer> when reading logs for an Init-phase pod.

Related guides