Radar for Kubernetes
Diagnose Kubernetes failures, changes, traffic, and configuration from one self-hosted interface.
The security policy states that local mode uses the existing kubeconfig and Kubernetes RBAC, the default listener is 127.0.0.1, and read-only identities, authentication, and network policies are recommended. Helm tests substantiate selected permission gates, Secret references, and keeping tokens out of container arguments. The README also explains local data flow and provides switches for MCP, exec, and Helm writes. Deductions apply because the product can delete resources, exec into containers, edit manifests, uninstall Helm releases, and perform GitOps actions, yet no per-action confirmation, approval policy, or MCP write-confirmation mechanism is shown. Cloud-tunnel and optional integration data boundaries are incomplete. Explicit rollback exists for Helm but no general recovery path is documented for deletion or other mutations. Dependencies are pinned and CI plus CodeQL are configured, but no vulnerability results, SBOM, or artifact verification are supplied. Repository ownership, an Apache license, and a security contact provide attribution, while publisher identity remains unverified as stipulated.
The README, security policy, Helm tests, and CI are broadly consistent about operating modes, RBAC, token configuration, and major capabilities. CI covers Go, frontend, shared UI, and Helm rendering. Dependencies are explicitly versioned and the core is presented as a single binary, but building still relies on a large Go/npm dependency graph, third-party Actions, and optional integrations; offline build or dependency-mirroring support is not established. Useful failure evidence includes rejected conflicting settings, rejection of missing cloud credentials, authorization-error guidance, and detailed slow-cluster diagnostics. Points are withheld because MCP/API error structures, retry behavior, and failure semantics across write operations are not shown.
The material thoroughly addresses laptop use, shared in-cluster deployment, multiple Kubernetes distributions, restricted RBAC, slow or large clusters, private registries, and air-gapped environments. Capability boundaries are partly documented through read/write inventories, disable flags, authentication modes, and the single-namespace cache limitation, but complete Cloud, MCP, and integration boundaries reside in absent documents. MCP is only described at a high level with a few named tools; schemas, trigger conditions, argument constraints, and selection rules for mutating tools are missing, so trigger precision is thin.
The README has strong navigation across installation, usage, views, security, and development, with clear multi-platform and Helm examples. The complete Apache-2.0 text matches the supplied license metadata. Command and option naming is mostly coherent, although radar, kubectl radar, the desktop distribution, and the explorer binary built in CI are not tied together by an explicit compatibility policy. Examples are plentiful but a complete FAQ is absent. Known limitations are unusually concrete, including namespace scoping, timeout misclassification, candidate caps, Gateway mutual exclusion, and Helm-version constraints, justifying full marks there. Versioning is represented mainly by a Releases link and a latest-release support statement; the revision's version, an included changelog, and migration policy are absent. A security address and response schedule identify an update path, but team governance and succession responsibility are not documented.
Topology, resource tables, timelines, comparisons, audits, capacity analysis, and GitOps diagnosis are described as actionable outputs, while consolidating these capabilities into one UI and MCP service offers substantial marginal value over separate tools. The cost-benefit score is reduced because the favorable single-binary, free, and agentless claims are not accompanied by resource-use measurements, while the broad dependency surface, cluster read access, optional write privileges, authentication setup, and external integrations impose operational and security costs.
Some claims trace directly to the security policy, pinned manifests, CI/CodeQL workflows, and focused Helm tests for RBAC and credential rendering; these files also provide limited cross-corroboration of the security model. The capacity documentation distinguishes exact, bounded, and unknown values, Helm wording labels inferred rollback patterns, and the slow-cluster section separates timeout artifacts from actual RBAC denial. Deductions apply because performance, scale, privacy, compatibility, the 31 audit checks, and many feature claims are primarily README assertions without implementation files or corresponding tests in the supplied evidence. Badges, a user quotation, and release links do not independently corroborate those claims within this source-only assessment.
- Inspect the rendered Helm RBAC before granting production access, and prefer a dedicated read-only, namespace-scoped identity.
- The evidence does not establish per-operation confirmation for deletion, exec, Helm uninstall, or MCP/GitOps mutations; keep those write capabilities disabled until confirmation and audit behavior are verified.
- Do not use the no-telemetry claim alone to infer the data boundaries of Cloud, Prometheus, Argo CD, registry, or traffic integrations; review the missing integration documentation and implementation.
- The quick install pipes a remote script to a shell. For production, download and inspect it and verify release artifacts first; checksums, signatures, and an SBOM are not shown.
- Configured CodeQL analysis does not establish the absence of known vulnerabilities; the large direct and transitive dependency set still requires revision-specific vulnerability and supply-chain review.
What does this agent do, and when should you use it?
Radar is an open-source Kubernetes UI maintained by Skyhook, with a built-in MCP server for AI clients. It runs as a single Go binary, either locally against the Kubernetes API through kubeconfig or in-cluster through its Helm chart for shared access. Its browser interface combines resource browsing, live topology, event and change history, Helm, ArgoCD and FluxCD operations, traffic, cost, audits, upgrade impact, and RBAC visibility. Informers watch the cluster and SSE delivers live updates, while the MCP layer returns compact topology, health, deduplicated event, and filtered log context. Local operation requires no account or cloud backend and keeps cluster data on the user's machine; shared deployments can add proxy or OIDC authentication with per-user Kubernetes impersonation. It is a strong fit for platform and operations teams that want broader diagnosis than raw YAML while retaining a self-hosted deployment boundary.
After kubectl radar or radar starts, Radar connects to the Kubernetes API with the configured identity, populates informer caches, and streams changes by SSE into resource tables, topology graphs, issue views, and the timeline. Resource drawers expose YAML, related objects, logs, and events; users can compare two resources in side-by-side or unified diffs, and inspect, search, or download files from container image filesystems. The Helm workspace reads releases, values, rendered manifests, histories, and hook evidence, and can upgrade, roll back, or uninstall when RBAC permits. The GitOps workspace diagnoses ArgoCD and FluxCD objects, while manage_gitops supports sync, suspend, resume, reconcile, and rollback requests. Radar can also consume Hubble, Caretta, or Istio traffic data, Prometheus/OpenCost metrics, and cached Kubernetes objects to produce audits, upgrade-impact results, Karpenter capacity analysis, TLS information, network-path diagnoses, and effective ServiceAccount permissions. Its default-on MCP server exposes compressed cluster context and capabilities such as diagnose, get_cluster_audit, and get_subject_permissions; read tools are read-only, while mutations remain subject to the caller's Kubernetes RBAC.
- An on-call engineer investigating CrashLoopBackOff, ImagePullBackOff, or missing ready endpoints can correlate Issues, logs, events, resource relationships, and the first broken hop in Reachability.
- A platform team operating a large cluster can use Topology, Resources, and Timeline to inspect cross-namespace relationships and live churn while filtering by namespace, kind, status, or problem.
- A delivery team using ArgoCD, FluxCD, or Helm can investigate drift, failed upgrades, stuck operations, rollback patterns, and hook failures from the GitOps and Helm workspaces.
- A cluster administrator preparing a control-plane upgrade can run Upgrade impact to find removed APIs, unsupported version skew, overlapping PDBs, and other evidenced blockers.
- A security or platform engineer can run the 31-check Cluster Audit and inspect effective RBAC permissions and workload blast radius for ServiceAccounts.
- A team using an MCP-compatible AI client can query Radar for condensed topology, health, event, and log context instead of feeding the model large amounts of raw
kubectlYAML.
What are this agent's strengths and limitations?
- A single Go binary can talk directly to the Kubernetes API from a laptop without cluster agents or CRDs, while a Helm-based in-cluster mode remains available for teams.
- The scope goes beyond a basic resource dashboard by combining topology, history, Helm, ArgoCD and FluxCD, traffic, cost, audits, upgrade impact, Karpenter, and RBAC analysis.
- The built-in MCP server supplies preprocessed topology, health, event, and log context, reducing the amount of verbose YAML an AI client must consume.
- Local mode requires no account, cloud sync, or cluster telemetry, and the project states that manifests, logs, events, metrics, and resource data are not uploaded to Skyhook.
- Proxy and OIDC modes, Kubernetes impersonation, feature-disable flags, and API-server-enforced RBAC provide explicit controls for shared deployments.
- The product depends on reachable Kubernetes API access and sufficient RBAC; restricted identities may be unable to list namespaces, RBAC objects, or integration CRDs, leaving some views incomplete.
- Several specialist features need existing cluster components: traffic requires Hubble, Caretta, or Istio; cost needs detectable OpenCost metrics in Prometheus; and capacity appears only when Karpenter NodePools are detected.
- High-latency, tunneled, or API-throttled clusters may produce premature timeouts, misleading RBAC-limit messages, or missed namespace candidates until four timeout and scope settings are tuned.
- Local mode has no authentication by default and binds only to loopback; operators exposing
0.0.0.0or shared in-cluster access must configure authentication, ingress, and network controls. - The documented GitOps scope is single-cluster. Hosted multi-cluster operation, SSO, and shared dashboards belong to the separate Radar Cloud offering.
- MCP mutations, Helm management, terminals, and debug shells broaden the operational surface. Although Kubernetes RBAC still applies, adopters must design least-privilege roles and decide which capabilities to disable.
How do you install or deploy this agent?
You need a kubeconfig that reaches the target Kubernetes cluster and an identity with suitable RBAC. On macOS or Linux, run curl -fsSL https://get.radarhq.io | sh; Homebrew users can run brew install skyhook-io/tap/radar, and Krew users can run kubectl krew install radar. On Windows, use irm https://get.radarhq.io/install.ps1 | iex, or run scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket followed by scoop install radar. Start the first session with kubectl radar; the quick installer, PowerShell installer, Homebrew, and Scoop also provide the shorter radar command. For shared in-cluster access, run helm repo add skyhook https://skyhook-io.github.io/helm-charts and then helm install radar skyhook/radar -n radar --create-namespace. Radar listens on 127.0.0.1:9280 by default; explicitly exposing 0.0.0.0 or an in-cluster instance should be paired with authentication and network controls.
How do you use this agent?
Run kubectl radar to start the server and open the browser automatically, or add --no-browser. Set an initial scope with --namespace or --namespaces ns1,ns2,ns3; accounts restricted to one namespace, or operators reducing cache size on large clusters, can combine a single --namespace with --namespace-scope. MCP is enabled by default and can be connected to a compatible AI client using the documented MCP configuration; pass --no-mcp when it is not required. For persistent history, use --timeline-storage sqlite --timeline-db ~/.radar/timeline.db, optionally setting --timeline-max-size to bound the database and WAL. Shared deployments can select --auth-mode proxy or --auth-mode oidc. Slow control planes may require larger values for --context-switch-timeout, --first-paint-backstop, --namespace-list-timeout, and --max-scope-candidates. Helm, exec, and GitOps mutations depend on the active Kubernetes identity's RBAC; use --disable-exec, --disable-helm-write, or --disable-local-terminal to reduce the exposed operational surface.
How does this agent compare with similar options?
Compared with raw kubectl output, Radar provides visual resource relationships, health assessments, deduplicated events, filtered logs, and compact MCP context rather than requiring operators or models to process verbose YAML. Compared with Kubernetes dashboards that require an in-cluster agent or CRDs, Radar can run only on a laptop and connect directly to the Kubernetes API, while still offering an optional Helm deployment for shared access.
FAQ
Does Radar require payment or an account?
Does it send cluster data to Skyhook?
Which Kubernetes permissions are required?
rbac.viewRBAC=true, and CRD integrations require both the CRD and read access. Mutations are authorized by the API server under the same identity.Can it run without Hubble, OpenCost, or Karpenter?
What should I change if a slow cluster times out or appears falsely RBAC-limited?
--context-switch-timeout, --first-paint-backstop, --namespace-list-timeout, and --max-scope-candidates, or use their corresponding RADAR_* environment variables. The documented defaults target healthy control planes over low-latency connections.