I'm trying to understand the design of Kubernetes Deployments. A Deployment does not create and manage Pods directly; instead, it creates and manages a ReplicaSet, which then creates and maintains the Pods. Why was this extra layer introduced? What advantages does separating Deployment and ReplicaSet provide compared with having the Deployment manage Pods on its own?
2 Answers
Each controller has a focused responsibility. A ReplicaSet maintains the requested number of interchangeable Pods, while a Deployment manages application releases: creating new ReplicaSets, changing their replica counts, tracking revisions, and supporting gradual rollouts and rollbacks. This compositional design also lets other higher-level controllers use ReplicaSets directly when they have their own lifecycle or update logic. ReplicaSets evolved from the older replication controller concept, while Deployments were added to handle release management on top of replica management.
The separation makes rolling updates and rollbacks much simpler. A ReplicaSet focuses on one exact Pod template and makes sure the desired number of replicas are running. During an update, the Deployment can manage both the old and new ReplicaSets at the same time, gradually scaling the new one up while scaling the old one down. The old ReplicaSet is usually retained at zero replicas, so rolling back mainly means scaling that previous version back up. If Deployments managed Pods directly, they would need to implement all of this replica-management and transition logic themselves.
That makes sense—so the ReplicaSet handles keeping one version at the right size, while the Deployment coordinates the transition between versions.