ReplicaSets and Rolling Updates: How Deployments Self-Heal

A Deployment is more than a static list of pods. Underneath it sits a ReplicaSet, the controller that keeps the right number of copies running, and the Deployment itself orchestrates changes through rolling updates. Understanding these two layers explains both self-healing and zero-downtime deploys.

The ReplicaSet layer

A ReplicaSet declares a desired pod count and continuously reconciles reality to match it. If a pod is deleted or crashes, the ReplicaSet creates a replacement. If you scale the count, it adds or removes pods. The Deployment controller manages ReplicaSets — one for each version of the workload.

How rolling updates work

When you change the image in a Deployment, the controller creates a new ReplicaSet with the new spec and gradually shifts traffic to it: old pods scale down as new pods pass readiness. The result is no external downtime, as long as the new version starts cleanly.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          readinessProbe:
            httpGet:
              path: /
              port: 80

The readinessProbe is what makes the rollout safe: the new ReplicaSet only counts a pod as ready once it answers the probe, and the rollout proceeds one pod at a time.

Watching a rollout

Trigger an update and observe the replacement process.

kubectl set image deployment/web web=nginx:1.26
kubectl rollout status deployment/web
kubectl get rs
kubectl get pods
kubectl rollout history deployment/web

The set image command changes the Deployment template, which triggers the new ReplicaSet.

Self-healing and rollout anatomy

Rolling back

If the new version fails readiness, the rollout stalls instead of serving bad traffic. Roll back to the prior ReplicaSet.

kubectl rollout undo deployment/web
kubectl rollout status deployment/web

Takeaway

ReplicaSets keep pod counts exact and replace failures automatically; Deployments layer rolling updates and rollbacks on top. Add readiness probes so rollouts only promote genuinely healthy pods. To feel how fast a Deployment notices a deleted pod, kill one on a k3s cluster at Netbay and watch the ReplicaSet rebuild it in seconds — netbayhosts.in.