Init containers in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define an init container in a Pod spec.

Kubernetes

initContainers:
  - name: init-myservice
    image: busybox
    command: ["[1]", "-c", "echo Init container running"]

Drag options to blanks, or click blank then click option'

Abash

Bsh

Csleep

Drun

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'run' which is not a shell command

Using 'sleep' which delays but does not run commands

Using 'bash' which may not be available in busybox

The init container uses sh to run the shell command.

2fill in blank

medium

Complete the code to specify the init container image.

Kubernetes

initContainers:
  - name: init-db
    image: [1]

Drag options to blanks, or click blank then click option'

Abusybox:1.35

Bnginx:latest

Cmysql:5.7

Dredis:alpine

Attempts:

3 left

💡 Hint

Common Mistakes

Using application images like nginx or mysql which are not typical for init containers

The init container uses the lightweight busybox:1.35 image for initialization tasks.

3fill in blank

hard

Fix the error in the init container command to run a shell script.

Kubernetes

initContainers:
  - name: setup
    image: busybox
    command: ["[1]", "-c", "echo Setup complete"]

Drag options to blanks, or click blank then click option'

Ash

Bbash

Ccmd

Dpowershell

Attempts:

3 left

💡 Hint

Common Mistakes

Using bash which may not be present

Using Windows shells like cmd or powershell which are invalid here

The sh shell is available in busybox and correctly runs the command.

4fill in blank

hard

Fill both blanks to define an init container that waits for a file before starting the main container.

Kubernetes

initContainers:
  - name: wait-for-file
    image: busybox
    command: ["[1]", "-c", "until test -f /tmp/ready; do [2] 1; done"]
containers:
  - name: main-app
    image: myapp
    volumeMounts:
      - name: shared-data
        mountPath: /tmp
volumes:
  - name: shared-data
    emptyDir: {}

Drag options to blanks, or click blank then click option'

Ash

Bbash

Csleep

Dcat

Attempts:

3 left

💡 Hint

Common Mistakes

Using bash which may not be in busybox

Using cat which does not pause

Using sleep as the command instead of inside the shell command

The init container uses sh to run the shell loop and sleep to wait between checks.

5fill in blank

hard

Fill all three blanks to create an init container that creates a directory and sets permissions before the main container starts.

Kubernetes

initContainers:
  - name: setup-dir
    image: busybox
    command: ["[1]", "-c", "mkdir -p /data [3] [2] 777 /data && echo Directory ready"]
    volumeMounts:
      - name: data-volume
        mountPath: /data
containers:
  - name: app
    image: myapp
    volumeMounts:
      - name: data-volume
        mountPath: /data
volumes:
  - name: data-volume
    emptyDir: {}

Drag options to blanks, or click blank then click option'

Ash

Bchmod

C&&

Dbash

Attempts:

3 left

💡 Hint

Common Mistakes

Using bash which may not be available

Using single & instead of && which causes syntax errors

Using wrong commands for permissions

The init container uses sh to run commands, chmod to set permissions, and && to chain commands.

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