A scrollable technical lesson · no framework · 2025–2026

What actually happens
when you type kubectl apply?

Follow the request through the apiserver, scheduler, etcd, kubelet, and the container runtime, all the way to a Running Pod. Then watch what changes when a node goes quiet, and when a single Pod dies. No black boxes.

3 scenarios ~12 min read v1.31 baseline

Begin the journey → Open cluster explorer ↗

inspector · 04 / independent of the journey

Inspect the cluster.
Pick a component.

The diagram in the journey reacts to the narrative. Here you drive. Click a component to read what it does, what it stores, who it talks to, and what fails if it disappears. SIMULATED CLUSTER

Illustrative state — not a live cluster monitor
components live
    Illustrative state — not a live cluster monitor
    detail · apiserverrunning

    the one thing you should remember

    Kubernetes in one mental model.

    Every journey, every scenario, every component above is a participant in the same closed loop. You declare what you want. Components observe what is. Controllers close the gap. That is the whole system.

    1Desired stateYou declare it. kubectl → apiserver → etcd.
    ↓
    2Scheduler / Controllers observeThrough watches on the apiserver, not direct etcd reads.
    ↓
    3Kubelet makes its node match the specCRI for runtime, CNI for network, CSI for volumes.
    ↓
    4Actual state flows back to the apiserverStatus objects, conditions, events.
    ↓
    ↺Controllers reconcileDesired ≠ actual? Close the gap. Repeat forever.

    Final anchor "Kubernetes is a control system. You state what you want. Components observe what exists. Controllers continuously close the gap. When something disappears, the loop makes a new one. When something should disappear, the loop deletes it. When something is in the wrong place, the loop moves it."