kubernetes3d — the 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. The whiteboard on the left wall is not part of the cluster either — it is where the state of it gets read and written.

outside · demarc → rtr-0 → fw-0 → sw-core fabric · rack uplink ↔ sw-core, one route per pod cidr access · server ↔ top of rack management · kubelet ↔ sw-mgmt ↔ apiserver storage · array ↔ fabric, where an image is read from programs · kube-proxy → the rack's bridge, carrying no packets power · every server, running or not packet in from outsidepod to podimage read

about kubernetes3d

kubernetes3d is a real Kubernetes cluster, not a recording of one. Every rack, server, pod, deployment, service and event on screen is live simulator state — this room is one of two skins over the same cluster: a rack is a node, a server is a pod, and scheduling is pressing a power button. The other skin is the rack, where an image is a tape and a pod is a deck playing it.

The cluster itself is webernetes, a Kubernetes simulator that runs entirely in the browser — a real apiserver, scheduler and controllers, so pods actually get bound to nodes, a rollout actually respects maxUnavailable, and a request that lands on the router is actually routed round-robin to a ready endpoint.

The physical look — lit surfaces, bezels with real falloff, switches with travel — comes from ambientcss, a lighting and surface library grounded on rendered reference scenes rather than hand-tuned gradients. It supplies the material; the room layout and the metaphor are this project's own.