A bare Pod dies and stays dead. A ReplicaSet ensures that a specified number of Pod replicas are running at all times. It's the first layer of self-healing — and understanding how it finds its Pods (label selection) is critical for debugging ownership issues.

1. What a ReplicaSet Does

A ReplicaSet has one job: maintain exactly N Pods matching a label selector. Its reconciliation loop:

1. Count Pods in the namespace matching its selector
2. Compare to desired replica count
3. If too few → create Pods from its template
4. If too many → delete excess Pods

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web
spec:
  replicas: 3                    # ← desired count
  selector:                      # ← how it finds its Pods
    matchLabels:
      app: web
      version: v1
  template:                      # ← Pod template (used to create new Pods)
    metadata:
      labels:
        app: web
        version: v1              # ← MUST match selector
    spec:
      containers:
        - name: nginx
          image: nginx:1.25

The Three Parts

2. The Label Selection Contract

This is the most important concept: ReplicaSets don't track Pods by internal state or a list of IDs. They find their Pods purely by label matching.

Rules of the Contract

1. Template labels must include selector labels — otherwise the RS creates Pods it immediately disowns (API server rejects this)
2. Template labels can be a superset — extra labels beyond the selector are fine
3. Any Pod matching the selector can be adopted — even Pods the RS didn't create
4. Removing a label from a Pod releases it — the RS no longer counts it

What "Matching" Means

# ReplicaSet selector:
selector:
  matchLabels:
    app: web
    version: v1

# This Pod matches (has both labels):
labels:
  app: web
  version: v1
  team: platform    # extra labels are fine

# This Pod does NOT match (missing version):
labels:
  app: web
  team: platform

3. Ownership & ownerReferences

When a ReplicaSet creates a Pod, it stamps an ownerReference on the Pod's metadata:

kubectl get pod web-abc12 -o yaml | grep -A8 ownerReferences
# ownerReferences:
# - apiVersion: apps/v1
#   kind: ReplicaSet
#   name: web-5d4f6b7c8
#   uid: a1b2c3d4-...
#   controller: true        # ← this is the managing controller
#   blockOwnerDeletion: true

What ownerReferences Enable

Orphan & Adopt Mechanics

Practical: Isolating a Bad Pod for Debugging

# Pod "web-abc12" is misbehaving. Want to debug it without 
# it being deleted by the RS, and without losing a replica:

# 1. Remove the RS selector label → orphans it
kubectl label pod web-abc12 app-      # removes "app" label

# RS immediately creates a replacement Pod (maintains count).
# The old Pod keeps running — you can now debug it at leisure.
# When done:
kubectl delete pod web-abc12

4. Scaling

Scaling a ReplicaSet just changes the desired count — the controller handles the rest:

# Scale up:
kubectl scale rs web --replicas=5
# RS counts 3 Pods → needs 5 → creates 2 more from template

# Scale down:
kubectl scale rs web --replicas=2
# RS counts 5 Pods → needs 2 → deletes 3 (newest first by default)

# Scale to zero (stop all Pods, keep RS for later):
kubectl scale rs web --replicas=0

Which Pods Get Deleted on Scale-Down?

The ReplicaSet controller uses a ranking algorithm:

1. Unassigned Pods (Pending) deleted first
2. Pods on nodes with more replicas (spread Pods across nodes)
3. Newer Pods deleted before older ones (by creation timestamp)
4. Pods with more container restarts deleted first

5. ReplicaSet vs Deployment — When to Use Which

Almost never use a ReplicaSet directly. In practice, you always use a Deployment, which manages ReplicaSets for you.

The ownership chain:

Deployment
  └── ReplicaSet (revision 1)  ← scaled to 0 after rollout
  └── ReplicaSet (revision 2)  ← current, owns the running Pods
        └── Pod A
        └── Pod B
        └── Pod C

6. Inspecting ReplicaSets

# List ReplicaSets:
kubectl get rs
# NAME          DESIRED   CURRENT   READY   AGE
# web-6f4a8b2   0         0         0       5d    ← old revision
# web-8b2c3d4   3         3         3       1d    ← current

# See which Pods a RS owns:
kubectl get pods -l app=web --show-labels

# Describe for events (scaling events, failures):
kubectl describe rs web-8b2c3d4

# Check ownerReferences on a Pod:
kubectl get pod web-8b2c3d4-xk2j9 -o jsonpath='{.metadata.ownerReferences[0].name}'
# web-8b2c3d4

Common Issues

The pod-template-hash Label

Deployments add a pod-template-hash label to both the RS and its Pods. This guarantees selector uniqueness across revisions:

kubectl get rs -o custom-columns=NAME:.metadata.name,HASH:.metadata.labels.pod-template-hash
# NAME          HASH
# web-6f4a8b2   6f4a8b2
# web-8b2c3d4   8b2c3d4

# The RS name IS the deployment name + hash
# Pods also carry this label → only the correct RS matches them

Summary