Visual walkthrough — Kubernetes — pods, deployments, services, ingress (concepts)

We will not assume you know what a "controller", a "state", or even a "loop" means here. We earn every word.

---

Step 1 — What is a "state"?

WHAT. Before we can talk about a gap between two states, we need to know what a single state is. A state is just a snapshot: a list of facts about the world right now. For us the fact we care about is one number: how many copies of my app are running?

WHY. Kubernetes cannot "want" anything abstract. It can only compare numbers and lists. So we reduce the whole messy idea of "my app is healthy" down to something countable — a count of running Pods. Everything visual on this page rides on that one countable quantity.

PICTURE. On the left, a jar labelled desired holds the number you asked for. On the right, a jar labelled observed holds the number that is actually running right now. These two jars are the entire drama.

In symbols we will write $D$ for the desired count and $O$ for the observed count. That's all the notation Step 1 introduces.

---

Step 2 — What is the "gap"?

WHAT. The gap is a single subtraction: $\underset{\text{the gap}}{\underbrace{g}}=\underset{\text{what you want}}{\underbrace{D}}-\underset{\text{what exists}}{\underbrace{O}}$ Every symbol: $g$ is the gap (a plain number, can be positive, negative, or zero), $D$ is the desired count from Step 1, $O$ is the observed count from Step 1.

WHY subtraction and not, say, a ratio? Because subtraction tells you both how far off and in which direction in one shot, using a sign:

• $g>0$ → you have too few Pods (want more than you have).
• $g<0$ → you have too many Pods (want fewer than you have).
• $g=0$ → perfect, nothing to do.

A ratio would break when $O=0$ (division by zero) and hides the direction. Subtraction is the simplest tool that carries magnitude and sign together — exactly the two things a controller must know.

PICTURE. A number line. Mark $O$ and $D$ on it; the arrow between them is $g$. When the arrow points right ($D$ to the right of $O$) we need to create; when it points left we need to delete.

---

Step 3 — What is the action $f$?

WHAT. $f$ is the function that turns a gap into a move. The parent wrote $\text{act}=f(D-O)$. Now we say what $f$ does: it takes the signed number $g$ and outputs "create $|g|$ Pods" or "delete $|g|$ Pods".

WHY a function at all? Because we want the same rule to work no matter the numbers. Whether the gap is $+1$ or $+900$, $f$ reacts the same way — it just scales. That reuse is the whole point of writing it as $f(\cdot )$ instead of a special case for every situation. Here $|g|$ means the size of the gap ignoring its sign (so $|-2|=2$): the sign told us the direction, the size tells us how much.

PICTURE. A little machine: gap arrow goes in on the left, and out the right comes an instruction card — green "spawn 2 Pods" when the gap was $+2$, red "kill 2 Pods" when the gap was $-2$.

---

Step 4 — Closing the loop (why it repeats forever)

WHAT. One pass — measure $O$, compute $g$, act — is not enough. The world keeps changing after you act. So we loop: measure again, recompute the gap, act again, forever. This never-ending cycle is the reconciliation loop.

WHY loop instead of run once? Because $O$ has a mind of its own — a node can die a second after you reached $g=0$. A one-shot fix would leave you broken until a human noticed. A loop means the system is self-correcting: any disturbance just reopens a gap the loop is already watching for.

PICTURE. A ring of four arrows: observe → compute $g$ → act → (world drifts) → observe.... Notice the loop has no exit. It idles quietly when $g=0$ and springs awake the instant $g\ne 0$.

---

Step 5 — Case: a Pod dies (the "heal" case)

WHAT. Start balanced: $D=3$, $O=3$, so $g=0$. A node crashes; one Pod vanishes. Now $O=2$, so $g=3-2=+1$.

WHY it self-heals. The gap became positive, so $f$ outputs "create $1$ Pod." The loop spawns a fresh Pod, $O$ climbs back to $3$, and $g$ returns to $0$. Crucially the reborn Pod is a brand-new Pod with a new IP — the loop only cares about the count, never the identity.

PICTURE. Timeline of the count $O$ over time: flat at 3, sudden drop to 2 (red), the loop notices $g=+1$, a new green Pod appears, back to 3.

---

Step 6 — Case: too many Pods (the "scale-down" case)

WHAT. Now the opposite. You lower the target: $D:3\to 1$ while $O=3$. The gap is $g=1-3=-2$.

WHY it works with the same $f$. No new logic. The gap is negative, so $f$ outputs "delete $2$ Pods." $O$ falls to $1$, $g$ returns to $0$. The exact same subtraction-and-sign machine handles growth and shrinkage — that's the payoff of building $f$ around a signed gap in Step 2.

PICTURE. The two jars again: desired jar drops to 1, the gap arrow now points left (delete), two red Pods get removed until the jars match.

---

Step 7 — Degenerate case: $g=0$ forever, and the rolling update

WHAT (idle). When $D=O$, $g=0$, and $f$ does nothing. The loop still runs — measuring, finding zero, resting. This is the healthy steady state most of the time.

WHAT (rolling update). A rolling update is the loop cleverly never letting the useful gap get dangerous. With $R$ = replicas, two knobs bound how far $O$ may wander during an upgrade: $\underset{\text{floor on live Pods}}{\underbrace{R-\text{maxUnavailable}}}\le P_{\text{available}}\text{and}\underset{\text{old + new}}{\underbrace{P_{\text{total}}}}\le \underset{\text{ceiling on Pods}}{\underbrace{R+\text{maxSurge}}}$ Term by term: $R$ is your steady replica count; $\text{maxUnavailable}$ is how far below $R$ the live count is allowed to dip; $P_{\text{available}}$ is how many are actually serving traffic; $\text{maxSurge}$ is how many extra Pods may exist mid-swap; $P_{\text{total}}$ is old-version plus new-version Pods combined.

WHY these bounds = zero downtime. As long as the floor $R-\text{maxUnavailable}$ stays $\ge 1$, there is always at least one live Pod to serve requests while old ones retire and new ones warm up. The loop only removes an old Pod once a new one is confirmed healthy — it keeps $P_{\text{available}}$ pinned above the floor.

PICTURE. A band chart over time: green area = new-version Pods rising, blue area = old-version Pods falling, a dashed red floor line the total-available never crosses, a dashed yellow ceiling the total never exceeds.

This is the Deployment layer (see parent) enforcing a sequence of tiny, safe gaps rather than one big scary one — the same reconciliation loop, applied to versions instead of just counts. It's the mechanism behind safe CI-CD Pipelines deploys.

---

Step 8 — Where the loop lives across all four objects

WHAT. The same loop runs at several layers, each closing a different gap:

Controller	$D$ (desired)	$O$ (observed)	Action $f$
Deployment / ReplicaSet	replica count	live Pods	create / delete Pods
Service (Endpoints)	Pods matching label	Pods currently in backend list	add / drop backend IPs
Ingress Controller	routing rules	live proxy config	rewrite proxy config

WHY it matters. Once you see the loop once, every Kubernetes object is just "another gap being closed." The Service's job in Microservices Architecture is a reconciliation loop over the label→Pod match: as Pods appear/vanish, it keeps its backend list equal to "all Pods with this label."

PICTURE. Three stacked identical loops, each fed by a different pair of jars, all the same shape — driving home that it is one idea reused.

---

The one-picture summary

This single diagram holds the whole page: two jars ($D$ and $O$) → subtraction giving signed gap $g$ → the machine $f$ acting only on reality → the ring that feeds the result back to be re-measured, forever.

Recall Feynman retelling — say it to a 12-year-old

Imagine a super-patient robot with two jars. The left jar holds the number you asked for — say "3 running copies of my app." The right jar holds the number actually alive right now. The robot does one boring thing over and over: it subtracts (right from left) to get a gap number. If the gap is a plus, it's short, so it makes new copies. If it's a minus, there are too many, so it kills some. If it's zero, it relaxes — but keeps watching. A copy crashes? The gap jumps to plus one; the robot makes a fresh copy (with a brand-new address, which is why you must talk to the stable Service and never memorise a copy's address). You want fewer? Lower the left jar; the gap goes minus; it removes some. Upgrading? The robot swaps copies a few at a time, never letting the alive-count drop below a safety floor, so users never notice. And this same jar-and-subtract robot runs at every level — one for keeping the right number of copies, one for keeping the list of live backends fresh, one for keeping the router up to date. Learn the jars-and-gap trick once, and you understand all of Kubernetes.

---

Recall

Recall Quick self-test

What are $D$ and $O$? ::: $D$ = desired count (you set it), $O$ = observed count (Kubernetes measures it). What does the sign of $g=D-O$ decide? ::: Positive → create Pods; negative → delete Pods; zero → do nothing. Why must the loop repeat instead of running once? ::: Reality ($O$) keeps drifting (crashes, node loss); a single pass can't stay correct, so the loop self-corrects continuously. Why does a healed Pod get a new IP? ::: The loop only enforces the count, not identity — it spawns a brand-new Pod, so you must front Pods with a stable Service. With $R=4$, maxUnavailable=1, what is the floor of available Pods during an update? ::: $4-1=3$. Scaling up and scaling down use... ::: the same loop; only the sign of $g$ differs.