Init Container

Definition

An init container is a container in a Kubernetes pod that runs to completion before the pod's main application containers start, typically used for setup tasks like fetching configuration or waiting on a dependency.

Overview

Kubernetes pods can define one or more init containers alongside their regular application containers. Init containers run sequentially, each one must exit successfully before the next starts, and only once every init container has completed does Kubernetes start the pod's main containers. If an init container fails, Kubernetes restarts the pod according to its restart policy, meaning the main application never starts running in a broken or unprepared state. This ordering guarantee makes init containers well suited to setup work that must finish before the application can safely run: cloning configuration from a git repository, running a database migration, waiting for a dependent service to become reachable, or setting file permissions on a shared volume. Because init containers are separate container images, they can use entirely different tooling than the main application — for example, a lightweight shell-based image with `curl` and `wait-for-it` scripts, even if the main application container is a minimal distroless image with no shell at all. Init containers differ from sidecar containers in a key way: sidecars run for the full lifetime of the pod alongside the main application, while init containers run once, before the application starts, and then exit. Both share the pod's volumes, which is what makes them useful together — an init container might download a TLS certificate into a shared volume that a sidecar or the main container later reads. Because they run before the main application and can block startup entirely if they fail or hang, init containers are also a common place to debug slow pod startup times, since a misbehaving init container will delay or prevent the whole pod from becoming ready.

Key Concepts

• Runs to completion before a pod's main containers start
• Multiple init containers run sequentially, each must succeed
• Commonly used for config fetching, migrations, or dependency waits
• Can use different tooling or images than the main application container
• Shares the pod's volumes with the main and sidecar containers
• Pod restarts if an init container fails, per the pod's restart policy
• Distinct from sidecars, which run for the pod's entire lifetime

Use Cases

Frequently Asked Questions

Related in DevOps