ReplicaSet

The Problem with Bare Pods

A bare Pod has no self-healing: if it's deleted, or the node it's running on fails, nothing recreates it. And when one Pod isn't enough for your traffic, nothing about a Pod spec says "run five of these." A ReplicaSet solves both problems by continuously ensuring that a specified number of identical Pods are running at all times.

ReplicaSet YAML

# replicaset.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

Desired State vs. Current State

The core idea is desired state vs. current state: the controller continuously compares the two and reconciles any difference. If a Pod is deleted and current state drops to 2 while desired state stays at 3, the controller creates a new Pod — it doesn't resurrect the old one, it just makes up the difference. This reconciliation loop is what's meant by self-healing.

kubectl apply -f replicaset.yml
kubectl get rs
kubectl get pods
kubectl describe rs nginx-rs
 
# Self-healing: delete a pod and watch it get replaced
kubectl delete pod nginx-rs-abcde
kubectl get pods -w
 
# Scale up or down — the controller creates or removes pods to match
kubectl scale rs nginx-rs --replicas=5

Where ReplicaSets Fall Short

Where ReplicaSets fall short is change management: they handle self-healing and scaling, but have no concept of rolling updates, rollbacks, or revision history. Editing the container image in a ReplicaSet's template doesn't trigger any update to Pods that already exist. That gap is exactly why Deployments exist — the subject of the next lesson.