Every Kubernetes visualization demo looks amazing with 50 workloads. A force-directed graph, colored circles, some arrows. Ship it.
Then you point it at a real production cluster and the map turns into a hairball that is exactly as unreadable as the YAML it was supposed to replace.
We just shipped K8Studio 4.0.0 with CloudMaps in beta: a live, explorable map of your cluster that we've been calling Google Maps for Kubernetes. This post is about the part that took us the longest, which was making it survive contact with real clusters. If you've ever built (or abandoned) a graph visualization, some of this will feel familiar.
The problem with drawing a cluster
Kubernetes is a graph. Deployments own ReplicaSets, ReplicaSets own Pods, Services select Pods by label, Ingresses and Gateway API routes point at Services, Pods mount ConfigMaps, Secrets, and PVCs. Every tool that draws this graph naively hits the same wall: the number of edges grows much faster than a human's ability to read them.
At 50 workloads a node-link diagram is helpful. At 500 it's noise. At 5,000 it's abstract art.
Most tools respond by filtering. Show one namespace, hide the rest. But filtering throws away exactly the thing a map is for: context. If you can only see one namespace at a time, you don't have a map. You have a prettier version of kubectl get all -n foo.
What cartographers figured out centuries ago
The answer we landed on is aggregation, and the model was literally cartography. A map of Europe doesn't show every building. It shows countries, then cities, then streets, revealing detail as you zoom. Nothing is deleted. It's just not drawn until the zoom level makes it useful.
CloudMaps applies that idea directly:
Pods aggregate into the workloads that own them.
Workloads sit inside their namespace, drawn as an island with resource counts and recognizable tool icons (Prometheus, Argo CD, CoreDNS, Helm) visible without opening anything.
Namespaces aggregate into regions grouped by purpose: monitoring, ingress, platform services, your own application domains.
For anything in the CNCF Landscape, the taxonomy already exists and engineers already trust it, so CloudMaps inherits that grouping instead of inventing a new one. Your own application code stays its own region, because forcing it into a borrowed taxonomy would be lying to the map.
At high zoom you see regions, islands, counts, and health signals. Zoom in and workloads, pods, ports, routes, storage relationships, and live dependencies appear. Same facts as the full resource list, but aggregated into something your eyes can process at once.
The constraint that made it hard: no agents
Here's the part that made this genuinely difficult. K8Studio is agent-free by design. No DaemonSets, no sidecars, no operators, no collectors. It talks to the Kubernetes API through your kubeconfig, exactly like kubectl, and everything happens locally on your machine.
Agent-based platforms get to pre-process topology server-side and stream a finished picture to a thin client. We don't. Layout, aggregation, relationship resolution, live updates: all of it computed client-side, on whatever laptop you happen to run.
Why keep a constraint that makes your life harder? Because it buys things we care about:
Works in air-gapped environments (if your workstation can reach the API server, the map works)
Zero added attack surface in the cluster
No cluster data leaves your machine
No dependency on our cloud being up
Getting fluid rendering at 5,000+ workloads under those rules took longer than any feature we've ever built. Level-of-detail rendering, careful caching of watch streams, and being ruthless about what gets drawn at each zoom level did most of the work.
What it's actually for
A map earns its place by making certain questions cheap:
What is this workload actually connected to?
Which Services and routes lead to it?
Which PVCs, nodes, and policies are related?
If this object changes (or gets compromised), what's the blast radius?
Where is resource pressure building right now?
Incident triage, architecture reviews, onboarding someone to an unfamiliar cluster, security discussions. Anything where the first step is "understand how things relate" gets faster when the relationships are drawn for you.
It's a beta, and we mean that
CloudMaps ships in 4.0.0 as a beta because it's evolving fast. Grouping rules, zoom behavior, and which relationships get drawn first have already changed based on feedback from teams running it against real clusters. If something in your cluster maps badly, that's a bug report we want.
4.0.0 also ships Gateway API views and clearer workload status across the app.
If you want to see your own cluster as a map: k8studio.io. Desktop app for macOS, Windows, and Linux, 15-day free trial, nothing installed in your cluster.
What's your current answer for "show me how everything connects" in a big cluster? Genuinely curious what people are using since Weave Scope was archived.
Top comments (0)