Multi Container Pods

In this lesson we cover Kubernetes multi-container Pods: what they are, when to use them, how containers inside a Pod interact, and a few practical YAML examples.

Overview Splitting a large monolithic application into smaller, focused components (often called microservices) enables independent development, deployment, and scaling of application parts. This decoupling reduces risk and speeds up development cycles.

The image shows the word "Monolith" above a large circle filled with overlapping colorful bubbles containing gear icons, representing bundled application components. A small database icon below is connected to the monolith, indicating a single data store.

Microservices let teams scale and evolve individual services without changing the entire application.

A dark presentation slide titled "Microservices" with rows of colorful circular icons—each containing white gear symbols—arranged in columns. The icons use gradient colors (blue, green, purple, orange) against a navy background.

When to use multi-container Pods There are cases where multiple processes need to run side-by-side and closely cooperate (for example, an app server plus a logging agent, proxy, or helper process). You may want these processes to:

Be maintained and deployed independently (different images, separate build pipelines).
Still run together so they scale, start, and stop as a unit.
Share network and storage resources without extra services or cross-Pod networking.

Multi-container Pods are the Kubernetes primitive for this pattern. They are commonly used for sidecars (logging, proxying, metrics), ambassadors, or adapter containers. Key Pod-level sharing properties

A slide titled "Multi-Container PODs" showing a diagram of a Pod card with two vertically connected containers (gear icons) and labels. To the left are three buttons labeled "LIFECYCLE", "NETWORK", and "STORAGE."

Shared aspect	What it means	Practical example
Lifecycle	Containers in a Pod are created and terminated together; Pod-level restartPolicy governs restarts.	If one container needs to be replaced, the Pod is updated or recreated.
Network	All containers share the same network namespace and IP; they can reach each other with `localhost` and container ports.	`web-app` listening on port `8080` is reachable from `sidecar` at `localhost:8080`.
Storage	Volumes declared on the Pod are mounted into each container that needs them.	Share logs or configuration files via a `emptyDir` or persistent volume.

Important note about ports and resources

Containers share the Pod IP and network namespace. Avoid binding multiple containers to the same port on the same Pod IP (port collisions will prevent containers from starting). Also define CPU/memory resources and limits per container to prevent resource contention inside the Pod.

Pod YAML examples Below are concise example Pod specs to illustrate single- and multi-container configurations. Single-container Pod (for comparison)

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp
  labels:
    name: simple-webapp
spec:
  containers:
  - name: web-app
    image: web-app
    ports:
    - containerPort: 8080

This Pod runs a single web-app container exposing port 8080. Multi-container Pod (two containers in the same Pod)

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp
  labels:
    name: simple-webapp
spec:
  containers:
  - name: web-app
    image: web-app
    ports:
    - containerPort: 8080
  - name: main-app
    image: main-app

In this example the Pod runs web-app and main-app together. Because they share the Pod network namespace, main-app can reach web-app at localhost:8080. Use Pod-level volumes when you need file sharing between containers. Best practices and common patterns

Sidecar pattern: run helpers like log shippers, proxies, or agents alongside the main app.
Ambassador/adapter: run a container that translates or proxies requests between the main app and external services.
Resource limits: always set resources.requests and resources.limits for each container to avoid noisy-neighbor issues.
Health and readiness probes: configure individual livenessProbe and readinessProbe for each container to ensure proper Pod health signals.

Remember: containers inside the same Pod share the Pod’s network namespace. If web-app listens on port 8080, main-app can reach it at localhost:8080. Use Pod-level volumes to share files between containers, and configure resource requests/limits and probes per container for reliable operation.

Links and references

Kubernetes Pods — official documentation on Pods and container sharing
Patterns: Sidecar, Ambassador, Adapter — common multi-container Pod patterns
Kubernetes Networking Concepts — understanding Pod networking and namespaces

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Multi Container Pods

Watch Video