ReplicaSets

In the previous chapter, we learned that standalone Pods are fragile — if one dies, it’s gone. ReplicaSets solve this by ensuring a specified number of identical Pod replicas are running at any given time.

What is a ReplicaSet?

A ReplicaSet is a Kubernetes controller that maintains a stable set of replica Pods running at all times. If a Pod fails or is deleted, the ReplicaSet creates a new one to replace it.

Key characteristics:

• Ensures a desired number of replicas are always running
• Uses label selectors to identify which Pods it manages
• Creates new Pods when there are too few, deletes Pods when there are too many
• Provides self-healing — automatically replaces failed Pods

ReplicaSet YAML

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Key Fields Explained

Field	Description
spec.replicas	Desired number of Pod copies (default: 1)
spec.selector	Label selector to identify Pods managed by this ReplicaSet
spec.template	Pod template — defines what each replica looks like

Important: The labels in spec.selector.matchLabels must match the labels in spec.template.metadata.labels. Otherwise, the ReplicaSet won’t recognize the Pods it creates.

Hands-On: Working with ReplicaSets

Create a ReplicaSet

Save the YAML above as replicaset.yaml and apply it:

kubectl apply -f replicaset.yaml

# Check the ReplicaSet
kubectl get replicasets
# or shorthand
kubectl get rs

Output:

NAME               DESIRED   CURRENT   READY   AGE
nginx-replicaset   3         3         3       10s

View the Pods

kubectl get pods -l app=nginx

Output:

NAME                     READY   STATUS    RESTARTS   AGE
nginx-replicaset-abc12   1/1     Running   0          15s
nginx-replicaset-def34   1/1     Running   0          15s
nginx-replicaset-ghi56   1/1     Running   0          15s

Test Self-Healing

Delete a Pod and watch the ReplicaSet create a replacement:

# Delete one Pod
kubectl delete pod nginx-replicaset-abc12

# Immediately check Pods
kubectl get pods -l app=nginx

You’ll see a new Pod being created:

NAME                     READY   STATUS              RESTARTS   AGE
nginx-replicaset-def34   1/1     Running             0          2m
nginx-replicaset-ghi56   1/1     Running             0          2m
nginx-replicaset-xyz78   0/1     ContainerCreating   0          2s

The ReplicaSet detected that only 2 of the desired 3 replicas were running and immediately created a replacement.

Scale the ReplicaSet

# Scale to 5 replicas
kubectl scale rs nginx-replicaset --replicas=5

# Verify
kubectl get rs nginx-replicaset
kubectl get pods -l app=nginx

Describe the ReplicaSet

kubectl describe rs nginx-replicaset

This shows events like Pod creation and scaling activity.

How the ReplicaSet Controller Works

The ReplicaSet controller is a reconciliation loop that continuously:

1. Observes — Counts the number of Pods matching its label selector
2. Compares — Checks if actual count matches desired replicas
3. Acts — Creates or deletes Pods to match the desired state

Desired: 3 replicas
Current: 2 Pods running
Action:  Create 1 new Pod

Desired: 3 replicas
Current: 5 Pods running
Action:  Delete 2 Pods

ReplicaSet vs. Bare Pods

Feature	Bare Pod	ReplicaSet
Self-healing	❌ Pod is gone if it dies	✅ Creates replacement Pods
Scaling	❌ Manual only	✅ kubectl scale
Rolling updates	❌ Not supported	❌ Not natively (use Deployments)
Production use	❌ Not recommended	⚠️ Use Deployments instead

Why You Should Use Deployments Instead

While ReplicaSets provide self-healing and scaling, they don’t support rolling updates. If you want to update the container image (e.g., from nginx:1.26 to nginx:1.27), a ReplicaSet would require you to delete and recreate it.

Deployments manage ReplicaSets and add:

• ✅ Rolling updates
• ✅ Rollback capability
• ✅ Update history
• ✅ Pause and resume updates

Rule of thumb: Always use Deployments in production. Deployments create and manage ReplicaSets for you.

Deployment
    └── ReplicaSet (managed automatically)
            ├── Pod 1
            ├── Pod 2
            └── Pod 3

Clean Up

kubectl delete rs nginx-replicaset
# This also deletes all Pods managed by the ReplicaSet

Summary

• ReplicaSets ensure a desired number of Pod replicas are always running
• They provide self-healing — automatically replacing failed Pods
• They use label selectors to track which Pods they manage
• ReplicaSets can be scaled dynamically
• In practice, you should use Deployments which manage ReplicaSets for you

What’s Next?

Now that you understand ReplicaSets, let’s learn about Deployments — the most commonly used resource in Kubernetes. Deployments give you everything ReplicaSets offer plus rolling updates though version management.

Next: Deployments →