Init containers in Kubernetes - Mini Project: Build & Apply

Init Containers in Kubernetes

📖 Scenario: You are deploying a web application on Kubernetes. Before the main application container starts, you need to run an initialization task that sets up necessary files.

🎯 Goal: Create a Kubernetes Pod manifest with an initContainer that runs a simple setup command before the main container starts.

📋 What You'll Learn

Create a Pod manifest named webapp-pod.yaml

Add an initContainers section with one container named init-setup

The init-setup container should use the busybox image and run the command echo Setup complete

Add a main container named webapp using the nginx image

Ensure the initContainer runs before the main container

💡 Why This Matters

🌍 Real World

Init containers are used in Kubernetes to perform setup tasks like configuration, waiting for services, or preparing data before the main application starts.

💼 Career

Understanding init containers is essential for Kubernetes administrators and DevOps engineers to ensure reliable and ordered application startup.

1

Create the basic Pod manifest

Create a Kubernetes Pod manifest named webapp-pod.yaml with apiVersion set to v1, kind set to Pod, and metadata.name set to webapp. Add a spec section with a single container named webapp using the nginx image.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: webapp
    image: nginx
# Your code here

Hint

Start by defining the Pod with the required fields and add the main container under spec.containers.

2

Add the initContainer section

Add an initContainers section under spec with one container named init-setup. Use the busybox image and set the command to ["echo", "Setup complete"].

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  initContainers:
  - name: init-setup
    image: busybox
    command: ["echo", "Setup complete"]
  containers:
  - name: webapp
    image: nginx
# Your code here

Hint

The initContainers section goes at the same level as containers inside spec.

3

Verify the initContainer runs before the main container

Ensure the Pod manifest has initContainers defined before containers and that the init-setup container uses the busybox image with the command ["echo", "Setup complete"].

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  initContainers:
  - name: init-setup
    image: busybox
    command: ["echo", "Setup complete"]
  containers:
  - name: webapp
    image: nginx
# Your code here

Hint

Double-check the order and content of initContainers and containers in the manifest.

4

Display the Pod manifest

Print the complete Pod manifest to verify the initContainers and main container are correctly defined.

Kubernetes

# Print the Pod manifest
print(open('webapp-pod.yaml').read())

Hint

Use a command or method to display the contents of webapp-pod.yaml.

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