⌂ Home

Kubernetes Init Containers

Interactive guide based on Lab 21. Explore ordered startup, dependency checks, shared volumes, multi-stage initialization, and failure handling before the main app container starts.

What Init Containers Do

Init containers are specialized containers that run to completion before the regular application containers in a Pod are allowed to start.

Repository YAML Files:
  • k8s/labs/workloads/init2-container.yaml — Pod with multiple init containers and a main app container for ordered startup labs.
Execution
Sequential
They run one by one in the order written in the manifest.
Success Rule
Required
Every init container must succeed before the app can start.
Typical Jobs
Prepare
Wait for services, create config, check prerequisites, run migrations.
Failure Effect
Blocked
The Pod does not proceed to app startup if init fails.

Init Container vs Sidecar

FeatureInit ContainerSidecar Container
When it runsBefore main containersAlongside main containers
LifecycleRuns once and exitsRuns continuously
Execution orderSequentialParallel
PurposeSetup and initializationSupport and monitoring
Failure impactPod startup is blockedPod may still continue

Common Lab 21 Patterns

Wait for dependencies

Use `getent hosts`, `nslookup`, or similar checks so the app does not start before required services are available.

Generate config in a shared volume

Init writes files to `emptyDir`; the main container later reads those files from the same volume.

Break startup into stages

Model startup as a series of smaller, auditable, ordered steps rather than one large boot script.

Pod Lifecycle with Init Containers

Click a stage to inspect what Kubernetes is doing at that point.

Step 1
Pod Created
The Pod exists, but app startup is held back.
->
Step 2
Init #1 Runs
Only the first init container is allowed to start.
->
Step 3
Later Init Waits
The next init container is blocked until the current one succeeds.
->
Step 4
All Init Complete
The Pod becomes initialized and can move on.
->
Step 5
App Starts
Main containers now become eligible to run.
->
Failure
Init Error
A failing init container prevents app startup.
Status progression: Pending -> Init:0/N -> Init:1/N -> PodInitializing -> Running

Pod Created

Kubernetes accepts the Pod and schedules it. Because init containers exist, the regular application container cannot start yet.

Interactive Lab Simulator

Step through the most important scenarios from `lab10-pod-init-containers.md`.

Service Dependency
Step 1 of 4
Pod status: Init:0/2
Main container: Waiting for init containers
Select a scenario and use Next Step to inspect state transitions.

How to read it

Only one init container can run at a time. Later stages wait until earlier ones complete successfully.

What to watch

  • Pod status like `Init:0/2` or `Init:Error`
  • Whether the main container is blocked
  • What the logs say the init container is waiting for

Why this matters

Init containers let you separate setup work from your application image and make the Pod's startup behavior easier to explain and debug.

YAML & Commands from Lab 21

Focused reference snippets from the markdown lab manual.

Exercise 1: Service Dependency Pod
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  initContainers:
  - name: init-myservice
    image: registry.access.redhat.com/ubi8/ubi:latest
    command: ['sh', '-c', 'until getent hosts myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: registry.access.redhat.com/ubi8/ubi:latest
    command: ['sh', '-c', 'until getent hosts mydb; do echo waiting for mydb; sleep 2; done;']
  containers:
  - name: myapp-container
    image: registry.access.redhat.com/ubi8/ubi:latest
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
kubectl apply -f init2-container.yaml
kubectl get pod myapp-pod
kubectl describe pod myapp-pod
kubectl logs myapp-pod -c init-myservice
kubectl logs myapp-pod -c init-mydb -f
Exercise 2: Config Setup with emptyDir
initContainers:
  - name: install-config
    image: busybox
    volumeMounts:
    - name: workdir
      mountPath: /work-dir
containers:
  - name: main-app
    image: busybox
    volumeMounts:
    - name: workdir
      mountPath: /config
volumes:
  - name: workdir
    emptyDir: {}
Exercise 4: Failure Handling
apiVersion: v1
kind: Pod
metadata:
  name: failing-init-pod
spec:
  initContainers:
  - name: init-success
    image: busybox
    command: ['sh', '-c', 'echo "Init 1 succeeded"; exit 0']
  - name: init-failure
    image: busybox
    command: ['sh', '-c', 'echo "Init 2 failed"; exit 1']
  containers:
  - name: main-container
    image: busybox
    command: ['sh', '-c', 'echo "Main container running"; sleep 3600']
  restartPolicy: Never
Exercise 5: Database Migration Pattern
initContainers:
  - name: wait-for-db
    image: busybox
  - name: run-migrations
    image: busybox
    volumeMounts:
    - name: migration-status
      mountPath: /migrations
containers:
  - name: webapp
    image: busybox
    volumeMounts:
    - name: migration-status
      mountPath: /migrations
volumes:
  - name: migration-status
    emptyDir: {}
kubectl logs webapp-with-migration -c wait-for-db
kubectl logs webapp-with-migration -c run-migrations
kubectl logs webapp-with-migration

Best Practices

Keep each init step focused

One init container per concern makes startup easier to understand and troubleshoot.

Use shared volumes deliberately

Use `emptyDir` when init needs to hand off generated files or status data to the app container.

Add useful log output

When a Pod is stuck in `Init:*`, clear logs are usually the fastest way to find the bottleneck.

No probes on init containers

Readiness, liveness, and startup probes are not supported for init containers.

Useful Commands

kubectl logs <pod> -c <init-container>
kubectl logs <pod> -c <init-container> -f
kubectl describe pod <pod>
kubectl get pod <pod> -w
kubectl get pod <pod> -o jsonpath='{.spec.initContainers[*].name}'
kubectl get pod <pod> -o jsonpath='{.status.initContainerStatuses[*].state}'

What To Check When Something Breaks

Stuck in waiting

  • Check init logs
  • Verify the service or DNS dependency exists
  • Confirm network access if needed

Stuck in Init:Error

  • Use `kubectl describe pod`
  • Inspect exit code and error message
  • Review restart policy behavior

Shared data missing

  • Confirm the same volume is mounted in both containers
  • Check write path vs read path
  • Validate file permissions if needed

Init takes too long

  • Add timeout logic
  • Set resource requests and limits
  • Avoid endless loops without an exit condition