Init containers in Kubernetes - Commands & Configuration

Introduction

Sometimes your main app needs some setup before it starts. Init containers run first to prepare things like files or settings, so your app can run smoothly.

When you need to download configuration files before your app starts

When you want to wait for a database to be ready before launching your app

When you need to set up permissions or create directories before the main container runs

When you want to run a script that checks or fixes something before the app starts

When you want to separate setup tasks from the main app for better organization

Config File - pod.yaml

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  initContainers:
  - name: init-setup
    image: busybox
    command: ['sh', '-c', 'echo Setting up environment; sleep 5']
  containers:
  - name: main-app
    image: nginx
    ports:
    - containerPort: 80

This YAML defines a Pod with two containers.

initContainers: Runs first to do setup tasks. Here it just prints a message and waits 5 seconds.

containers: The main app container runs after the init container finishes successfully.

Commands

This command creates the Pod with the init container and main container defined in pod.yaml. It starts the setup process first.

Terminal

kubectl apply -f pod.yaml

Expected Output

pod/example-pod created

Check the status of the Pod to see if the init container has finished and the main container is running.

Terminal

kubectl get pods

Expected Output

NAME          READY   STATUS    RESTARTS   AGE

example-pod   1/1     Running   0          10s

See detailed information about the Pod, including the init container status and logs if needed.

Terminal

kubectl describe pod example-pod

Expected Output

Name:         example-pod

Namespace:    default

Status:       Running

Init Containers:

  init-setup:

    Container ID:   docker://abc123

    Image:          busybox

    State:          Terminated

      Reason:       Completed

    Last State:     Terminated

      Reason:       Completed

Containers:

  main-app:

    Container ID:   docker://def456

    Image:          nginx

    State:          Running

      Started:      Thu, 01 Jun 2024 12:00:00 +0000

Key Concept

Init containers run and finish before the main containers start, ensuring setup tasks complete first.

Common Mistakes

Not defining init containers under the correct spec key 'initContainers'

Kubernetes will not recognize the setup container as an init container and may run it alongside the main container.

Always place setup containers under 'initContainers' in the Pod spec to run them first.

Init container command fails or never completes

The main container will never start because init containers must finish successfully first.

Ensure init container commands complete successfully and handle errors properly.

Expecting init containers to keep running after main container starts

Init containers always stop after finishing; they do not run alongside main containers.

Use regular containers for long-running processes, init containers only for setup.

Summary

Define init containers in the Pod spec under 'initContainers' to run setup tasks before the main app.

Use 'kubectl apply -f pod.yaml' to create the Pod with init containers.

Check Pod status with 'kubectl get pods' and details with 'kubectl describe pod example-pod' to verify init container completion.

Practice

1. What is the primary purpose of an init container in Kubernetes?

easy

A. To run setup tasks before the main application container starts

B. To replace the main application container

C. To monitor the health of the main container continuously

D. To scale the number of application containers automatically

Solution

1. Step 1: Understand the role of init containers

   Init containers run before the main app container to prepare the environment, such as setting up files or waiting for services.

2. Step 2: Compare options with this role

   Only To run setup tasks before the main application container starts describes running setup tasks before the main container starts, which matches the purpose of init containers.

3. Final Answer:

   To run setup tasks before the main application container starts -> Option A

4. Quick Check:

   Init container purpose = setup before main container [OK]

Hint: Init containers run first to prepare environment [OK]

Common Mistakes:

• Thinking init containers replace main containers
• Confusing init containers with health checks
• Assuming init containers handle scaling

2. Which of the following is the correct syntax to define an init container in a Kubernetes Pod spec?

easy

A. containers:
- name: init-example
image: busybox
initContainers:
- name: init-example
image: busybox

B. initContainers:
- name: init-example
image: busybox
containers:
- name: app
image: nginx

C. init:
- name: init-example
image: busybox
containers:
- name: app
image: nginx

D. containers:
- name: app
image: nginx
init:
- name: init-example
image: busybox

Solution

1. Step 1: Recall Kubernetes Pod spec structure

   Init containers are defined under the initContainers field, separate from containers.

2. Step 2: Identify correct syntax

   initContainers: - name: init-example image: busybox containers: - name: app image: nginx correctly places initContainers before containers with proper indentation and keys.

3. Final Answer:

   initContainers: - name: init-example image: busybox containers: - name: app image: nginx -> Option B

4. Quick Check:

   Init containers use 'initContainers' key [OK]

Hint: Use 'initContainers' key, not 'init' [OK]

Common Mistakes:

• Using 'init' instead of 'initContainers'
• Placing init container inside 'containers' list
• Incorrect indentation or YAML structure

3. Given this Pod spec snippet, what will happen when the Pod starts?

initContainers:
- name: wait-for-db
  image: busybox
  command: ['sh', '-c', 'until nslookup db-service; do echo waiting; sleep 2; done']
containers:
- name: app
  image: myapp

medium

A. The init container runs in parallel with the app container

B. The app container starts immediately without waiting

C. The Pod fails because 'nslookup' is not a valid command

D. The init container waits until 'db-service' DNS resolves before app starts

Solution

1. Step 1: Understand init container behavior

   Init containers run before app containers and must complete successfully before the app starts.

2. Step 2: Analyze the command in init container

   The command loops until the DNS name 'db-service' resolves, so it waits for the database service to be ready.

3. Final Answer:

   The init container waits until 'db-service' DNS resolves before app starts -> Option D

4. Quick Check:

   Init container waits for service readiness [OK]

Hint: Init containers run sequentially and block app start [OK]

Common Mistakes:

• Thinking init containers run in parallel
• Assuming app starts immediately
• Believing 'nslookup' is invalid in busybox

4. You defined an init container but your main app container never starts. What is the most likely cause?

medium

A. The Pod spec is missing the 'containers' section

B. The app container image is missing

C. The init container failed or is stuck and did not complete successfully

D. The init container is running after the app container

Solution

1. Step 1: Recall init container lifecycle

   Init containers must complete successfully before the app container starts.

2. Step 2: Identify why app container never starts

   If the init container fails or hangs, the app container will not start, causing the Pod to stall.

3. Final Answer:

   The init container failed or is stuck and did not complete successfully -> Option C

4. Quick Check:

   Init container failure blocks app start [OK]

Hint: Check init container status if app never starts [OK]

Common Mistakes:

• Ignoring init container failure status
• Assuming app container image issues cause this
• Thinking init containers run after app containers

5. You want to use multiple init containers to prepare your Pod environment: one to create a config file, and another to download data. How does Kubernetes handle their execution?

hard

A. Init containers run sequentially, one after another, before the app starts

B. Init containers run after the app container starts

C. Only the first init container runs; others are ignored

D. All init containers run in parallel, and the app starts when all finish

Solution

1. Step 1: Understand init container execution order

   Kubernetes runs init containers one by one, in the order defined, waiting for each to finish before starting the next.

2. Step 2: Confirm app container start timing

   The app container only starts after all init containers have completed successfully.

3. Final Answer:

   Init containers run sequentially, one after another, before the app starts -> Option A

4. Quick Check:

   Init containers run sequentially before app [OK]

Hint: Init containers run one by one before app starts [OK]

Common Mistakes:

• Assuming init containers run in parallel
• Thinking app starts before init containers finish
• Believing only the first init container runs