kubernetes3d · server room
A rack is a node and a server is a pod. Every machine in this room is already bolted in and plugged in — capacity is hardware, not something that appears when you schedule — so scheduling is choosing one of them and pressing its power button, and an unscheduled pod is a boot request with no machine against its name. Everything the cluster does to a packet is done by a box you can point at: a router is the way in, a firewall is policy, the core switch routes the per-node pod subnets, and a Service is a patch panel with a jumper to every ready endpoint. Every rack holds the node's own kit as well — the bridge its pods land on and take an address from, the kube-proxy that programs that bridge, and the kubelet the control plane talks to — with both agents on a second, separate management network, because neither is in the data path. The web tier calls the api tier for every page it serves, so the room also carries east-west traffic: watch an amber packet leave a web machine, cross the fabric when the api pod it was sent to is in another rack, and come back. Click any machine to wheel the crash cart to it and light up the cables it depends on.