Expected Answer
A Container is a single image instance running a specific process. A Pod is the smallest execution unit in Kubernetes. A Pod acts as a wrapper around one or more containers.
Containers inside the same Pod share the same Network Namespace (they can talk to each other via localhost) and can share Storage Volumes.
Analogy: If a container is a worker, a Pod is a shared office where a few workers (containers) sit together and share the same phone line and filing cabinet.
Why It Matters
Understanding Pods is essential because you never deploy a “container” directly to Kubernetes. You always deploy Pods. The Pod abstraction allows for the Sidecar Pattern, where you might have your main app container and a separate “helper” container (like a log forwarder or a service mesh proxy) running in the same Pod.
Example Code
A multi-container Pod (Sidecar Pattern)
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
spec:
containers:
- name: main-app
image: my-app:latest
- name: log-exporter
image: fluentd:latest
Common Mistakes
- Thinking 1 Pod = 1 Container is always true: While common, Pods are designed to hold multiple tightly-coupled containers.
- Trying to talk to another container in the same Pod via its IP: You should use
localhost instead.
- Forgetting that Pods are ephemeral: You shouldn’t store important data in the Pod’s local storage; it will be lost if the Pod is rescheduled.
Follow-up Questions
- When should you put two containers in the same Pod? (Answer: Only when they are tightly coupled and must share resources like the local filesystem or network stack).
- What is the “Pause” container? (Answer: An infrastructure container that holds the namespaces (network, etc.) for the Pod, allowing other containers to join them).
- How do containers in a Pod communicate with each other? (Answer: Via
localhost and shared IPC).
References