skyhook-io/radar

Radar is a self-hostable Kubernetes dashboard aimed at people debugging live clusters: it ranks broken workloads, shows resource topology and a change timeline, and exposes the same view of the cluster to AI agents over MCP. It can run from a laptop against your kubeconfig or in-cluster for a team.

What it helps you do

The starting point is an Issues queue: crash loops, image pull failures, stuck rollouts, unschedulable pods, dangling references and failing Argo CD/Flux conditions, each with an Investigate action. From a failing resource you can open its owners and Services on the topology graph, see what changed and when on the timeline (with diffs, in memory by default or persisted to SQLite/Postgres), and read events, logs and YAML in a detail drawer. Helm, GitOps, traffic, cost, capacity and RBAC views extend this, plus a 44-check audit scanner run against cached data (README views, Issues).

How it works

Radar is a single Go binary that talks to the Kubernetes API with your kubeconfig and watches the cluster through informers, pushing live updates to the browser over SSE. The author's caveat in the associated HN thread is that server load stays modest because each client syncs locally, and an in-cluster Helm install can serve several users (HN discussion).

The MCP server and AI investigations

MCP is on by default on the same port as the UI. /mcp-readonly exposes no write tools; /mcp adds write tools (restart, scale, apply, rollback, GitOps sync, node drain) marked destructive. --mcp-read-only disables /mcp (and with it applying a fix from an investigation); --no-mcp disables MCP and investigations. Neither blocks ordinary UI writes. Secret reads never include .data/.stringData, and environment variables, Helm values and logs are scrubbed for known secret patterns — which the docs say cannot catch everything, and the opt-in exec_pod tool returns raw output (MCP security).

AI investigations delegate to an agent CLI you already have (Claude Code, Codex, Cursor, OpenCode) on the machine running Radar, so no API key is required. They need MCP on and authentication off, and do not run in in-cluster installs. With Cursor and OpenCode Radar cannot constrain the agent's own tools, and those clients auto-approve tool requests during a run (AI investigations).

Requirements and limits

Local mode needs only a kubeconfig; the desktop app needs no terminal. In-cluster deployment uses Helm and supports OIDC or auth-proxy login with per-user RBAC through impersonation; auth is off by default for local use. Non-loopback binding needs authentication and network controls. Traffic needs a source such as Hubble, Istio, Caretta or Beyla (Beyla needs its network feature and extra attributes enabled, or per-port edges will be partial). Metrics and cost views need a Prometheus-compatible backend or Kubecost. Karpenter, cost and similar views appear only when the relevant data is detected (installation, authentication). Cluster data stays local; anything an agent or investigation reads goes to that agent's model provider. Usage reporting is opt-in and limited to anonymous counts and coarse cluster facts.

The project's benchmark claims — roughly 3× faster diagnosis via MCP than kubectl, and the AI SRE comparison — come from the maintainer's own SREGym studies on a 3-node EKS cluster, so treat them as vendor-reported (benchmarks).