CKAD — Why Multi-Container Pods
When Do You Need Multiple Containers?
A single-container Pod is the most common pattern. But there are real scenarios where two or more containers must work tightly together — sharing network, storage, and lifecycle. Multi-container Pods solve this.
Ask yourself: Do these containers need to run on the same host and share resources? If yes, they belong in the same Pod.
What Multi-Container Pods Share
All containers in a Pod:
| Shared Resource | How It Works |
|---|---|
| Network namespace | Same IP address, same localhost. Containers can reach each other on localhost:<port>. |
| Volumes | Containers can mount the same volume and read/write shared files. |
| Lifecycle | Containers start and stop together as a unit. |
| IPC namespace | Containers can communicate via inter-process communication (shared memory, semaphores). |
| Hostname | All containers see the same hostname (spec.hostname). |
Multi-Container Design Patterns
Kubernetes supports four widely-recognized design patterns for multi-container Pods:
| Pattern | Purpose | Runs When | Example |
|---|---|---|---|
| Sidecar | Extends or enhances the main container | Alongside main container (entire Pod lifetime) | Log shipper, proxy, monitoring agent |
| Init | Runs setup tasks before the app starts | Before main container, sequentially | Wait for DB, download config, run migrations |
| Ambassador | Proxies connections to external services | Alongside main container | DB connection pool, API gateway |
| Adapter | Transforms output for external consumers | Alongside main container | Log formatter, metrics converter |
When NOT to Use Multi-Container Pods
Not everything belongs in the same Pod. Use separate Pods (and Services) when:
| Scenario | Why Separate Pods |
|---|---|
| Different scaling needs | A web frontend may need 10 replicas, an API only 3 |
| Different lifecycles | A database should not restart when the app container crashes |
| Different resource needs | A GPU workload should not be co-located with a lightweight sidecar |
| Independent deployment | Different teams deploy at different cadences |
| Loose coupling | The services communicate over the network, not localhost |
Rule of thumb: If the containers can be deployed independently, they should be in separate Pods. If they MUST share resources and lifecycle, put them in the same Pod.
How the Exam Tests This
The CKAD exam may ask you to:
- Add an init container to a Pod that waits for a service
- Add a sidecar container that ships logs or acts as a proxy
- Debug a Pod where init containers are failing
- Identify which pattern fits a described scenario
- Create multi-container Pods from scratch
Speed matters — practice creating these patterns until they are muscle memory.
Next: Learn the most common pattern with Sidecar Pattern →
