Init Containers: Setup Tasks Before Your Main App Runs
Init containers are setup tasks that run to completion before your main application starts. Use them to wait for dependencies, fetch configs, or run database migrations.
Why it exists
Applications often have startup dependencies. They might need a database to be available, a configuration file to be generated, or a specific directory structure to exist. Putting this logic inside the main application couples it with infrastructure concerns and can bloat the container image.
The mental model
An init container is like a pre-flight checklist for an airplane. The plane (your main app container) can't take off until every item on the checklist (each init container) is successfully completed in order. If any check fails, the flight is grounded, and the main application never starts.
How it works
When a Pod starts, Kubernetes runs any defined init containers sequentially. The first init container starts, runs its command, and must exit with a status code of 0. Only then does the second init container start. This continues until all have completed successfully. If any init container fails, Kubernetes restarts it according to the Pod's restartPolicy. Once all are done, Kubernetes starts the main application containers.
When to use it
Use init containers for blocking setup tasks that must complete before the application starts. Three common places this shows up: first, using a shell command to wait for a database or API endpoint to become available; second, using git or curl to clone a repository or download configuration files into a shared volume; third, running a database migration script before the app server starts.
When not to use it
Do not use init containers for ongoing tasks that should run alongside your main application, like logging, metrics collection, or service mesh proxies. These are better suited for sidecar containers. Also, avoid long-running tasks in init containers, as they directly delay your application's startup time and can make your Pod seem unresponsive.
One canonical example
A web application Pod needs a database to be ready before it starts. An init container can be defined with a simple shell script: until nc -z my-database-service 5432; do echo 'waiting for database...'; sleep 2; done;. This container runs in a loop, checking the database port. Once the connection succeeds, the init container exits successfully, and Kubernetes proceeds to start the main web application container, which can now safely connect.
Interview question
Which statement accurately describes the execution behavior of Init Containers in a Kubernetes Pod?
- a.They start after the main application containers to perform post-startup cleanup tasks.
- b.They execute in a defined sequence, and each must complete successfully before the next or the main application starts.Correct
- c.They are primarily used for logging and metrics collection during the application's runtime.
- d.They run concurrently with the main application containers to provide auxiliary services.
Why? this is the answer
Init containers are designed to run sequentially and must complete successfully before the main application containers are started, acting as a pre-flight checklist. Options A and C describe sidecar containers, which run alongside the main application for ongoing tasks, while option A incorrectly states they run after the main application.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles