I'm trying to understand the design behind Kubernetes Deployments. A Deployment does not create and supervise Pods directly; it creates and manages ReplicaSets, which then maintain the desired number of Pods. Why is this split into two controller layers? What responsibilities belong to the ReplicaSet, and what does the Deployment gain by managing ReplicaSets instead of managing Pods itself?
3 Answers
The extra layer separates two different responsibilities. A ReplicaSet makes sure the desired number of Pods for one specific Pod template are running. The Deployment handles changes between Pod templates, such as rolling updates and rollbacks. During an update, it can scale a new ReplicaSet up while scaling the previous one down. The old ReplicaSet is usually retained at zero replicas, so reverting to the previous version is mostly a matter of scaling it back up.
This division keeps each controller focused. A ReplicaSet answers, “How many Pods matching this exact template should exist?” A Deployment answers, “How should the application move safely from one version to another?” If Deployments managed Pods directly, they would need to include all the replica-maintenance logic themselves, along with the rollout and rollback behavior.
It also reflects how the controllers evolved. Earlier Kubernetes replication controllers handled basic replica counts, but they did not provide a complete application release lifecycle. ReplicaSets improved replica selection, while Deployments added declarative rollout management. Other higher-level controllers can use a ReplicaSet directly—or manage Pods through their own lifecycle logic—without needing a Deployment.
That makes sense—so the Deployment is coordinating the transition, while each ReplicaSet only worries about maintaining its own replica count.