Radar on Cloud Native FM: Kubernetes as a Graph, and What Agents Change

On September 16, 2026 I joined Saim Safdar on Cloud Native FM for an hour, most of it spent driving Radar against one of our test clusters - the messy one, with real critical issues in it. The full episode is here:

Saim asked better questions than the usual demo interview, and a few of them are ones we get in GitHub issues every week. Here are the answers in short, with links to where we have written them up properly.

Why build another Kubernetes UI?

The honest version of the answer: most of the existing tools are, as I put it on the show, a glorified resource viewer. They show you a list of resources. You click one, you see a bit more about it. Some do a little more than that, but the shape is the same.

Developers tend to describe Kubernetes as a hierarchy - Deployment owns ReplicaSet owns Pod. A real production application is a graph: an Ingress, a Service, a Deployment, a ReplicaSet, Pods, a ConfigMap, a Secret, a PodDisruptionBudget, NetworkPolicies, and more. The relationships between them are not one-to-one, and they change over time. Any tool that does not try to understand that graph, and how it moved, is going to be partial at best when you are trying to work out what broke.

That is what Radar follows. We wrote up the concrete version of this gap in five questions you can't answer with kubectl, and ranked ourselves against everyone else, including where we lose, in the 2026 dashboard comparison.

Can it tell me what will break when I upgrade?

Radar does not upgrade your cluster. What it does is run the upgrade checks against the cluster as it is actually running, not only against the YAML.

One example: you have an admission or conversion webhook responsible for handling a resource, and the Service backing that webhook is not running. Nothing in your manifests is wrong. The upgrade still fails, at the moment the API server needs that webhook to answer. Static analysis of your configs will not catch it, because the config is fine.

Radar checks both, and sorts findings into what is likely to break, what is worth knowing about, and what passed. Kubernetes 1.37 was released on August 26, 2026, and Radar's checks for it shipped the same day; the full list of what we look for is in Kubernetes 1.37 breaking changes.

What does MCP actually change?

Radar ships with an MCP server, on by default. The thing I care about here is that it is not a wrapper around kubectl. Several Kubernetes MCP servers are exactly that, and if a shell is what your agent needs, it already has one.

The problem with handing an agent kubectl is that the agent then spends its time rebuilding, one call at a time, the graph Radar already has - fetching resources, guessing at relationships, not knowing what it has missed, and paying for walls of YAML it mostly does not need.

On SREGym, a public fault-injection suite we had no hand in building, we ran the same model against the same 54 faults twice: once with a shell and kubectl, once with Radar's MCP and kubectl blocked. Radar reached a correct root cause in a median 41 seconds against 154 seconds, which is 3.8x at the median, and it answered sooner in 43 of the 44 scenarios both arms got right. Accuracy converges if you let both grind for half an hour (91% vs 87%), but nobody grants an agent half an hour during an incident. At a five-minute budget it is 91% against 56%.

The full methodology and the 54 replays are public, including the faults Radar got wrong.

Who sees what?

This is the one I have spent the most time on. For Radar to be fast, it has to maintain its own model of the cluster - the graph, the timeline, the changes. Building that per user, on request, would be slow enough that half of what Radar does would not be possible. So the model is built centrally, with the permissions you grant Radar itself, and then each user is evaluated separately for what they are allowed to see out of it.

Running Radar locally, this is easy: it uses your kubeconfig and your credentials. In-cluster it gets more interesting, and the part that matters is that we did not invent a parallel permission system - Radar Cloud maps roles to Kubernetes groups and impersonates the user against the API server, so your existing RBAC and audit tooling still work. That is written up in SSO and RBAC without passing around kubeconfigs.

The same scoping has to apply to agents, not just people, and read-only is not the safety guarantee people assume it is - a read-only agent can still pull secrets into its context, which is why we redact. We argued that one at length in read-only is not a safety boundary.

What's coming

Three things I mentioned on the show that we are actively building:

• A better agent experience in the UI. Today, triggering an investigation from a resource gives you an assessment, the evidence, and remediation steps. The next version threads the evidence into the explanation and walks you through it, rather than handing you a pile of findings and trusting you to assemble them.
• More depth on capacity and GPUs. Scheduling and allocation for GPU workloads, on top of the existing capacity views.
• Adapting views to the workload. A batch job, a long-running service, a worker, and an agent are all "an application" in Kubernetes, and you want to look at completely different things for each.

The longer roadmap is in what we're building in 2026, and everything that ships lands in the changelog.

Try it, and come find us

I said this three times on the podcast: it takes about 15 seconds to find out whether any of this is true for your cluster. Radar is a single Go binary, Apache-2.0, no account, no agents to install, and it auto-detects what is running in your cluster rather than asking you to assemble plugins. More than 50 people have contributed to it so far.

curl -fsSL https://get.radarhq.io | sh && radar

Or brew install skyhook-io/tap/radar. Star it on GitHub if it earns it.

We will be at KubeCon North America with a booth - stop by, and bring the cluster you cannot explain.