The Problem
Kubernetes operators lack a single, local-first tool for day-to-day cluster visibility. kubectl gives fragmented views, commercial dashboards require cluster-side agents or cloud accounts, and debugging across topology, events, and traffic means juggling multiple tools. radar addresses this by providing a unified, real-time view of cluster state from a single binary with no cluster-side installation.
What This Does
radar is a Go-based Kubernetes visibility tool that runs locally and talks directly to the K8s API. It provides topology visualization, event timelines, service traffic views, resource browsing, Helm management, and GitOps monitoring for FluxCD and ArgoCD. The core lives in internal/k8s/ (client, cache, discovery, topology adapter) and internal/server/ (handlers for exec, logs, dashboard, GitOps). An MCP server in internal/mcp/ exposes cluster querying to AI assistants.
The project has two front-ends: a CLI (cmd/explorer/main.go) that opens a browser, and a native desktop app (cmd/desktop/) built with Wails. Both connect to the same backend server logic. In-cluster deployment is supported via a Helm chart in deploy/helm/radar/ with RBAC templates and optional ingress.
How To Use It
Setup — the quick install is a curl script (install.sh) that fetches a release binary. Homebrew, Krew, Scoop, and direct downloads are documented in the README. Building from source uses the Makefile and go.mod (Go 1.26+).
Configuration — the CLI reads kubeconfig context like kubectl. In-cluster deployments configure auth and RBAC via deploy/helm/radar/values.yaml. OIDC authentication is available through internal/auth/oidc.go.
Running it — the primary entry point is cmd/explorer/main.go:
curl -fsSL https://raw.githubusercontent.com/skyhook-io/radar/main/install.sh | bash kubectl radar
For in-cluster shared access:
helm repo add skyhook https://skyhook-io.github.io/helm-charts helm install radar skyhook/radar -n radar --create-namespace
Real-World Use
A platform team with multiple EKS clusters can run kubectl radar locally to inspect a misbehaving deployment: visualize the topology to spot networking issues, stream logs from internal/server/exec.go, inspect the container image filesystem via internal/images/inspector.go, and check Helm release status through internal/helm/handlers.go — all without installing anything on the cluster or exposing it to the internet.
Code Health & Issues
Med - Authentication complexity — internal/auth/ includes OIDC, revocation, and middleware; the README claims "no account" but in-cluster deployments need auth setup. Expect configuration friction here. Low - Desktop app platform-specific files (cmd/desktop/bootenvlinux.go, mouse_darwin.go) suggest OS-specific behavior that may be unevenly tested; only 22 test files across the codebase. Low - internal/cloud/ (client, conn, dialer, serve) hints at cloud connectivity features that contradict the "no cloud dependency" claim — worth clarifying what this does. Positive - CI workflows, CodeQL, dependabot, and a license are present. Tests exist for core packages (internal/k8s/, internal/auth/, internal/prometheus/).
The Bottom Line
radar is a well-architected, genuinely useful tool for Kubernetes operators who want fast, local cluster visibility without cluster-side agents. The zero-install approach and single-binary design are strong differentiators. It's best suited for developers and SREs who work across multiple clusters; teams needing multi-user shared access will need to evaluate the in-cluster Helm deployment and its auth setup.