What Is an Init Container? Setup Before Your App Starts
An init container runs and finishes before the main containers in a pod start - a guaranteed setup step that gates the app from running until it succeeds.
Sometimes a pod needs preparation before the app boots: waiting for a dependency, running a migration, fetching config. Init containers handle exactly this. They run in order, one after another, and the app containers only start once all of them have completed successfully.
Run-to-completion semantics
Init containers run sequentially before app containers. Each must exit successfully before the next runs. If one fails, Kubernetes restarts the pod and retries - the app never starts on a half-prepared pod.
Common uses
- Waiting until a database or service is reachable.
- Running a schema migration before the app boots.
- Fetching secrets, certs, or config into a shared volume.
- Setting filesystem permissions on a mounted volume.
Init container vs sidecar
An init container does setup and exits before the app; a sidecar runs for the whole pod lifetime alongside the app. Use init for "do this first", sidecar for "keep doing this".
Sharing results
Init containers commonly write to a volume that the app container also mounts - fetched config or certs land there, ready for the app when it starts.
The CI parallel
This mirrors a CI setup step that must succeed before tests run - installing dependencies, waiting for a service container, seeding data. Both enforce "prepare, verify, then proceed".
Key takeaways
- Init containers run to completion, in order, before app containers start.
- They guarantee setup (waits, migrations, config) before the app boots.
- Unlike sidecars, they exit; they do not run for the pod’s lifetime.