Multi-container Pods concept in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a pod with two containers.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: container1
    image: nginx
  - name: [1]
    image: busybox

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

Amain

Bapp

Csidecar

Dcontainer2

Attempts:

3 left

💡 Hint

Common Mistakes

Using the same name as the first container causes errors.

Leaving the name blank is invalid.

The second container in the pod is named 'container2' to clearly identify it as the second container.

2fill in blank

medium

Complete the code to add a shared volume to both containers in the pod.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: shared-volume-pod
spec:
  volumes:
  - name: shared-data
    emptyDir: {}
  containers:
  - name: app
    image: busybox
    volumeMounts:
    - name: [1]
      mountPath: /data
  - name: sidecar
    image: alpine
    volumeMounts:
    - name: shared-data
      mountPath: /cache

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

Ashared-data

Bdata

Ccache

Dvolume1

Attempts:

3 left

💡 Hint

Common Mistakes

Using a different name than the volume causes the mount to fail.

Forgetting to define the volume in the pod spec.

The volumeMount name must match the volume name 'shared-data' to mount the shared volume correctly.

3fill in blank

hard

Fix the error in the pod spec by completing the missing field.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: error-pod
spec:
  containers:
  - name: app
    image: nginx
  - name: sidecar
    [1]: alpine

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

Aimage

Bcommand

Cargs

DvolumeMounts

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'command' or 'args' without specifying 'image' causes pod creation failure.

Misspelling 'image' field.

Each container must have an 'image' field specifying the container image to run.

4fill in blank

hard

Fill both blanks to define environment variables for the containers.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: env-pod
spec:
  containers:
  - name: app
    image: nginx
    env:
    - name: [1]
      value: "production"
  - name: sidecar
    image: busybox
    env:
    - name: [2]
      value: "debug"

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

AENV_MODE

BLOG_LEVEL

CAPP_MODE

DDEBUG_MODE

Attempts:

3 left

💡 Hint

Common Mistakes

Using lowercase or invalid environment variable names.

Using the same name for both containers' environment variables.

Common environment variable names are 'ENV_MODE' for app mode and 'LOG_LEVEL' for logging level.

5fill in blank

hard

Fill all three blanks to complete the pod spec with resource limits and requests.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: resource-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      limits:
        cpu: [1]
        memory: [2]
      requests:
        cpu: [3]

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

A500m

B256Mi

C250m

D1Gi

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing units like '500' instead of '500m' for CPU.

Setting requests higher than limits causes scheduling errors.

CPU limits are set to '500m' (0.5 CPU), memory limits to '256Mi', and CPU requests to '250m' (0.25 CPU) to allocate resources properly.

Practice

1. What is the main purpose of having multiple containers inside a single Kubernetes Pod?

easy

A. To isolate containers completely from each other

B. To run containers on different nodes for load balancing

C. To run containers with different Kubernetes versions

D. To allow containers to share network and storage resources closely

Solution

1. Step 1: Understand Pod resource sharing

   Containers in the same Pod share network and storage, enabling close cooperation.

2. Step 2: Compare options

   Only To allow containers to share network and storage resources closely correctly describes this sharing. Other options describe different Kubernetes features.

3. Final Answer:

   To allow containers to share network and storage resources closely -> Option D

4. Quick Check:

   Multi-container Pods share resources = C [OK]

Hint: Pods share network/storage among containers [OK]

Common Mistakes:

• Thinking containers run on different nodes in one Pod
• Believing containers in a Pod are isolated
• Confusing Pod with Kubernetes version management

2. Which of the following is the correct way to define multiple containers inside a single Pod YAML spec?

easy

A. containers: [{name: 'app', image: 'app-image'}, {name: 'sidecar', image: 'sidecar-image'}]

B. container: [{name: 'app', image: 'app-image'}, {name: 'sidecar', image: 'sidecar-image'}]

C. containers: {name: 'app', image: 'app-image', name: 'sidecar', image: 'sidecar-image'}

D. pods: [{name: 'app', image: 'app-image'}, {name: 'sidecar', image: 'sidecar-image'}]

