Day 31intermediateMar 3, 2026

Run Setup Tasks Before Your App with Init Containers

Init containers guarantee your dependencies are ready before your app starts.

kubernetespodsinitialization

What

Init containers run before your application containers start and must complete successfully before the main container launches. They run sequentially — each must finish before the next begins. They're perfect for setup tasks like waiting for a database, fetching configuration, running schema migrations, or setting file permissions.

Why It Matters

Without init containers, your app might crash on startup because a database isn't ready yet or config hasn't been fetched. You'd need retry logic baked into your application code. Init containers move that responsibility to the infrastructure layer, keeping your app code clean and your startup reliable.

Example

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  initContainers:
  # Wait for database to be reachable
  - name: wait-for-db
    image: busybox:1.36
    command: ['sh', '-c',
      'until nslookup postgres-service.default.svc.cluster.local;
       do echo waiting for db; sleep 2; done']
  # Fetch config from remote source
  - name: fetch-config
    image: curlimages/curl:8.4.0
    command: ['sh', '-c',
      'curl -o /config/app.yaml https://config-server/app.yaml']
    volumeMounts:
    - name: config-vol
      mountPath: /config
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: config-vol
      mountPath: /config
  volumes:
  - name: config-vol
    emptyDir: {}

yaml

Common Mistake

Not setting resource limits on init containers, causing them to consume excessive cluster resources during startup. Init containers also count toward the pod's total resource allocation.

Quick Fix

Set resource requests and limits on init containers just like you do for app containers. Also set a reasonable timeout or failure threshold so a broken init container doesn't block your pod forever.