Bird
Raised Fist0
Kubernetesdevops~5 mins

Multi-container Pods concept in Kubernetes - Commands & Configuration

Choose your learning style10 modes available
Introduction
Sometimes, you want to run two or more containers together on the same machine so they can share resources and work closely. Multi-container Pods let you do this by grouping containers that need to cooperate tightly in one unit.
When you want a helper container to provide files or data to the main app container.
When you need a logging or monitoring container to watch the main app inside the same pod.
When two containers must share the same network and storage space closely.
When you want to split responsibilities but keep containers tightly coupled for easier management.
When you want to run a sidecar container that adds features like proxy or security alongside your main app.
Config File - multi-container-pod.yaml
multi-container-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: main-app
    image: nginx:1.23.3
    ports:
    - containerPort: 80
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx
  - name: sidecar-logger
    image: busybox
    command: ["sh", "-c", "tail -f /var/log/nginx/access.log"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx
  volumes:
  - name: shared-logs
    emptyDir: {}

This YAML defines a Pod with two containers: main-app running Nginx and sidecar-logger running BusyBox to watch logs.

The emptyDir volume named shared-logs is shared between containers to let the logger read Nginx logs.

This setup shows how containers in one Pod share storage and network.

Commands
This command creates the Pod with two containers defined in the YAML file.
Terminal
kubectl apply -f multi-container-pod.yaml
Expected OutputExpected
pod/multi-container-pod created
Check that the Pod is running and ready with both containers inside.
Terminal
kubectl get pods
Expected OutputExpected
NAME READY STATUS RESTARTS AGE multi-container-pod 2/2 Running 0 10s
See detailed information about the Pod, including both containers and their shared volumes.
Terminal
kubectl describe pod multi-container-pod
Expected OutputExpected
Name: multi-container-pod Namespace: default Priority: 0 Node: <node-name>/192.168.1.100 Start Time: <time> Labels: <none> Annotations: <none> Status: Running IP: 10.244.1.5 Containers: main-app: Container ID: docker://<id> Image: nginx:1.23.3 State: Running Ready: True sidecar-logger: Container ID: docker://<id> Image: busybox State: Running Ready: True Volumes: shared-logs: Type: EmptyDir (a temporary directory that shares a pod's lifetime) Medium: QoS Class: BestEffort Node-Selectors: <none> Tolerations: <none> Events: <none>
Key Concept

If you remember nothing else from this pattern, remember: containers in the same Pod share network and storage, so they can work closely as one unit.

Common Mistakes
Defining multiple containers but forgetting to share volumes for data exchange.
Containers cannot share files or logs without a shared volume, so they cannot cooperate properly.
Use a shared volume like emptyDir and mount it in all containers that need to share data.
Expecting containers in different Pods to share network or storage automatically.
Pods are isolated units; only containers inside the same Pod share network and storage.
Put tightly coupled containers inside the same Pod to share resources.
Summary
Create a Pod YAML with multiple containers listed under spec.containers.
Use shared volumes like emptyDir to let containers share files or logs.
Apply the YAML with kubectl apply and verify the Pod runs with kubectl get pods and kubectl describe pod.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard