Probes cannot fix bad addressing: what a browser-run Kubernetes cluster actually shows

The default that produces the outage is the absence of a probe, not the presence of a bad one. With nothing configured, Kubernetes treats a container as Ready the moment it starts, including the seconds it spends initialising before it listens on port 8080 ^[6]. The container is up, it is advertised as healthy, and requests arriving in that window fail ^[6]. Nothing malfunctioned. The kubelet did what it was told, and it was told nothing.

The cost lives in the restart curve. CrashLoopBackOff starts at 10 seconds and doubles with each crash up to a ceiling of 5 minutes ^[7]. Run the sequence: 10, 20, 40, 80, 160, then 320 clipped to 300, so the sixth backoff already sits at the cap and about 10 minutes of wall clock is gone ^[14]. After that the container gets 12 start attempts an hour ^[15]. If the caller behaves like the post's pod-b, one request every 2 seconds ^[12], each capped gap is 150 requests with nowhere to land ^[16]. That is the mechanism behind "restart loops that take hours to recover from" ^[4]: a doubling that outruns the person watching it.

The more useful demo is the one where the probe is correct and the requests still fail. Add an httpGet startup probe and the pod reports itself not ready until the first GET /startup returns a status in the 200-399 range ^[9][11]. The client in the demo keeps failing anyway, because it is pointed at pod-a's IP address directly, which never consults readiness ^[2]. Readiness gates endpoints, not packets. It cannot correct a caller that already knows the address, and in a real cluster that caller is an ingress controller, a load balancer, or another service holding a stale target ^[12].

The probe budget is the other misconfiguration with teeth: periodSeconds multiplied by failureThreshold, roughly 5 seconds in the post's example, after which the kubelet kills the container rather than waiting longer ^[9]. Set that budget below a container's honest startup time and slow becomes dead, and dead re-enters the backoff schedule above ^[17]. Each node runs its own kubelet making these decisions locally ^[10], so the failure is per-node and looks like flapping rather than a policy error.

On the tooling itself, the author reports porting more than 100,000 lines of Kubernetes Go to TypeScript so the simulated cluster runs in the browser, verifying demo behaviour against k3s, and finding a bug in Kubernetes in the process ^[5][1]. The bug is announced and deferred to a later section ^[3]. Until it is named, the supportable claim is the narrower one: the port tracks k3s closely enough that its author trusted a divergence rather than assuming his own translation was wrong. That earns it standing as a teaching rig. It is not yet evidence about upstream. Also worth noting for anyone reading the demos literally: the NotReady label is the author's shorthand, since the API exposes a Ready condition that is True, False, or Unknown ^[13], and the backoff was compressed from 10 seconds to 3 for the demo ^[7], which makes the visible loop kinder than the one in production.