u/k8studio
-
1points
-
1points
This map is more than cool (v.redd.it)
-
27points
Google map for Kubernetes using React (v.redd.it) [General Discussion]
-
1points
Google Maps for Clusters (i.redd.it) [Tools]
-
3points
Google Maps for Clusters (v.redd.it)
-
2points
Google Maps for Kubernetes Cluster (v.redd.it)
-
2points
Google Maps for Kubernetes Cluster (v.redd.it)
k8studio
k8studio
Well I think a c4 model the best prompt that you can give
k8studio
Yes!
k8studio
Hey! thanks for putting the post back! I can not understand why moderators deleted the post
k8studio
https://reddit.com/link/oxo7nwc/video/ucfzy69a5edh1/player
Every tool for exploring Kubernetes clusters (the infrastructure that runs most modern software) visualizes them the same way: as a tree or a nested list. Namespace, then resources, then drill in, back out, drill into the next one. It works, but it fights how humans actually process scale. Nobody navigates a city by reading a nested list of streets. We use maps, because spatial reasoning is the thing our brains are absurdly good at. There's Nobel-winning neuroscience behind it (O'Keefe and the Mosers' 2014 work on place cells and grid cells, the hippocampus literally building internal maps). Infrastructure tooling has never really exploited that.
https://www.youtube.com/watch?v=8iPLsSawg4k
So I'm building CloudMaps, which renders a cluster as an actual map:
- Namespaces = continents
- Applications = countries
- Workloads, services, storage = cities
- Network connections between them = roads
The encodings I'm playing with: traffic volume as road width and congestion, incidents as weather systems over a region, resource pressure as terrain elevation. Semantic zoom throughout, from the whole cluster down to a single pod, without losing your sense of where you are. Basically stealing every idea Google Maps already validated and pointing it at infrastructure instead of geography.
The design problem I keep chewing on, and where I'd love this sub's take: infrastructure has no inherent geography. A real map works partly because positions are stable and meaningful. Paris doesn't move. Here, layout is something I have to invent, and if it shifts between sessions the whole "place cells" argument collapses. So:
- Does a spatial metaphor still buy you anything when the space itself is synthetic? Or does the layout just need to be stable for spatial memory to kick in, even if it's arbitrary?
- At what density does this degenerate into the classic hairball problem? Clusters can have thousands of services. Does zoom plus aggregation actually beat a well-filtered tree at that scale, or is it visual noise with better production values?
- Has anyone seen prior art on map metaphors for abstract data that actually shipped and survived contact with real users? I know the old "software cartography" research, but I'm curious about anything more recent.
Beta is live at https://k8studio.io
k8studio
https://reddit.com/link/oxni6mm/video/x2u6brw9dddh1/player
I got tired of navigating Kubernetes clusters through YAML trees, so I started building a version that works like a map instead
Been stewing on this for a while and wanted to get it in front of people who'd actually push back on it.
Every tool we use to look at a cluster (k9s, Lens, the dashboard, kubectl itself) is basically a list or a tree. Namespace, then a bunch of resources under it, then you drill into one, then you're back out, then you drill into another. It works, but it's not how humans are actually good at understanding scale. Nobody navigates a city by reading a nested list of streets. We use maps, because our brains are stupidly good at spatial reasoning. There's actual Nobel-winning neuroscience behind this: the hippocampus has "place cells" and "grid cells" that build a literal internal map of your surroundings, discovered by O'Keefe and the Mosers in 2014. We just never brought that instinct to infrastructure.
So the thing I'm building, called CloudMaps, treats a cluster like an actual map:
- Namespaces = continents
- Applications = countries
- Workloads, Services, PVCs, Ingress = cities
- Connections between things (a Service hitting a Pod, cross-namespace traffic) = roads
The idea is you get real zoom, whole cluster down to a single namespace down to a single pod, without losing your sense of where you are or how it connects to everything else. Traffic volume could show up as road width or congestion, incidents as weather over a region, resource pressure as terrain. Basically stealing every good idea Google Maps already figured out and pointing it at a cluster instead of a city.
Still early. Curious what this sub thinks: is spatial navigation actually useful at cluster scale, or does it fall apart once you're dealing with thousands of services and it just becomes visual noise like a bad service mesh graph? Also curious if anyone's tried something like this and hit a wall I haven't found yet.
beta available at https://k8studio.io
k8studio
https://reddit.com/link/oxne9ts/video/zfxvuf377ddh1/player
I got tired of navigating Kubernetes clusters through YAML trees, so I started building a version that works like a map instead
Been stewing on this for a while and wanted to get it in front of people who'd actually push back on it.
Every tool we use to look at a cluster (k9s, Lens, the dashboard, kubectl itself) is basically a list or a tree. Namespace, then a bunch of resources under it, then you drill into one, then you're back out, then you drill into another. It works, but it's not how humans are actually good at understanding scale. Nobody navigates a city by reading a nested list of streets. We use maps, because our brains are stupidly good at spatial reasoning. There's actual Nobel-winning neuroscience behind this: the hippocampus has "place cells" and "grid cells" that build a literal internal map of your surroundings, discovered by O'Keefe and the Mosers in 2014. We just never brought that instinct to infrastructure.
So the thing I'm building, called CloudMaps, treats a cluster like an actual map:
- Namespaces = continents
- Applications = countries
- Workloads, Services, PVCs, Ingress = cities
- Connections between things (a Service hitting a Pod, cross-namespace traffic) = roads
The idea is you get real zoom, whole cluster down to a single namespace down to a single pod, without losing your sense of where you are or how it connects to everything else. Traffic volume could show up as road width or congestion, incidents as weather over a region, resource pressure as terrain. Basically stealing every good idea Google Maps already figured out and pointing it at a cluster instead of a city.
Still early. Curious what this sub thinks: is spatial navigation actually useful at cluster scale, or does it fall apart once you're dealing with thousands of services and it just becomes visual noise like a bad service mesh graph? Also curious if anyone's tried something like this and hit a wall I haven't found yet.
The beta version is available at https://k8studio.io
k8studio
The Gestapo Cancelation
k8studio
Looks like a moderator removed it
k8studio
This is not a new product, nor is it a framework. It is a new concept: how to use maps to manage Kubernetes.
This is a genuine conversation. I have not even included any link to the project.
The moderation team should allow the conversation to continue, as it is valuable for the community.continue
NOT COOL REALLY!!!!
k8studio
Guys the moderators decided to remove the post!!!
Moderators, reddit is to have conversations, this is not cool!!!
This is the reason:
Posts about new projects/tools/frameworks can only be posted in the weekly thread. A new one is added every Wednesday, scroll back in the current week to find it.
k8studio
No, this is the reason!!! Really!
What the hell is going on with these moderators
Posts about new projects/tools/frameworks can only be posted in the weekly thread. A new one is added every Wednesday, scroll back in the current week to find it.
k8studio
Thanks!
k8studio
Lol same in Spanish :). Thanks
k8studio
Yes! BTW what do you use to monitor your traffic? Caretta?
k8studio
Yes, exactly. It makes it a lot easier to have an actual conversation with less technical people, instead of losing them at the first YAML dump. When they can see the shape of what's going on, they tend to appreciate what's involved instead of just seeing a black box, and that turns them into someone helping you prioritize instead of an obstacle asking "why is this taking so long."
Appreciate the RemindMe, happy to have you check back in.
k8studio
Yes, Keeping each namespace as its own island preserves its identity
k8studio
Thank you!
Definitely https://uxxu.io