Multi-container Pods concept in Kubernetes - Step-by-Step Execution

Process Flow - Multi-container Pods concept

Pod Created

↓

Multiple Containers Defined

↓

Containers Share Pod Resources

↓

Containers Communicate via localhost

↓

Containers Start Together

↓

Pod Runs as Single Unit

This flow shows how a Pod is created with multiple containers that share resources and communicate locally, running together as one unit.

Execution Sample

Kubernetes

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

This YAML defines a Pod with two containers: an nginx app and a sidecar container that prints a message and sleeps.

Process Table

Step	Action	Pod State	Container States	Notes
1	Pod manifest applied	Pod created	Containers: Pending	Kubernetes accepts Pod definition
2	Scheduler assigns Pod to node	Pod scheduled	Containers: Pending	Pod assigned to a worker node
3	Kubelet starts containers	Pod running	app: Running, sidecar: Running	Both containers start simultaneously
4	Containers share localhost network	Pod running	app: Running, sidecar: Running	Containers can communicate via localhost
5	Sidecar executes command	Pod running	app: Running, sidecar: Running	Sidecar prints message and sleeps
6	Pod continues running	Pod running	app: Running, sidecar: Running	Pod runs as a single unit with both containers

💡 Pod runs continuously until deleted or stopped; containers run together sharing resources.

Status Tracker

Variable	Start	After Step 3	After Step 5	Final
Pod State	Not created	Running	Running	Running
app Container	Not started	Running	Running	Running
sidecar Container	Not started	Running	Sleeping after echo	Sleeping

Key Moments - 3 Insights

Why do both containers start at the same time inside the Pod?

Because the Pod is the smallest deployable unit in Kubernetes, all containers defined in it start together as shown in execution_table step 3.

How do containers inside the Pod communicate with each other?

They share the same localhost network namespace, so they can communicate via localhost as shown in execution_table step 4.

What happens if one container in the Pod stops?

The Pod is considered unhealthy or failed; Kubernetes may restart the Pod depending on its restart policy, since containers run as a single unit.

Visual Quiz - 3 Questions

Look at the execution table, at which step do both containers start running?

A Step 2

B Step 5

C Step 3

D Step 1

💡 Hint

Check the 'Container States' column in execution_table row for Step 3.

According to variable_tracker, what is the state of the sidecar container after Step 5?

A Not started

B Sleeping

C Running

D Terminated

💡 Hint

Look at the 'sidecar Container' row under 'After Step 5' in variable_tracker.

If the Pod had only one container, how would the execution table change?

A Only one container state would be shown as running

B There would be no container states listed

C Containers would start at different steps

D Pod would not be scheduled

💡 Hint

Refer to the 'Container States' column in execution_table and consider how many containers are defined.

Concept Snapshot

Multi-container Pods run multiple containers together in one Pod.
Containers share network and storage resources.
They start and stop as a single unit.
Containers communicate via localhost inside the Pod.
Useful for sidecar patterns and helper containers.

Full Transcript

A Kubernetes Pod can have multiple containers running together. When you create a Pod with multiple containers, Kubernetes schedules the Pod as one unit. Both containers start at the same time and share the same network and storage resources. They can talk to each other using localhost because they share the same network namespace. For example, a Pod might have an nginx container and a sidecar container that logs or modifies data. The Pod runs continuously until it is deleted or stopped. If one container stops, the Pod is affected as a whole. This concept helps run related containers together efficiently.

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