Lab Solution Init Containers Optional

In this lesson we explore Kubernetes init containers. You will identify pods that use init containers, inspect their state, add an init container to a pod, and debug a failing init container. These tasks reinforce common operational workflows with kubectl and help you understand how init containers affect pod startup.

Quick tip: init containers always run to completion before regular containers start. They appear in kubectl describe pod under the “Init Containers” section — they do not contribute to the READY column in kubectl get pods.

1) Which pod has an init container?

List the pods:

controlplane ~ ❯ k get pods
NAME    READY   STATUS    RESTARTS   AGE
red     1/1     Running   0          23s
green   2/2     Running   0          23s
blue    1/1     Running   0          23s

At a glance green shows 2/2 (two regular containers) and blue shows 1/1, but kubectl get pods does not show init container information in the READY column. To inspect init containers, use kubectl describe pod <pod-name>. Describing red shows only regular containers:

controlplane ~ ❯ k describe pod red
Name:         red
Namespace:    default
Status:       Running
IP:           10.42.0.10
Containers:
  red-container:
    Image:          busybox:1.28
    Command:
      sh -c 'echo The app is running! && sleep 3600'
    State: Running
Conditions:
  Initialized:  True
  Ready:        True
  ContainersReady: True

Describing blue reveals an Init Containers: section, identifying blue as the pod with an init container:

controlplane ~ ❯ k describe pod blue
Name:         blue
Namespace:    default
Status:       Running
IP:           10.42.0.11

Init Containers:
  init-myservice:
    Image:         busybox
    Command:
      sh -c 'sleep 5'
    State:         Terminated
      Reason:      Completed
      Exit Code:   0
      Started:     Sun, 17 Apr 2022 18:51:55 +0000
      Finished:    Sun, 17 Apr 2022 18:52:00 +0000
    Ready:         True

Containers:
  blue-container:
    Image: busybox:1.28
    Command:
      sh -c 'echo The app is running! && sleep 3600'
    State: Running

Answer: the pod with an init container is blue.

2) What image is used by the init container on `blue`?

From the Init Containers: section:

Image: busybox

So the init container uses the busybox image.

3) What is the state and reason for the init container on `blue`?

From the Init Containers: details:

State: Terminated
Reason: Completed
Exit Code: 0

Explanation: the init container executed sleep 5 and exited normally (exit code 0). Init containers terminate when their task completes, after which the pod’s regular containers are started.

4) How many init containers does pod `purple` have? What is the pod state and how long until the application becomes available?

Check the pod status:

controlplane ~ ❯ k get pod purple
NAME    READY   STATUS     RESTARTS   AGE
purple  0/1     Init:0/2   0          11s

Describe purple:

controlplane ~ ❯ k describe pod purple
Name:         purple
Namespace:    default
Status:       Pending
IP:           10.42.0.12

Init Containers:
  warm-up-1:
    Image:         busybox:1.28
    Command:
      sh -c 'sleep 600'
    State:         Running
    Ready:         False

  warm-up-2:
    Image:         busybox:1.28
    Command:
      sh -c 'sleep 1200'
    State:         Waiting
    Reason:        PodInitializing
    Ready:         False

Containers:
  purple-container:
    Image:         busybox:1.28
    Command:
      sh -c 'echo The app is running! && sleep 3600'
    State:         Waiting
    Reason:        PodInitializing

Conditions:
  Initialized:    False
  Ready:          False
  ContainersReady: False
  PodScheduled:   True

Number of init containers: 2 (warm-up-1 and warm-up-2)
Pod state: Pending (because init containers are not finished)
Total initialization time: warm-up-1 (600s) + warm-up-2 (1200s) = 1800s (30 minutes)

Note: init containers run sequentially — the application container waits until all init containers complete. In real workloads, init containers perform tasks like migrations, configuration generation, or pre-warming caches.

5) Add an init container to `red` that sleeps for 20 seconds

Goal: add an init container named init-busybox that runs sleep 20 using the busybox image. Example pod manifest (save as red-pod.yaml and apply with kubectl apply -f or re-create as needed):

apiVersion: v1
kind: Pod
metadata:
  name: red
  namespace: default
spec:
  initContainers:
  - name: init-busybox
    image: busybox
    imagePullPolicy: IfNotPresent
    command:
      - sh
      - -c
      - sleep 20
  containers:
  - name: red-container
    image: busybox:1.28
    command:
      - sh
      - -c
      - echo The app is running! && sleep 3600

