Pods, ReplicaSets, Deployments

Three resources, stacked. Pod is the atom. ReplicaSet keeps N pods alive. Deployment manages ReplicaSets so you can roll forward and back safely.

Pod

A pod is one or more containers that share a network namespace, IPC, and optionally volumes. They get one IP, they can talk over localhost. Co-locating containers in a pod is for sidecars (log shippers, proxies, init logic), not for two services that just happen to deploy together.

Containers in a pod live and die together. The pod is the scheduling unit. The kubelet creates the sandbox (a pause container holding the namespaces) then starts your containers inside it.

ReplicaSet

Keep N copies of a pod template running. That is the whole job. It watches Pods matching its selector, counts them, creates or deletes to match replicas. You almost never create a ReplicaSet directly.

Deployment

A Deployment owns a ReplicaSet. When you change the pod template (new image, new env var), the Deployment controller creates a new ReplicaSet, scales it up, scales the old one down according to maxSurge and maxUnavailable. Defaults: 25% surge, 25% unavailable. For 4 replicas that means one extra pod during the roll and one allowed missing.

Rollback

kubectl rollout undo deployment/foo rewinds to the previous ReplicaSet. The old RS is kept around (revision history, default 10) precisely so this is instant. No image rebuild, no re-pull, just scale the old RS back up.

When NOT to use a Deployment

• StatefulSet for things with stable identity and persistent volumes (databases, Kafka, Elasticsearch).
• DaemonSet for one-per-node agents (log shippers, CNI, node exporters).
• Job / CronJob for run-to-completion work.

The interview answer

Pods are ephemeral and pet-free. ReplicaSets are reconcile loops for replica count. Deployments wrap ReplicaSets to give you versioned rollouts with rollback. You operate at the Deployment level, you never touch the ReplicaSet.