What is the difference between a Kubernetes Pod and a Deployment?
A Pod and a Deployment solve different problems in Kubernetes. Understanding the distinction is fundamental to using Kubernetes correctly.
**Pod** is the smallest deployable unit in Kubernetes. It encapsulates one or more containers that share a network namespace (same IP address and localhost), storage volumes, and lifecycle. Containers in a pod are always co-scheduled on the same node. Pods are ephemeral by design — they are not self-healing. If a Pod crashes, is evicted, or the node it runs on fails, the Pod is gone. Creating a Pod directly with `kubectl apply` gives you exactly one instance that will never be replaced.
**Deployment** is a controller that manages a **ReplicaSet**, which in turn manages a set of identical Pods. You declare desired state — "I want 3 replicas of this container image" — and the Deployment controller continuously reconciles actual state to match. Key capabilities:
- **Self-healing**: if a Pod crashes or a node goes down, the Deployment's ReplicaSet replaces it automatically by scheduling a new Pod on a healthy node. - **Scaling**: `kubectl scale deployment my-app --replicas=10` adds Pods; the controller handles scheduling. - **Rolling updates**: update the container image in the Deployment spec, and Kubernetes progressively replaces old Pods with new ones (configurable with `maxUnavailable` and `maxSurge`). Zero-downtime deployments by default. - **Rollback**: `kubectl rollout undo deployment/my-app` reverts to the previous ReplicaSet instantly — the old ReplicaSet is retained for this purpose. - **History and audit**: Deployment revision history records what changed and when.
**When to use a Pod directly**: rarely, and only for debugging, one-off inspection tasks, or very simple local development. A standalone Pod provides no resiliency.
**Other controllers**: Deployments are for stateless workloads. For stateful workloads (databases, message queues with persistent storage), use a **StatefulSet** which assigns stable network identities and ordered rolling updates. For per-node daemons (log collectors, monitoring agents), use a **DaemonSet**.
The mental model: a Deployment is a specification of desired state for Pods over time; a Pod is a single instance of that desired state at a point in time.
| Aspect | Pod | Deployment |
|---|---|---|
| Abstraction level | Lowest — single instance | Controller managing ReplicaSet + Pods |
| Self-healing | No — if it dies, it's gone | Yes — replaces failed Pods automatically |
| Scaling | Manual — one pod per manifest | kubectl scale or HPA autoscaling |
| Rolling updates | N/A | Built-in with maxUnavailable/maxSurge |
| Rollback | No | kubectl rollout undo |
| Use case | Debugging, one-off tasks | Production stateless workloads |
| Manages state | No | Tracks revision history and desired replicas |
Correctly explains that Pods are ephemeral and not self-healing, explains that a Deployment manages ReplicaSets which manage Pods, and describes rolling update and rollback capabilities.
Covers the Deployment → ReplicaSet → Pod hierarchy, explains maxUnavailable/maxSurge configuration for rolling updates, distinguishes Deployments from StatefulSets and DaemonSets for other workload types, and gives a concrete scenario for when you'd use each.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment