PodInitializing: An init container is still running, so the main containers have not started

PodInitializing means the pod's init containers have not all completed. Init containers run one at a time, in order, to completion, and none of the app containers start until every one of them has succeeded.

Applies to: All Kubernetes versions

What it means

Init containers run before the pod's regular containers, sequentially, and each must exit successfully before the next begins. While any of them is still running, the pod reports PodInitializing, and kubectl get pods shows a status like Init:0/2 — the numbers being how many init containers have completed out of how many exist. This is a normal transitional state. It becomes a problem when an init container is waiting on something that will never arrive, which is common because init containers are so often used as a gate: waiting for a database, waiting for a migration, waiting for a dependency's service to answer. A gate with no timeout holds the pod forever and produces no error.

Most common causes

• An init container is deliberately waiting for a dependency — a database, a service endpoint, a migration — that is not ready or never will be.
• An init container is doing genuinely slow work such as downloading a large dataset.
• An init container is crashing and restarting, which shows as Init:CrashLoopBackOff rather than a plain PodInitializing.
• An init container's own image is still being pulled.
• A volume that the init container mounts has not attached.
• The init container's readiness logic is wrong — for example polling a hostname that does not resolve inside the cluster.

How to diagnose it

1. Find which init container is running: kubectl get pod POD -o jsonpath='{.status.initContainerStatuses[*].name}', or read the Init Containers section of kubectl describe pod POD.
2. Read that container's logs specifically — kubectl logs POD -c INIT_CONTAINER. Logs for init containers are not returned by default.
3. Check the Init:N/M counter in kubectl get pods to see how far the sequence got.
4. If the init container is waiting on a service, confirm that service has endpoints: kubectl get endpoints SERVICE.
5. Check events for image pull or volume mount problems affecting the init container.

How to fix it

1. Make the dependency the init container is waiting for actually available, or fix the check if it is testing the wrong thing.
2. Give waiting init containers a bounded retry with a non-zero exit on timeout, so a stuck dependency produces a visible failure instead of a silent hang.
3. Move genuinely long-running work out of an init container and into the application's own startup, paired with a startupProbe.
4. Fix the underlying image pull or volume problem if the init container never started at all.

Notes

Init containers do not run in parallel, so one slow init container delays every one after it. If several independent checks are being done, combining them into a single init container that runs them concurrently is usually faster than chaining several.

Related

• Init:Error — An init container exited non-zero
• Init:CrashLoopBackOff — An init container keeps failing and restarting

Sources

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