> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Lab Solution Init Containers Optional

> Hands-on guide to Kubernetes init containers, showing how to identify, inspect, add, and debug them with kubectl and how they affect pod startup.

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.

<Callout icon="lightbulb" color="#1CB2FE">
  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`.
</Callout>

## 1) Which pod has an init container?

List the pods:

```bash theme={null}
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:

```bash theme={null}
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:

```bash theme={null}
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:

```bash theme={null}
controlplane ~ ❯ k get pod purple
NAME    READY   STATUS     RESTARTS   AGE
purple  0/1     Init:0/2   0          11s
```

Describe `purple`:

```bash theme={null}
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):

```yaml theme={null}
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:

```bash theme={null}
# 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:

```bash theme={null}
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`:

```bash theme={null}
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:

```bash theme={null}
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`.

<Callout icon="warning" color="#FF6B6B">
  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.
</Callout>

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

```yaml theme={null}
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`:

```bash theme={null}
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:

```bash theme={null}
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/](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)
* kubectl reference: [https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands](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/](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)

***

End of lab solution.

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/cka-certification-course-certified-kubernetes-administrator/module/2ddcf79b-abb0-4aeb-ad0c-3d54c7b4fc64/lesson/e49fcabb-1859-4f44-aa0d-dabeadfeddd5" />
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.