Skip to main content

ReplicaSets: The Reconcilers

Key Takeaways for AI & Readers
  • Self-Healing: ReplicaSets maintain the desired count of Pods by constantly reconciling the actual state with the specified configuration.
  • Label-Based Tracking: They identify "their" Pods using label selectors rather than direct ownership.
  • Deployment-Managed: In modern Kubernetes, you rarely manage ReplicaSets directly; instead, you manage Deployments which orchestrate ReplicaSets for updates.

While you usually manage Deployments, under the hood, the Deployment creates and manages ReplicaSets. A ReplicaSet is the component that actually ensures the "Desired Number" of pods is running.

1. Desired vs. Actual​

The ReplicaSet runs a continuous loop (Reconciliation). If a Pod is deleted, the ReplicaSet instantly creates a new one to replace it.

ReplicaSet (Desired: 3)
REPLICASET SCOPE
📦pod-0
📦pod-1
📦pod-2
The ReplicaSet's only job is to ensure that the number of pods matching its selector is exactly equal to the desired count.

2. Why not use ReplicaSets directly?​

You should almost always use a Deployment instead of a ReplicaSet.

  • Deployments allow you to do Rolling Updates (gradually moving from v1 to v2).
  • ReplicaSets are binary—they just ensure N copies of a specific pod exist. They don't know how to "update" the image without killing all pods at once.

3. How they find Pods: Selectors​

ReplicaSets don't "own" pods. They find them using Labels. If you create a Pod manually that matches the ReplicaSet's label selector, the ReplicaSet might kill your manual pod if it already has enough replicas!