yeke.io · docs
KubeWorld
KubeWorld shows the selected cluster as a living city: trouble stands out on the map, and the side panel says why. This guide covers the city's vocabulary, the toolbar, and what is measured versus estimated.
What it's for
See the cluster at a glance, and summarise what's going on — problems, pending approvals — at a glance.
The KubeWorld band in the Monitoring header (Enter KubeWorld) opens a map of the selected cluster; the Monitoring button at the far left of the toolbar takes you back. The namespace selection carries over between the two screens. KubeWorld collects no new data: it reads what the monitoring pipeline and the live lists already carry, in a different form. A click on the map only selects and opens details; it never changes an object. No license required (Community).
The city's vocabulary
Legend in the toolbar shows the same mapping over the map; every city item is listed next to its Kubernetes counterpart.
| In the city | In Kubernetes |
|---|---|
| District | Namespace. Its health is the worst of what it holds. |
| Building | Workload. The building comes from the workload's shape, not its kind name: tower — replicated copies; bank — numbered copies; telecom mast — one copy per node; workshop — runs to completion; clock-tower factory — scheduled; shop — unrecognised owner; house — pods without an owner. Floors follow the replica count, up to a cap. |
| Room / window | Pod. |
| Power plant | Node. Goes dark when NotReady; smokes under a pressure
condition (e.g. MemoryPressure). |
| Toll gate | HTTPRoute / Ingress; the sign shows the host. |
| Mailbox | Service. A locked mailbox has no pods behind it. |
| Depot | Volume claim (PVC); the stack shows used space. An unbound claim is an empty lot. |
| City hall | YEKE operations. The queue in front is operations awaiting approval (up to three people are drawn). |
| Weather | The cluster at a glance (below). |
Rooms and emergencies
State is carried by shape, not colour; a pod's own failure is shown before the failure of the node it runs on.
| Room | Pod |
|---|---|
| Lit window | Running and ready |
| Dim window | Running, not ready |
| Scaffolding | Pending |
| Broken glass, smoke | Crash loop |
| Flooded room | OOMKilled |
| Rubble | Failed |
| Shutter down | Succeeded |
| Fog | State unknown |
| Power cut | The pod's node is NotReady |
A single vehicle comes to a troubled building: a fire engine for a crash loop, an ambulance
for OOMKilled, a tow truck for a NotReady node, a crane for Pending
or a scaling workload. If a building has several failures, the most urgent gets the vehicle;
the others still show in their rooms with their own shape.
Weather
The sky tells you the state of the cluster at a glance; a local cloud shows where the problem is.
- Clear — no problems.
- Cloudy — warnings. A district with a critical problem also gets its own dark cloud.
- Storm — critical at cluster level: a critical cluster alert, a dark power plant, or critical problems across a large share of districts.
- Haze — no problem is visible, but one of the health sources (states, nodes, alerts) could not be read. Sunshine would mean “no problems”; an unknown state is never drawn as sunshine.
Pending pods don't change the weather — rollouts happen every day.
Traffic — an estimate
Traffic is not measured. Density is estimated from the receiving pods' network intake; no road claims a measured flow.
The roads themselves come from configuration: a service's selector and an entrance rule's backend. The number and type of vehicles come from the measured receive rate of the pods at the end of that road — scooter for light, car for medium, sports car for heavy traffic. A pod's receive rate also includes responses to its own outbound calls, so this is an upper-bound estimate.
Traffic to a cluster-internal service that sits behind no entrance is carried by mail carriers: a mail carrier on foot for light traffic, a bicycle courier for heavy traffic. They walk the sidewalk and deliver in front of the receiving building. A carrier stands for local delivery; no route is drawn from one mailbox to another service, because that flow is not measured.
- No service-to-service flow is drawn. YEKE does not measure pod-to-pod traffic; whether service A calls service B is not on the map.
- A road that isn't measured has no moving carrier. Only a faint dashed route is drawn. The depot truck is always drawn like this: volume I/O is not measured.
- Vehicles don't pile up. At the toll gate and on the road there is always a gap between vehicles; the line in front of a gate is not a congestion signal, traffic is only an estimate.
- Every carrier finishes its route. When data refreshes, vehicles and mail carriers are not reset; each one disappears when it reaches its end — the exit, the target gate, the mailbox — and new ones appear only at the start of a route. Vehicles on the road all move at one speed; speed carries no data, the vehicle type shows the density.
- With reduced motion on, nothing moves on the roads or sidewalks and emergency lights stay steady.
Side panel
The reason for what you see on the map is written in the three cards on the right.
- Selection — click a building, a window, a power plant, a mailbox or a toll gate.
The card shows the object's details and a Why line: the reason it counts as a problem
(
CrashLoopBackOff, “not scheduled on any node”, “no pods behind it”…). There is no “problem” mark without a reason. Open object takes you to the object's page; Esc clears the selection. - Operations — from YEKE's own records: how many operations await approval, how many are applying, how many were applied or failed in the last 24 hours, and the latest one. If they can't be read, the card says “unknown”, not “0”. Clicking the city hall opens the same summary.
- Problems — the list of problems on the map; selecting one moves the camera there. Pods that can't be scheduled and claims waiting to bind sit in a separate Waiting group.
When a data source can't be read, a named chip appears in the toolbar (“No metrics”, “Alerts unknown”…); the city doesn't go blank, the missing piece is shown as missing.
Labels and Save
On the left, the way back to Monitoring and what the map shows; on the right, navigation and sharing.
- Problems only narrows the map to troubled objects; Legend opens the city's vocabulary.
- Labels hides or shows the text on the map (district names, problem callouts, toll-gate signs); labels are off by default. Problem markers, the selection and the side panel stay. The choice is remembered in this browser. The number of problem callouts is limited by screen area; the ones that don't fit fold into a “+N” badge on the district sign, and all of them stay in the Problems list.
- Save downloads the current view of the city as a PNG — at least 2× resolution regardless of your screen's pixel density, with a “YEKE | KubeWorld” card in the bottom left. The cluster name and time are not written into the image; the cluster name only appears in the file name. Turn labels off before sharing and namespace and host names stay out of the image too.
- Zoom in, Zoom out, Fit and Full screen are for moving around the map; you can also drag to pan and use the wheel to zoom.
Limits
KubeWorld is a reading — not a topology tool, not a one-to-one inventory.
- Traffic is an estimate (see Traffic); outbound traffic and volume I/O are not measured.
- Pod metrics are read for at most 1000 pods. Every pod is still drawn on the map; on a larger cluster only the metrics list is cut. The “N pods without metrics” chip in the toolbar says how many pods have unknown CPU, memory and network.
- Only what you can access is drawn. If your access covers part of the cluster, pods outside it are not on the map; a chip says how many are visible.
- Memory ratio is against the limit only when one is set; a pod without a limit is measured against node capacity and naturally looks low. Requests are not used.
- The map refreshes with a delay of a few seconds — objects stream live, metrics and operations are read every 30 seconds.