Apply the manifest:

# Save to red-pod.yaml then:
kubectl replace --force -f red-pod.yaml
# or:
kubectl apply -f red-pod.yaml

After the init container completes (20 seconds) the pod’s main container will start and the pod will become Running.

6) Debugging a failing init container: pod `orange`

Initial symptom:

controlplane ~ » k get pod orange
NAME    READY   STATUS                 RESTARTS   AGE
orange  0/1     Init:CrashLoopBackOff   1 (12s ago)   15s

Describe shows the failing init container init-myservice:

controlplane ~ » k describe pod orange
Init Containers:
  init-myservice:
    Image: busybox
    Command:
      sh -c 'sleeep 2;'
    State:         Terminated
      Reason:       Error
      Exit Code:    127
    Last State:
      Terminated
      Reason: Error
      Exit Code: 127

Fetch the init container logs:

controlplane ~ » k logs orange -c init-myservice
sh: sleeep: not found

Root cause: a typo in the command (sleeep instead of sleep) causes the shell to return exit code 127 (command not found), which leads to Init:CrashLoopBackOff.

When an init container repeatedly fails, the pod remains in initialization state. Use kubectl describe pod <pod> to see the init container section and kubectl logs -c <init-container> to get its logs. Fix the command or image and reapply the manifest.

Fix the typo by editing the manifest or using kubectl edit pod orange and update the init container:

spec:
  initContainers:
  - name: init-myservice
    image: busybox
    imagePullPolicy: Always
    command:
      - sh
      - -c
      - sleep 2;
  containers:
  - name: orange-container
    image: busybox:1.28
    command:
      - sh
      - -c
      - echo The app is running! && sleep 3600

After applying the fix, the init container completes and the pod becomes Running:

controlplane ~ » k describe pod orange
Init Containers:
  init-myservice:
    Image: busybox
    Command:
      sh -c 'sleep 2;'
    State:         Terminated
      Reason:       Completed
      Exit Code:    0
Containers:
  orange-container:
    Image: busybox:1.28
    State: Running
Conditions:
  Initialized:    True
  Ready:          True
  ContainersReady: True
  PodScheduled:   True

Final pod status:

controlplane ~ » k get pods orange
NAME    READY   STATUS    RESTARTS   AGE
orange  1/1     Running   0          27s

Summary: a small typo in an init container command can block pod startup and cause Init:CrashLoopBackOff. Diagnose with kubectl describe and kubectl logs -c <init-container>, then correct the manifest and reapply.

Quick reference table

Pod	Init Containers	Pod State (example)	Notes
`red`	None (before step 5) / 1 (after)	Running (after init completes)	Add `initContainers` to pod manifest to delay app start for pre-work
`green`	0	Running	`READY` shows regular containers only
`blue`	1 (`init-myservice`)	Running (init completed)	Init container used `busybox` and exited `Completed`
`purple`	2 (`warm-up-1`, `warm-up-2`)	Pending (`Init:0/2`)	Init containers run sequentially; total delay = sum of sleeps
`orange`	1 (failing `init-myservice`)	Init:CrashLoopBackOff (until fixed)	Use `kubectl logs -c <init>` to find command errors

Links and references

Kubernetes init containers concept: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
kubectl reference: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
Diagnosing pods and containers: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-pod-replication-controller/

End of lab solution.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Lab Solution Init Containers Optional

1) Which pod has an init container?

2) What image is used by the init container on `blue`?

3) What is the state and reason for the init container on `blue`?

4) How many init containers does pod `purple` have? What is the pod state and how long until the application becomes available?

5) Add an init container to `red` that sleeps for 20 seconds

6) Debugging a failing init container: pod `orange`

Quick reference table

Links and references

Watch Video

​1) Which pod has an init container?

​2) What image is used by the init container on blue?

​3) What is the state and reason for the init container on blue?

​4) How many init containers does pod purple have? What is the pod state and how long until the application becomes available?

​5) Add an init container to red that sleeps for 20 seconds

​6) Debugging a failing init container: pod orange

​Quick reference table

​Links and references

Watch Video

1) Which pod has an init container?

2) What image is used by the init container on `blue`?

3) What is the state and reason for the init container on `blue`?

4) How many init containers does pod `purple` have? What is the pod state and how long until the application becomes available?

5) Add an init container to `red` that sleeps for 20 seconds

6) Debugging a failing init container: pod `orange`

Quick reference table

Links and references