Solution

1. Step 1: Recall Pod spec syntax

   The Pod spec uses a key 'containers' with a list of container objects.

2. Step 2: Validate options

   containers: [{name: 'app', image: 'app-image'}, {name: 'sidecar', image: 'sidecar-image'}] correctly uses 'containers' as a list. The other options use wrong keys or wrong data structures.

3. Final Answer:

   containers: [{name: 'app', image: 'app-image'}, {name: 'sidecar', image: 'sidecar-image'}] -> Option A

4. Quick Check:

   Multiple containers use 'containers' list = A [OK]

Hint: Use 'containers' key with a list for multiple containers [OK]

Common Mistakes:

• Using 'container' instead of 'containers'
• Using curly braces instead of list for multiple containers
• Confusing 'pods' key with 'containers'

3. Given this Pod YAML snippet, what will be the output of kubectl get pods after applying it?

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app
    image: nginx
  - name: sidecar
    image: busybox
    command: ['sleep', '3600']

medium

A. Pod will fail because multiple containers are not allowed

B. Pod 'multi-container-pod' will be Running with two containers inside

C. Pod will be Pending indefinitely

D. Pod will run only the first container and ignore the second

Solution

1. Step 1: Analyze Pod spec

   The Pod defines two containers: 'app' running nginx and 'sidecar' running busybox sleep command.

2. Step 2: Understand Kubernetes behavior

   Kubernetes supports multiple containers in one Pod; both will run together. The Pod status will be Running if both containers start successfully.

3. Final Answer:

   Pod 'multi-container-pod' will be Running with two containers inside -> Option B

4. Quick Check:

   Multi-container Pod runs all containers = A [OK]

Hint: Multiple containers run together; Pod status shows Running if all start [OK]

Common Mistakes:

• Thinking multiple containers are not allowed in one Pod
• Assuming Pod stays Pending without reason
• Believing only one container runs per Pod

4. You created a Pod with two containers, but the second container keeps restarting. What is the most likely cause?

medium

A. The second container's command or image is incorrect causing crash loop

B. Kubernetes does not support more than one container per Pod

C. The Pod spec is missing the 'containers' key

D. The first container is using all CPU resources

Solution

1. Step 1: Identify container restart reasons

   Containers restart if their command fails or image is invalid, causing crash loops.

2. Step 2: Eliminate other options

   Kubernetes supports multiple containers per Pod. A missing 'containers' key causes Pod creation failure. Resource starvation usually affects all containers but does not cause restart loops.

3. Final Answer:

   The second container's command or image is incorrect causing crash loop -> Option A

4. Quick Check:

   Container restart loops = command/image error [OK]

Hint: Restart loops usually mean container command or image error [OK]

Common Mistakes:

• Believing Kubernetes disallows multiple containers
• Ignoring container command correctness
• Assuming resource usage causes restarts immediately

5. You want to add a logging container to your Pod that shares the same volume with the main app container. Which configuration is correct to achieve this?

hard

A. Mount the volume only in the logging container

B. Create separate volumes for each container and do not mount them

C. Define a shared volume under 'volumes' in Pod spec and mount it in both containers under 'volumeMounts'

D. Use different Pods for logging and app containers without shared volumes

Solution

1. Step 1: Understand volume sharing in Pods

   Volumes defined at Pod level can be mounted by multiple containers to share data.

2. Step 2: Check options for volume usage

   Define a shared volume under 'volumes' in Pod spec and mount it in both containers under 'volumeMounts' correctly defines a shared volume and mounts it in both containers. Other options either separate volumes or do not mount properly, preventing sharing.

3. Final Answer:

   Define a shared volume under 'volumes' in Pod spec and mount it in both containers under 'volumeMounts' -> Option C

4. Quick Check:

   Shared volumes require Pod-level volume and mounts in containers [OK]

Hint: Share volumes by defining once and mounting in all containers [OK]

Common Mistakes:

• Defining separate volumes for each container
• Not mounting volumes in all containers needing access
• Using separate Pods instead of multi-container Pod