Skip to content
KubeGlass

KubeGlass vs Radar

Radar is an open-source Kubernetes UI from Skyhook, under the Apache-2.0 license. Like KubeGlass, it is one Go binary that serves a web UI from your computer or from a cluster, and it also comes as a desktop app. It has a topology graph, a ranked list of issues, a timeline of events and changes, Helm, Argo CD and Flux, live traffic between services, costs, best-practice checks and an MCP server. Skyhook also sells Radar Cloud, a hosted service that puts several clusters behind one address.

Radar and KubeGlass overlap more than the other tools on these pages. They differ in how many clusters one copy shows, how a shared install decides what each person may read, whether the change history can undo a change, and how access is reviewed.

At a glance

Section titled “At a glance”
Feature KubeGlass Radar
License AGPL-3.0 Apache-2.0
Project The KubeGlass maintainers Skyhook; latest release v1.16.0, 7 October 2026
Cost Free Free. Radar Cloud, the hosted service, has a free tier for three clusters and paid plans
Runs as A binary that opens the UI in your browser, a container, or a Helm chart in a cluster A binary that opens the UI in your browser (also as a kubectl plugin), a desktop app for macOS, Linux and Windows, or a Helm chart in a cluster
Several clusters Every kubeconfig context in one list with its problem counts, and lists and search across several at once; installed in a cluster, only that cluster One context at a time: switching it in one browser tab switches every tab, and showing several at once is an open feature request. Installed in a cluster or with sign-in on, the context is set at startup. Radar Cloud shows several clusters under one address
Team sign-in OIDC, a pasted Kubernetes token, or an auth proxy such as OAuth2 Proxy OIDC, or an auth proxy such as OAuth2 Proxy, Pomerium or Cloudflare Access
What a signed-in person sees Every read and every change runs as that person, so their RBAC applies kind by kind Changes run as that person. Reads come from one cache that Radar fills as its own ServiceAccount, filtered by namespace: someone who may read Pods in a namespace also sees its ConfigMaps and Services. Secrets and cluster-wide kinds are checked kind by kind
Live updates Watches, pushed over WebSocket Watches, pushed as server-sent events
What is broken An Overview of every object with a problem, errors first and then the newest, with the likely cause and the change before it Issues: one ranked list of failing workloads, pods that can’t start, references to missing objects, and failed conditions on Argo CD, Flux and other resources
Logs Merged across a workload’s pods, previous run, search, JSON expansion Merged across a workload’s pods, with copy and download of the lines shown
Shells Pod exec, debug containers with a choice of image and target, node shells (opt-in), a shell on your computer (opt-in); split panes, broadcast, recording Pod exec, debug containers, node debug pods, and a terminal on the machine Radar runs on
Port forward Pods and Services, when KubeGlass runs on your computer Pods and Services, when Radar runs on your computer. In a cluster it shows the kubectl port-forward command instead, and can send a GET to an HTTP port from inside the cluster
Files Browse a container’s folders, download files and folders, and upload files of up to 256 MiB. A file goes either way in an image without tar A pod file browser that lists, previews text files and downloads; uploading is an open request
YAML Edit with a server-side dry run and a diff; a Secret’s or ConfigMap’s values decoded, one key at a time Edit with server-side apply and a check for changes made meanwhile; a dry run or diff before applying isn’t documented. A Secret’s values can be edited decoded where they are shown
Relationships A tree on each object’s page, and a map of a namespace, application or project that marks the chain leading to a broken object Topology: a graph of the cluster’s resources, with a Traffic mode that follows the network path
Change history Changes to Deployments, StatefulSets, DaemonSets, CronJobs, Services, Ingresses, ConfigMaps, Secrets and autoscalers while KubeGlass runs, field by field, with the field manager and the KubeGlass user who made them. From the first launch it also lists the rollouts, Helm releases and config writes the cluster’s own records hold from before. It lists those kinds, and Secrets for Helm, with KubeGlass’s own credentials: in every namespace, or in up to 25 namespaces when the credentials allow only some. Kept 30 days in the data directory (in a cluster, on a volume you give it). Revert after a dry run, or restore a deleted object A Timeline of events and every change it sees, with a diff, plus container restarts and exits, GitOps and Helm activity, while Radar runs. Kept in memory by default and lost on restart, or in SQLite or PostgreSQL. Reverting a change from it isn’t documented; workloads roll back to an earlier revision, and Helm releases have a history view, apart from it
Helm Releases, history, values, upgrade, rollback, uninstall and a chart catalog to install from Releases, history, values, diffs between revisions, failed hooks, upgrade to a chosen version, rollback and uninstall; installing a chart isn’t documented
Argo CD and Flux Built in: applications, sync, refresh, stop, roll back Built in: a fleet view, drift diagnosis, sync, reconcile, suspend and resume, and rollback for Argo CD
Argo Rollouts Built in: promote, promote full, abort, retry, restart Built in: promote, promote full, skip a step, retry, abort
Access review An access matrix for any user, group or ServiceAccount, who can do something, and a form for roles and bindings What a ServiceAccount may do, who is bound to a role, what a pod or workload could do if compromised, and your own permissions in a namespace. A matrix, “can I” queries and editing bindings are listed as later work
Metrics CPU and memory from metrics-server or Prometheus, PromQL, Alertmanager alerts and silences, rightsizing CPU and memory from metrics-server or a Prometheus-compatible backend; request rate, errors and latency from Beyla or Istio; rightsizing
Checks Best-practice checks, certificates, Trivy Operator reports, Gatekeeper and Kyverno violations, and an upgrade check 31 best-practice checks, TLS certificate expiry, Trivy Operator and Kyverno reports, and an upgrade impact check
Search A command palette that searches every namespace you may read, or every cluster, by name, label, image, state or IP address; a list’s filter also matches addresses, nodes and images A search of the whole cluster with kind:, ns:, label: and image: filters; a list’s search covers names, labels, annotations and status, with regular expressions
Keyboard k9s-style keys in every list, and a command palette with : for any kind j and k, l for logs, y for YAML, and g and a letter to change view
AI An MCP server with 41 tools that only read An MCP server whose tools can also restart, scale, apply and roll back, after the AI client asks; investigations of a failing resource with your own agent CLI
Telemetry None; OpenTelemetry tracing to your own collector if you turn it on Anonymous usage counts, off unless you turn them on

