Skip to content
beginner Phase 3 · Core Workloads

ReplicaSets

Learn how ReplicaSets maintain pod replication and ensure application availability.

40m
0 problems
Topic Progress 0%

Reconciliation in Miniature

Reconciliation in Miniature

A ReplicaSet stores a desired count and a selector; its controller counts pods that satisfy both the label selector and an ownerReference pointing at the ReplicaSet, then creates or deletes until the counts agree.

selector:
  matchLabels: { app: web, tier: frontend }
template:
  metadata:
    labels: { app: web, tier: frontend, track: stable }

Extra labels on pods are harmless; omitting a required selector label means the pod falls outside the count. ownerReferences do two jobs: they stop two controllers from fighting over one pod, and they enable cascading garbage collection when the ReplicaSet itself is deleted.

Scaling and Inspection

Scaling and Inspection

kubectl scale replicaset/web-stable --replicas=6
kubectl get rs -l app=web \
  -o custom-columns=NAME:.metadata.name,DESIRED:.spec.replicas,READY:.status.readyReplicas
kubectl delete rs web-stable --cascade=orphan   # keep the pods

Reaching into a ReplicaSet that a Deployment owns is usually a mistake — the Deployment reconciles the count right back. Scale the Deployment instead. Standalone ReplicaSets still fit fixed pools of workers you manage without rollouts.

Note spec.minReadySeconds: a pod counts as available only after remaining Ready that long, which slows rollout accounting rather than the scheduler.

Pitfalls and Interview Angles

Pitfalls and Interview Angles

Pitfall 1 — immutable selectors. spec.selector cannot change after creation. If template labels drift from the selector, the ReplicaSet reports desired=N with zero matching pods and emits no useful error beyond events.

Pitfall 2 — accidental adoption. A pod whose labels match but whose ownerReference points elsewhere will not be adopted; the controller creates new pods instead, leaving duplicates that confuse capacity accounting.

Interview-ready: explain the count-match loop, why Deployments layer ReplicaSets on top — rollout history plus traffic shifting via the pod-template-hash label — and how you debug "RS exists but no pods": selector versus template labels, scheduler events, then resource requests.

Quiz

1. What must a pod have to count toward a ReplicaSet?

Question 1 options

2. Can you change a ReplicaSet's spec.selector after creation?

Question 2 options

3. Why does scaling a Deployment-owned ReplicaSet not stick?

Question 3 options

Flashcards

Question

ReplicaSet inputs

Answer

spec.replicas (desired) + spec.selector (owned pods), reconciled by its controller.

Question

ownerReference purpose

Answer

Marks pod ownership so controllers do not fight and garbage collection cascades correctly.

Question

pod-template-hash

Answer

Label the Deployment adds so each pod template revision maps to one ReplicaSet.

Question

minReadySeconds

Answer

Time a pod must stay Ready before counting as available — slows accounting, not scheduling.

Revision Notes

Key Takeaways

  • 1. Counting requires matching labels AND correct ownership
  • 2. Selectors are immutable; rollouts work by creating new ReplicaSets
  • 3. Scale the Deployment, not the ReplicaSet it owns

Interview Tips

  • • Explain how ReplicaSets enable zero-downtime rollouts when layered by Deployments
  • • Debug a no-pods ReplicaSet in order: selector match, events, requests

Cheat Sheet

ReplicaSet = replicas + selector + ownerRefs. Selectors immutable; scale the Deployment. Zero pods? Compare selector vs template labels, then read describe events.

Continue Learning