Why ReplicaSets

You deployed a bare Pod for your web application. At 3am, it crashed. Nobody noticed. It stayed down until someone checked manually hours later. You restarted it. It crashed again. You restarted it again. This loop has a name: it is called being on-call for a process that should be managing itself. And it does not scale.

The problem is not the crash. Crashes happen. The problem is that nobody was watching and nothing acted. And if the node itself had failed, even a manual restart would have required more intervention.

The Gap in Bare Pods

Let’s make it concrete. Create a bare Pod and then delete it to simulate a crash:

nano bare-pod.yaml

# illustrative only
apiVersion: v1
kind: Pod
metadata:
  name: bare-pod
spec:
  containers:
    - name: web
      image: nginx:1.28

kubectl apply -f bare-pod.yaml
kubectl delete pod bare-pod
kubectl get pods

The Pod is gone. Nothing recreated it. That gap, between a Pod dying and a new one appearing, is the gap ReplicaSets fill.

Why is this the default behavior? Kubernetes does not make bare Pods self-healing by design, not by oversight. Not every workload should restart on failure. A database migration that ran successfully should not loop forever. A one-shot batch job is supposed to exit when it finishes. Self-healing is a policy decision, and Kubernetes lets you apply it explicitly through controllers. The Pod is an execution unit. The controller is the policy.

One Rule, Continuous Enforcement

A ReplicaSet enforces one rule: “there must always be exactly N copies of this Pod running.” It watches all Pods that match its selector and, if the count is off, it acts. Too few: create more. Too many: delete the excess.

Think of a bare Pod as hiring one person for a critical role with no backup plan. When they quit, the role is empty until someone notices and hires again. A ReplicaSet is like a staffing agency with a standing contract: “keep 3 people in this role at all times. If one leaves, hire another immediately.”

The controller does not care why the Pod disappeared. Crash, node failure, accidental deletion: the response is identical. It detects a count below desired and creates a replacement from its Pod template.

Both Directions Work

Self-healing handles the “too few” case. But the ReplicaSet also handles “too many.” If a manually created standalone Pod happens to carry labels that match the selector, the ReplicaSet adopts it and counts it toward the total. If that pushes the count above desired, the controller deletes one. This symmetry is intentional: the controller’s job is to make reality match the desired count, whichever direction the gap goes.

A ReplicaSet is the first self-healing primitive in Kubernetes. It is simpler than a Deployment and more powerful than a bare Pod. In the next lesson, you will write one from scratch, learn the three fields that distinguish it from a Pod manifest, and see the controller act in the simulator.