Kubernetes Runtime
Reconciliation as the core mental model, plus the runtime behaviours that produce most real incidents: scheduling, requests and limits, OOM kills, throttling and probes.
You write desired state; a controller observes actual state; the difference is the instruction. That loop never stops running, which is the whole idea.
Accepted, scheduled, pulled, started, ready and receiving traffic are six different moments, separated in time — so desired state is never instant reality.
Placement is a filter-then-score decision made against declared requests. `Pending` is not a failure state — it is the scheduler telling you no node satisfied the constraints.
A request is a scheduling reservation; a limit is an enforced ceiling. CPU and memory behave completely differently when you reach the ceiling, and that difference is the lesson.
Four failure shapes come from two numbers being wrong in two directions each — and each shape has a distinct symptom that tells you which one you are looking at.
Memory cannot be taken back, so the only enforcement available is termination. Over the limit, the kernel kills the process — it does not slow it down or warn it.
Over a CPU limit the container is descheduled until the next period rather than killed. Nothing errors, nothing restarts, and the tail latency gets worse for reasons nothing in the application explains.
Readiness gates traffic, liveness restarts the container, startup covers a slow boot. Confusing the first two turns a dependency outage into a cluster-wide restart storm.
One decision tree covers most Kubernetes failures: is it running, is it ready, is it routed — and each "no" points at a different, small set of causes.