We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Kubernetes Containers
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Kubernetes Containers
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Your web application needs a database. On startup, the database might not be ready yet. is still provisioning the pod, running its own init containers, applying migrations. If your app starts and immediately tries to connect, it crashes. So you add retry logic with exponential backoff. Now your application code knows about database startup sequences. That is not its job.
Your needs secrets from HashiCorp Vault. You bake Vault-fetching logic into the app. Now every service has Vault authentication code, and a Vault outage during app startup causes cascading failures across your entire fleet.
Init containers solve this by separating setup concerns from application logic. They run before the main container starts, complete their task, and exit. Only after all init containers succeed does the main container start. If an init container fails, Kubernetes retries it. The main container never starts in a broken state.
Airbnb uses init containers extensively in their Kubernetes deployment pipeline. Every service pod has three init containers: one that waits for dependent services, one that runs database migrations, and one that fetches secrets from their configuration service. The application container starts clean, with all dependencies ready and configuration in place.
| Pattern | Init Container Does | Why Not in App Container |
|---|---|---|
| Wait for dependency | Polls until database/cache/queue is reachable | App code should not know about infra startup timing |
| Database migration | Runs flyway migrate or prisma migrate deploy | Migration should run once, not in every replica |
| Config fetch | Downloads secrets from Vault/AWS Secrets Manager | Separates config management from app logic |
| Permission setup | chown and chmod on shared volumes | Runs as root while the app runs as non-root (UID 1000) |
| Schema validation | Checks database schema version matches expected | Prevents app from starting against an incompatible schema |
| Certificate generation | Creates TLS certs using cert-manager or SPIFFE | Cert rotation is infra concern, not app concern |
Key behaviors you need to know:
Init containers run sequentially. Init-1 must exit with code 0 before Init-2 starts. If any init container exits non-zero, restarts the pod (subject to restartPolicy). The entire init chain runs again from scratch.
Init containers can use different images than the main container. Your wait-for-db init can use a 5MB busybox image. Your migration init can use the Flyway image. Your app container uses your application image. Each init container is purpose-built for its task.
Init containers can run as root even if the main container runs as a non-root user. This is useful for chown operations on shared volumes. The PodSecurityContext's runAsNonRoot does not apply to init containers (though securityContext on individual init containers can enforce it).
Init containers share volumes with the main container. An init container can write config files to an emptyDir volume, and the main container reads them from the same mount point.