What is the difference between a ReplicaSet and a Deployment?

Think of it like a factory floor. A ReplicaSet is a shift supervisor whose only job is headcount — make sure exactly 5 workers are on the assembly line at all times. If one leaves, immediately bring in a replacement. If there are too many, send some home. That's all the supervisor does: count and maintain.

A Deployment is the factory manager above the supervisor. The manager handles everything the supervisor does (maintaining headcount) but also manages shift changes (rolling updates): when the factory switches from building Product v1 to Product v2, the manager coordinates bringing in v2-trained workers while gradually sending v1 workers home, ensuring the production line never stops. If the new Product v2 has defects, the manager can instantly recall the v1 workers (rollback). The manager keeps records of every shift change (revision history) so they can go back to any previous version.

Technically, a ReplicaSet has one job: maintain the desired count of Pods matching a label selector. If a Pod dies (node failure, OOMKill, manual deletion), the ReplicaSet controller notices within seconds (via the API server's watch mechanism) and creates a replacement. If you scale from 3 to 5 replicas, it creates 2 new Pods. If you scale from 5 to 3, it terminates 2 Pods. But a ReplicaSet has no concept of updates — if you change the Pod template (new image version), existing Pods are NOT affected. Only newly created Pods use the updated template. You'd have to manually delete the old Pods to trigger replacements with the new template.

A Deployment solves this by managing ReplicaSets. When you update the Pod template in a Deployment (say, change the image from v1 to v2), it creates a brand new ReplicaSet for v2 and orchestrates the transition: scaling up v2 while scaling down v1 according to the strategy (RollingUpdate or Recreate). The old v1 ReplicaSet isn't deleted — it's kept at 0 replicas so kubectl rollout undo can scale it back up instantly. This is why kubectl get replicaset often shows multiple ReplicaSets for one Deployment — the old ones are rollback snapshots.

The key takeaway: you should almost never create a ReplicaSet directly. Always use a Deployment instead. The only exception is if you're building a custom controller that needs fine-grained control over Pod lifecycle — and even then, you should strongly consider using a Deployment with a custom strategy. In CKA/CKAD exams, if a question asks you to create a ReplicaSet, do it, but in any real-world answer or production discussion, always recommend Deployments.