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?
2. Can you change a ReplicaSet's spec.selector after creation?
3. Why does scaling a Deployment-owned ReplicaSet not stick?
Flashcards
Question
ReplicaSet inputs
Click to reveal answer
Answer
spec.replicas (desired) + spec.selector (owned pods), reconciled by its controller.
Question
ownerReference purpose
Click to reveal answer
Answer
Marks pod ownership so controllers do not fight and garbage collection cascades correctly.
Question
pod-template-hash
Click to reveal answer
Answer
Label the Deployment adds so each pod template revision maps to one ReplicaSet.
Question
minReadySeconds
Click to reveal answer
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.