Choose Radar if

Section titled “Choose Radar if”
  • You want a desktop app as well as the browser UI.
  • You want costs from OpenCost or Kubecost, live traffic between services from Hubble, Istio, Caretta or Beyla, a view of Karpenter capacity, or a way to browse a container image’s files without running it. KubeGlass has none of these.
  • You want AI tools that can make changes, with the client asking first. KubeGlass’s MCP server only reads.
  • You want many clusters behind one address with SSO as a hosted service, and are willing to pay for Radar Cloud above three clusters.
  • You run very large clusters. Radar’s README says it is tested on tens of thousands of pods; KubeGlass hasn’t been tested at that size (see Performance).
  • You prefer the Apache-2.0 license.

Choose KubeGlass if

Section titled “Choose KubeGlass if”
  • You work with several clusters from one copy: every context in one list with its problems, and lists and search across clusters at once.
  • In a shared install, you want each person’s reads checked kind by kind, as kubectl checks them. Radar checks reads namespace by namespace.
  • You want the history to start before the tool did. On the first launch KubeGlass lists the rollouts it reads from ReplicaSets and ControllerRevisions, and Helm’s release revisions, with what it records; Radar’s Timeline holds what it saw while it ran. In a cluster the chart’s role gives KubeGlass the access that takes; on your computer it reads with your kubeconfig’s credentials, in up to 25 namespaces when they allow only some.
  • You want to revert a recorded change after a dry run, or restore a deleted object. KubeGlass keeps the history for 30 days, on disk by default when it runs on your computer; in a cluster, either tool needs a volume to keep it through a restart.
  • You review access: what any user or group may do, who may do something, and a form for roles and bindings.
  • You install Helm charts from a catalog, or want a dry run and a diff before applying YAML.
  • You want to upload files into a container. Radar’s file browser lists and downloads them; uploading is an open request.
  • You compare clusters, check them for drift on a schedule, or mark production clusters so that deleting or scaling to zero asks for the name.
  • You work from the keyboard the way you do in k9s, or sign people in with a pasted Kubernetes token.

Using both

Section titled “Using both”

Both read your kubeconfig and need nothing installed in the cluster when they run on your computer. Radar listens on port 9280 and KubeGlass on 8090, so they can run side by side against the same clusters. Installed in a cluster, each has its own ServiceAccount and Helm release.

Sources

Section titled “Sources”

Checked on 7 October 2026; files and Secrets on 9 October 2026.

Section titled “Related”
KubeGlass compared with other tools
KubeGlass vs Headlamp