Kubernetes Init Container Lifecycle

Kubernetes Init Container Lifecycle is the distinct execution model applied to containers declared under a Pod's spec.initContainers, governing how they are started, ordered, retried, and ultimately excluded from the running Pod once their work is done. Init containers exist specifically to perform setup tasks that must complete before an application container is allowed to start, and their lifecycle rules enforce that guarantee strictly.

Strict Sequential Execution

One at a Time, in Order

Init containers run one after another in the exact order they are listed in the PodSpec. The kubelet does not start the second init container until the first has exited successfully, unlike application containers, which typically start together.

apiVersion: v1
kind: Pod
metadata:
  name: init-lifecycle-example
spec:
  initContainers:
    - name: fetch-secrets
      image: registry.example.com/secret-fetcher:1.0.0
    - name: run-migrations
      image: registry.example.com/migrator:1.0.0
  containers:
    - name: app
      image: registry.example.com/app:1.0.0

Completion Gate for Application Containers

No application container starts until every init container in the list has exited with status code zero. This is what makes init containers suitable for enforcing hard preconditions, database availability, configuration presence, filesystem preparation, rather than soft checks.

Restart Behavior on Failure

Governed by restartPolicy

If an init container fails, the kubelet's retry behavior follows the Pod's restartPolicy. With Always or OnFailure, the kubelet restarts the failed init container in place and does not proceed to the next one until it eventually succeeds. With Never, a failed init container causes the entire Pod to be marked Failed immediately.

spec:
  restartPolicy: OnFailure

Effect on Pod Phase

While an init container is retrying, the Pod remains in Pending phase, and the Initialized condition stays false, which is a common cause of Pods appearing stuck before ever reaching Running.

Resource Accounting

Peak, Not Sum

Because init containers never run concurrently with each other, the node only needs to reserve the resource requests of the single largest init container, not the sum of all of them, when computing whether the Pod fits. However, this peak init-container request is compared against the sum of application container requests, and the greater of the two values determines the effective resource reservation for the Pod.

Termination After Success

Init Containers Do Not Persist

Once an init container exits successfully, it is not restarted again and does not continue running alongside application containers. Its state in initContainerStatuses remains Terminated with reason: Completed for the life of the Pod, serving only as a historical record.

status:
  initContainerStatuses:
    - name: fetch-secrets
      state:
        terminated:
          reason: Completed
          exitCode: 0

Restartable Init Containers

The sidecar Extension

A more recent extension allows an init container to declare restartPolicy: Always at the container level, marking it as a restartable init container. Such a container starts in the normal init sequence but, once running, continues alongside application containers for the life of the Pod and is restarted independently if it fails, effectively behaving as a sidecar that is guaranteed to start before the main application.

initContainers:
  - name: proxy-sidecar
    image: registry.example.com/proxy:1.0.0
    restartPolicy: Always

Init Container Lifecycle Diagram

Understanding this ordered, gating behavior is essential for diagnosing Pods that never leave Pending: the failure is often not in the application container at all, but in an init container earlier in the sequence that has not yet succeeded.