Kubernetes Visual Handbook · interactive lab / POC
You declare it.
Who keeps it running?
Two replicas are ready. Change one number in the manifest: more Pods appear, node reservations grow, and eventually a Pod has nowhere to go. Delete a Pod and watch its owner replace it. Then try the same thing without an owner.
The tree shows resource ownership; the badges show node assignments. Every status, counter and event below comes from one state model.
Edit replicas, requests, limits or image. Changes take effect after Apply.
─ ownershipNode badge = scheduling assignmentClick a Pod to inspect it
1000 m reserved by requests
512 Mi reserved by requests
0 m reserved by requests
0 Mi reserved by requests
checkout-r1-001
- API phase
- Running
- Display status
- Running
- Node
- worker-01
- Container restarts
- 0
- Last termination
- None
- Requests
- 500m / 256Mi
- Limits
- 1000m / 512Mi
Its ReplicaSet replaces a deleted Pod with a new UID. A container restart keeps the existing UID.
Container is running. This experiment uses a fixed two-step startup before Ready.
Container is running. This experiment uses a fixed two-step startup before Ready.
Bound to worker-01 using requests, not limits or observed usage.
Bound to worker-01 using requests, not limits or observed usage.
ReplicaSet creates a Pod to match the desired replica count.
ReplicaSet creates a Pod to match the desired replica count.
Desired state accepted. Reconciliation happens on the next step.
Synthetic workload per running container
CPU under the limit. Requests reserve capacity; limits constrain runtime.
Replay the experiment
Each clock tick advances one simulated second. History also includes edits. Rewind preserves UIDs, events and applied manifests. The timings are didactic.
Local simulation · no cluster connected. Two fixed 2-CPU / 2-Gi nodes; first-fit placement. Image catalog: nginx:1.27, nginx:1.28. Recreate strategy, one container per Pod. No HPA, node autoscaling, probes, networking or node-pressure eviction.
Break it, one field at a time
- Change
replicas: 2to6, then Apply and Run. The Deployment's ReplicaSet creates the missing Pods. Each node fits four requests of 500m; placement consumes requests, not CPU limits. - Request
3000mof CPU and set its limit to4000m. Neither 2000m node fits one Pod. Both nodes together have 4000m free, but a Pod cannot straddle them. - Choose “Memory limit exceeded”. The synthetic process needs 192 Mi, above its 128Mi limit. The container is OOM-killed and restarted with backoff. Its Pod UID and reservation stay. Lower the working set to 96 Mi to let it recover.
- Delete a selected Pod. A Deployment replaces it with a new UID. Load “A Pod without a controller” and repeat: no replacement appears. Reapplying the manifest after deletion creates the standalone Pod again.
- Try “Image pull fails”. Scheduling succeeds and requests are reserved, yet the Pod remains Pending.
ImagePullBackOffis a waiting reason, not a Pod phase. - Scale to zero. Pods enter Terminating. Their reservations are released after the declared grace period, not when you click Apply.
Three jobs, three different identities
The controller maintains a replica count; the scheduler binds a new Pod to a node; the kubelet manages containers on that node. Restarting a container keeps the Pod UID. Replacing a Pod gives it a new UID. A Pod is scheduled once, rather than moved between nodes. Pod lifetime →
requests determine scheduling reservations. CPU limits can throttle; memory limits can lead to an OOM kill. Neither automatically changes the replica count. Resource management →
The boundary of this experiment
This POC uses two fixed nodes, first-fit placement and a synthetic working set. Startup takes two simulated steps; restart backoff is deliberately shortened. It supports one container, explicit CPU/memory requests and the Deployment's Recreate strategy. Unknown manifest fields are rejected so that an unsupported setting cannot appear to work.
It does not implement the Kubernetes scheduler, API server or Linux cgroups. It omits HPA, node autoscaling, probes, sidecars, affinity, storage, networking, quotas and node-pressure eviction. The gauges show unreserved allocatable capacity, not live cluster usage or a sizing recommendation. The simulated image catalog is explicit.
Run the counterpart
Manifest files and commands → Apply them to a disposable cluster with kubectl. Observe scheduling, deletion/replacement and image-pull failure against the real API. Real scheduling and timing depend on that cluster; the synthetic load is not a measurement of nginx.
A container is OOM-killed and restarted. Does the Pod get a new UID?
Commit to an answer first. You cannot change it afterwards.
END-OF-LAB CHECKPOINT · BANK 0.1.0
Check your Pod lifecycle reasoning
Three questions after the experiment. Apply the mechanisms you observed; this is a practice checkpoint.
3 questions · 7 points · target 70%
Practice bank · educator review pending for 3 questions.