# Radar - Full Documentation

> Radar is an open-source Kubernetes UI with a built-in MCP server for AI agents. See what's broken, why, and what changed.

## About Radar

Radar's Apache 2.0 Go binary runs locally against any kubeconfig or in-cluster with Helm. Its Issues and Applications views connect failures and workload health to topology, retained event and resource-change history, Helm, GitOps, live traffic, image inspection, and cluster audits. It also surfaces cost and capacity when OpenCost or Karpenter is detected. Radar Cloud extends the same model across clusters with up to one year of retention, SAML/OIDC SSO, scoped RBAC, and routed alerts.

### Core capabilities (open source, Apache 2.0)

- **Topology graph**: Live Kubernetes resource graph laid out by ELK.js, updated via SSE. Group by namespace, app label, or ungrouped.
- **Event timeline**: Every K8s event and resource delta, persisted past the kube-apiserver's default 1-hour TTL. In-memory or SQLite locally, with cloud-backed retention up to one year in Radar Cloud.
- **Image filesystem viewer**: Browse container image filesystems without pulling locally or running kubectl exec. Works with private registries.
- **Cluster audit**: 36 best-practice checks across security, reliability, and efficiency. Runs against cached cluster state.
- **Helm release manager**: Every release, every revision, every value file. Rollbacks from the UI.
- **MCP server for AI agents**: 23 read tools and 7 annotated write tools. Token-optimized output, RBAC-aware, secrets never exposed.
- **Diagnose with AI**: AI Kubernetes troubleshooting driven by the user's own agent CLI (Claude Code, Codex, or Cursor) - keyless, no account. Read-only investigation against Radar's live cluster model, root cause with a coarse confidence band, honest inconclusive verdicts, and an approval-gated fix that runs in a separate session. https://radarhq.io/product/diagnose

### Agent benchmark (measured, not claimed)

What the result is about: pre-correlated cluster context, not the MCP protocol. MCP is the connector an agent uses to reach a tool. An MCP server that only wraps kubectl returns the same raw YAML a shell does, with an extra hop, and should not be expected to beat kubectl. The measured gain comes from Radar answering out of a continuously maintained model of the cluster, so the agent asks one question instead of reconstructing the resource graph across many serial calls.

Radar's MCP server was benchmarked against raw kubectl on 54 paired fault scenarios from SREGym (Microsoft + UIUC), injected into real applications on a live 3-node EKS cluster. Both arms ran claude-sonnet-5; the Radar arm had kubectl blocked outright so it could not fall back to a shell. Grading used SREGym's own LLM judge at temperature 0 on the first diagnosis each agent submitted.

Results:
- Median time to a correct diagnosis, measured across the 44 faults both arms answered correctly so neither side's failures move its own number: 41s through Radar vs 154s on raw kubectl, roughly 4x sooner. Across every submission regardless of correctness it is 43s vs 220s.
- Across the 44 faults both arms diagnosed correctly, Radar answered sooner in 43.
- Pass rate 91% (49/54) vs 87% (47/54); mean diagnostic score 0.920 vs 0.889.
- Held to a 5-minute budget, which is what a real incident allows: 91% vs 56%. At 2 minutes: 83% vs 30%.
- Radar's slowest correct diagnosis was 4 minutes; kubectl's was 24 minutes.
- Mechanism: the kubectl agent spends 73% of the incident blocked waiting on the cluster; through Radar that is 6%. Diagnosis shifts from I/O-bound to model-bound, so faster models widen the gap rather than closing it.
- Radar lost 5 of the 54. Two patterns: evidence living inside a running process, which needs exec that Radar deliberately does not offer; and time-based detectors that had not warmed up when the agent asked, so it got a confident-looking answer too early.

Every scenario is replayable side by side, including the losses: https://radarhq.io/benchmark

### Kubernetes MCP server benchmark (five tool surfaces)

Radar also benchmarked four Kubernetes MCP approaches plus raw kubectl on a separate 25-fault SREGym sample: Radar MCP, containers/kubernetes-mcp-server, Flux159/mcp-server-kubernetes, k8sgpt MCP, and kubectl. Flux159/mcp-server-kubernetes is an independent repository and is unrelated to Flux CD. Every arm used the same claude-sonnet-5 agent, 3-node EKS, us-east-1, first-submission rule, and claude-opus-5 judge.

Median time to the first submitted diagnosis across all 25 faults:
- Radar MCP: 38.0s, 8 median tool calls
- Flux159/mcp-server-kubernetes: 61.5s, 14 calls
- containers/kubernetes-mcp-server: 64.3s, 14 calls
- raw kubectl: 72.4s, 8 calls
- k8sgpt MCP: 119.4s, 18 calls

Radar used 38% less time than the next-fastest MCP server and 48% less than kubectl across the full sample. Because the full-sample median includes misses, the page also shows the stricter 16-fault subset every arm diagnosed correctly: Radar 36.0s, containers/kubernetes-mcp-server 55.8s, Flux159/mcp-server-kubernetes 57.2s, kubectl 62.8s, and k8sgpt 91.0s. Radar leads in both views.

Most tools scored highly and the gaps are too small for a confident accuracy ranking. All 25 per-scenario timings, scores, verdicts, and tool-call counts are downloadable: https://radarhq.io/benchmark/kubernetes-mcp-servers

For the broader product decision, we rank the five servers across diagnosis usefulness, measured speed, safety, writes, operational coverage, installation, multi-cluster reach, and governance:
1. Radar MCP - fastest measured diagnosis, investigation work completed before the agent asks, explicit writes, and a path from local OSS to governed fleet access.
2. containers/kubernetes-mcp-server - the strongest standalone native Kubernetes API bridge, with multi-context support and a strict read-only mode, but more of the investigation is left for the agent to assemble.
3. Flux159/mcp-server-kubernetes - a broad kubectl and Helm control surface, but with more safety and governance work left to the operator. It is unrelated to Flux CD.
4. k8sgpt - useful codified analyzers, but a narrower general operational server and the slowest MCP arm in this benchmark.
5. Lens MCP - a capable read-only bridge constrained by a paid Lens plan and a running desktop app; it was not benchmarked.

That overall order is editorial, not a composite benchmark score, and we build Radar. Speed is measured separately; product facts link to primary sources: https://radarhq.io/kubernetes-mcp-comparison

### Radar Cloud (hosted)

- **Multi-cluster fleet view**: Search across every connected cluster from one bar. Compare workload versions side by side.
- **Long-term retention**: Cloud-backed event retention up to one year, plus 30-day audit log retention on Team and up to one year on Enterprise.
- **SSO and scoped RBAC**: SAML/OIDC SSO, SCIM provisioning, per-cluster or per-namespace scoped roles.
- **Routed alerts**: Slack, PagerDuty, MS Teams, webhooks. Per-cluster routing, in-app inbox, suppression windows.
- **GitOps visibility**: Native ArgoCD and Flux support. See sync state next to live resource state.

### Pricing

- **Cloud Free**: up to 3 connected clusters, unlimited users, full fleet views and cross-cluster search, shared links/views/annotations, saved investigations and incident snapshots, MCP access, included Radar AI usage (agent issue investigation), 24-hour timeline retention. Free forever.
- **Team**: $149 per cluster per month. Unlimited clusters, 2x AI agent usage, 3-day timeline / 30-day audit retention, advanced alert rules, fleet cost rollup, PagerDuty/Teams/webhooks, scoped RBAC.
- **Enterprise**: $299 per cluster per month, self-serve. Everything in Team, plus SAML & OIDC SSO + SCIM 2.0, 8x AI agent usage, 30-day timeline / 1-year audit retention + SIEM export, BYOC/self-hosted, priority support.
- **Custom**: Annual contract. Everything in Enterprise, plus volume pricing, air-gapped deployment, custom retention, custom IdP and data residency, custom AI usage and model configuration, 99.9% uptime SLA and a dedicated CSM.
- Plans purchased before the current pricing keep their price and features for as long as the subscription stays active (grandfathered); new pricing applies to new subscriptions only.

## Blog Posts

### Introducing Radar Cloud: Multi-Cluster Kubernetes Visibility for Teams

- **URL**: https://radarhq.io/blog/introducing-radar-cloud
- **Date**: 2026-05-28
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Announcements
- **Tags**: radar-cloud, kubernetes, multi-cluster, observability, launch


A platform engineer we talk to runs staging, two prod regions, and a handful of ephemeral preview clusters. She loves Radar OSS - she has it aliased to `r` on her laptop and uses it every day. But when her on-call teammate pings her in Slack at 1am asking "what does the topology look like right now in prod-us?", she has to either screenshot her own view or walk him through `kubectl` for the next twenty minutes.

The OSS tool works exactly as designed. One engineer, one cluster, one laptop. That's the product. But teams need something else: a shared view that doesn't vanish when someone closes their terminal, access controls that aren't "whoever has the kubeconfig wins", and a timeline that survives past the last restart.

That's what Radar Cloud is.

## TL;DR

Radar Cloud is the hosted extension of Radar OSS. Radar runs in each cluster, connects outbound-only over TLS to `api.radarhq.io`, and Cloud reverse-proxies browser requests through to it on demand. You get fleet views across every connected cluster, Google and GitHub sign-in on every plan (including Free) with SAML / OIDC SSO on Enterprise, Kubernetes-native scoped RBAC via impersonation, an org-scoped audit log, hub-side notifications for connection and billing events, and shareable deep links.

The control plane keeps no replica of your current cluster state - live Kubernetes state is the source of truth, read through the tunnel on demand. The timeline is the deliberate exception: Cloud retains event and change history so it outlives any single pod. Credentials stay in the cluster. Logs and exec stream on demand and are never stored at rest.

Free tier for up to 3 clusters. $149 per cluster per month on Team. Custom on Enterprise.

## What OSS can't do for a team

Radar OSS is a single Go binary that runs locally against your kubeconfig or in-cluster via Helm. That architecture is a feature: nothing leaves your machine, instant startup, no account required. It's the right shape for individual debugging, regulated environments, and air-gapped clusters.

It's the wrong shape for a team of eight engineers running twelve clusters.

Five things break once you scale past one engineer and one cluster:

- **No fleet view.** OSS talks to whatever kubeconfig context is active. Switching contexts is manual. There's no single screen that says "across all my clusters, what's unhealthy right now?"
- **No shared links.** If you spot a broken pod and want to point a teammate at it, the best you can do is a screenshot. There's no URL that opens the same view on their machine.
- **Whoever has the kubeconfig can do anything.** OSS respects your cluster RBAC, but it doesn't layer anything on top. There's no group-to-role mapping out of the box, no audit log of who did what.
- **No SSO.** Access is a kubeconfig file passed around however your team passes around kubeconfig files.
- **No connection-state notifications.** OSS shows you what's happening when you're looking. It doesn't tell you when a cluster has gone dark while you weren't watching.

Every one of those gaps is a thing we kept hearing from OSS users. Radar Cloud closes them without changing the OSS architecture or pulling features behind a paywall.

## A concrete before and after

Last month one of our early-access teams hit a cascading DNS failure that took out two services across their prod-eu cluster. Three engineers ended up debugging together across a two-hour window.

With OSS alone, every engineer was on a different laptop with a different kubeconfig context. Coordination was someone screenshotting their view into Slack, then someone else asking "is that prod-eu or prod-us?", then a fourth engineer joining and asking the same question.

With Radar Cloud, they all opened the same fleet view, picked prod-eu, and were inside the in-cluster Radar's live state - same Pods, same events, same topology. They sent a deep link to the cluster view to the SRE who joined forty minutes late, who clicked through and was looking at the right cluster's CoreDNS pods in two seconds, not asking "which cluster are we on?" again.

No heroics. Just: one URL, scoped access, and everyone looking at the same source of truth.

## What Cloud adds

### Fleet views

One dashboard across every connected cluster. Today's fleet views answer the questions that are painful one cluster at a time: which clusters have critical problems, where is a resource named `payments-api` running, which clusters still fail a specific audit check, which package versions are drifting. The views fan out to connected clusters over the tunnel and render progressively for large fleets.

Drill into any cluster and you're inside the same resource, topology, timeline, Helm, GitOps, and audit views you already know from OSS.

### Cross-cluster compare

Pick two clusters and diff the same resource side by side as YAML - the fastest way to catch the staging-vs-prod drift behind "but it works on the other cluster." It's wired into fleet search, so you can jump from a match straight into compare mode.

### Event timeline

Resource changes, Kubernetes events, Helm operations, and observed state transitions. Standalone Radar keeps this in memory, or in local SQLite when configured with a PVC. Cloud pulls the same feed over the existing tunnel and retains it centrally, so the history outlives any single pod - 24 hours on Free, 30 days on Team, 1 year on Enterprise.

### Single sign-on

Google and GitHub sign-in on every plan, including Free. Corporate SSO - SAML and OIDC (Okta, Entra ID, Google Workspace, OneLogin, and any spec-compliant provider) with self-serve setup - is available on **Enterprise**.

### Kubernetes-native RBAC via impersonation

Three Cloud roles (`owner`, `member`, `viewer`) map to standard Kubernetes ClusterRoleBindings (`admin`, `edit`, `view`) by default. The Cloud control plane injects `X-Forwarded-User` and `X-Forwarded-Groups`, and the in-cluster Radar pod impersonates the user when it talks to the K8s API. Whatever K8s RBAC permits, the user can do. Whatever it doesn't, they can't.

You override the defaults via two lines in `cloud.defaultRbac.*` in the Helm values. Per-user namespace-scoped RoleBindings work too, via the `cloud:user:<user_id>` group. There's no parallel permission system to maintain - it's K8s RBAC the whole way down.

### Audit log

Every authentication event, role change, scope change, cluster registration, and write operation through Cloud lands in an audit log. Tier-based retention: 7 days on Free, 30 days on Team, 365 days on Enterprise.

### Agent and MCP governance

Radar speaks the Model Context Protocol, so AI agents - Claude, Cursor, your own in-house bots - can read live cluster state through the same backend the UI and CLI use. Cloud adds the governance layer on top: a dedicated **Agents page** that inventories every agent and personal access token across the org, with activity status, so you can see exactly what has access and revoke anything stale.

Because an agent runs with a user's token, it inherits that user's Kubernetes RBAC - the same impersonation model as a human, no separate permission plane. And every tool an agent can call is marked **read-only or write** (apply, scale, exec are write), so a read-only assistant is never quietly confused with one that can mutate prod.

### Notifications

Hub-side notifications cover connection-state events (`cluster.disconnected`, `cluster.reconnected`), org membership events (`org.member.invited`, `org.member.joined`), and billing events. Configurable destinations are Slack and webhooks; there's also an always-on in-app inbox and per-user email preferences.

We're deliberately conservative on what gets pushed. The value is in the dashboard you already use, not a chatty Slack channel.

### Shareable deep links

Every view has a URL. Resource detail, filtered timeline slice, topology view, cluster view. Paste it into Slack, link it from an incident doc, bookmark it. The URL preserves filters and the cluster scope.

## Architecture

Radar Cloud is split in two: in-cluster Radar and a multi-tenant control plane.

![Radar Cloud architecture](/images/blog/radar-agent-architecture.png)

In-cluster Radar is the same Go binary as Radar OSS, deployed as a Deployment via Helm. It uses the `client-go` SharedInformer pattern - list once per resource type, then watch deltas. No polling, no periodic full scans.

**The connection is outbound-only.** Radar dials `api.radarhq.io:443`, negotiates TLS, upgrades to a WebSocket, authenticates with a cluster-scoped bearer token, and runs yamux for stream multiplexing on top. The cluster doesn't need a LoadBalancer, Ingress, NodePort, or inbound firewall rule. If your cluster can make an outbound HTTPS call to one FQDN, Radar works. This is the property that makes Radar tolerable to security teams.

Radar runs with a **scoped Kubernetes ServiceAccount**. Read-only by default. You opt into write features (logs, exec, Helm management, scale, restart) per-feature if you want to drive operations from the Radar UI.

**The control plane is a reverse proxy.** When a browser asks for cluster data, Cloud authenticates the user, opens a fresh yamux stream over the existing WebSocket, and forwards the HTTP request through to the in-cluster Radar pod, which serves it live from its SharedInformer cache. The Hub keeps no replica of your current Kubernetes objects. Live K8s state is the source of truth for anything you're looking at now.

**What the control plane does store:** org membership, roles, cluster registry metadata, audit log entries, PAT hashes, billing state, hub-native events (cluster.disconnected, member invitations, billing), and the retained event timeline - resource changes, Kubernetes events, and Helm operations pulled from the connected cluster, kept for 24 hours on Free, 30 days on Team, and 1 year on Enterprise.

**What stays in the cluster:** all cluster resources, including Secret and ConfigMap values. Logs, exec sessions, and port-forwards are streamed through the tunnel on demand only when a user opens them, and **are never stored at rest** on the Cloud side.

Each cluster is enrolled with a bearer token issued from the Radar dashboard. The raw token is shown exactly once at creation and stored only as a SHA-256 hash bound to the cluster record. An owner can rotate it at any time, which invalidates the previous hash and forces Radar to reconnect with the new value.

### Install

```bash
helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm repo update

helm install radar skyhook/radar -n radar --create-namespace \
  --set cloud.enabled=true \
  --set cloud.url=wss://api.radarhq.io/agent \
  --set cloud.clusterName=prod-us \
  --set cloud.token=$RADAR_CLOUD_TOKEN
```

The dashboard hands you this command with the token and cluster name already filled in when you enroll a cluster.

One minute from `helm install` to a cluster tile lighting up green in the fleet view. After that, you don't go back to Helm to stay current: when a cluster's in-cluster Radar falls behind, the dashboard flags it and upgrades the agent in place over the existing tunnel - one click, no second `helm upgrade`.

## A tour in five views

### Fleet

The landing page. Cards for every cluster you've enrolled, grouped however you want, with health, recent warnings, and drill-in. The view OSS users have been asking for since week one.

### Topology

The same structured-DAG topology from OSS, running at cluster scope. Ownership chains, Service routing, Ingress paths, ConfigMap and Secret references, HPA targets. Problem resources light up yellow or red.

One honest note: **topology in v1 is single-cluster.** You pick a cluster, you get its graph. Cross-cluster topology edges are on the roadmap but not in GA. We'd rather ship single-cluster topology that's correct than cross-cluster topology that fakes the edges.

### Timeline

The cross-source event view from in-cluster Radar - K8s events, resource diffs, pod lifecycle, GitOps reconciles, Helm operations - served live from the in-cluster pod. Filter by cluster, namespace, resource kind, or severity. Persists across pod restarts when the in-cluster timeline is configured with SQLite storage.

### Helm and GitOps

All Helm releases and Argo CD or Flux resources across every cluster. Status, chart version, app version, sync state, owned-resource health. Install, upgrade, rollback, uninstall, sync, reconcile - if Radar's ServiceAccount has write permissions in that namespace.

### Notifications

Hub-side notifications cover the events the control plane actually owns: cluster disconnect and reconnect, org member invites and joins, billing failures, free-tier cap. Destinations: in-app inbox, Slack, email preferences, generic webhook. Per-user toggles for which kinds you want to hear about.

This is deliberately a small surface. Routing every K8s event into chat is the way you end up muting the channel.

## What it costs

| Plan | Clusters | Audit log retention | Users | Auth | Notifications | SLA | Price |
|------|----------|---------------------|-------|------|---------------|-----|-------|
| **Free** | 3 included | 7 days | Unlimited | Google / GitHub | Slack, webhook, in-app | Best-effort | $0 |
| **Team** | Unlimited | 30 days | Unlimited | Google / GitHub | Slack, webhook, in-app | 99.5% | $149 / cluster / month |
| **Enterprise** | Unlimited | 365 days | Unlimited | SAML / OIDC SSO + SCIM | Slack, webhook, in-app | 99.9% | Contact us |

Enterprise adds 365-day audit retention, BYOC / on-prem deployment of the control plane, US or EU data residency, SCIM 2.0 directory sync, and a dedicated CSM. Annual contracts get 20% off the Team list rate.

Billing is per connected cluster, not per node or per pod. A 3-node dev cluster and a 300-node prod cluster cost the same on Team. That's deliberate - we don't want to penalize you for running bigger workloads, and the per-cluster cost to us doesn't scale linearly with cluster size.

## OSS vs Radar Cloud

| | Radar OSS | Radar Cloud |
|---|---|---|
| Install location | Your laptop or in-cluster Helm | Radar per cluster + hosted control plane |
| Clusters | One at a time | Aggregated fleet view across all connected |
| Timeline | In-memory or SQLite, in-cluster | Same in-cluster timeline, served live through reverse proxy |
| Auth | Local kubeconfig | Google / GitHub sign-in on every plan; SAML / OIDC SSO (Okta, Entra ID) on Enterprise |
| RBAC | Inherits kubeconfig | K8s impersonation - 3 default roles + per-user RoleBindings |
| Audit log | - | 7 / 30 / 365 days by tier |
| Notifications | None | Slack, webhook, in-app inbox (hub events) |
| Shareable views | No | Deep links per resource and view |
| Agent / MCP access | MCP server, single cluster | Same MCP, plus org-wide agent + token inventory and read-only/write tool labels |
| Price | Free forever | Free for 3 clusters, $149 / cluster / month Team, Enterprise custom |
| SLA | None | 99.9% on Enterprise |

## What we are not shipping in v1

This is the honest list. Some of these will land in the next two quarters, some we're still debating.

- **Cross-cluster topology edges.** Single-cluster topology only in v1. Cross-cluster topology and cross-cluster timeline are on the roadmap, not shipping today.
- **Custom dashboards.** The views are the views. You can filter and deep-link, but you can't build your own tiles or drag widgets around. In the design queue.
- **Long-term cluster-event archive.** We don't store your cluster events on the control plane at all - they live in the cluster, with optional SQLite persistence in-cluster. If you need a seven-year regulatory archive, ship events to your SIEM; we're not that system.
- **Self-hosted control plane below Enterprise.** The BYOC / on-prem deployment path is an Enterprise feature. If you need the Radar experience inside your own infra without an Enterprise contract, the path today is Radar OSS plus the in-cluster Helm deployment.

Radar Cloud is also not a metrics platform, not an APM, and not a log aggregator. It's a Kubernetes visibility plane. Prometheus, Grafana, Datadog, and your existing log backend keep their jobs.

## Why hosted when OSS exists

The obvious question: if Radar OSS is free and good, why build a paid hosted thing?

Because some things can't live on one laptop. SSO needs an identity layer. Org-scoped audit logs need a database. Notifications about a cluster going dark need a system that's awake when you're not. Cross-cluster aggregation needs a fan-in point. None of those belong in a local Go binary, and bolting them on would ruin the thing that makes OSS good.

So we drew the line cleanly.

**Radar OSS stays free, stays fully featured for single-cluster work, and keeps all the views it launched with.** We're not pulling topology behind a paywall. We're not crippling the Helm view. We're not adding a "cloud login required" nag screen.

**Radar Cloud is the thing you reach for when one laptop isn't enough.** The hosted backend is different code, the value is different. If that value is worth $149 per cluster per month to your team, great. If it isn't, OSS is still there.

That's the split. No bait-and-switch, no "community edition" with missing features, no mandatory sign-up to make OSS work. The two products serve different jobs.

## Getting started

Sign up at [radarhq.io](https://radarhq.io) and you get the Free tier immediately - 3 clusters, full SSO, unlimited teammates in your workspace. Enroll your first cluster with the Helm install above.

Full docs live at [radarhq.io/docs](https://radarhq.io/docs). The OSS source is linked from the docs site.

If you're already running Radar OSS and want to try Cloud on a single non-critical cluster, the install is drop-in. You don't have to choose.


---

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

- **URL**: https://radarhq.io/blog/radar-on-cloud-native-fm
- **Date**: 2026-09-17
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Open source
- **Tags**: radar, kubernetes, mcp, ai-agents, open-source


On September 16, 2026 I joined Saim Safdar on [Cloud Native FM](https://www.youtube.com/live/xgVTudkYXvE) 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:

<div className="not-prose my-8 aspect-video w-full overflow-hidden rounded-xl border border-black/5">
  <iframe
    className="h-full w-full"
    src="https://www.youtube.com/embed/xgVTudkYXvE"
    title="Cloud Native FM Ep 147: AI vs Kubernetes vs Dashboard - Where Does Radar Fit In"
    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
    allowFullScreen
  />
</div>

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](/blog/five-questions-you-cant-answer-with-kubectl), and ranked ourselves against everyone else, including where we lose, in [the 2026 dashboard comparison](/blog/best-kubernetes-dashboards-2026).

## 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](/blog/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](/blog/radar-mcp-vs-kubectl-benchmark) 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](/blog/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](/blog/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](/blog/what-were-building-in-2026-radar-oss-and-cloud), and everything that ships lands in the [changelog](https://radarhq.io/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.

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

Or `brew install skyhook-io/tap/radar`. Star it on [GitHub](https://github.com/skyhook-io/radar) if it earns it.

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


---

### Karpenter Troubleshooting: Pending Pods, Failed Launches, and Nodes That Never Join

- **URL**: https://radarhq.io/blog/karpenter-troubleshooting
- **Date**: 2026-09-05
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Engineering
- **Tags**: kubernetes, karpenter, autoscaling, scheduling, troubleshooting


[Karpenter](https://karpenter.sh/) changes how you debug a Pending pod.

A Karpenter NodePool can report `Ready=True` while the nodes it launches repeatedly fail to register. And that is only one reason these incidents can be confusing: the scheduler, NodePool, NodeClaim, NodeClass, and controller logs each hold a different part of the answer.

On a fixed set of nodes, Pending usually means the nodes you already have cannot take the pod. With Karpenter, there is another question: did Karpenter rule out every NodePool, or did it try to create capacity and fail?

This guide maps the failures we run into most often to the place I would look next. The screenshots come from Radar's Capacity view, the open-source tool we maintain, which assembles the same evidence from the cluster itself.

## Karpenter pending pods: symptom, cause, where to look

Scheduler messages usually arrive as `0/N nodes are available:` followed by a reason. That message is useful, but with Karpenter it is often only the first step.

| Symptom or message | Usual cause | Where to look |
|---|---|---|
| `didn't match Pod's node affinity/selector` | Pod requires a label no NodePool declares | NodePool `requirements` and `spec.template.metadata.labels` |
| `had untolerated taint {key: value}` | NodePool template taints the node, pod has no toleration | NodePool `spec.template.spec.taints` vs pod tolerations |
| `Insufficient cpu` / `Insufficient memory` | Existing nodes are full. Says nothing about what Karpenter could provision | Node allocatable vs scheduled requests, then Karpenter's scheduling event |
| Pod pending, no NodeClaim created | Every pool ruled the pod out, or NodePool limits are reached | Karpenter `FailedScheduling` event; `status.resources` vs `spec.limits` |
| NodeClaim created, no node appears | Launch failed, or instance launched and never registered | NodeClaim conditions for launch failures; `NodeRegistrationHealthy` for repeated registration failures |
| Nodes launch then disappear | Registration timeout | NodePool `NodeRegistrationHealthy` |
| Pod stuck with no scheduler attempt | Scheduling gate still present | `spec.schedulingGates` |
| Nodes not consolidating | Disruption blocked or budgets exhausted | `DisruptionBlocked` / `Unconsolidatable` events |

![The Capacity overview: capacity managers, the cluster scheduling bar, prioritized operational signals including "Node registration unhealthy" and "NodeClass not ready", and a node group inventory spanning two Karpenter NodePools and one EKS managed node group](/images/blog/radar-capacity-overview.png)

The important part is that these failures do not all live on the same object. A scheduling event can tell you why a pool was rejected, while a NodeClaim or NodePool condition tells you why capacity that should have appeared never did.

## "didn't match Pod's node affinity/selector"

This is a common Karpenter misconfiguration and one of the easier ones to identify from configuration alone.

Karpenter only applies labels that come from a NodePool's `requirements` or its template labels. If a pod requires a custom label that no NodePool declares, no node Karpenter builds will ever carry it.

![Radar's Demand view showing a blocked group headlined "No pool can take this group" because the Pod requires a node label the NodePool never declares](/images/blog/radar-capacity-demand-blocked.png)

In production this is often a stale label: a `workload-type` renamed during a migration, or a `nodeSelector` copied from another cluster.

Start with:

```bash
kubectl describe pod <pod>
```

Then compare the pod's selectors and required affinity against each NodePool's:

```
spec.requirements
spec.template.metadata.labels
```

If the label the pod requires is never declared by any NodePool, Karpenter has nowhere to place it.

Radar's Demand view does this comparison across all NodePools and groups pods with the same scheduling constraints together, but the underlying check is the same one you can do manually.

## "had untolerated taint" on a Karpenter cluster

Karpenter taints nodes from `spec.template.spec.taints` on the NodePool.

A pod without a matching toleration cannot land on anything that pool creates, so Karpenter can rule the pool out before provisioning even starts.

Compare:

```
NodePool.spec.template.spec.taints
```

against the pod's:

```
spec.tolerations
```

One thing to watch: startup taints are different from permanent taints.

Startup taints, along with the well-known unreachable/not-ready taints, are expected during parts of a node's lifecycle. They should not automatically be treated as evidence that the NodePool can never run the workload.

## LaunchFailed, VCPULimitExceeded, and InsufficientInstanceCapacity

If Karpenter creates a NodeClaim and the cloud provider refuses it, the useful evidence moves away from the pod.

Look at the NodeClaim lifecycle conditions.

Common AWS examples include:

- `VCPULimitExceeded` - the account's vCPU quota for that instance family is exhausted.
- `InsufficientInstanceCapacity` - AWS does not currently have capacity for that instance type in the requested region or zone.
- `Unauthorized` - the instance profile or IAM configuration is wrong.
- `LaunchFailed` - Karpenter reached the launch stage but could not create the instance successfully.

A detail that makes these annoying to debug: failed NodeClaims do not necessarily stay around forever.

Timed-out NodeClaims are deleted, and the conditions attached to them disappear too. Karpenter can surface repeated launch or registration trouble at the NodePool level through `NodeRegistrationHealthy`, but the individual history - which claims failed, how many, and in what order - can be harder to reconstruct afterward.

That is why events and controller logs matter for intermittent failures.

Radar's Activity view keeps a longer provisioning history, but even without Radar, the practical rule is simple: if you see a NodeClaim, inspect it before assuming the pod event contains the answer.

## Why aren't my Karpenter nodes joining the cluster?

This is one of the more confusing failure modes because the NodePool itself can still report `Ready=True`.

Karpenter tracks `NodeRegistrationHealthy` separately from the NodePool's top-level `Ready` condition.

That means the NodePool can be valid for provisioning, successfully launch instances, and still fail to produce usable nodes because those instances never register with the cluster.

The pattern looks roughly like this:

1. Karpenter decides the NodePool can satisfy the workload.
2. A NodeClaim is created.
3. The cloud instance launches.
4. The node never registers successfully.
5. The registration timeout is reached.
6. The instance is deleted.
7. Karpenter tries again.

From the workload side, the result is simple: the pod stays Pending and capacity never arrives.

From the NodePool side, `Ready=True` alone does not tell the whole story.

This is different from a broken NodeClass.

![The gpu-workloads NodePool detail page leading with two warnings - NodeClass Not Ready and NodePool Node Registration Unhealthy - each with a cause and a next step, above the capacity ledger](/images/blog/radar-capacity-nodepool-diagnosis.png)

For example, if an EC2NodeClass looks like this:

```
ValidationSucceeded=False
SecurityGroupsReady=False
SubnetsReady=False
InstanceProfileReady=Unknown
```

then the NodeClass itself is not ready. That propagates through `NodeClassReady`, so this is not a case where the NodePool remains happily `Ready` while nodes fail to register.

Typical NodeClass problems include selectors that resolve to no subnets or security groups, a missing instance profile, or another prerequisite that cannot be resolved before launch.

A `Ready=True` plus `NodeRegistrationHealthy=False` problem happens later: the NodeClass was valid enough to provision, but the resulting node never successfully joined the cluster.

Those two failures can look nearly identical from the pod's point of view, but they require looking in different places.

## Am I about to hit a NodePool limit?

Karpenter stops provisioning when a NodePool reaches `spec.limits`.

The pods that would have triggered more capacity stay Pending, and no NodeClaim is created for them.

Karpenter does tell you when this happens. Look for a `FailedScheduling` event containing messages such as:

```
node limits have been exhausted for nodepool
all available instance types exceed limits for nodepool
```

The number Karpenter checks is `status.resources`.

That matters because `status.resources` includes resources represented by in-flight NodeClaims. So:

```
headroom = limit - provisioned
```

not:

```
headroom = limit - allocatable
```

A NodePool can therefore be close to or at its limit even when relatively little capacity has successfully registered with Kubernetes.

The event tells you which pool hit its limit. To understand how much room is left elsewhere, compare `spec.limits` and `status.resources` across the other pools.

## Provisioned, allocatable, requests, usage: which number means what

These numbers answer different questions:

| Number | Source | What it tells you |
|---|---|---|
| Provisioned | `status.resources` | What counts against NodePool `spec.limits`, including in-flight claims |
| Node allocatable | Registered nodes | What Kubernetes can actually schedule onto now |
| Scheduled requests | Pod specs | What the scheduler has already committed |
| Actual usage | Metrics API | What workloads are consuming, not what can still be scheduled |

Karpenter and Kubernetes schedule based on requests, not current CPU or memory usage.

A node can be using 20% CPU and still be completely full from the scheduler's point of view if all of its CPU has already been requested.

That is why Radar keeps eight capacity values separate instead of reducing them to a single utilization percentage.

There is another subtlety: `unallocated` is only an aggregate subtraction.

If a cluster has 4 CPUs and 8 GiB of memory unallocated in total, that does not prove a pod requesting 4 CPUs and 8 GiB can fit. Those resources still need to exist together on a single node that also satisfies the pod's other constraints.

## What does DisruptionBlocked mean in Karpenter?

`DisruptionBlocked` and `Unconsolidatable` do not mean Karpenter disrupted a node.

They mean disruption was **prevented**.

Read either as disruption happening and the timeline reads backwards.

![An Activity episode reading "Karpenter disruption is blocked", tagged to nodepool/general-purpose and nodeclaim/general-purpose-def34, with the raw k8s event "DisruptionBlocked: Nodeclaim does not have an associated node"](/images/blog/radar-capacity-activity-blocked.png)

Common causes include:

- a disruption budget that is exhausted
- a PodDisruptionBudget that cannot be satisfied
- a `karpenter.sh/do-not-disrupt` annotation
- a NodeClaim with no associated node to disrupt

The raw event is usually the best place to start:

```
DisruptionBlocked: Nodeclaim does not have an associated node
```

Do not treat these events as evidence that Karpenter removed capacity. They are evidence that Karpenter considered a disruption and could not proceed.

## Why a pod evaluates as "unknown" instead of incompatible

When we built this evaluation into Radar, we found it useful to separate three cases:

- `declared compatible`
- `incompatible`
- `unknown`

The difference matters because configuration can prove some scheduling failures, but not all of them.

A required custom label that no NodePool declares is **incompatible**. Nothing the cloud provider does can fix that.

Provider-controlled labels such as zone, instance type, capacity type, and architecture are different. If the NodePool leaves them open, the provider's actual offerings may still satisfy the pod.

Requests are similar. Observed nodes can tell you whether a known machine shape is large enough, but they do not prove which instance types the provider could create next.

Radar therefore does not simulate provider offerings or claim that a compatible pod will schedule. It only says that the declared constraints do not rule it out.

If the available information cannot prove either outcome, the result is `unknown` instead of a guess.

## Why some numbers show ≥ or ?

Capacity information is not always complete.

For example, RBAC may prevent access to one source, or metrics may only be available for part of the fleet.

Radar marks that distinction explicitly:

| Glyph | Meaning |
|---|---|
| (none) | Exact - the source was fully observed |
| `≥` | Lower bound - only part of the source was observed |
| `≤` | Upper bound - derived from a lower-bound input |
| `?` | Unknown - the source was not observed |

Missing data is never shown as zero, and partial data is never shown as exact.

This matters during an incident because "0" and "I could not read it" are very different answers.

## What this doesn't cover

- **No full scheduling simulation.** Provider inventory, spot availability, and exact bin-packing remain Karpenter's job.
- **DRA demand is outside the normal requests ledger.** Dynamic Resource Allocation `ResourceClaims` can carry accelerator demand outside normal container requests.
- **No long-term trend analysis.** This is about current state and recent failure evidence.
- **Single cluster.** Same scope as the rest of Radar OSS.

Clusters without Karpenter can still be inspected through the normal node and node-group views. The Karpenter-specific Demand and Activity analysis depends on NodePools and NodeClaims being present.

## Running it

Radar is Apache-2.0, runs as a single binary, and does not install anything in the cluster:

```bash
brew install skyhook-io/tap/radar
radar
```

Capacity requires Radar v1.9.0 or newer.

You can open it from the sidebar or jump there directly from a stuck pod using "Evaluate against Karpenter NodePools".

If Radar reaches a verdict you can prove wrong, that's worth an [issue on GitHub](https://github.com/skyhook-io/radar).

Related reading: [Five Questions You Can't Answer With kubectl](/blog/five-questions-you-cant-answer-with-kubectl), [Everything Is Green and Nothing Works: Network Reachability in Radar](/blog/kubernetes-network-reachability), and [Kubernetes 1.37 Breaking Changes](/blog/kubernetes-1-37-breaking-changes).


---

### Kubernetes 1.37 Breaking Changes: What to Check Before You Upgrade

- **URL**: https://radarhq.io/blog/kubernetes-1-37-breaking-changes
- **Date**: 2026-08-26
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Engineering
- **Tags**: kubernetes, cluster-upgrades, kube-proxy, prometheus, radar


```yaml
# kubelet configuration - added for native sidecar support, harmless ever since
featureGates:
  SidecarContainers: true
```

Harmless until Kubernetes 1.37. The feature went GA in 1.33 and the gate has been a no-op even longer - and 1.37 removes it. A kubelet that finds a removed gate in its config doesn't warn, it refuses to start. On upgrade day that looks like new nodes going NotReady over a line nobody has touched since it was added. The same applies to a control-plane component carrying it in `--feature-gates`.

SidecarContainers is one of 25 gates removed in 1.37. Another 13 get locked to fixed values, and an explicit setting that contradicts a locked default fails the same way.

Kubernetes 1.37 was [released on August 26, 2026](https://github.com/kubernetes/kubernetes/releases/tag/v1.37.0). The gate removals are the sharpest edge, but not the only one: the release also drops 18 kubelet flags, kubeadm's v1beta3 config format, and an alpha scheduling API, removes a batch of metrics, changes what `eventRecordQPS: 0` means, and starts the kube-proxy move from iptables to nftables. The feature side of the release - KYAML output for kubectl, pod-level resources, and DRA device taints and tolerations going stable, among the 16 graduations - is covered in [the official v1.37 announcement](https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/); this post is about the upgrade side. All of it is in [the changelog](https://github.com/kubernetes/kubernetes/blob/release-1.37/CHANGELOG/CHANGELOG-1.37.md). The work is figuring out which of it exists in *your* cluster.

This post walks through each change and how to check for it by hand. If you'd rather not do that, Radar has a dedicated view for exactly this - Upgrade impact - which runs every one of these checks against your live cluster and reports what it found per change ([how to run it](#upgrade-impact-check-your-cluster-for-137-in-one-command)). Here it is on a GKE cluster:

<RadarScreenshot
  src="/images/blog/radar-upgrade-impact-k8s-137.png"
  alt="Radar's Upgrade impact view on a GKE cluster targeting Kubernetes 1.37: Admission webhook readiness, CRD conversion webhook readiness, and Node drain feasibility rows marked Blocked, plus the expanded kube-proxy mode transition check showing the finding 'Linux proxy mode is not explicit' with its impact, remediation, and the kube-system/kube-proxy DaemonSet as evidence"
/>

## What breaks in Kubernetes 1.37

The short version:

| Change in 1.37 | What happens on upgrade |
|---|---|
| 25 feature gates removed, 13 locked to defaults | Component rejects the setting and fails to start |
| `--concurrent-service-syncs`, `PodGroupWorkloadExists` admission plugin removed | Component fails to start |
| 18 kubelet cAdvisor flags removed | Kubelet fails to start |
| Static Pods referencing Secrets or ConfigMaps | The static Pod cannot start |
| `scheduling.k8s.io/v1alpha2` Workload and PodGroup dropped | Stored objects must be deleted before the upgrade |
| kubeadm v1beta3 configuration API removed | kubeadm rejects the stored config |
| `eventRecordQPS: 0` semantics change | Event rate limit silently lifts from 5/s to unlimited |
| SELinux mount-time labeling expands | Conflicting labels on shared volumes can leave Pods in ContainerCreating |
| API-server, DRA, and cAdvisor metric changes | Alerts and dashboards silently stop matching data |
| kube-proxy implicit mode | Warnings start in 1.37; the Linux default flips to nftables in 1.40 |

The first six rows are the ones to clear before upgrading: they can keep a component from starting or stop the upgrade itself. The rest change runtime behavior or monitoring, or set up work for 1.40.

## Feature gates, component flags, and kubeadm config removed in 1.37

Start with the gates, because they're the likeliest thing to actually be in your cluster. 1.37 removes 25 feature gates and locks 13 more to their defaults; the exact diff is in the official [feature lifecycle lists](https://github.com/kubernetes/kubernetes/blob/release-1.37/test/compatibility_lifecycle/reference/versioned_feature_list.yaml). A component started with a removed gate, or a locked gate set to a non-default value, refuses to start.

The removed set includes gates people actually set by hand: SidecarContainers, `JobSuccessPolicy`, `PodLifecycleSleepAction`, `SchedulerQueueingHints`. These sit in `--feature-gates` arguments and kubelet `featureGates` blocks for years because nothing ever complains about them. Until the release that removes them.

To check a node by hand, read its effective kubelet config through the API:

```bash
kubectl get --raw "/api/v1/nodes/$NODE/proxy/configz" \
  | jq '.kubeletconfig | {featureGates, eventRecordQPS}'
```

Two more removals fail the same way: kube-controller-manager's `--concurrent-service-syncs` flag, and the `PodGroupWorkloadExists` admission plugin. The plugin is rejected whether it appears in `--enable-admission-plugins` or `--disable-admission-plugins` - yes, *disabling* a plugin that no longer exists also keeps the API server from starting.

One removed gate carries a behavior change with it: `PreventStaticPodAPIReferences` is gone, and with it the opt-out that let static Pods reference Secrets and ConfigMaps. A static Pod that still does gets its node configuration rejected on 1.37 and cannot start.

In Radar's Upgrade impact report, the gate check reads every node's configz and every control-plane Pod's arguments (including split `command`/`args` forms) and names the exact gate on the exact node.

### 18 kubelet cAdvisor flags are removed

The kubelet loses 18 cAdvisor flags on top of that (`--enable-load-reader`, `--containerd`, the whole `--storage-driver-*` family; `--housekeeping-interval` survives). These are harder to audit than the gates. They live in systemd units and bootstrap scripts on the node itself, where no Kubernetes API can see them, so checking by hand means a pass over every node's kubelet startup arguments.

Radar can't see your systemd units either - nothing with only API access can - so instead of pretending the check passed, it hands you the list of 18 flags to grep for on your nodes.

### kubeadm v1beta3 is gone

On kubeadm clusters, the v1beta3 config format is gone too. If `kubeadm-config` in kube-system still holds v1beta3 documents, run `kubeadm config migrate` with a pre-1.37 binary *before* upgrading; kubeadm 1.37 won't accept the old format even to migrate it. The `PublicKeysECDSA` and `NodeLocalCRISocket` kubeadm gates go with it.

## scheduling.k8s.io/v1alpha2: delete stored objects before you upgrade

If you never enabled the alpha scheduling gates, skip this section. It doesn't apply to you.

For everyone else: 1.37 stops serving `scheduling.k8s.io/v1alpha2`, the alpha gang-scheduling API, as Workload and PodGroup [promote to v1beta1](https://github.com/kubernetes/kubernetes/pull/140184). The trap is the order of operations. Delete the stored v1alpha2 objects *before* the upgrade, then recreate them as v1beta1 after the control plane reaches 1.37 - and expect to update the manifests to the v1beta1 schema, not just the apiVersion line. Upgrade first and the stored objects block you. Recreate too early and v1beta1 isn't served yet.

Worth saying clearly: this is the only served API that 1.37 removes. Deployments, StatefulSets, Services - manifests that were valid on 1.36 remain valid on 1.37. (kubeadm's v1beta3 above is a config-file format, not an API the cluster serves.)

## eventRecordQPS: 0 now means unlimited

This one changes silently, which is why I'd check it even if you're confident about everything else.

```yaml
# kubelet configuration, valid on 1.36 and 1.37 - with different meanings
eventRecordQPS: 0
```

On 1.36, that zero doesn't mean what it looks like: it reaches client-go, which quietly substitutes its own fallback of 5 events per second. On 1.37, zero means zero throttling. The kubelet starts fine. Nothing warns. Every node carrying the setting just starts recording events as fast as it produces them. This was the one that surprised us most going through the changelog - nothing in the kubelet's own configuration surface hints that the zero was being overridden downstream.

The upstream recommendation is an explicit 50, the normal kubelet default - or 5, if you were deliberately relying on the old fallback. The `configz` command above shows the live value per node, and Radar flags every node whose effective config carries the setting.

## Removed metrics: cAdvisor series, DRA renames, API-server cache stats

None of the metric changes will block your upgrade. What they'll do is quietly break the dashboards and alerts you'd use to notice everything else on this page.

1.37 replaces the API-server cache-list metrics with `apiserver_storage_list_*{storage="watchcache"}` equivalents, renames DRA metrics, and drops several cAdvisor series: `container_cpu_load_average_10s`, `container_cpu_load_d_average_10s`, `container_tasks_state`, the custom `container_application_*` metrics, and `userDefinedMetrics` in the kubelet's `/stats/summary`.

The failure mode is silence. A PrometheusRule referencing a removed metric doesn't error; the expression just stops matching series, and the alert can never fire again. Grep your rules for the removed cAdvisor and cache-list names; the DRA renames are in the changelog:

```bash
kubectl get prometheusrules -A -o yaml \
  | grep -nE 'container_tasks_state|container_cpu_load(_d)?_average_10s|container_application_|apiserver_cache_list_'
```

Radar runs the same check against every PrometheusRule expression in the cluster and points at the exact expression and metric token. Where upstream removed a metric without a replacement, the finding says so rather than inventing one.

## kube-proxy mode: warnings in 1.37, nftables default in 1.40

Nothing about how kube-proxy moves traffic changes in 1.37. What starts is the countdown: the implicit Linux default flips from iptables to nftables in 1.40 ([KEP-5343](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/5343-nftables-to-default)), and IPVS mode begins a staged deprecation - expected disabled by default in 1.40 and removed in 1.43 ([KEP-5495](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/5495-deprecate-ipvs-mode-in-kube-proxy)). So 1.37 starts warning wherever the proxy mode is implicit.

That's the finding expanded in the screenshot at the top - "Linux proxy mode is not explicit", on the kube-system/kube-proxy DaemonSet, with both KEPs linked. The fix is one line: set the mode explicitly, iptables or nftables, after validating whichever backend you pick. Set it now and there's nothing left to do when 1.40 arrives.

## SELinux mount-time labeling applies to more volumes

This one only matters on SELinux-enforcing nodes. 1.37 makes more volume shapes eligible for mount-time labeling instead of recursive relabeling. Mounts get faster. But a volume shared by Pods with conflicting SELinux labels stops being slow-but-tolerated: the kubelet can mount it with only one context, and a Pod requesting a different label can hang in ContainerCreating.

The knobs are explicit. Align the SELinux label across every Pod sharing a volume, or set `seLinuxChangePolicy: Recursive` in the Pod's `securityContext` to keep the old behavior for that Pod. You can also defer the whole transition by setting the SELinuxMount feature gate to false on every kubelet, but that opt-out works for 1.37 only; the gate is expected to lock enabled in 1.38.

Radar warns on conflicts it can actually observe (kubelet mismatch metrics, SELinuxLabelConflict Events) and flags shared-volume setups that could conflict for review.

## Upgrade impact: check your cluster for 1.37 in one command

Everything above is public knowledge - most of this list came out of the changelog pass we did while updating Radar's checks for 1.37. What no changelog can tell you is whether *your* cluster has any of it: a locked gate in one node pool's kubelet config, a v1alpha2 object left over from an experiment, or a `container_tasks_state` alert nobody has looked at in two years.

That's what the Upgrade impact view is for. It ships in open-source Radar, with the check catalog updated for 1.37:

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

Then open Checks in the sidebar, switch to the Upgrade impact tab, pick 1.37 as the target, and find out whether `SidecarContainers: true` is still set somewhere in your fleet.

A few things about how the report behaves, because they decide whether you can act on it without re-verifying everything yourself.

### Radar checks the upgrade path, not just the target

Each check is bound to the release that makes it relevant, and only the ones your upgrade path crosses run. A cluster on 1.35 targeting 1.37 gets the 1.36 boundary checked too; a cluster already on 1.37 isn't nagged about gates it can no longer have. The release-specific checks land on top of the standing ones in the screenshot: admission webhook readiness, CRD conversion webhook readiness, node drain feasibility, removed API usage.

![Release-path gating: a cluster on 1.35 targeting 1.37 runs the 1.36 and 1.37 check groups, while the 1.38 group is skipped as beyond the target](/images/blog/kubernetes-1-37-release-path-gating.png)

### Every finding includes its evidence

Not "you may be affected by the cAdvisor removals" but the specific field on the specific object: a configz path, a container argument, a stored object's `apiVersion`, an expression inside a PrometheusRule. A blocker means Radar actually observed configuration or stored API that will reject startup or the upgrade. Warnings cover observed behavioral and monitoring impact. Review is everything that needs a human: the kubelet flags Radar can't read, the transitions you have to schedule.

### Unknown is not green

"Couldn't check" is never reported as a pass. When Radar can't inspect a surface, the result is Unknown, not green. On the GKE cluster in the screenshot, control-plane checks that need mirror Pods come back N/A, provider-managed: Google owns that surface, and you couldn't fix a finding there anyway. The same absence on a self-managed cluster is Unknown, because there the surface is yours. It's the same reasoning that shaped [Reachability's verdict semantics](/blog/kubernetes-network-reachability), and it's why the kubelet-flags check above gives you a grep list instead of a checkmark.

One more note for GKE, EKS, and AKS: on release channels, the control plane moves to 1.37 on the provider's schedule over the coming months, not yours. The provider-managed rows are their problem. The kubelet config, the workloads, the PrometheusRules, and the kube-proxy mode are still yours.

## Scripting it: the headless scan and MCP

If you'd rather stay in the terminal, the same scan is an HTTP endpoint on the same binary. This installs Radar, starts it headless against your current kubectl context, and prints every non-passing check for the 1.37 path:

```bash
curl -fsSL https://get.radarhq.io | sh   # skip if already installed
radar --no-browser &
curl -sf --retry 40 --retry-delay 3 --retry-all-errors \
  "http://localhost:9280/api/upgrade-readiness?target=1.37" -o scan.json
jq -r '"\(.currentVersion) -> \(.targetVersion)  verdict: \(.verdict)  (\(.summary.blocked) blocked, \(.summary.warnings) warnings, \(.summary.reviews) review)",
  (.checks[] | select(.status | IN("passed","not_applicable") | not)
    | "[\(.status)] \(.title) - \(.summary)")' scan.json
```

The retries cover startup and the first cache sync. Drop the `target` parameter to scan against whatever your cluster's next minor is. The full report - evidence paths, remediation, upstream references - lands in `scan.json`, and the process you just started is also the full UI at [localhost:9280](http://localhost:9280).

The same scan is exposed over MCP, so an AI agent can run the readiness pass and read the same evidence-backed findings ([MCP for Kubernetes](/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools) covers the pattern). The [upgrade impact docs](https://radarhq.io/docs/features/upgrade-impact) have the full check catalog, coverage semantics, and the read-only RBAC Radar needs.

However you run the checks, run them before the control plane moves. Many of these issues are quick fixes once you know where they are - a kubelet setting, a deleted object, an updated expression. The expensive version is discovering the same list on upgrade day, one NotReady node at a time.


---

### Everything Is Green and Nothing Works: Network Reachability in Radar

- **URL**: https://radarhq.io/blog/kubernetes-network-reachability
- **Date**: 2026-08-12
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Engineering
- **Tags**: kubernetes, networking, network-policy, troubleshooting, observability


A `checkout` Deployment listening on port 80, behind a Service that dials 8080:

```yaml
# Deployment: the port the container actually opens
ports:
  - containerPort: 80    # nginx listens here
---
# Service: the port it forwards to
ports:
  - name: http
    port: 80
    targetPort: 8080     # ...but the Service dials here
```

Nothing here is red. Pods are 2/2 Ready - no readiness probe consults a Service's `targetPort`, why would it. The Service is Active with endpoints listed. The Ingress has an address. No Warning events, because no controller considers anything wrong. `kubectl get` returns clean output on every object on the path, which is exactly why this class of bug survives the first twenty minutes of debugging.

Open the Service's Reachability tab:

![Radar's Reachability tab on the broken checkout Service: the headline reads "Unreachable via API server - real path not confirmed", and the Service hop carries the finding "Service targetPort likely wrong"](/images/blog/radar-reachability-first-hop.png)

Radar v1.9.1 adds that tab to Services, Ingresses, Gateways, and HTTPRoute/GRPCRoute. It traces the declared network path hop by hop, live-probes it, and names the first hop that breaks - here, **"Service targetPort likely wrong"**, from config analysis alone, before a packet moved. It's in the open-source version.

Read the headline again, though: *"Unreachable via API server - real path not confirmed."* Not "your service is down." That hedge is the most important design decision in the feature.

## Two layers, one question

The tab answers exactly one question about a network entry point:

> If traffic is sent toward this resource, does it reach a healthy process - and if not, which hop is the first to break?

Two layers answer it:

1. **A static trace**, always on. Ingress to Service to selected pods, route to parent Gateway, selectors, ports, readiness. Pure functions over Radar's in-memory informer cache - no API calls, typically under 100ms.
2. **An active test**: one round of real probes along the declared path - DNS, TCP, TLS where it applies, then HTTP for HTTP-shaped ports. The round is budgeted at 3 seconds, probes run in parallel, and each layer has a strict timeout (DNS 250ms, TCP 700ms, TLS 1s, HTTP 1s) so one dead hop can't starve the rest.

The path model matches how traffic behaves. Upstreams into a resource are parallel - a Service reached by two Ingresses isn't broken because one of them is, since the other still delivers traffic. Downstream is a chain, and the first critical finding along it is *the* broken hop; later findings still show, but the diagnosis starts where the failure starts.

Each hop carries the findings observable at that hop, and every finding comes with the kubectl that reproduces the raw state behind it:

```bash
kubectl describe service checkout -n shop
kubectl get pods -n shop -l app=checkout
```

You aren't being asked to trust a verdict. You're handed the evidence trail you'd have assembled by hand, already assembled.

## Where you test from changes the answer

A reachability result is meaningless without knowing where the request came from. It works from your laptop but not from the caller pod, or the reverse, and the difference *is* the bug.

So the vantage is first-class, drawn as its own lane on the graph. There are three:

- **Radar on your machine** - dialing as an ordinary client on your network
- **API-server proxy** - relayed through Kubernetes (`/services/{name}:{port}/proxy/`), which bypasses parts of the real traffic path
- **In-cluster probe** - a consent-gated, throwaway pod testing from the real dataplane, where NetworkPolicy and mesh mTLS actually apply

Selecting a vantage genuinely re-routes the graph and re-scopes the verdict; a laptop's success is never painted onto the in-cluster lane. And the vantages Radar *cannot* use - a request from one of your actual caller workloads, a genuine external client - stay visible as stated gaps rather than quietly disappearing, so a synthetic test never masquerades as full coverage.

Here's what that buys you. In the same namespace as the broken `checkout` Service, `payments` sits behind a NetworkPolicy named `payments-allow-checkout-only`:

![The payments Service reached via the API-server proxy with HTTP 200, while the headline stays explicit that this was not live traffic](/images/blog/radar-reachability-vantage.png)

The API-server proxy got an HTTP 200. Paint that green and you'd ship, and real callers would still fail, because the proxy's path is not your callers' path. So the headline reads *"Reached via API server - not live traffic (HTTP 200)"*, the inspector spells out what the 200 proves ("something is serving") and what it doesn't ("that the normal path works"), and the NetworkPolicy sits on the pods hop as a source-restricted advisory. Whether a caller gets through depends on who the caller is, which no synthetic probe can settle.

The three classic ways a probe lies to you are all vantage problems:

- **Service mesh mTLS.** Strict mTLS rejects any connection without a mesh client certificate. Your laptop doesn't have one. The probe fails while sidecar-to-sidecar traffic is perfectly healthy.
- **NetworkPolicy.** Policies are source-scoped. A policy can allow real workload traffic while blocking the probe's identity, or the reverse.
- **Split-horizon DNS.** A hostname that resolves inside the cluster may not resolve from your machine, or may resolve to something else entirely.

The rule for all three: a failure attributable to the vantage itself never sets the headline verdict. It annotates the hop, localizes the symptom, and leaves the verdict at *unknown* instead of condemning a path real traffic may well reach. We call it failing toward silence - better "couldn't confirm from here" than a 2am false alarm about a service that's fine.

## The rules that keep it honest

The same principle, in four more places.

**Verdicts are coverage claims, not vibes.** Each tested route carries an `outcome` (verified, reached, server-error, unreachable, not-tested) and a `confidence` (real traffic vs. indirect relay). Those roll up into the resource verdict, and only a real-traffic result can set it. Reached only via the API-server proxy rolls up to *unknown*, never to a confident green.

**Non-HTTP ports get non-HTTP tests.** A Redis or Postgres Service gets an honest TCP connection test, not a fabricated HTTP request thrown at a database port, and the result states its own ceiling:

![redis-master after an in-cluster TCP test: "Reachable - server reached, route not verified", with the coverage line stating that only TCP connections were checked](/images/blog/radar-reachability-redis-tcp.png)

*"Reachable - server reached, route not verified"*, footed by *TCP connections only - application protocol not checked*. The transport works. Nothing beyond that is claimed.

**NetworkPolicy is predicted, never enforced by Radar.** The static layer evaluates the caller-independent ingress rules of policies selecting the subject's pods and surfaces a would-block as a *prediction*, because the CNI is the only authority on enforcement and some CNIs store the NetworkPolicy object while enforcing none of it. The in-cluster probe then confirms the prediction or downgrades it when real traffic got through.

**Skipped checks say why.** A route that couldn't be tested from a given vantage shows as skipped with the reason, per vantage, instead of quietly vanishing from the report.

And the lines it won't cross:

- **No external-path probing for LoadBalancer / NodePort.** Modeling cloud load balancer state honestly is its own problem; pretending to have solved it would produce exactly the false confidence this feature exists to kill.
- **No CNI-specific enforcement modeling.** Prediction plus live confirmation, as above.
- **No Traefik IngressRoute, Istio VirtualService, or Knative resolution yet.** Each needs its own path logic, and guessing produces wrong graphs.
- **No new CRDs, no agents to install.** Everything reads the same informer cache as the rest of Radar, and active probes are one-shot actions you trigger, not a polling loop.

Nor does a probe pod land in your cluster unless you click the button. The in-cluster test is consent-gated, and the dialog names the exact requests before it runs - one short-lived, self-deleting Job per request, under the target namespace's ServiceAccount. If your RBAC denies pod creation, Radar falls back to a copyable kubectl command instead of failing mysteriously. (Why "read-only plus explicit, visible actions" is the right shape for cluster tooling is [a post of its own](/blog/read-only-is-not-a-safety-boundary).)

## How this compares

| Approach | What it gives you | The catch |
|----------|-------------------|-----------|
| kubectl checklist + netshoot | Ground truth, eventually | You're the correlation engine; 8-10 commands and a mental model of the path |
| Hubble (Cilium) | Per-flow verdicts with drop reasons, from eBPF | Requires Cilium as your CNI; observes traffic that happened rather than testing a declared path on demand |
| Calico policy tooling | Policy impact analysis and packet capture | Calico-specific, policy-scoped |
| Kubeshark / tcpdump | Full packet-level truth | Heavy to run; you still reconstruct the path and the intent yourself |
| Radar Reachability | Declared path traced and live-probed from explicit vantages, first broken hop named | Won't model cloud LB paths or CNI enforcement - and tells you so instead of guessing |

[Hubble](https://docs.cilium.io/en/stable/operations/troubleshooting/) is the one that composes rather than competes: Radar names which hop of the declared path breaks and from where, Hubble tells you what the datapath did to individual packets. Flow observability needs traffic to observe; a reachability test manufactures its own evidence on demand, against the path the config *declares* - including the hops where no traffic is flowing precisely because they're broken.

The other difference is scope. Everything above except the manual checklist ties you to a specific CNI or a capture stack. The Reachability tab is CNI-agnostic because it stays out of the enforcement-modeling business.

## Agents get the same trace

Everything the tab shows is what Radar's MCP server returns. Point the general-purpose `diagnose` tool at a network entry kind and it returns the reachability trace in one call; `probe: true` adds the active test, `inCluster: true` runs it from the real dataplane under the caller's RBAC.

The verdict semantics matter more for agents than for humans, because agents key actions on results. The per-route `outcome` and `confidence` fields exist so an agent can tell "verified over real traffic" from "reached via proxy, real path untested" instead of pattern-matching a coarse healthy/broken flag. We wrote about the general pattern in [MCP for Kubernetes](/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools).

## Try it

Reachability shipped in [Radar v1.9.1](https://github.com/skyhook-io/radar/releases/tag/v1.9.1), in the open-source version, not behind a paid gate. If you already run Radar, open any Service and hit the Reachability tab - the API-server proxy test runs automatically. If you don't:

```bash
brew install skyhook-io/tap/radar
radar
```

Point it at a kubeconfig, open a Service that's been quietly bothering you, and see which hop answers. The [changelog entry](https://radarhq.io/changelog#reachability-network-path) has the release details, and the [design doc](https://github.com/skyhook-io/radar/blob/main/docs/reachability.md) covers verdict semantics, RBAC requirements, and probe image resolution in full.

kubectl can tell you everything about any one object on the path. What it can't tell you is [how the path composes](/blog/five-questions-you-cant-answer-with-kubectl) - and the network path is the composition question you get paged about.


---

### Kubernetes Events Expire in an Hour. Your Incidents Don't.

- **URL**: https://radarhq.io/blog/kubernetes-event-retention
- **Date**: 2026-08-01
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Engineering
- **Tags**: kubernetes, events, observability, radar-cloud, open-source


**TL;DR.** Kubernetes deletes events quickly, after the default one-hour TTL, and they never capture many of the changes that cause incidents: image updates, ConfigMap edits, resource-limit changes. Radar's open-source binary watches both events and resource changes, merges them into one timeline, and retains that history in SQLite - on local disk, or on a volume when you run it in-cluster. Radar Cloud retains the same timeline centrally, so it survives pod, disk, and cluster loss without keeping a cached copy of live cluster state.

The incident started at 02:14. You are reading the thread at 09:30, and someone asks the only question that matters: what was the cluster doing when the pods started failing?

```bash
kubectl get events -n payments --sort-by=.lastTimestamp
```

Fourteen lines. All of them from the last twenty minutes. Nothing from 02:14.

This surprises people the first time, and then it keeps surprising them, because nothing in the output tells you that history was deleted. The events aren't hidden or filtered. They are gone.

## Events are garbage collected on purpose

A Kubernetes Event is an API object like any other, stored in etcd, and the apiserver expires it on a TTL. The flag is `--event-ttl` and it defaults to `1h`.

That default is not an oversight. Events are the chattiest objects in the API: a single crashlooping pod produces a steady drip of them, a rollout produces a burst per replica, and a misconfigured controller can produce thousands a minute. All of that lands in etcd, which you want small, fast, and boring. Clusters big enough to feel the pressure often route events to a separate etcd instance (`--etcd-servers-overrides`) for exactly this reason.

So the flag exists, and on a self-managed control plane you can raise it:

```bash
# kube-apiserver, self-managed control planes only
--event-ttl=24h
```

Two problems with that as a plan.

**You probably can't set it.** EKS, GKE, and AKS don't hand you apiserver flags. If your control plane is managed, the retention window is your provider's decision, not yours.

**It buys less than you think.** Events are lossy before they ever reach etcd. Similar events collapse into a single object with a `count` field and updated timestamps, so a pod that failed its probe 400 times is one row, and "when exactly did this start happening" gets fuzzy. Client-side spam filtering drops events from noisy sources under load. And the object you care most about may have emitted nothing at all.

That last point is the real one, and it has nothing to do with TTLs.

## Much of what you need was never an event

Ask what changed before the outage. In practice the answer is usually one of these:

- the image tag moved from `v1.9.0` to `v1.9.1`
- someone raised a memory limit, or lowered it
- a ConfigMap was edited in place
- a Service selector was retargeted
- a HorizontalPodAutoscaler's `minReplicas` changed

None of those emit an event describing the change. Kubernetes records events when a *controller decides to say something* - scheduled, pulled, failed, backoff, evicted. It does not maintain a change log of your objects. `resourceVersion` moves, and on most kinds `metadata.generation` increments, but the previous state is not kept anywhere. Once the write lands, the old spec is gone unless something was watching.

This is why "turn up the event TTL" never actually closes the loop. You would be retaining more of the symptom and none of the cause.

## The usual workarounds, and where each one stops

| Approach | What it answers | Where it stops |
| --- | --- | --- |
| `kubectl get events` | What a controller complained about, in the last hour | Expires, aggregates duplicates, no resource changes, no cross-restart history |
| Event exporter to Loki / Elastic / a SIEM | Long-term searchable event text | Still only events. Text records, not object state - you get the message, not the diff. Correlating back to a workload is a query you write yourself |
| Kubernetes audit log | Who called what API, with the request body | Off, or landing somewhere nobody reads mid-incident, on most managed clusters. Expensive at volume, and shaped for compliance rather than debugging. Answers "who changed it," not "what did it look like before" |
| kube-state-metrics + Prometheus | Numeric time series: replicas, restarts, phase over time | Metrics, not objects. You can see restarts climb; you cannot see the manifest that caused it |

Each of these is a reasonable thing to run, and most teams end up running two or three. The gap is that none of them gives you the one artifact you want during an incident: a single chronological view of everything that happened to *this workload*, with the events and the actual configuration changes side by side.

## Watch the objects, not just the complaints

If you want resource changes, something has to observe them as they happen. That is what informers are for. Watch a kind, keep the last observed state per object, and when a new version arrives, diff it. The apiserver never stores the old spec, but a process that was watching has it.

That is how Radar builds its timeline. It merges, per resource and cluster-wide:

- Kubernetes events, indexed and searchable rather than TTL'd away
- resource changes, with a structured field-level diff between versions
- pod lifecycle: starts, restarts, exits, OOM kills
- Helm operations - install, upgrade, rollback, uninstall
- GitOps activity: Argo and Flux reconciliations and their outcomes
- audit-check transitions, when a resource starts or stops failing a check

Merged into one stream, that answers "what happened at 02:14" without asking you to join four systems by hand.

All of that lives in the open-source binary. The informers, the diffing, the merged stream, the storage, the UI you read it in - Apache 2.0, running in your cluster, no account required. Worth being clear about before the next two sections, because retention is one of those capabilities tools usually reserve for the paid tier. Here it isn't a capability that gets unlocked; it's the same store either way.

What differs is the ceiling. In the cluster, history is bounded by the volume you gave it and it answers for that cluster only. Radar Cloud raises both ceilings: the history is no longer bounded by one cluster's disk or lifetime, and it can be queried across the fleet. Depth and reach, not features.

![Kubernetes API watched by Radar informers, merged into one timeline, persisted to memory or SQLite in the cluster, then pulled over the existing tunnel and retained centrally by Radar Cloud](/images/blog/kubernetes-event-retention-flow.png)

## Keeping it locally: memory, then SQLite

Radar OSS is a single Apache 2.0 binary, and by default the timeline lives in memory - fast, zero setup, and cleared the moment the process exits. That's the right default for a laptop and the wrong one for a shared install.

Point it at SQLite and history survives restarts:

```bash
radar --timeline-storage=sqlite \
      --timeline-db=$HOME/.radar/timeline.db \
      --timeline-retention=720h \
      --timeline-max-size=8Gi
```

`--timeline-retention` defaults to 7 days and `--timeline-max-size` to 1Gi, so out of the box you get a week of history bounded by a gigabyte of disk. Both are budgets, not guarantees: whichever ceiling you hit first prunes the oldest events.

In-cluster, the same thing needs a volume that outlives the pod:

```yaml
timeline:
  storage: sqlite
  dbPath: /data/timeline.db
persistence:
  enabled: true
  size: 20Gi
```

This is genuinely useful and it is where most teams should start. The limits are the concrete ones: lose the PVC and you lose the history, decommission the cluster and the history goes with it, and ["what happened across our fleet last Tuesday"](/blog/the-fleet-visibility-gap) is still five separate lookups.

## Retaining history centrally, without caching live state

Radar Cloud retains that history centrally. The interesting part is how it gets there, because we had a constraint: Radar Cloud [does not keep a server-side replica of your live cluster state](/blog/why-radar-cloud-doesnt-cache-your-cluster-state). Live views reverse-proxy to the Radar pod in your cluster and read the truth from the API server. We were not going to quietly break that to add history.

The distinction we landed on is between *state* and *record*. A cached copy of your live state is a liability: it goes stale, it lies during exactly the incident you need it for, and it is a copy of your cluster sitting in someone else's database. A record of events that already happened has neither problem. It cannot go stale, because it describes the past.

So the control plane pulls, and it pulls the same history Radar already keeps:

**It rides the tunnel you already have.** The connected Radar pod holds one outbound WebSocket to the control plane, which is how the UI reaches it. The puller opens a stream on that same tunnel and reads the same endpoint the browser reads. No second agent, no inbound access, no new egress rule.

**It pulls the existing timeline rather than caching live state.** Nothing here mirrors your current cluster. The control plane copies a record of events that already happened, and live views keep reverse-proxying to your cluster for anything that describes now.

**Gaps are recorded, not hidden.** When Radar's store is recreated by a pod restart, the puller detects it and writes an explicit coverage record for the window it wasn't watching. An unmarked gap renders as *nothing happened*, which during a postmortem is not a missing answer but a wrong one.

**Reads stay inside your cluster's RBAC.** When you read retained history, the control plane asks *your cluster* which namespaces you can see, using your identity and the same computation Radar performs for the live view. No permission data is persisted. If the cluster is unreachable and nothing recent is cached, the read is denied rather than served wide.

The delivery mechanics underneath, including how the pull cursor doubles as the acknowledgement and how late-arriving events land at their historical position, follow the same pull-not-push shape described in [the Radar Cloud architecture post](/blog/why-radar-cloud-doesnt-cache-your-cluster-state).

The client contract is identical to the local binary's: the browser loads one window of events, then polls for what arrived since, and every zoom and pan resolves against what it already has. The timeline API and UI stay the same. What changes is where the history is stored, how long it survives, and how broadly you can query it.

## What this is not

**It is not a SIEM, and we are not trying to be your system of record.** This is incident-shaped history: deep enough to cover the postmortem, the regression that showed up a week later, the "when did this actually start" question. If you need multi-year archives, immutability guarantees, or one searchable store spanning every system you run, keep shipping events to your log backend. That is a different job.

**Retention starts when you turn it on.** There is no backfill of history that nobody was watching. Today is the earliest you can start.

**A long disconnect can still cost you.** The local store is the buffer, so if the control plane can't pull for longer than that store's retention window, the oldest events are pruned before they're read. Known disconnects show up as coverage gaps.

**Fail-closed cuts both ways.** History for a cluster that has been disconnected for a long time is readable only by users whose access scope was verified recently. That is the correct default for a permission check, and it does mean a decommissioned cluster's history is not freely browsable. Namespace-restricted users also don't see cluster-scoped events, which have no namespace to match against.

## Common questions

### How long does Kubernetes retain events?

One hour, by default. Events are API objects in etcd and the apiserver expires them on the `--event-ttl` flag, which ships set to `1h`. The window is a configuration choice, not a property of Kubernetes, but it remains the common default.

### Can you increase event retention on EKS, GKE, or AKS?

Generally, not through the managed control plane. `--event-ttl` is a kube-apiserver flag, and managed services do not normally expose those flags. On a self-managed control plane you can raise it, at the cost of more pressure on etcd. Either way you keep events longer without gaining any record of what changed.

### Do Kubernetes events record ConfigMap and Deployment changes?

Not the change itself. Events capture what a controller chose to report, such as scheduling, pulls, probe failures, and evictions. A new image tag, an edited ConfigMap, or a raised memory limit produces no event describing the diff, and the previous state is not retained anywhere once the write lands.

### How does Radar retain Kubernetes history?

Radar watches resources through informers and diffs each new version against the last, so it records changes as well as events, merged into one timeline. That store is in the open-source binary: memory by default, SQLite when you point it at a database. Radar Cloud pulls the same history over the cluster's existing tunnel and retains it centrally, so it survives the volume, the pod, and the cluster.

## Where to start

If you run Radar OSS today, the highest-value ten minutes you can spend is switching the timeline to SQLite, giving it a PVC, and setting a retention budget you can afford. That alone moves you from "one hour of events" to a real month of history, in one command.

```bash
radar --timeline-storage=sqlite --timeline-retention=720h --timeline-max-size=8Gi
```

The full set of storage flags is in the [timeline docs](https://radarhq.io/docs/features/timeline), and the Helm values for a persistent in-cluster install are in the [in-cluster deployment docs](https://radarhq.io/docs/configuration/in-cluster). Missing history is one of [five questions you can't answer with kubectl](/blog/five-questions-you-cant-answer-with-kubectl); the others have the same shape.

When one cluster's disk stops being the right place for that history - because you have six clusters, because the postmortem is about a cluster that no longer exists, or because the people who need the answer shouldn't be reaching into the cluster to get it - [Radar Cloud](https://radarhq.io) retains it for you, over the tunnel you already have open.

The apiserver will keep deleting events after an hour. That's its job. Remembering them is somebody else's.


---

### We Build a Kubernetes Dashboard. AI Agents Might Make It Obsolete.

- **URL**: https://radarhq.io/blog/dashboards-in-the-agent-era
- **Date**: 2026-07-28
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Platform
- **Tags**: radar, ai-agents, kubernetes, dashboards, observability


We build a Kubernetes dashboard, so let me argue against my own product for a minute, because if the argument holds I'd rather hear it from me than from a competitor.

It goes like this. For years the reason you opened a dashboard was that a cluster is too much state to keep in your head, and you needed something to draw it so you could look. An agent doesn't look. It reads structured data, reasons over it, and increasingly acts on it. If the agent is doing the operating, then a dashboard is a horse in 1910 - still useful, clearly on the wrong side of the trend. Every hour of operations that moves into an agent is an hour nobody spends in our UI.

I think that's half right, and the wrong half is the interesting one. This isn't the [agent-vs-UI-vs-CLI question we wrote about in June](/blog/agent-or-ui-false-choice-kubernetes-operations), which was about which surface you reach for today. It's the harder version: if agents keep climbing the [autonomy ladder](/blog/ai-agent-autonomy-levels-kubernetes), what is a dashboard even for in three years?

**TL;DR.** The bear case is real, and it kills one specific dashboard - the one you click through to run the cluster by hand. But as agents take over the operating, the job that grows is supervising: verifying, approving, auditing, and rebuilding your bearings at 3am when an agent hands you something strange. That job needs a purpose-built visual surface as much as flying ever did. The dashboard doesn't die. It flips from the cockpit you fly to the tower you watch from.

## The bear case, made honestly

I'm not going to strawman this, because the people making it are serious and some of the evidence is ours.

Satya Nadella [said in late 2024](https://www.windowscentral.com/microsoft/hey-why-do-i-need-excel-microsoft-ceo-satya-nadella-foresees-a-disruptive-agentic-ai-era-that-could-aggressively-collapse-saas-apps) that business applications "will all collapse in the Agent Era," because most of them are a database with some business logic on top, and the logic is moving up into an agent tier. Andrej Karpathy, in a [talk I'd actually recommend](https://www.latent.space/p/s3), framed agents as a third consumer of software alongside humans and other programs - one that doesn't want your GUI, because a screen built for eyes is a bad way to feed a model. And I can't wave away our own numbers: when we [benchmarked an agent against raw kubectl on 54 cluster faults](/benchmark), the agent reasoning over structured cluster data diagnosed better and got there about four times sooner. Agents genuinely don't need pixels to make sense of a cluster. They need structured state, which you can hand them without ever drawing a graph. We proved that on our own blog.

Put the autonomy ladder on top and the erosion gets concrete. Every verb a team lets an agent handle unattended is one less reason to open the dashboard, and if enough of them move, the daily click-path - check the pods, scan the events, restart the stuck one - just evaporates. The strongest version of this story already had its news cycle, when Klarna announced it was dropping Salesforce and Workday because AI would replace them. It made every headline. The quieter follow-up didn't: the products did go, but the work they held didn't dissolve into a chat window - it got rebuilt across internal systems, and the CEO spent the next year walking back how much of the company AI could actually run on its own. Hold onto that, because the walk-back is where the real answer lives.

## What actually dies

Some of the dashboard genuinely is going away, and I'd rather name it than pretend our whole surface is safe.

The resource browser as a daily workflow is dying. The endless list pages were never the good part anyway; they were the price of not having a better way to ask. Click-ops - the muscle memory of navigating four screens to restart a Deployment - is dying and mostly deserves to. And the worst version of a dashboard, the one you keep open because you might miss something, is dying fastest of all. Charity Majors, who co-founded an observability company, [called this out back in 2021](https://charity.wtf/2021/08/09/notes-on-the-perfidy-of-dashboards/): every dashboard is an answer to some question you've since forgotten, and staring at one waiting for trouble is pattern-matching, not debugging. She was careful about her target, though - static dashboards, the frozen kind, explicitly not the interfaces you can interrogate - and that distinction is going to matter in a minute. On the static kind she was right then, and an agent that actually watches the cluster for you makes the watch-it-yourself dashboard indefensible. If a dashboard's whole pitch is "a nicer place to do by hand the things an agent will soon do for you," the bear case eats it, and it should. Ours included, to the degree that's what ours is.

## But look at what the agent companies actually ship

Here's the tell. The teams furthest ahead on operational AI agents are not shipping a chat box and stopping there. Look at what their agents produce. Datadog's incident agent, the first one they made generally available, resolves an incident by rendering an investigation page: each hypothesis marked validated or ruled out, the root cause laid out with the evidence behind it, and citations you can click to check the reasoning before you trust it. That's not a transcript. It's a dashboard, built so a human can verify the agent at a glance. And OpenAI - whose own leadership argues apps will collapse - extended the Model Context Protocol specifically so agents can draw interactive interfaces inside the chat. When the people building the agents keep building visual surfaces to sit on top of them, that isn't a coincidence to explain away. It also isn't proof that agents need pixels to function, because they don't. It's evidence about the other end of the loop: nobody has yet figured out how to get a human to trust an agent's work without showing it.

Three things, specifically, don't go anywhere.

## One: eyes are parallel, transcripts are serial

A lot of what a good visualization does happens before you're even conscious of looking. A red cell in a field of green pops out in under a quarter second no matter how many green cells surround it, because your visual system checks the whole field at once instead of walking it item by item. That's the deal a well-drawn wall of state offers: hundreds of signals scanned in parallel, the anomaly handed to you before you've decided to look for it. A chat transcript is the opposite: one token after another, in a line, with the picture left for you to assemble.

Meanwhile a big context window is not the same as reliable use of everything in it. The research on this is consistent enough that I'll spare you the citation parade: models can miss or underweight what's buried in a long input well before the window is full, which is exactly why well-built agents don't swallow the cluster wholesale - they query for the relevant slice. But notice what that workaround concedes. The fix for the agent's weakness is structure and selection, and structure and selection aimed at eyes instead of tokens is just called a dashboard. Our own benchmark said agents reason better over structured data than over raw dumps; a dashboard is that same structuring, aimed at the other reasoning engine in the room, which is the person supervising the agent.

## Two: at 3am you arrive cold

The autonomy-ladder post made a point I want to borrow: once an agent handles the routine cases on its own, the incidents that still page a human are, by definition, the ones it couldn't handle - the weird ones - and you show up to the weird one with less recent practice on the normal ones than you've ever had.

What you need in that moment isn't a log of what the agent tried. You need to get oriented fast: what's there, what it means, where it's heading. Human-factors people have a name for this - situational awareness - and the reason it matters here is that a transcript gives you the raw perception and makes you assemble the meaning and the trajectory yourself, under pressure, at the worst possible time. A topology graph with the blast radius lit up, a timeline of what changed when, health rolled up across the fleet - that's a machine for rebuilding understanding quickly. Its whole job is to take someone who was asleep ninety seconds ago and make them oriented, and no paragraph does that as fast as the right picture.

## Three: trust has to render somewhere

This is the one the bear case misses worst, because it assumes the hard part is doing the work. The hard part is trusting that the work was done right.

The demand signal here is loud. When [Grafana asked practitioners](https://grafana.com/observability-survey/) about AI in operations in this year's observability survey, the thing they were most united on - something like nineteen in twenty - was that it matters for the AI to show its reasoning. Most of the same respondents saw value in AI acting autonomously too; it just drew more skepticism than anything else they were asked about. People want the help and they want to see the work before they believe it, and seeing the work is a UI problem. An approval gate has to show you exactly what will change, as a diff, not describe it in a sentence, because you can check a diff in seconds and you can't really check a paragraph at all. The overnight report has to be scannable. Verification at a glance is precisely what a visual interface is for, and it gets more important as agents do more, not less.

## The inversion

So the dashboard doesn't die. Its job flips.

For years the dashboard was where you operated the cluster - the cockpit, hands on the controls, reading the instruments to fly. As agents take over the flying, the surface you need is the one where you supervise: the control tower. You're not holding the stick. You're watching a system that mostly flies itself, and you need to see, instantly and with total trust in the picture, when to step in.

That changes what a Kubernetes UI is even made of. The valuable surfaces stop being resource lists and become the approval queue, where you see what the agent wants to do and why and wave it through or stop it. The action audit trail, showing what it did and [under whose name](/blog/read-only-is-not-a-safety-boundary). The agent inventory, with the button to cut one off. The replay of what the agent saw and the path it took. The evidence view that lays out a root cause so you can check it rather than take it on faith. None of those were on the 2020 dashboard, because in 2020 you were the one doing the work.

Make that concrete. An agent notices a rollout pushed error rates up and proposes reverting it. The surface you want in that moment shows the affected services lit up on the topology, the deploy and the error curve on the same timeline, the evidence that ruled out the database, the exact diff the revert will apply, and the identity it will run under. You can approve that in seconds, or catch the one assumption that looks wrong. A chat message that says "I found the issue and I can fix it" asks for the same click with none of the checkability.

![The dashboard's job inverts from operating to supervising: browse, click-ops, and watch-in-case surfaces give way to an approval queue, audit trail, agent inventory, replay, and evidence view](/images/blog/supervision-surfaces.png)

| The dashboard you operate | The surface you supervise from |
| --- | --- |
| Browse resource lists | Review the evidence behind a diagnosis |
| Click through screens to act | Approve or reject proposed actions |
| Watch graphs in case something breaks | Handle the anomalies that survived triage |
| Inspect current state by hand | Replay what the agent saw and did |
| The human operates, the UI displays | The agent operates, the UI proves |

This is also the honest reading of the Klarna story. The interfaces went away; the workflows, the records, and the controls they carried had to land somewhere, and rebuilding all of that turned out to be the actual work. Removing the surface didn't remove the job. It moved it.

I'm not the first to see this coming. Charity Majors - the same skeptic who called dashboards pattern-matching back in 2021 - [wrote earlier this year](https://www.honeycomb.io/blog/honeycomb-10-year-manifesto-part-1) that the future isn't "dashboards with AI" but interfaces where the visualization exists to serve understanding, with humans in the loop and on the loop. Which is to say: a new dashboard - one that inherits her old carve-out, interrogable instead of frozen, doing a different job than the one it replaces.

## The part I can't close

The one part of the bear case I can't fully answer is where all of this renders. Maybe these supervision surfaces don't ship as a fixed product at all. Maybe an agent composes the right view on demand from a description, or the approval gate lives in your incident channel, or the evidence view opens inside your editor. OpenAI and Anthropic are both betting real effort in the generative-UI direction, and it might be where this lands. If it does, the tab you keep open - the destination dashboard, the thing we literally sell - shrinks with it. I'm not going to pretend otherwise.

But none of those futures remove the requirement underneath, which is that the picture be trustworthy: one consistent model of cluster state, agent actions, evidence, identity, and history that any surface can render without drifting from what the agent actually saw. That's the actual bet we're making, and it's why we build the [UI and the agent interface on one engine](/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools): when the dashboard and the MCP server read from the same model of the cluster, the view a human checks and the data an agent acted on can differ only by time, never by interpretation. A generated interface still needs that model to generate from. Whether the pixels are hand-designed, composed on demand, or drawn inside somebody else's tool is a question about where the supervision layer shows up, not whether it exists.

## How this changes what we build

This is the part about our own product, so discount it accordingly - but it isn't a thought experiment for us, it's the roadmap. [Diagnose](https://radarhq.io/product/diagnose), in the current Radar release, is an early version of the inversion: the agent investigates, and what it hands back is built for checking - the checks it ran, the evidence it gathered, a verdict with a confidence estimate, and an apply step that shows you the exact change before you approve it. That's not a chat box, and it's not a transcript either. It's one investigation rendered so a person can verify it, built on the same engine that serves the dashboard and the MCP server. Where we're going next is the rest of that list - the approval queue, the audit trail, the agent inventory - as first-class surfaces, because I think that's what a Kubernetes UI is turning into. I don't claim we have it all figured out. I do think the teams betting that agents delete the dashboard are going to be surprised by how much dashboard it takes to supervise an agent.

We build a Kubernetes dashboard. I think its job is about to get more important, not less - it just won't be the one you click through all day. The cockpit is quieting down. The tower is where the work is going.

If you want to poke at the first version of that, Radar is open source and Diagnose ships in the current release, next to the topology and timeline views it builds its case from.

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


---

### Read-Only Is Not a Safety Boundary

- **URL**: https://radarhq.io/blog/read-only-is-not-a-safety-boundary
- **Date**: 2026-07-28
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Engineering
- **Tags**: radar, ai-agents, security, kubernetes, mcp


There are two sentences I hear in every meeting where a team wires an AI agent into a Kubernetes cluster. The first is "it's fine, we gave it read-only access." The second is "just point it at the service account." Both sound like the cautious choice, and I've said versions of both myself. They come back to bite you later, in ways that don't show up in the demo.

This is a post about why, and what I'd check instead. I'm writing it as the person who had to make these calls for our own product, so it's opinionated rather than exhaustive. And to be clear up front: read-only is still a control worth having. It genuinely bounds what an agent can change, and you should use it. The mistake is treating it as a boundary on what an agent can learn, leak, or be talked into - which is what the meeting quietly assumes.

**TL;DR.** In Kubernetes, being able to read is close to being able to read the credentials, and for an agent every read is also a send - out to a model, usually off your infrastructure. The cluster state it reads is partly written by attackers, so read access is also an injection surface. And a shared service account means the audit log can't tell you which human's agent did what. None of these are fixed by the model getting smarter. They're fixed by scrubbing reads at the tool layer, cutting off the exits an attacker can see, and giving the agent a real identity - the human's when a human is driving, its own when nobody is.

## "Read-only" doesn't mean what you think

Start with the part everyone treats as obviously safe. Kubernetes ships a built-in `view` role, and its own [documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) is blunt about what that role leaves out on purpose:

> This role does not allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation).

The people who designed Kubernetes RBAC already decided that being able to read Secrets is the same thing as privilege escalation, and they built the default read-only role specifically so it can't. A Secret's contents are base64, which is encoding and not encryption, so anything that can `get` a Secret gets the value. To read one is to hold the credential.

So if your agent is bound to `view`, it can't read Secrets. The trouble is that credentials don't stay in Secrets as reliably as the meeting assumes. To be precise about the mechanics: a credential that reaches a pod through `secretKeyRef` is safe from `view`, because the pod spec carries a reference to the Secret rather than the value. But a password typed straight into `env[].value` is sitting right there in the pod spec. Connection strings live in ConfigMaps because a ConfigMap is less hassle than a Secret. Tokens get printed into container logs on an error path more often than anyone likes to admit, and they get quoted back inside Events. Locking the Secret while leaving the pod spec, the ConfigMap, the log, and the Event readable locks less than it sounds like.

What "read-only" actually bounds is what a human can change. It barely touches what a human, or an agent, can learn. For a person that gap is usually harmless, because a person reads one thing at a time for a reason. An agent reads differently, and that's where it stops being harmless.

## Reading is sending

Here's the part the phrase "read-only" hides completely. When you run `kubectl get`, the bytes land on your screen and stop there. When an agent reads the same object, those bytes go into a model's context, and unless you're running that model on your own hardware, they leave your infrastructure on the next API call.

So "read-only" for a person means look but don't touch. For an agent wired to a hosted model it means everything it can look at gets shipped to a third party. Those are different promises, and the meeting usually only makes the first one out loud. To be fair to the providers, the defaults are mostly reasonable - the major APIs say they don't train on your traffic by default. But retention windows, abuse monitoring, human review, and regional processing all vary by provider and by how your account is configured, and once the bytes are sent, what happens next is governed by someone else's policy rather than your RBAC. "Handled responsibly at a vendor" is a different security story than "never left the cluster." The setup that genuinely keeps cluster contents inside your boundary is a model you run inside it - and even then only if the agent's other tools and telemetry stay inside too.

One distinction to keep straight, because the next section depends on it. This is a confidentiality question between you and your vendors, about where your data goes when nothing is attacking you. It is not yet about an attacker stealing anything. The model provider's API is not a channel your attacker can read. What an attacker needs is different, and most agents have it anyway.

## The cluster is writing to your agent

Now the failure mode that turns a quiet concern into an active one.

There's a framing I keep coming back to from Simon Willison, who named the [lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) in 2025. An LLM system gets dangerous when it combines three things: access to private data, exposure to untrusted content, and a way to send data somewhere an attacker can see it. Any one or two of those is usually fine. All three together mean an attacker who controls the untrusted content can talk the model into taking the private data and shipping it out.

A read-only cluster agent has all three more often than you'd think. The private data is the whole point, because it reads your cluster. The way out is any channel an attacker can actually observe - a web search or URL fetch the agent is allowed to make, or anything it can write where an attacker might later read it, down to a ticket reply or an issue comment. Note what's not on that list: the model API call itself. Sending your data to the provider is the confidentiality problem from the last section, but your attacker can't read the provider's servers, so it isn't their exit. The exits that matter are the mundane ones. And the untrusted content is hiding in the cluster state, which is the part people miss. A pod name, a log line, an annotation, an Event message - a lot of what an agent reads is text that somebody else can write. Anyone who can get a workload to log a line, or set an annotation on an object, has put words in front of your agent, and a model can't reliably tell the difference between data it was asked to look at and instructions dressed up as data.

![The lethal trifecta on a Kubernetes cluster: private data, untrusted content, and attacker-visible egress meeting at the agent - and where the tool layer severs each leg](/images/blog/lethal-trifecta-cluster-v2.png)

The demonstration I'd point at is the [Supabase MCP case](https://simonwillison.net/2025/Jul/6/supabase-mcp-lethal-trifecta/) from last summer. Researchers showed that instructions planted in a support ticket could steer a database agent into reading private tables and writing what it found back into the ticket thread, where the attacker could simply read it. No customer was breached; it was a proof of concept against an agent running with far more privilege than it needed. Two things about it are worth keeping. The untrusted content did its job - the agent followed instructions it found in data. And the exit was a write, which means the vendor's own read-only mode would have severed exactly that channel, and it's now the recommended default. Read-only helped there not by making reading safe but by removing the one exit that agent happened to have. Point an agent at the same data with a web-fetch tool in its pocket and read-only mode has nothing left to say.

When I first drafted this post I had a paragraph here admitting I couldn't find a public Kubernetes-specific demonstration. I've since deleted it. There's now a paper - [LogJack](https://arxiv.org/abs/2604.15368), from this spring - showing debugging agents hijacked through instructions planted in cloud logs, with six of the eight models tested pushed all the way to remote code execution. And Kubernetes MCP servers have started accumulating CVEs whose advisories name indirect prompt injection as the way in - [one of them](https://github.com/advisories/GHSA-wvxp-jp4w-w8wg) lets a crafted string reach `sh -c` inside your pod. The ingredients were always sitting there. Now the demonstrations are too.

## What a real read boundary looks like

If read-only isn't the boundary, you have to build one, and you build it at the tool layer instead of hoping the model behaves.

You scrub what leaves the cluster, so Secret values never enter the context in the first place and log lines get scanned for credential shapes before an agent sees them. This is pattern-based and therefore imperfect - a novel secret format will slip past it - and I'd rather say that plainly than oversell it, but it moves the default from "everything ships" to "the obvious credentials don't."

You keep write capability off the read path entirely - not a write tool that's present but disabled, and not one that's merely hidden from the model's tool list, but a surface that doesn't have the capability, with the cluster's own RBAC behind it in case anything gets through. Hiding tools from the model is attack-surface reduction; the boundary has to hold server-side, where a successful injection can't negotiate with it.

And you cut off the exits on purpose, because the Supabase lesson generalizes: you don't have to defeat prompt injection if the injection has no channel an attacker can read. When we built read-only investigations into Radar, we turned off the agent CLI's built-in web search during a run, specifically because it reaches the public internet and would hand an injection its exit. One of the supported CLIs can't be fully closed - Cursor has no way to suppress a user's own MCP servers - so there Radar tells you exactly that in a consent step before the run, instead of pretending. That closes the loudest exit, not every conceivable one - the honest version of this work is an inventory of every outbound path the agent holds, and a decision about each.

## "Just use the service account"

So much for the first sentence. The second one is about who the agent is, and it fails in a quieter way. Wire the agent to a shared in-cluster ServiceAccount and you've answered what it can do without ever answering who it is. Those two come apart the moment something goes wrong.

I went and looked at how the AI-for-Kubernetes tools people actually deploy show up in the audit log, and they mostly split into two shapes. A tool that runs off your kubeconfig acts as you, and the API server authorizes and records its actions as you typing. There's a user-agent string that might hint an AI was involved, but it's self-reported by the client, not something the cluster will vouch for.

An operator-style tool runs as one shared ServiceAccount, so the API server sees the same principal - something like `system:serviceaccount:ai:agent` - no matter which of your engineers kicked off the action, or whether a human was involved at all. That's not anonymous, exactly; you know it was the agent. But it collapses every person and every workflow into one name.

Neither shape can answer the question an incident review actually asks, which is: whose agent did this, and who approved it. The audit log records the identity you handed the agent, so its answer is only ever as good as that identity. (All of this also presumes you've turned audit logging on and given it a policy, which the API server won't do for you. Worth checking before the night you need it.)

Kubernetes already ships the thing that fixes this, and it's the same mechanism we [used for human SSO](/blog/sso-and-rbac-without-passing-around-kubeconfigs): impersonation. Run the agent behind a service that authenticates as itself and impersonates the person driving, and the audit event carries both names - the service that made the call and the human it acted for. Two caveats belong in the same breath, because impersonation is a power tool. The right to impersonate is itself RBAC, and the service holding it becomes a thing worth attacking, so scope it tightly. And the mapping from logged-in human to impersonated identity has to live in your code, somewhere no model output can touch it. [Teleport](https://goteleport.com/blog/kubernetes-agent-identity-access/) put the underlying principle better than I can: an agent with its own identity is accountable and traceable, and one silently borrowing a user's identity is neither. The kubeconfig shape is the silent borrowing they mean. Impersonation through a service that authenticates as itself is the opposite: everybody involved is on the record.

## Two right answers, depending on who's driving

This is where identity gets interesting, and where it ties back to [autonomy levels](/blog/ai-agent-autonomy-levels-kubernetes). "Give the agent an identity" has two correct answers, and which one you want depends on whether a human is in the loop.

When a human is driving - the interactive case, someone asking the agent to investigate or approving a fix - the agent should act under that human's authority. The service impersonates you against the API server, the audit event carries both of you and reads like "Eyal, through the agent, restarted this pod," and the agent's ceiling can never rise above your own RBAC. A read-only engineer's agent can only read. You get that for free from impersonation, and it's the right model for every agent that acts because a person told it to.

When nobody is driving - the proactive agent acting unattended at 3am - there is no human to borrow from. It can't impersonate someone who's asleep, and you wouldn't want it to, because that puts a name on an action the person never saw. An agent acting on its own needs its own identity, with its own scoped permissions and its own envelope of what it may do without asking. This is the thing the whole identity industry spent the last year building, and I'll leave it at that rather than list every product. The mistake isn't picking impersonation or a dedicated identity. The mistake is the shared account, which hides the human when one was driving and reuses one identity - and one blanket ceiling - for every human and every workflow when one wasn't.

## You can't revoke what you can't inventory

There's a scaling problem underneath all of this. Agents don't stay singular. Soon it's one per engineer's laptop, plus one in CI, plus a Slack bot, plus whatever somebody spun up for a demo and never turned off. CyberArk's [latest landscape survey](https://www.cyberark.com/press/machine-identities-outnumber-humans-by-more-than-80-to-1-new-report-exposes-the-exponential-threats-of-fragmented-identity-security/) puts machine identities at 82 for every human one, with AI agents pouring fuel on the fire - and that's the only statistic I'll allow this post.

The consequence is boring and expensive. When an engineer leaves, or when one agent's token leaks, the question is whether you can shut that one credential off right now - tonight, not after an afternoon of spelunking. Most teams I ask can't say yes with a straight face. So two unglamorous things end up mattering more than any clever guardrail. You need an inventory: every agent and token with cluster access in one place, with an owner and a scope, because you can't revoke what you can't see. And you need those credentials to be short-lived and individually killable, not one static ServiceAccount token minted once and shared forever - which is exactly the direction Kubernetes' own guidance pushes, toward bound, expiring tokens over the legacy static kind.

## Where this stops working

None of this is a silver bullet, and pretending otherwise would just repeat the "read-only is safe" mistake in a new outfit. Scrubbing catches known shapes and misses novel ones. Running the model locally closes the reading-is-sending gap but does nothing about a locally-hosted agent being talked into a bad action - different leg of the trifecta, still a problem. The whole MCP ecosystem is young enough that plain integration bugs still leak data without any attacker involved. And identity buys you attribution, not judgment: a perfectly named, well-scoped agent can still be confidently wrong, which is the autonomy-ladder problem and a separate discipline.

## How we apply this in Radar

This is the part of the post about our own product, so weigh it accordingly. The honest summary is that we've tried to put every boundary above into the tool layer, where the model can't argue with it.

Radar's [MCP server](/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools) separates read tools from seven explicit write tools. Reads scrub Secret values and known credential shapes before they reach the model - pattern-based, with the limits that implies. Writes are enforced by Kubernetes RBAC and annotated so a client that honors them prompts first; one that doesn't is bounded by RBAC alone. During a [Diagnose](https://radarhq.io/product/diagnose) investigation the write tools aren't present on the surface the agent talks to, the agent's built-in web search is switched off for the duration (with the Cursor caveat above), and an approved fix runs in a separate session bound to that one change.

Identity depends on which Radar you're running, and I'll describe it in the terms this post set up. Local Diagnose drives your own agent CLI under your own kubeconfig - the acts-as-you shape. Its ceiling is your RBAC, which is the right ceiling, but the audit log reads as you alone; I won't pretend that's the dual-attribution ideal from the last section. In Radar Cloud, requests go through the impersonation path we built for human SSO: the service authenticates as itself and impersonates the requesting user, so the ceiling is still the human's RBAC and the audit event names both. We have not shipped an agent that acts with nobody driving - when we do, it gets its own scoped identity, not a borrowed one and not a shared account.

None of that makes an agent something you can stop thinking about. It moves the important decisions out of the model's judgment and into places you can [read the code](https://github.com/skyhook-io/radar) for.

## The two sentences, again

Next time you're in that meeting, put the two sentences under a little pressure. When someone says it's read-only, ask read-only what - Secrets, or the env vars and logs that hold the same values - and ask where what it reads ends up, a model you host or one you don't, and what's writing the text it reads along the way. When someone says just use the service account, ask whose name lands in the audit log when this thing acts at 3am, whether a human is even driving, and if this token leaked tonight, whether you could revoke just this one by morning.

If those have good answers, you built the boundaries. If they don't, "read-only" and "the service account" were never the safe choices. They just sounded like them.


---

### Radar MCP vs kubectl: A Kubernetes Agent Benchmark on 54 Faults

- **URL**: https://radarhq.io/blog/radar-mcp-vs-kubectl-benchmark
- **Date**: 2026-07-20
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Engineering
- **Tags**: radar, mcp, ai-agents, kubernetes, kubectl, benchmark


> **Updated August 6, 2026.** This post originally reported a 52-scenario run on `claude-sonnet-4-6`. I have re-run the whole thing on `claude-sonnet-5` with 54 paired scenarios and fixed a measurement mistake that was understating the speed result. Every number below is from the new run. One of the original headlines - "76% fewer tool calls" - did not survive, and I explain why. You can now [replay any of the 54 scenarios yourself](/benchmark).

I wanted to know one thing: when an AI agent debugs a broken Kubernetes cluster, does it matter what tools we hand it?

Most vendors hand-wave this - "our MCP makes your agent smarter." That is not the bar. If you're giving Claude, Cursor, or an in-house agent access to Kubernetes, the tool surface has to beat raw `kubectl` on accuracy, cost, and safety. I didn't want to ship a claim I couldn't defend, so I ran the same Kubernetes benchmark with the same model on two tool surfaces. One arm drove raw `kubectl` through a shell. The other drove [Radar's Kubernetes MCP server](/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools).

Radar won, but not on the axis I first reported.

## TL;DR

On 54 real Kubernetes fault-injection scenarios, an agent driving Radar's Kubernetes MCP server reached a correct diagnosis in a **median 41 seconds against 154 seconds** for the same agent on raw `kubectl` - about **four times sooner**. Overall accuracy was close (**91% vs 87%** pass rate), but nobody gives an agent half an hour during an incident: **cap it at five minutes and it's 91% against 56%**, because Radar's slowest correct diagnosis in the entire benchmark was four minutes and kubectl's was twenty-four.

Worth being precise about what won, because it isn't MCP. MCP is a connector; an MCP server that just proxies `kubectl` returns the same wall of YAML with an extra hop in front of it, and I'd expect that to be slower than the shell, not faster. What won is what came back through the connector: a model of the cluster Radar keeps current. The `kubectl` agent spends **73% of the incident blocked**, waiting on the cluster to answer. Radar spends 6%.

## What changed since the first version of this post

Three things, and one of them was my mistake.

**I was timing the wrong thing.** The benchmark runs in two stages: the agent submits a diagnosis, then goes on to attempt a fix. I had been measuring the whole session, launch to exit, when the claim was only ever about diagnosis. That second stage ran 60 to 250 seconds in both arms and was squashing the gap. Measuring to the moment the diagnosis is submitted - which is also the artifact that gets graded - takes the result from "about half the time" to about four times sooner.

**"76% fewer tool calls" did not replicate.** On the stronger model the gap narrows to 43% by mean and 19% by median. A better model simply flails less with raw `kubectl`. I am retiring that headline: counting tool calls weights a 0.1-second cache read the same as a 60-second rollout wait, which makes it a poor proxy for anything a user feels. Time to a correct answer is the honest metric, and it is the one that got stronger.

**Better model, more scenarios.** `claude-sonnet-5` instead of `claude-sonnet-4-6`, and 54 paired scenarios instead of 52.

## What I tested

The setup was deliberately simple: same benchmark suite, same model, same goal, two tool surfaces.

- **Scenarios:** SREGym - 54 paired fault-injection scenarios on a live cluster. Bad DNS policies, wrong selectors, missing env vars, broken probes, auth disruptions, stale secrets, admission webhooks, slow image pulls. Real faults, not puzzles.
- **Cluster:** EKS, 3 nodes, us-east-1.
- **Model:** `claude-sonnet-5` on both arms.
- **Tool surfaces:** Arm A got raw `kubectl` via Bash, including `exec`. Arm B got Radar's MCP tools with `kubectl` blocked outright, so it could not fall back to a shell.
- **Grading:** SREGym's own LLM judge at temperature 0. The graded artifact is the first diagnosis each agent submits.

## The numbers

| Metric | kubectl | Radar MCP |
|---|---|---|
| Pass rate | 87% (47/54) | **91% (49/54)** |
| Avg diagnostic score (0-1) | 0.889 | **0.920** |
| Median time to a correct diagnosis (44 faults both got right) | 154s | **41s** |
| Answered sooner, of the 44 both got right | 1 | **43** |
| Slowest *correct* diagnosis | 1430s (24 min) | **242s (4 min)** |
| Share of the incident blocked on the cluster | 73% | **6%** |

The accuracy rows are close enough that I would not lean on them. The timing rows are not close, and they are consistent: across the 44 faults both arms diagnosed correctly, Radar answered sooner in 43.

## Accuracy you can actually wait for

Reporting accuracy and speed separately understates what is happening, because nobody lets an agent grind for thirty minutes while production is down. Put the two together - how much of each arm's accuracy is reachable inside a given time budget - and the near-parity disappears:

| Agent time budget | Radar MCP | kubectl |
|---|---|---|
| 2 minutes | **83%** | 30% |
| 5 minutes | **91%** | 56% |
| 10 minutes | **91%** | 72% |
| 30 minutes | **91%** | 87% |

Radar delivers every correct answer it will ever produce within five minutes; its curve is flat after that. Capping the agent at five minutes costs Radar nothing and costs `kubectl` more than a third of its correct answers.

## Why this Kubernetes MCP server beats raw kubectl - and why not all of them would

This is the part that explains the numbers instead of just reporting them.

Radar's MCP is not a `kubectl` wrapper - that distinction is the whole mechanism. Give an agent raw `kubectl` and a single `kubectl get pod -o yaml` hands back hundreds of lines: `managedFields`, full status blocks, annotations, the entire object as the API server stores it. The one useful signal - an `OOMKilled` condition, a failing readiness probe - is buried in the wall of text. And the agent re-reads its accumulated context every turn, so by call 30 it's dragging a huge transcript of YAML it already parsed.

To trace a cross-cutting fault - "this Service can't reach its pods" - a `kubectl` agent has to reconstruct the graph by hand: list the Service, read its selector, list pods, check labels, read endpoints, check the network policy, pull events, cross-reference timestamps. Worse, most of that is *waiting*. Rollout status, log tails, sleep-and-retry loops, and in several trials the agent launched a throwaway pod just to run `curl` from inside the cluster, at roughly two minutes a go. That is where the 73% figure comes from.

Radar hands over the already-computed answer instead. The MCP returns **minified, enriched, secret-redacted** data: pre-built topology graphs, problem-correlated timelines, deduplicated events, error-filtered logs. It calls the issues API and gets the causal chain - what broke, what it's connected to, what changed - instead of the raw materials to derive it. Those calls return in well under a second, because the expensive work happened continuously, before the incident.

That flips diagnosis from I/O-bound to model-bound. Radar's floor is how fast the model thinks; `kubectl`'s floor is how fast a cluster answers serial commands. Faster models widen this gap rather than closing it.

This is exactly the argument Roy made in ["Agents, UIs, and CLIs: The False Choice in Kubernetes Operations"](/blog/agent-or-ui-false-choice-kubernetes-operations) - a cluster is a live graph, and raw YAML is a poor way for *anything* to make sense of it, human or LLM. This benchmark is that argument with a number attached.

## Where Radar pulls ahead, and where it loses

Radar's biggest wins are the faults where nothing crashes. A rotated Secret the pod never picked up, a feature flag flipped in a ConfigMap, a CoreDNS rule changed in another namespace. Every pod reports Ready, `describe` looks clean, and there is no event to find. The `kubectl` agent ground for fifteen minutes or more on several of these and still got them wrong. "What changed, and does it correlate with the symptom" is precisely what Radar computes continuously.

We lost five scenarios, and they are all in the [replay](/benchmark) if you want to watch them go wrong. Two patterns account for most of it.

The first is evidence inside a running process. When a database grant is revoked *inside* the database and no Kubernetes object changes, the `kubectl` agent can shell in and read it. Radar has no exec, so it gets the component right and the mechanism shallow.

The second is squarely our bug. The benchmark injects a fault and starts the agent seconds later, while some of Radar's time-based signals are still warming up. The agent asks, gets a short and confident-looking answer, and stops - when the correct answer would have been there two minutes later. Radar needs to say "I have not watched this cluster long enough yet" instead of looking finished. That is on our roadmap because this benchmark found it.

Worth being blunt about the other side too: the `kubectl` arm's distinctive wins rest on giving an autonomous agent free-form `exec` on your cluster. Almost no security team grants that, and they are right not to.

## You don't want an agent loose on raw kubectl

Speed and accuracy aside, raw `kubectl` through a shell is the *ungoverned* option. The agent inherits whatever that shell can do, every call is a potential mutation, and you get no record of what it touched. This benchmark contains a fault whose most natural diagnostic command prints a production password in plaintext, straight into an LLM context window.

Radar's MCP is the opposite by design: read tools are read-only and secret-redacted, writes are RBAC-enforced and gated so the client can prompt before anything changes, and [Radar Cloud](/blog/introducing-radar-cloud) adds the governance layer on top - an inventory of every agent and token with cluster access, the same Kubernetes impersonation a human gets, and audited tool activity for agent actions.

"Faster and a little more accurate" is the benchmark result. "And you can actually let it near production" is why teams route the agent through Radar in the first place.

## Why this is the argument for an agent surface

Step back and the result isn't really about AI - it's about data shape. Agents reason over Kubernetes far more cheaply, and a little more accurately, when the data is structured for them. It's the same reason we build dashboards instead of reading raw YAML: eyes need the graph rendered, and it turns out agents need the same graph modeled.

So Radar is one engine that watches your clusters, with two surfaces over it. Humans consume it as a UI - still the surface most of our users live in. Agents consume it as MCP. Both need the same thing: the cluster made sense of, not just dumped. This benchmark was about the second surface, but the human-first one is still the point - we build Radar for the person staring at a cluster at 2am, and increasingly some of that work is done by an agent on their behalf.

## Watch it, then run it yourself

You don't have to take my word for any of this. Every one of the 54 scenarios is replayable side by side, call by call, including the ones Radar got wrong:

**[Replay the benchmark →](/benchmark)**

Radar is open source with the MCP server on by default, so you can point your own agent at it and break something on purpose to see how it reasons.

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

That gets you the UI and the MCP server in one go. Aim your agent at the MCP endpoint and watch it work a fault on a cluster you trust.

This study asks whether Radar's correlated MCP surface beats raw `kubectl`. The newer [five-surface Kubernetes MCP benchmark](/benchmark/kubernetes-mcp-servers) compares Radar with other MCP servers on 25 live faults, and the [Kubernetes MCP server comparison](/kubernetes-mcp-comparison) covers operations, safety, and fleet governance.


---

### The 3am Test: Autonomy Levels for AI Agents in Kubernetes Operations

- **URL**: https://radarhq.io/blog/ai-agent-autonomy-levels-kubernetes
- **Date**: 2026-07-17
- **Author**: Roy Libman, CPO, Skyhook
- **Category**: Platform
- **Tags**: radar, ai-agents, mcp, kubernetes, sre


While you slept last night, your cluster healed itself several times. A kubelet restarted a container that failed its liveness probe. A ReplicaSet replaced a pod that died with its node. The HPA added two replicas during a traffic spike and took them back an hour later. Nobody approved any of it, and nobody minds.

So why does "an AI agent restarted the pod at 3am" land so differently from "the kubelet restarted the container at 3am"?

That question is basically the whole debate about AI agents in production operations, and right now a lot of tools answer it with a config flag.

**TL;DR.** Agents don't add automation to a cluster - Kubernetes has plenty. They add judgment, and you have to decide how much of it to delegate. This post proposes six levels for that decision, L0 to L5. The line that matters runs between L3, where the agent acts after you say yes, and L4, where it acts and you read about it at 9am. Two rules keep the levels meaningful: **a level belongs to a verb in an environment** ("restart pods, in staging"), not to an agent as a whole, and **a level only counts if the write path enforces it**, because the prompt won't. Most teams are at L1-L2 today. Too many tools ship L1 plus a config flag that jumps straight to L4.

## Rules are not judgment

The kubelet that restarted your container was executing a contract you can read: `restartPolicy: Always`, a liveness probe, a documented backoff curve. Same inputs, same behavior, every time. Kubernetes is a pile of these contracts reconciling toward desired state, and that pile is why we trust it. "Should automation touch production at night" stopped being a live question the day you adopted it.

An agent is a different kind of thing. Before it restarts a pod, it diagnosed a situation - read logs, correlated events, formed a theory - and then picked that action out of everything else it could have done. Give it the same symptoms tomorrow and you might get a different theory and a different action. A controller that surprises you means you misread a rule somewhere. An agent that surprises you is working as designed.

Delegating rules is engineering. Delegating judgment is trust, and you would never take a new engineer from "can read the runbook" straight to "unsupervised prod changes at night." That's exactly the jump most AI-for-Kubernetes tooling offers, though: a read-only mode, a fully-autonomous mode, and not much in between. Driving had the same vocabulary problem and fixed it with [SAE J3016's six levels](https://www.sae.org/standards/content/j3016_202104/). Operations could use the same.

## The six levels

This isn't the first ladder of its kind, and it's worth saying so: the [Google SRE book](https://sre.google/sre-book/automation-at-google/) sketched an automation hierarchy a decade ago, Google published [AI autonomy levels for its own operations](https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/) this spring, and [Rootly maintains a maturity model](https://rootly.com/ai-sre-guide/maturity-model) for AI SRE products. What none of them pin down is what a small platform team actually negotiates with an agent: which cluster verbs, in which environments, on whose approval. So here's the ladder in those terms.

| Level | Name | Who diagnoses | Who picks the fix | Who executes | Where the human is |
|---|---|---|---|---|---|
| **L0** | Manual | You | You | You | Doing everything |
| **L1** | Explain | Agent summarizes, you conclude | You | You | Driving, with a narrator |
| **L2** | Propose | Agent | Agent proposes | You | Reviewing a concrete diff |
| **L3** | Act on approval | Agent | Agent | Agent, after your yes | The approval gate |
| **L4** | Bounded autonomy | Agent | Agent, inside an envelope | Agent | Reading the 9am report |
| **L5** | Full autonomy | Agent | Agent, anywhere | Agent | Finding out eventually |

![The six autonomy levels, and the 3am line between L3 and L4](/images/blog/ai-agent-autonomy-levels-ladder.png)

**L0 - Manual.** kubectl, a dashboard, a runbook. Still where every break-glass procedure should bottom out.

**L1 - Explain.** The agent reads cluster state and answers questions; the diagnosis and the typing are still yours. This is where most teams genuinely are in mid-2026, and it's the most value for the least risk anywhere on the ladder.

**L2 - Propose.** The artifact changes from prose to a diff: a root cause plus a specific remediation, which you review like a colleague's change and run yourself.

**L3 - Act on approval.** The agent executes its own proposal through a bounded set of verbs, after an explicit yes. It feels like a small step from L2, but the agent now holds write credentials, and the whole thing turns on the gate: what exactly did you approve, and is that exactly what runs?

**L4 - Bounded autonomy.** The agent acts without waking anyone, inside an envelope you wrote down in advance: "may restart crashlooping pods in staging; may roll back deploys under 30 minutes old; may never touch a PVC." You review at 9am, from a report.

**L5 - Full autonomy.** "Keep production healthy," any verb, any cluster. Nobody ships this responsibly - driving, with a decade head start and standardized roads, hasn't shipped its L5 either. When a vendor says "fully autonomous," they mean L4 with an envelope they haven't shown you.

## The 3am test, and the 9am question

The ladder turns into a tool when you apply it per action. For every verb an agent could run, ask two questions.

**The 3am test: would I rather be woken up to approve this, or read about it at 9am?** That sorts the verb into L3 or L4. It's a question about you rather than about the model, which is why the answers tend to be honest. Nobody wants to be paged to approve a staging pod restart. Nearly everyone wants to be awake when something drains a prod node.

**The 9am question: if it chose wrong, is 9am too late to find out?** That caps how high the verb can ever go, and the cap comes down to reversibility and blast radius. Note that a smarter model does not raise the ceiling - no future model makes deleting a PVC reversible. The ceiling is a property of the verb.

| Verb | Reversible? | Blast radius | Ceiling |
|---|---|---|---|
| Restart a crashlooping pod | Yes | One workload | L4 |
| Scale within declared bounds | Yes | One workload | L4 |
| Roll back a deploy under 30 min old | Usually - watch for migrations | One service | L3 in prod, L4 in staging |
| Trigger a GitOps sync / reconcile | Yes | One app | L4 |
| Cordon and drain a node | Mostly | Everything on that node | L3 |
| Edit a NetworkPolicy | Technically - but failures are silent | A security boundary | L2 |
| Delete a PVC, a namespace, a CRD | No | That data, forever | L2, permanently |

For what it's worth, I'd hand an agent most of the staging column tomorrow - and nothing drains a production node while I sleep, no matter whose model it runs.

"What level is your agent?" is the wrong question, and the table shows why: one agent should be running L4 for staging restarts, L3 for prod rollbacks, L2 for anything near a security boundary, and L1 for whatever it can't classify. The level lives in the (verb, environment) cell.

Promotion between levels works the way it does for people: on track record. A verb earns L4 when, say, its last 50 proposals were approved unmodified and none got reverted - the same bar as a new hire's path to unsupervised deploys. The ratchet turns both ways, too. An agent-caused incident demotes the verb, immediately.

## Where the tools actually are in mid-2026

Mapping real tools onto the ladder is clarifying. I went through the docs of the tools people actually deploy; this isn't a dunk, and most of these defaults are reasonable choices.

| Tool | Investigation | Execution |
|---|---|---|
| [K8sGPT](https://github.com/k8sgpt-ai/k8sgpt-operator/blob/main/AUTO_REMEDIATION.md) | Autonomous (read) | Auto-remediation is alpha and opt-in, gated by a risk threshold and a similarity check; rollback is marked TODO in the docs |
| [HolmesGPT / Robusta](https://holmesgpt.dev/latest/data-sources/builtin-toolsets/kubernetes-remediation-mcp/) | Read-only by design | Separate opt-in toolset; every write can require per-action approval |
| [kagent](https://kagent.dev/docs/kagent/examples/human-in-the-loop) | Free within its RBAC | Write tools pause for approval - if you list them under `requireApproval` |
| [kubectl-ai](https://github.com/GoogleCloudPlatform/kubectl-ai) | Interactive | Confirms mutations by default; `--skip-permissions` turns the gate off |
| [Datadog Bits AI SRE](https://www.datadoghq.com/blog/bits-ai-sre/) | Starts autonomously on an alert | Human-gated: proposed PRs and one-click actions |
| [Azure SRE Agent](https://learn.microsoft.com/en-us/azure/sre-agent/agent-run-modes) | Autonomous | Review mode by default (plan, then wait); Autonomous mode only inside predefined incident-response plans |
| [Komodor Klaudia](https://komodor.com/blog/komodor-introduces-extensible-autonomous-multi-agent-architecture-for-ai-driven-site-reliability-engineering/) | Autonomous | Policy guardrails you loosen as confidence grows |
| [Cast AI](https://cast.ai/automation-academy/agentic-operations/) | Autonomous | Per-category envelopes - e.g. resource changes within ±30% auto-execute, larger ones wait for review |

**The read side has gone autonomous without much debate.** Nobody gates "the agent may look" anymore. The contested zone is the L3/L4 boundary, which is some validation that the 3am line is where the real question lives.

**The graduated middle is thin, especially in open source.** Most open-source tools give you two settings: a safe read-only mode, and a flag like `--skip-permissions` or `autoRemediation.enabled: true` that skips straight from L1 to L4. The rungs in between - approving individual verbs, writing an envelope, promoting a verb once it has a track record - mostly show up in commercial products, when they show up at all.

**The coding world already ran this experiment.** Coding agents went from "YOLO mode or nothing" to graduated permission modes - plan modes, per-action approval, sandboxed bypass - in roughly 18 months, helped along by public failures. The most famous failure came in July 2025, when [Replit's agent deleted a founder's production database during an explicit code freeze](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/); Replit added dev/prod separation and a planning-only mode afterward. Kubernetes tooling is earlier on the same curve, and a cluster usually holds more than one database. It would be good to converge faster than the coding tools did.

## The level lives in the write path, not the prompt

Telling the model to "always ask before making changes" is a suggestion. Models drift, prompts get long, and one poisoned log line can argue back. A level counts when it's enforced where the writes happen - in the tool surface:

- **Bounded verbs, not shell.** The agent gets `restart`, `scale`, `rollback`, `sync` - not `kubectl anything`. You can only put a ceiling on a verb if the verbs are a short list you can point to, not whatever a shell happens to allow.
- **The agent acts as somebody.** While a human is in the loop, the natural identity is that human: calls go through RBAC as you, and the agent's ceiling can't exceed yours. An unattended L4 agent can't borrow a sleeping person's identity, so it gets its own scoped account - robot accounts are nothing new - and that account's permissions become the envelope. What you don't want is one shared, anonymous account that's more privileged than anyone on the team.
- **Destructive verbs are marked as destructive** in the tool definition itself, so a client that honors the annotation can prompt first. The gate that still holds when a client does not is Kubernetes RBAC, not the model's manners.
- **Investigation and execution don't share a session.**

That last one is where prompt injection lives, and it's why we built [Diagnose in Radar v1.8.3](https://github.com/skyhook-io/radar/pull/947) the way we did: the investigation runs against a read-only MCP mount - write tools aren't just disabled, they're not discoverable, and a regression test fails if one leaks in. When you approve the proposed fix, the apply runs in a fresh session bound to exactly the confirmed fix, so nothing the agent read along the way - logs, events, annotations, all of it untrusted - can steer what gets written.

And if you run GitOps, you already own this infrastructure. [Flux's docs are blunt](https://fluxcd.io/flux/concepts/): change the cluster with kubectl and the change will be "promptly reverted." Argo CD with `selfHeal` reverts live drift [within seconds](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/) (the three-minute figure you sometimes hear is the Git polling interval, a different mechanism). An agent that patches a managed resource hasn't fixed anything; it has started an argument with a reconciler, and the reconciler wins. On a GitOps cluster the durable write path is Git itself: the fix arrives as a PR, review is the L3 gate, and `git log` is the audit trail. GitOps teams built graduated agent autonomy years ago - for humans. (Radar's Diagnose currently gates applies to managed resources behind an explicit acknowledgment; proposing the PR instead is where the arrow points.)

## What unattended autonomy costs

There's a 1983 paper I keep coming back to, Lisanne Bainbridge's ["Ironies of Automation"](https://ckrybus.com/static/papers/Bainbridge_1983_Automatica.pdf). Automate the routine work, she argued, and the human is left holding exactly the tasks the designer couldn't automate - while losing the practice that made them good at those tasks. That's on-call with an L4 agent: it eats the crashloops, so the 3am page you still get is the one it couldn't handle, and you arrive at it with fewer recent reps than you've ever had.

She also warned that humans are bad at monitoring mostly-correct automation. Waymo learned this on camera and [walked away from Level 3 driving entirely](https://cleantechnica.com/2017/11/01/googlewaymo-stopped-testing-level-3-self-driving-tech-testers-literally-fell-asleep-using-switched-full-autonomy/) - its 2013 highway tests filmed drivers sleeping and doing makeup at 56mph, because once the system handles almost everything, the human stops being a real fallback. The ops version is my real worry about L3 in practice: an approval gate you always click through is an autonomy level you haven't admitted to. If the agent files thirty approvals a day and you approve all thirty, you're at L4 without an envelope. Write the envelope for the verbs you rubber-stamp, and keep the gates rare enough that a human actually reads them.

One more thing worth stealing from the big-cloud postmortems: when automation takes down production, it usually did exactly what it was configured to do, just with too much authority. When [DynamoDB's DNS automation](https://aws.amazon.com/message/101925/) deleted its own active plan last October, AWS's response was to disable that automation worldwide while they rebuilt the safeguards. No AI involved, but that's the move you want available for agents too: a per-verb off switch that works at 3am without shipping anything.

I'll spare you the survey tour - the short version is that executives trust agents to act far more than the people on call do ([PagerDuty](https://www.pagerduty.com/newsroom/ai-resilience-survey-2025/) found 81% of executives trust AI agents in a crisis, while 84% of the same companies have already had an AI-related outage). Draw the 3am line with the people who hold the pager, not the people who bought the tool.

## Where the framework runs out

**Levels don't fix diagnosis quality.** They just decide how expensive a wrong diagnosis is. An agent that's wrong 15% of the time is mildly annoying at L2 and dangerous at L4; autonomy amplifies whatever accuracy you have.

**The driving analogy leaks.** Roads are standardized and clusters are anything but: your CRDs, your operators, your admission chain. Driving is one action space, while operations is hundreds of verbs with different ceilings. And there's no DMV - every vendor grades its own homework, so expect level inflation. When you hear "autonomous," it's worth asking which verbs that covers, in which environments, and based on what track record.

**The ladder is a policy, not an org chart.** It won't tell you who reads the 9am report or who owns an agent-caused incident. A good envelope document is where those answers end up.

## Where Radar sits on its own ladder

Radar ships L1 through L3 and stops there. This is the part of the post about our own product, so read it with that in mind.

**L1 - ask the cluster anything.** Radar's [MCP server](/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools) is on by default in the OSS binary. Its read tools scrub secrets and answer in structures instead of YAML dumps: `get_topology` hands back the ownership and routing graph as one object, `get_changes` answers "what changed in the last 20 minutes," and `issues` returns a ranked queue with causally-related failures already grouped. To pin it at L1, give it a read-only Kubernetes identity, which makes every write fail at the API, or use Radar Cloud's organization-wide read-only mode, which removes mutating tools from the surface. Radar also exposes seven explicit write tools for L3, when you let the agent act; Kubernetes RBAC enforces them. On [a 54-fault benchmark](/benchmark), the same model diagnosing through Radar beat raw `kubectl` on accuracy and reached a correct answer about four times sooner.

**L2 - Diagnose.** This one shipped in v1.8.3. Hit Diagnose on a misbehaving resource and your own agent CLI (Claude Code, Codex, or Cursor - local, keyless, no account) investigates over the read-only mount, then hands back a root cause, a specific proposed fix, and a coarse confidence band. It will also conclude "healthy" or "inconclusive" when that's the truth. We spent real effort on the inconclusive path - an engine that can't say "I don't know" shouldn't be trusted with a fix.

**L3 - the gated apply.** One click, behind a confirmation that previews exactly what will change. GitOps-managed resources get an extra acknowledgment, and after applying, Radar re-checks health instead of declaring victory. Every action runs under your RBAC identity via impersonation, and [Radar Cloud](/blog/introducing-radar-cloud) adds the org view: a list of every agent and token that can reach your clusters, each one revocable in one click, with an audit trail behind it. That's the red button.

We have not shipped L4, and by this post's own rules we shouldn't yet: bounded autonomy needs envelopes you can actually write down, per-verb track records to justify promotions, and reports worth reading at 9am. That's what we're building toward, in the open.

## Ask your team the question

Here's the exercise. It takes half an hour, and it's worth doing before you flip on any tool's write mode. List the five verbs an agent would most plausibly run against your clusters. For each one, ask both questions: woken to approve, or read at 9am? And if it chose wrong, is 9am too late? Disagreements are the interesting part - when the platform lead says L4 and last week's on-call says L2, that conversation was overdue anyway.

You end up with a one-page envelope document. The verbs everyone agreed on are your L4 candidates, everything contested stays behind an approval, and the irreversible ones go on the never list. It's the page most "autonomous AI SRE" rollouts skip.

If you want an L1-L3 substrate to run the exercise against:

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

Point your agent at the MCP endpoint, break something in staging on purpose, and see where your own 3am line falls.


---

### Radar v1.8: Applications, Rebuilt Navigation, and Helm Upgrade Tracking

- **URL**: https://radarhq.io/blog/radar-v1-8
- **Date**: 2026-07-15
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Announcements
- **Tags**: radar, radar-cloud, kubernetes, helm, mcp, open-source


Radar v1.8 is out. It's a big one: new features, deep enhancements, and a new navigation and search experience.

## Applications

Radar now smartly groups related resources into logical Applications, based on signals like Helm, Argo, Flux, common labels and resource names. Nobody thinks about their app as a pile of replicasets - the Applications view collects everything that makes up an app in one place. On Radar Cloud, the view extends across your fleet, so you can compare an application across the clusters you connect.

<RadarScreenshot
  src="/images/blog/radar-v1-8-applications-list.webp"
  alt="The Radar Applications view: workloads grouped into the apps they form, with each app's source (Argo CD, Helm, label) and health surfaced inline"
/>

## Navigation and search, redesigned

A ground-up rebuild: a modern sidebar with room for everything Radar now does, and a global search that finds anything, from anywhere, in a couple of keystrokes.

<RadarScreenshot
  src="/images/blog/radar-v1-8-search.webp"
  alt="Radar's global search with a kind: Deployment filter pill applied, ranking matching workloads across every namespace in the cluster"
/>

## Helm

A more complete Helm operations experience: custom registry tracking, side-by-side version comparisons, and upgrade tracking that includes failed and rolled-back releases.

<RadarScreenshot
  src="/images/blog/radar-v1-8-helm-compare.webp"
  alt="Comparing two Helm revisions in Radar: release metadata diffed field by field, with the rendered manifest diff and add/remove counts for values, resources and hooks"
/>

## Large clusters

Performance improved across the board, comfortably handling tens of thousands of resources per cluster, with fallbacks and controls to limit what Radar watches in extreme cases.

## Issues

Now a top-level view. Radar groups or links related items when it has high confidence, so you get less noise and faster root cause analysis. Issues are linked from related resources and from the relevant MCP tools, so neither you nor your agents miss anything important.

<RadarScreenshot
  src="/images/blog/radar-v1-8-issues.webp"
  alt="The Radar Issues view: live cluster problems grouped by the resource they affect, each with a category, severity and the underlying detail - scheduling failures, crash loops, a stuck Helm release, blocked evictions"
/>

## AI

Radar MCP now speaks Prometheus: your agent can query any Prometheus-compatible metrics source in the cluster (VictoriaMetrics, Mimir, etc.). On Radar Cloud, you can connect your AI agent over OAuth instead of managing tokens.

## Get it

Radar stays a single Go binary, fully open source (Apache-2.0): local-first, no account, nothing to assemble, no plugins to manage, with 24 integrations for the ecosystem's most popular tools built in. Run it on your laptop as a binary or native desktop app, or in-cluster for team-wide access.

Install and run in 15 seconds (brew/krew/helm/scoop/apt/rpm in the repo):

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

Full changelog: [radarhq.io/changelog](https://radarhq.io/changelog)


---

### MCP for Kubernetes: Live Cluster Context for AI Tools

- **URL**: https://radarhq.io/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools
- **Date**: 2026-07-10
- **Author**: Roy Libman, CPO, Skyhook
- **Category**: Engineering
- **Tags**: radar, kubernetes, mcp, ai, claude, cursor


The first time I asked Claude to debug a CrashLoopBackOff via raw `kubectl` access, it spent 4,000 tokens parsing a single Pod's YAML before it noticed the OOMKilled status condition. The condition was the second-to-last field. Everything before it was `managedFields`, status I didn't ask for, and annotations that had nothing to do with the question.

That's the failure mode of giving an AI raw cluster access. The tool works - it can read, it can run commands - but the signal-to-token ratio is terrible. You burn budget on noise before getting to the useful part, and even then the AI has no idea which events relate to which workload, what's owned by what, or which Secret values it must never read.

Radar ships a built-in [Kubernetes MCP server](/product/mcp) that fixes this, using the open [Model Context Protocol](https://modelcontextprotocol.io). Same surface area as the UI, packaged for token efficiency and protected by your existing RBAC.

![Radar MCP for AI tools](/images/blog/mcp-for-kubernetes-hero.png)

## What's wrong with raw kubectl

Three things break when you point an AI at unfiltered cluster access.

**Token waste.** A single `kubectl get pod -o yaml` is 2-3 KB of `managedFields`, internal annotations, and status fields nobody asked for. Across a namespace with 80 pods, you're spending ten thousand tokens before the AI has even seen one useful piece of state.

**No correlation.** Raw output doesn't relate Pods to Services to Ingresses, doesn't dedupe events, doesn't know which logs are interesting. When you ask "why is the api Deployment unhealthy?", the AI has to fetch the Deployment, then the ReplicaSet, then the Pods, then the events, then the logs - five separate tool calls, each returning more raw YAML, each costing tokens. Most of the round-trips you can skip if the tool surface is shaped right.

**Unrestricted writes.** kubectl can modify or delete anything the user behind the kubeconfig can. Giving an AI agent that level of authority makes you nervous, and it should. Even with `--dry-run=client` everywhere, one missed flag and you've nuked a production resource.

## What Radar's MCP server gives an AI instead

Four properties that change the math.

**Resources are minified.** `managedFields`, `last-applied-configuration`, redundant status fields, and internal annotations are stripped before they hit the wire. The meaningful spec and status are kept. A Pod that costs 3 KB through raw `kubectl` typically costs ~600 bytes through Radar's MCP. You can fit ten times more cluster into the same context window.

**Resources are enriched.** `get_resource` accepts an `include` parameter (`events,relationships,metrics,logs`) that returns the related signals in one call. Topology relationships, deduped events, secret-safe logs, observed metrics. The AI doesn't have to build a mental model of how Kubernetes objects own each other - the tool answers correlation questions directly.

**Writes are explicit, not shell access.** No raw `delete`. No force-uninstall. No arbitrary shell. The write tools are a bounded set: `apply_resource`, `patch_resource`, `manage_workload` (restart, scale, rollback), `manage_rollout` (abort, retry, promote, fully promote, advance one step), `manage_cronjob` (trigger, suspend, resume), `manage_gitops` (sync, reconcile, suspend, resume), and `manage_node` (cordon, uncordon, drain). They're annotated as mutating or destructive where appropriate so MCP clients can present confirmation UI, and most read-only AI workflows never touch them.

**Secrets and tokens are scrubbed.** Secret `.data` and `.stringData` never leave the cluster. Env values get redacted by pattern. Log lines are scrubbed for known secret shapes (API keys, JWTs, base64 blocks of suspicious entropy). The AI literally cannot see a Secret value, even if you ask it to.

## The tool list

Compact view of the OSS tools wired up today. Cloud adds org-level tools such as `list_clusters` and fleet-wide tools on `/mcp`.

| Read tool | What it returns |
| --- | --- |
| `get_dashboard` | Cluster health overview - counts, problems, warnings, Helm status, recent changes |
| `list_resources` | Resources of a kind, minified summaries |
| `get_resource` | One resource, optionally with `events,relationships,metrics,logs` |
| `get_topology` | Resource relationships graph (or text summary) |
| `get_events` | Recent events, deduplicated, optionally scoped to a resource |
| `get_pod_logs` | Filtered logs (errors / warnings prioritized, secrets scrubbed) |
| `get_workload_logs` | Aggregated logs across pods of a workload |
| `list_namespaces` | Namespaces with status |
| `get_changes` | Recent resource changes from the timeline |
| `list_helm_releases` | Helm releases with status |
| `get_helm_release` | Detailed release info; optional `values,history,diff` |
| `list_packages` | What's installed across Helm, workload labels, CRDs, Argo CD Applications, and Flux. Each row carries a `sources` array so you can see why a package was detected, plus per-source health and version |
| `get_cluster_audit` | Cluster audit findings, filterable by category and severity |
| `get_cluster_upgrade_readiness` | Evidence-backed upgrade impact for a target Kubernetes minor |
| `issues` | Ranked stream of what's broken right now |
| `diagnose` | Root-cause a workload or GitOps reconciler with the causal chain assembled |
| `get_neighborhood` | Focused topology around one resource |
| `get_subject_permissions` | Effective RBAC for a user, group, or ServiceAccount |
| `search` | Find resources by name, labels, env refs, images, config keys, or content |
| `top_resources` | Live CPU and memory usage ranked with workload context |
| `query_prometheus` | Run PromQL against the cluster's Prometheus |
| `discover_metrics` | Discover metric names and metadata from Prometheus |
| `get_prometheus_rules` | Prometheus alerting and recording rules with current state |

| Write tool | What it does |
| --- | --- |
| `apply_resource` | Create / update from YAML, multi-doc, supports `dry_run` |
| `manage_workload` | restart / scale / rollback Deployments, StatefulSets, DaemonSets, and Argo Rollouts |
| `manage_rollout` | abort / retry / promote / fully promote / advance one step of an Argo Rollout |
| `manage_cronjob` | trigger / suspend / resume |
| `manage_gitops` | Argo or Flux: sync / reconcile / suspend / resume |
| `manage_node` | cordon / uncordon / drain |
| `patch_resource` | JSON Patch, merge patch, or strategic merge patch against one resource |

There's also a `cluster://` URI scheme for the resource style: `cluster://health`, `cluster://topology`, `cluster://events`. Useful for MCP clients that prefer resources over tool calls.

## Setup

OSS Radar exposes MCP on the same port as the UI (default `9280`), localhost-only.

For Claude Code:

```bash
claude mcp add radar --transport http http://localhost:9280/mcp
```

For Cursor (`~/.cursor/mcp.json`):

```json
{ "mcpServers": { "radar": { "url": "http://localhost:9280/mcp" } } }
```

For Claude Desktop (`~/Library/Application Support/Claude/claude_desktop_config.json`):

```json
{
  "mcpServers": {
    "radar": {
      "type": "http",
      "url": "http://localhost:9280/mcp"
    }
  }
}
```

Windsurf, VS Code Copilot, JetBrains AI, OpenAI Codex, Gemini CLI - same shape, different config file. The [MCP docs](https://radarhq.io/docs/features/mcp) cover each in detail, along with the complete tool catalog and security model.

For Cloud, the default is one org-level MCP endpoint gated by OAuth or a personal access token:

```json
{
  "mcpServers": {
    "radar-cloud": {
      "type": "http",
      "url": "https://api.radarhq.io/mcp",
      "headers": { "Authorization": "Bearer rhp_..." }
    }
  }
}
```

The dashboard's **Connect an AI client** wizard auto-fills the snippet for whichever tool you pick. Cloud exposes `list_clusters` on the org endpoint, so a multi-cluster AI workflow can ask "what clusters do I have access to?" without you hardcoding cluster IDs. You can also scope a token to one cluster; that snippet uses `https://api.radarhq.io/c/<cluster_id>/mcp`.

## RBAC: the part that surprised some early users

Each MCP call goes through Kubernetes with the user's identity, not a shared agent identity. In OSS, that's whatever your kubeconfig grants. In Cloud, the in-cluster Radar pod impersonates the user (via `X-Forwarded-User` and `X-Forwarded-Groups` headers injected by Cloud), so a `cloud:viewer` user's MCP calls hit the cluster as a `view`-level identity. A 403 from K8s comes back as a 403 from MCP.

This means an AI agent inherits the permissions of whoever's running it. A read-only engineer's AI can read. An admin's AI can write the things admins can write. Nobody has to maintain a "service account for AI" that's secretly more privileged than the humans using it.

## What this changes about debugging

The honest answer is that it changes a workflow, not a productivity multiplier.

A typical debugging session with this in place looks like:

1. Page fires, you open the AI chat.
2. "The api Deployment in prod is unhealthy. What changed in the last hour?"
3. AI calls `get_dashboard`, then `get_resource Deployment/api include=events,relationships`, then `get_changes since=1h kind=ConfigMap namespace=prod`.
4. AI reports back: "ConfigMap `api-config` was patched 47 minutes ago. The `cache.preload_on_startup` field flipped from `false` to `true`. The first OOMKill on the api pods was 3 minutes after that."
5. You decide whether to revert.

It's not magic. The AI didn't fix anything. It just stitched the timeline together using tools that knew how Kubernetes objects relate to each other. Without MCP, that stitch takes the AI a lot of token-expensive raw YAML reads to figure out, and it's about a 50/50 shot whether it gets there before context runs out.

With it, the stitch is the first three tool calls, and the answer is in the first response.

## What MCP isn't

Two honest gaps.

**Not a replacement for the UI.** I use both. MCP is for "I want to ask a question and get an answer." The UI is for "I want to see the shape of the cluster and decide what to do." They serve different jobs.

**Not a replacement for runtime safety.** The write tools are explicit and narrower than a raw shell, but they still change real state. `apply_resource`, `patch_resource`, rollback, and drain deserve the same review you would give a human operating against prod - with a dry-run where available, a review, and a willingness to roll back.

## The shape of it

The reason MCP-via-Radar works better than MCP-via-kubectl is that we'd already done the work of minifying, correlating, and securing cluster reads for the UI. Exposing the same surface area to AI tools is a small additional step on top of that, and the result is a context window that doesn't get burned on `managedFields` and a write surface that doesn't let the AI delete prod by accident.

If you're already running Radar, MCP is on by default. If you're not, [install the open-source binary](https://radarhq.io/docs/install), then use one of the client configurations above to point Claude or Cursor at your cluster.

If you're comparing tool surfaces rather than setting one up, see the [five-surface Kubernetes MCP benchmark](/benchmark/kubernetes-mcp-servers) and the broader [Kubernetes MCP server comparison](/kubernetes-mcp-comparison).


---

### Migrating from Lens and OpenLens in 2026

- **URL**: https://radarhq.io/blog/migrating-from-lens
- **Date**: 2026-07-07
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Open source
- **Tags**: kubernetes, lens, openlens, freelens, migration


If you're still running Lens, you've probably noticed the ground shifting under you. The open-source repo no longer matches the commercial desktop product. Lens now requires an account, and organizations above the revenue or funding threshold need a paid plan - [currently starting at $25 per user per month](https://app.k8slens.dev/subscribe). The tool you adopted because it was a free, open desktop UI for Kubernetes is a different product now.

Nobody did anything wrong by picking Lens. It was the right call for years. But if you're reading this, you're probably deciding where to go next, and most "Lens alternatives" articles are written by vendors who conclude, surprisingly, that the answer is their product. We make one of the alternatives, so discount accordingly - but here's the map as we honestly see it.

Lens's licensing shift is the trigger for this decision, not the whole decision. Replacing Lens with another resource browser fixes the account and pricing problem, but not necessarily the operational gaps that made Kubernetes hard in the first place: understanding what connects to what, what changed before an incident, and where traffic is actually flowing.

## TL;DR

- Want exactly the Lens desktop experience, still free? **Freelens.**
- Want a CNCF-governed, plugin-extensible dashboard? **Headlamp.**
- Live in the terminal? **k9s**, and you probably already know it.
- Want the capabilities we couldn't get from Lens forks or plugin-first dashboards - topology, persistent history, live traffic, GitOps, audit, and agent-ready context - in one no-login tool? That's why we built **Radar**.

Weighing every option line by line? We keep a [full comparison of Lens alternatives](/lens-alternative) and a [detailed Radar vs Lens breakdown](/vs/lens) up to date separately. This post is the decision framework.

## What actually happened to Lens

A quick timeline, because the fork situation confuses everyone:

- **Mid-2022:** Lens 6.0 introduces paid subscription requirements for commercial use.
- **January 2023:** Mirantis moves exec, logs, and shell into proprietary code in Lens 6.3. OpenLens builds lose core features, and community energy starts shifting to forks.
- **June 2023:** OpenLens publishes its [last release](https://github.com/MuhammedKalkan/OpenLens/releases). Its repository now says to expect no more updates because Lens closed its source code.
- **Freelens** emerges as the actively maintained community fork and becomes the real successor for people who want the Lens desktop experience.
- **January 2024:** the original lensapp/lens repo publishes its [last GitHub release](https://github.com/lensapp/lens/releases). Since then, the commercial Lens product and the OSS repo have diverged.
- **Today:** Lens is a commercial desktop product with mandatory login and per-seat pricing for organizations above the revenue threshold.

### On OpenLens? Migrate now

OpenLens is unmaintained software running with powerful credentials against clusters whose API surfaces keep moving. That's the most urgent migration in this article. You do not need to move workloads or change cluster configuration - pick a replacement, point it at the same kubeconfig, and verify the workflows you used in OpenLens.

## Option 1: Freelens - the "I just want my Lens back" path

[Freelens](/vs/freelens) is the actively developed fork, and it's good. Same desktop paradigm, same mental model, no login, no paywall. If your team's muscle memory is Lens-shaped and you want the smallest possible migration, this is the honest recommendation. Point it at your kubeconfig and you're done in minutes.

The tradeoff: it inherits Lens's architecture - an Electron desktop app doing client-side work against the API server, one kubeconfig per laptop. That was Lens's ceiling too. It browses resources well; it doesn't explain a cluster to you.

## Option 2: Headlamp - the CNCF path

[Headlamp](/vs/headlamp) is a CNCF Sandbox project under SIG UI, extensible through plugins, and shipping fast. If your organization weights foundation governance heavily, or you want to assemble a dashboard from plugins to your exact taste, it's a solid choice - and it runs in-cluster as a web app, not only on the desktop.

The tradeoff is the assembly itself: much of the depth arrives via plugins you select, install, and maintain, and the out-of-box experience is a resource browser. We ranked it honestly against everything else in [our 2026 dashboard comparison](/blog/best-kubernetes-dashboards-2026).

## Option 3: k9s - the terminal path

If you're a k9s person, you're not reading a migration guide. [k9s](/vs/k9s) is excellent - it's just answering a different question: fast keyboard-driven resource operations, not visual cluster understanding. Plenty of Radar users keep k9s open in the next pane. Coexist.

## Option 4: Radar - the "understand the cluster" path

Radar exists because neither the Lens family nor plugin-first dashboards gave us the operational view we needed at Skyhook. We wanted one tool that understood the cluster as a connected system, covered the ecosystem we actually ran, and worked equally well for an engineer in the UI and an agent over MCP.

The result is a single Go binary, Apache 2.0, with no login, no account, and no agents to install. Run it locally against your kubeconfig, as a desktop app, or in-cluster as a web UI. Where Lens-style tools show you lists of resources, Radar's core is the relationships: a live topology with ownership chains (Deployment to ReplicaSet to Pods), an event timeline for "what broke first", service traffic, Helm release forensics, and a built-in audit that runs the checks you forgot. It auto-detects 120+ ecosystem CRDs as typed views and topology edges - plus any other CRD in your cluster - instead of asking you to assemble plugins.

Lens has MCP now, so the question is not "MCP or no MCP." It is whether the MCP is a thin kubectl-style bridge or a real cluster-understanding layer. Radar's [built-in MCP server](/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools) gives the agent topology, issues, timelines, relationships, scrubbed logs, and diagnosis tools instead of making it reconstruct the cluster from raw API output.

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

Or Homebrew (`brew install skyhook-io/tap/radar`), a desktop app, or Helm for in-cluster - all four on [the homepage](/).

**Radar's tradeoffs, honestly:** multi-cluster fleet views live in [Radar Cloud](/pricing), a separate per-cluster-priced product - OSS Radar is one cluster at a time. And it's the youngest project on this list: weekly releases mean fast fixes, but also a tool that's still growing into some corners.

## The migration itself

Whatever you pick, the actual migration is undramatic. None requires moving workloads or changing cluster configuration, and the local options read your existing kubeconfig:

1. **Inventory what you actually used in Lens.** Most teams: resource browsing, logs, exec, port-forward, maybe metrics. Everything on this page covers those.
2. **Check your extensions.** Lens extensions don't port anywhere. List what you depended on and find the equivalent - a Headlamp plugin, a Radar integration, or a standalone tool.
3. **Run the new tool alongside Lens for a week.** Nothing about this is one-way.
4. **If you're on OpenLens, don't wait.** Unmaintained software with cluster-admin credentials is not a neutral state.

## Where this leaves you

The Lens story is a reminder to inspect a Kubernetes tool's governance, license, and escape hatches before you standardize on it. It is also a useful moment to decide whether you want continuity or a more capable operating model: Freelens if you want the familiar desktop workflow, Headlamp if you want foundation governance, k9s if you want the terminal, Radar if you want the cluster explained rather than listed.

Radar is open source and takes about two minutes to try against a real cluster: [github.com/skyhook-io/radar](https://github.com/skyhook-io/radar). If it doesn't answer a question kubectl couldn't, delete the binary and keep the two minutes as a story.


---

### The Best Kubernetes Dashboards in 2026 (Including Our Competitors)

- **URL**: https://radarhq.io/blog/best-kubernetes-dashboards-2026
- **Date**: 2026-06-13
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Open source
- **Tags**: kubernetes, dashboard, comparison, open-source, tools


Let's get the disclosure out of the way: we build Radar, one of the tools on this list. You should weigh everything below accordingly. We've tried to make this the list we wish existed when we were evaluating - including being clear about where the other tools beat ours.

Some context for why this list looks different from the 2024 version of every "best Kubernetes dashboard" post: the official **Kubernetes Dashboard was retired in January 2026** - archived, unmaintained, no more security patches. Thousands of clusters are quietly running an EOL web UI right now. If that's you, the question isn't *whether* to move, it's where.

Here's the field, organized by what you're trying to do.

## TL;DR - pick by use case

| You want... | Pick |
|---|---|
| The fastest tool for terminal people | **k9s** |
| A semi-official, vendor-neutral project (governance over features) | **Headlamp** |
| One shared web view with topology, history, and GitOps in core | **Radar** (ours) |
| Lens, but without the subscription | **Freelens** |
| Docker + Swarm + K8s in one platform | **Portainer** |
| A commercial desktop IDE anyway | **Aptakube**, or **Lens** if you want its team-collaboration layer |

## 1. k9s - the terminal standard

**Apache 2.0 · ~34k stars**

If everyone who needs cluster visibility at your org is comfortable in a terminal, install k9s and stop reading. It's keyboard-first, instant, and has earned every one of its stars. Resource browsing, logs, exec, port-forwards - all faster than any web UI on this list, ours included.

What it isn't: a dashboard you can hand to someone who expects a URL. No topology, no shared views, no history. Most teams we talk to run k9s *and* a web UI - they solve different moments.

## 2. Headlamp - the semi-official option

**Apache 2.0 · ~7.1k stars · Kubernetes SIG UI**

Headlamp's real selling point is governance. SIG UI named it the recommended Dashboard replacement, it's vendor-neutral, and it'll outlive any single company's roadmap. If a semi-official project is a hard requirement for your org, that's a legitimate reason to pick it, and the only one we'd lean on.

As a tool, it's a resource browser with a basic built-in resource map, extended by a plugin catalog. The official plugins are real and growing - Flux, OpenCost, Prometheus, Helm (app catalog), cert-manager, KEDA, Karpenter, and an alpha AI assistant (BYO model key) - but you install and version each one yourself, and the catalog has real gaps. GitOps comes as two separate installs: the official Flux plugin, plus an [Argo CD plugin](https://github.com/headlamp-k8s/plugins/tree/main/argocd) that joined the official catalog in mid-2026 and is still early (0.x, an LFX mentorship project). There's nothing for service-traffic flow, and nothing for a persistent event timeline. It replaces what Dashboard was; it doesn't change what Dashboard wasn't.

## 3. Radar - ours, so judge accordingly

**Apache 2.0 · ~2.9k stars · single Go binary**

Radar is what we wanted during incidents: one tool with the resource browser *plus* the things you reach for when something's on fire - live topology, an event timeline that persists past the API server's ~1 hour memory, log streaming, exec, Helm management, GitOps status for ArgoCD and Flux, traffic visibility, and a 36-check best-practices audit. In core, not as plugins.

The coverage also runs unusually wide: it renders 120+ ecosystem CRDs as typed views and topology edges - Argo CD, Flux, Istio, Karpenter, cert-manager, KEDA, Prometheus, Trivy, Crossplane, Velero and more - all compiled into the binary, not bolted on as plugins. The generic browsers here just show you the raw object; Headlamp covers a chunk of this, but only after you install and version each plugin yourself.

On AI, Radar skipped the bundled chatbot and bet on agents instead: it ships [an MCP server](/blog/mcp-for-kubernetes-live-cluster-context-for-ai-tools) - free, on by default, with read tools purpose-built for cluster context - so the agent you already use (Claude, Cursor, your own) reasons over live cluster state directly. Lens and Headlamp are adding AI of their own, but we deferred an in-app chat on purpose. Our [54-fault SREGym benchmark](/benchmark) supports that bet: across the 44 faults both arms solved, the same model reached a correct diagnosis in a median 41 seconds through Radar versus 154 through kubectl.

Shipping an MCP server is no longer unusual on its own: [Portainer](https://github.com/portainer/portainer-mcp), [Rancher](https://github.com/rancher/rancher-ai-mcp), [KubeSphere](https://github.com/kubesphere/ks-mcp-server) and [Lens](https://docs.k8slens.dev/k8slens/mcp-server/) all ship first-party ones, and Headlamp is an MCP *host* that connects to external servers rather than exposing one, which is a different thing again. What separates ours is where it lives: in the free Apache-2.0 binary with nothing to install in the cluster, where Rancher's and Lens's sit behind paid tiers and KubeSphere's hasn't been touched since May 2025.

The mechanics: `brew install skyhook-io/tap/radar`, then `kubectl radar` - a single compiled binary that reads your kubeconfig and opens a browser, zero cluster-side install. Run it locally, as the desktop app, or as a shared in-cluster instance with SSO and RBAC that respects each viewer's real cluster permissions - not the per-laptop-kubeconfig world the desktop clients live in.

The one tool on this list we recommend without reservation alongside Radar: k9s. If you live in the terminal, it's faster, and plenty of our own users run both.

## 4. Freelens - Lens without the license

**MIT · ~5.4k stars**

Lens moved exec, logs, and shell into proprietary code in 2023 and requires a paid per-user subscription for commercial use. Freelens is the actively maintained community fork that restored what the open builds lost. You get the familiar Lens layout - multi-cluster switching, resource views, live metrics (with metrics-server installed), and the exec/logs/shell OpenLens dropped - and most Lens extensions still load.

If your team likes the desktop-IDE model and your only problem is the subscription, this is the shortest move: same Electron architecture, same per-laptop kubeconfig world. (Weighing the whole Lens-exit decision? We compared [every Lens alternative](/lens-alternative) in one place.)

## 5. Portainer - when Kubernetes is only part of the estate

**Open-core · ~38k stars**

Portainer is broader than everything else here: Docker, Swarm, and Kubernetes under one roof, with its own RBAC, teams, app templates, and git-based deployments - plus an edge agent that reaches remote or air-gapped clusters. The free Community Edition covers most of that; the Business Edition adds org-scale access controls. For mixed container estates - especially ones with a hosting/homelab flavor - that breadth is the point; for a Kubernetes-only platform team it's more platform than you need, and the K8s-native views are shallower than the focused tools here.

## 6. Lens - the incumbent

**Proprietary (MIT core repo) · ~$22-35/user/mo for commercial use**

Lens's strengths: it's stable, it's been around since 2016, and a lot of engineers have muscle memory in it. It also bundles two things the open desktop clients here don't - Lens Teamwork, a cloud layer for shared team spaces and access control, and Prism, a built-in AI chat panel for natural-language troubleshooting. The AI piece is no longer a differentiator, though - Headlamp ships an assistant plugin too, and Radar's MCP route (above) skips the in-app bot entirely.

That's where the credit ends. You're paying per seat, per month, for a per-laptop Electron app whose open-source story collapsed in 2023 when exec, logs, and shell moved into proprietary code - and everything you're paying for, minus Lens Teamwork, is available free elsewhere on this list. If muscle memory is the tie-breaker, Freelens keeps it without the invoice. [Detailed comparison](/vs/lens) if you want it line by line.

## 7. Aptakube - the indie desktop client

**Closed source · paid per seat**

Credit first: it's a real native app rather than an Electron bundle, it starts fast, and the side-by-side multi-cluster tabs are excellent UX - impressive for a solo-developer project. If you specifically want a paid native desktop client, it's the better-executed version of that idea than Lens.

The limits are structural rather than quality: closed source, per seat, per laptop, single user - nothing shared, no history. Whether that matters depends entirely on whether you're tooling up yourself or a team.

## What about the old Kubernetes Dashboard?

Don't start there in 2026 - it's archived and unpatched. If you're migrating off it, we wrote a [dedicated migration guide](/kubernetes-dashboard-alternative) covering all the successor options, including the official one.

## The full comparison

The seven picks above are the ones most teams should actually choose between. This is the rest of the field, sixteen tools including the archived ones, because roundups still recommend them.

Every capability value is `yes`, `no`, `partial`, `paid`, or `?` where nobody has verified it yet. Definitions are below the table, so a cell can be argued with on the definition rather than on vibes, and every non-obvious value is linked to its source. The numbers regenerate weekly from the GitHub API, so this doesn't quietly rot. The [underlying data](https://github.com/skyhook-dev/marketing/blob/main/content/radar/_data/kubernetes-ui-tools.yaml) is CC0: copy it into your own article without asking.

Radar's losses are in here. Ten of these have more stars than we do, and multi-cluster is free and unlimited for Headlamp, Rancher, KubeSphere, Karpor, Devtron and kubewall, where ours is capped at three clusters before you pay. The wins are in the same table: Radar's is the only row that scores `yes` across topology, event timeline, Helm, GitOps and MCP server at once, and all five of those ship in the free Apache-2.0 binary, with nothing installed in the cluster.

{/* BEGIN GENERATED CAPABILITIES */}

| Tool | Interface | Open source | No in-cluster install | Topology view | Event timeline | Helm | GitOps | MCP server | Multi-cluster free |
|---|---|---|---|---|---|---|---|---|---|
| k9s | terminal | yes | yes | no | no | yes | no | no | partial |
| Lens | desktop | no | yes | partial | no | yes | paid | paid | paid |
| Freelens | desktop | yes | yes | partial | no | yes | partial | no | partial |
| Headlamp | web + desktop | yes | yes | yes | no | yes | partial | no | yes |
| Kubernetes Dashboard | web | yes | no | no | no | no | no | no | no |
| Octant | web | yes | yes | yes | no | no | no | no | no |
| Rancher | web | yes | no | no | no | yes | yes | yes | yes |
| Portainer | web | partial | no | no | no | yes | yes | yes | partial |
| Devtron | web | partial | no | ? | ? | yes | yes | no | yes |
| KubeSphere | web | yes | no | ? | ? | yes | yes | yes | yes |
| Kubevious | web | yes | no | yes | yes | no | ? | no | no |
| Skooner | web | yes | no | no | no | no | no | no | no |
| Karpor | web | yes | no | yes | ? | ? | ? | no | yes |
| kubewall | web | yes | yes | no | no | no | no | no | yes |
| Aptakube | desktop | no | yes | no | no | ? | no | no | paid |
| Radar | web + desktop | yes | yes | yes | yes | yes | yes | yes | partial |

#### Notes and sources, tool by tool

- **k9s.** Sources: [Helm](https://k9scli.io/topics/commands/).
- **Lens.** Repo last pushed 2025-02-11; development moved to the proprietary, subscription-only product, now branded Lens x Mirantis. It ships a first-party MCP server with read-only kubectl and Prometheus tools, on paid tiers, which is what paid means in that cell. GitOps is Flux only and also paid, and topology depends on extensions rather than the core app. Sources: [licensing](https://github.com/lensapp/lens), [GitOps](https://docs.k8slens.dev/k8slens/flux-cd/), [MCP](https://docs.k8slens.dev/k8slens/mcp-server/).
- **Freelens.** Community fork of OpenLens, actively released. Topology and GitOps come through extensions: an official Resource Map, an official Flux extension and a community-maintained Argo CD one, which is why those cells are partial rather than yes. Sources: [topology](https://github.com/freelensapp/freelens-resource-map-extension), [Helm](https://www.virtualizationhowto.com/2025/06/freelens-is-an-open-source-and-free-kubernetes-ide-for-2025/), [GitOps](https://github.com/freelensapp/freelens-fluxcd-extension).
- **Headlamp.** CNCF Sandbox project, under kubernetes-sigs. Its MCP support is client-side: Headlamp acts as an MCP host that connects to external MCP servers, rather than shipping one that exposes the cluster to an agent. That is a genuinely useful feature, and it is not what this column measures, which is why it scores no. GitOps is partial because both the Flux plugin and the newer Argo CD plugin, which arrived mid-2026 and is still 0.x, are catalog installs rather than core. Sources: [topology](https://headlamp.dev/blog/2025/01/17/making-sense-of-kubernetes-with-headlamps-map-view/), [Helm](https://headlamp.dev/docs/latest/), [GitOps](https://github.com/headlamp-k8s/plugins), [MCP](https://headlamp.dev/docs/latest/learn/mcp-support/).
- **Kubernetes Dashboard.** Archived. Retired by the Kubernetes project, no security updates.
- **Octant.** Archived since 2022. Listed because roundups still cite it.
- **Rancher.** Cluster management platform, broader in scope than a dashboard. MCP verified 2026-07-26: rancher-ai-mcp is first-party and genuinely exposes a server, running as a Kubernetes deployment and serving resource inspection and mutation tools across local and downstream clusters. Two caveats worth knowing rather than penalizing them for: SUSE describes it as embedded in Rancher Prime, which is the commercial tier, and the repo currently carries no license file. Scored yes rather than paid because the server itself is public and active. Where the evidence is ambiguous, this table resolves in the competitor's favor. Sources: [MCP](https://github.com/rancher/rancher-ai-mcp).
- **Portainer.** Sources: [MCP](https://github.com/portainer/portainer-mcp).
- **Devtron.** Sources: [MCP](https://github.com/devtron-labs/devtron).
- **KubeSphere.** MCP verified 2026-07-26: ks-mcp-server sits in the first-party org, so it scores yes, but it was last pushed 2025-05-07 and has not been touched in over a year. This column measures existence, not liveness. Sources: [MCP](https://github.com/kubesphere/ks-mcp-server).
- **Kubevious.** Sources: [event timeline](https://kubevious.io/docs/features/time-machine/).
- **Skooner.** Last push 2024-06-30, maintenance appears stalled.
- **Karpor.** Checked 2026-07-26: the product overview lists Search / Insight / AI, with "Natural Language Operations" and "AIOps" described as direction rather than a shipped MCP server. Event timeline, Helm and GitOps are left unverified because the overview does not address them either way. Sources: [topology](https://karpor.kusionstack.io/), [MCP](https://kusionstack.io/karpor/).
- **kubewall.** Single binary, browser-based. Five cells were resolved 2026-07-26 against the README feature list, which is explicit and does not include topology, retained event history, Helm release management or GitOps. Its AI feature calls out to OpenAI, Claude, Gemini, Ollama and similar for troubleshooting, so it consumes AI rather than exposing a server, the same distinction applied to Headlamp. The repo notes active development, so these may change. Sources: [features](https://github.com/kubewall/kubewall).
- **Aptakube.** Closed source, no public repo, so the maintenance table below can only mark it proprietary. The whole application is a subscription after a 15-day trial, which is why multi-cluster is paid along with everything else. Sources: [MCP](https://aptakube.com/), [pricing](https://aptakube.com/pricing).
- **Radar.** Ours, and we maintain this table, so weigh it accordingly. Every yes in this row refers to the free Apache-2.0 binary, run from a kubeconfig with nothing installed in the cluster - not to a paid tier. Multi-cluster is partial because the free hosted tier aggregates up to three clusters; unlimited clusters and long-term event retention are paid. Sources: [pricing](https://radarhq.io/pricing), [features](https://radarhq.io/docs).

{/* END GENERATED CAPABILITIES */}

### What the columns mean

**Interface.** `terminal` is a TUI, `desktop` is an installed application, `web` is served in a browser.

**Open source.** `yes` means an OSI-approved license covering the product you actually run. `partial` marks open core. Lens is `no` despite a public repo, because the shipping product has been proprietary since 2023.

**No in-cluster install.** Can you get a working UI by pointing the tool at an existing kubeconfig, without deploying anything into the cluster? The most practical dividing line in the category and the one most roundups omit.

**Topology view.** A rendered graph of relationships, not a filtered list. A resource table with a details pane is `no`.

**Event timeline.** Can you see what changed and when, past the point where Kubernetes drops the event? Kubernetes discards events after roughly an hour, so surfacing the live stream alone is `partial`. `yes` means the tool retains history itself.

**Helm.** Browsing and managing installed releases, not merely rendering a chart.

**GitOps.** First-party awareness of Argo CD or Flux state. Plugin-only support is `partial`.

**MCP server.** Does the tool ship a Model Context Protocol server so an agent can query the cluster through it? This measures *exposing* a server, not *consuming* one: a tool that connects to external MCP servers as a host scores `no`.

**Multi-cluster free.** Viewing several clusters at once without paying. Switching contexts one at a time is `partial`, and so is a free tier capped at a handful of clusters - which is where Radar sits.

### Maintenance status

{/* BEGIN GENERATED TABLE */}

_Figures from the GitHub API, last updated 2026-08-15. Refreshed weekly._

| Tool | License | Stars | Latest release | Last commit | Status |
|---|---|---:|---|---|---|
| [Portainer](https://github.com/portainer/portainer) | Zlib | 38,246 | 2.39.6 (2026-08-12) | 2026-08-14 | active |
| [k9s](https://github.com/derailed/k9s) | Apache-2.0 | 34,353 | v0.51.0 (2026-06-06) | 2026-08-14 | active |
| [Rancher](https://github.com/rancher/rancher) | Apache-2.0 | 25,853 | v2.15.0 (2026-07-30) | 2026-08-14 | active |
| [Lens](https://github.com/lensapp/lens) | MIT | 23,215 | v2024.1.300751-latest (2024-01-31) | 2025-02-11 | stale (>6mo) |
| [KubeSphere](https://github.com/kubesphere/kubesphere) | see repo | 17,031 | helm-chart-1.1.5 (2025-04-18) | 2026-07-15 | active |
| [Kubernetes Dashboard](https://github.com/kubernetes-retired/dashboard) | Apache-2.0 | 15,424 | kubernetes-dashboard-7.14.0 (2025-10-30) | 2026-01-21 | **archived** |
| [Headlamp](https://github.com/kubernetes-sigs/headlamp) | Apache-2.0 | 7,077 | v0.44.0 (2026-07-29) | 2026-08-14 | active |
| [Octant](https://github.com/vmware-archive/octant) | Apache-2.0 | 6,241 | v0.25.1 (2022-02-24) | 2023-01-19 | **archived** |
| [Devtron](https://github.com/devtron-labs/devtron) | Apache-2.0 | 5,579 | v2.2.0 (2026-07-21) | 2026-08-14 | active |
| [Freelens](https://github.com/freelensapp/freelens) | MIT | 5,390 | v1.10.3 (2026-07-07) | 2026-08-14 | active |
| [Radar](https://github.com/skyhook-io/radar) | Apache-2.0 | 2,914 | v1.10.0 (2026-08-12) | 2026-08-14 | active |
| [kubewall](https://github.com/kubewall/kubewall) | Apache-2.0 | 1,925 | v0.0.21 (2026-07-26) | 2026-08-14 | active |
| [Karpor](https://github.com/KusionStack/karpor) | Apache-2.0 | 1,731 | v0.6.4 (2025-04-02) | 2026-07-12 | active |
| [Kubevious](https://github.com/kubevious/kubevious) | Apache-2.0 | 1,706 | v1.1 (2022-10-12) | 2026-06-13 | active |
| [Skooner](https://github.com/skooner-k8s/skooner) | Apache-2.0 | 1,441 | alpha0.0.1 (2021-06-25) | 2024-06-30 | stale (>6mo) |
| Aptakube | closed source | n/a | n/a | n/a | proprietary |

{/* END GENERATED TABLE */}

### What is deliberately not in the table

**Performance and memory.** No trustworthy cross-tool benchmark exists, and a vendor-run one would not be credible.

**Ease of use.** Not measurable without user research nobody here has done.

**Pricing.** Changes too fast to keep honest at this refresh cadence.

**Security posture.** Deserves real analysis rather than a checkbox.

If a cell is wrong, [email us](mailto:radar@skyhook.io) with a source and we'll fix it, including cells that flatter us.

## How to actually decide

Three questions settle it faster than any feature matrix:

1. **Who consumes it?** Terminal people → k9s. Engineers plus everyone else → a web UI (Radar, or Headlamp if vendor-neutral governance outranks features for you). Desktop-IDE devotees → Freelens.
2. **Do you need memory?** If "what happened at 3am?" is a question you ask, you need persisted event history - that's Radar's core bet, and largely unaddressed elsewhere on this list.
3. **Assembled or assembly kit?** Headlamp gives you governance and a plugin kit you assemble; Radar ships the integrated set in one binary. Both are Apache 2.0 - trying both takes one afternoon.

If we've misrepresented any tool here, [email us](mailto:radar@skyhook.io) and we'll fix it.


---

### SSO and RBAC Without Passing Around Kubeconfigs

- **URL**: https://radarhq.io/blog/sso-and-rbac-without-passing-around-kubeconfigs
- **Date**: 2026-06-11
- **Author**: Roy Libman, CPO, Skyhook
- **Category**: Platform
- **Tags**: radar-cloud, sso, rbac, platform-engineering, identity


A contractor starts Monday. They need read-only access to your staging cluster for a four-week engagement. Nothing more.

Without something better than kubeconfigs, this is a ticket that bounces between you, IT, and security for a week. Someone generates a kubeconfig. Someone else argues about whether to create a dedicated ServiceAccount or reuse one. Security asks how you'll revoke when the contract ends. Nobody has a clean answer. The contractor spends their first three days reading docs.

Radar Cloud's access model is built around a different split:

- **Cloud authenticates the human** and decides which org they belong to.
- **The in-cluster Radar pod impersonates** that human's Cloud role against the Kubernetes API.
- **Kubernetes RBAC decides** what the request can actually do.

No shared kubeconfig to pass around.

![Radar RBAC](/images/blog/radar-rbac-hero.png)

## Why kubeconfig falls apart at team scale

Kubeconfig wasn't designed for this. It was designed for an operator with a laptop talking to a cluster. Everything that's awkward about it for teams is a consequence of using it past that point.

- **Client certificates are long-lived by default.** Once minted, they sit in someone's `~/.kube/config` until they expire. Revoking a leaked cert means rotating the cluster CA, which nobody does.
- **Scoping is a RoleBinding exercise.** You can do it, but you end up with a matrix of ServiceAccounts, Roles, and RoleBindings across clusters. For a fleet of ten clusters, that's ten places to update when someone changes teams.
- **No native link to your IdP.** Your company already has Okta or Entra ID. Kubeconfig doesn't know anything about it. You can wire OIDC into the API server, but that's per-cluster plumbing, and it still doesn't give you group-to-role mapping for free.
- **Audit trails are thin.** API server audit logs tell you that `kubernetes-admin` did a thing. They don't tell you which human that was, unless you've done the OIDC work above.

This isn't a criticism of Kubernetes. Kubeconfig is fine for what it is. It's just that "onboard a contractor in an hour with scoped, revocable, auditable access" isn't what it's for.

## How Radar Cloud handles it

Two ideas, both boring on purpose.

**SSO is the front door.** Every plan signs in with Google or GitHub, including Free - identity isn't an "enterprise upsell" gate at the entry level. Corporate SSO - SAML and OIDC, including Okta, Entra ID, Google Workspace, OneLogin, and any spec-compliant provider - is available on Enterprise. Radar Cloud uses WorkOS as its identity-provider abstraction, and setup is self-serve: an owner clicks **Set up SSO** in the dashboard, lands in the WorkOS Admin Portal, configures the IdP there, and saves. We don't sit between you and your IdP for setup.

**Cloud roles map to standard Kubernetes RBAC via impersonation.** This is the part that surprised some early users in a good way. Radar Cloud doesn't invent a parallel permission system. It maps each user's Cloud role (`owner`, `member`, `viewer`) to a Kubernetes group and lets the in-cluster Radar pod impersonate the user when it talks to the API server.

The Helm chart ships three default ClusterRoleBindings out of the box:

| Cloud role | Group | Bound to ClusterRole |
|---|---|---|
| Owner | `cloud:owner` | `admin` |
| Member | `cloud:member` | `edit` |
| Viewer | `cloud:viewer` | `view` |

Standard K8s built-in ClusterRoles. Nothing custom. If you trust `view`, you trust Viewer. If `edit` is too broad for your members, swap the binding to a custom ClusterRole - it's two lines in `values.yaml`.

```yaml
cloud:
  defaultRbac:
    create: true                     # emit the default bindings
    member: true                     # keep the cloud:member binding
    memberClusterRole: my-edit       # but map it to your custom ClusterRole
```

To disable a tier entirely (e.g. owners only, no members or viewers), set the flag to `false`:

```yaml
cloud:
  defaultRbac:
    member: false
    viewer: false
```

## What the request actually looks like

When a Cloud user clicks into a cluster, the control plane strips inbound `X-Forwarded-*` headers (so they can't be spoofed) and injects:

```
X-Forwarded-User: user_01HF...
X-Forwarded-Groups: cloud:viewer,cloud:org:org_01H...,cloud:user:user_01HF...
```

The in-cluster Radar pod runs in proxy auth mode, sees those headers, and impersonates the user against the K8s API. Whatever permissions you've granted the `cloud:viewer` group (or that specific user via the `cloud:user:...` group) is exactly what they can do. K8s does the gatekeeping. We don't.

If you need finer control - say, "Alice can edit Deployments only in the `apps-prod` namespace" - you bind directly to her per-user group:

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alice-apps-edit
  namespace: apps-prod
subjects:
  - kind: Group
    name: cloud:user:user_01HF...
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
```

That's a regular K8s RoleBinding. `kubectl get rolebindings` works, your existing RBAC tooling works, audit policies on the apiserver capture impersonated calls with the user ID and groups intact.

The blast radius is also easy to reason about: the Radar pod's ServiceAccount is the upper bound, and Kubernetes impersonation narrows each request to the user or role that made it.

## The contractor, end to end

Monday morning:

1. **IT adds the contractor to your Okta tenant.** They get JIT-provisioned into your Radar org on first SSO sign-in - that's WorkOS doing the work.
2. **Owner sets their role to Viewer.** That's one click in **Settings → Members**, or automatic via domain auto-join + default role.
3. **The contractor signs in.** They land on the cluster list, see the staging cluster you've granted them access to, and can read - resources, topology, events, audit findings, Helm releases. They cannot exec, cannot edit, cannot delete. K8s says no, because `cloud:viewer` is bound to `view`.
4. **Four weeks later, IT removes them from Okta.** Their next sign-in attempt 403s. Existing sessions die at cookie expiry; if you need an immediate cut, **Settings → Members → Remove** kills the server-side session right away.

Total Radar work for this onboarding: zero, after the initial setup. Everything else is an IdP operation IT already knows how to run.

## SCIM and time-bounded access

Two things worth being explicit on.

**SCIM 2.0 directory sync** ships on Enterprise. JIT provisioning works on every plan - the first SSO sign-in creates the Cloud user and adds them to the org if domain auto-join is configured. For teams that need directory-driven user and group lifecycle from their IdP (often for compliance or procurement), SCIM is the upgrade path.

**Time-bounded access** ("Admin for the next four hours, then auto-revert") isn't shipped natively yet. The workaround is the IdP one - add to a group, remove when done. It works. It's just not as clean as a one-click ephemeral grant. On the roadmap.

## Audit

Every authentication event, scope change, and write operation lands in the Cloud audit log. Retention scales with plan: 7 days on Free, 30 days on Team, 1 year on Enterprise. K8s audit policies capture the impersonated calls separately, so you can correlate "user X did Y in Cloud" against "user X impersonation hit endpoint Z in the apiserver" if you need full provenance.

What's not in the audit log: every read click. We log write operations, scope changes, sign-ins, and SSO config changes. We don't log "Alice opened the Pods view and scrolled."

## The shape of it

Onboarding a teammate to a Kubernetes cluster should be an IdP operation, not a kubeconfig-distribution project. The reason it usually isn't is that most teams layered their access tooling on top of `~/.kube/config` and never went back to reconsider.

Radar Cloud moves the decision to where your identity already lives - your IdP - and lets standard K8s RBAC do the gatekeeping in the cluster, not a parallel permission system in the dashboard. Less novel infrastructure, fewer places for things to drift, and a cleaner answer when someone asks "who has access to prod, and how do you revoke it?"

If you want to try it, the Free tier covers up to three clusters and includes SSO. Set it up in **Settings → Organization → SSO** - the WorkOS portal walks you through your IdP from there.


---

### Why We Priced Radar Per Cluster, Not Per Seat

- **URL**: https://radarhq.io/blog/why-per-cluster-pricing
- **Date**: 2026-06-09
- **Author**: Roy Libman, CPO, Skyhook
- **Category**: Platform
- **Tags**: radar-cloud, pricing, saas, go-to-market, platform-engineering


A platform lead we talked to last month runs a fleet of nine clusters with a team of twelve. Their incumbent "Kubernetes management" vendor quoted her $1,500 per seat per year. Twelve seats. $18,000. But that number only covers the twelve people on her team today. The on-call engineer from the partner team who gets paged once a quarter? Another seat. The security reviewer who wants to audit the cluster once a year? Another seat. The CFO who wanted to see what they were paying for? You can imagine.

She did the thing every sensible engineering leader does: bought six seats, shared logins with the rest of the team, and disabled audit logs so it wouldn't show up in reviews.

That's the outcome per-seat pricing creates. Not "more revenue per customer." Shared logins, broken audit trails, and a vendor that's quietly hostile to the job it's sold to do.

When we priced Radar Cloud, we ruled out per-seat on day one. Here's the rest of the thinking.

## TL;DR

Radar Cloud is priced per cluster, not per seat. Free for up to three clusters. $149 per cluster per month on Team. Custom on Enterprise.

A visibility tool gets more valuable the more people look at it, so pricing that punishes adoption is pricing at war with the product. Per-cluster aligns with our actual costs (we run one tunnel and one cluster's worth of registry / audit / billing state per connected cluster) and with the thing you care about (how much infrastructure you're monitoring).

It's not the right model for every customer - we'll be honest about that below.

## The five models we compared

Every pricing decision is a choice between bad options. We sketched five on a whiteboard.

| Model | Scales with | Predictable? | Fair at growth? | Hostile to adoption? |
|-------|-------------|--------------|-----------------|----------------------|
| Per seat | Team size | Yes | No | Yes |
| Per cluster | Fleet size | Yes | Mostly | No |
| Per node | Node count | Sometimes | No | No |
| Per event / per GB | Cluster chaos | No | No | No |
| Flat tiers by feature | Whatever we pick | Yes | Depends | Neutral |

Each has a real argument for it. Here's why we landed where we did.

## Why not per seat

The pitch for per-seat is simple: it's how most SaaS is priced, buyers understand it, and your revenue scales with the customer's team. The problem is that it scales against what Radar is actually for.

A visibility tool is worth more when more people can look at it. The on-call engineer who didn't deploy the thing that broke at 3am needs the dashboard more than the engineer who did. The security reviewer running a quarterly check. The manager who wants to see cluster health before a steering committee. The new hire trying to build a mental model of prod.

Per-seat pricing turns every one of those people into a line item someone has to justify. The outcomes we saw in the wild:

- **Shared logins.** We've interviewed teams who share a `devops@company.com` credential across ten people because the seat math doesn't work otherwise. Audit logs turn into "devops@ did it."
- **Procurement friction for new hires.** Onboarding a new engineer should be a `helm install` and a Slack invite. Not a purchase order.
- **The "we forgot about bob" bill.** Someone leaves, nobody remembers to deprovision, and the renewal has line items for people who haven't logged in for a year.

The worst part: per-seat incentivizes us to make the tool harder to use without an account. The opposite of the thing we want.

## Why not per node

Per-node sounds like it tracks infrastructure scale. It doesn't.

We ran the numbers on a hundred real clusters from our beta cohort. The 90th-percentile cluster had 47 nodes. The 99th had 340. Meanwhile the p50 cluster had 9 nodes. Under per-node pricing, a customer with one beefy 200-node cluster running a correctly-tuned HPA would pay the same as one running ten small-and-wasteful 20-node clusters. That's backwards. The HPA team is doing the right thing.

Our cost of running Radar Cloud doesn't scale linearly with node count either. Radar watches the Kubernetes API server, not the nodes. Watching a 50-node cluster and a 500-node cluster costs us roughly the same in tunnel bandwidth and control-plane state - the object count grows sublinearly with nodes for most workloads. Per-node would punish customers for infrastructure they don't care about.

## Why not per event or per GB

This is the Datadog model and it's the one that produces the worst end-of-quarter conversations in our industry.

The whole point of Radar is to surface the events you didn't know about. If those events cost you money, you're incentivized to drop your retention, mute your alerts, and generally let less signal through. We want exactly the opposite behavior. A pod in CrashLoopBackOff should get *more* eyes on it, not less, and the billing department shouldn't be the reason your incident got harder to debug.

Per-event pricing also makes bills impossible to predict. A bad deploy that generates 40,000 events in an hour is already a bad day. It shouldn't also be an invoice shock next month.

## Why not flat feature tiers

"Radar Starter, Radar Pro, Radar Enterprise, $x / $y / $z" is the path of least resistance. We have tiers - Free, Team, Enterprise - but the axis we price on inside those tiers is still per-cluster.

Flat-fee tiering has two failure modes. The first is that a two-cluster customer and a forty-cluster customer pay the same, which is absurd on both ends: the small customer overpays for capacity they don't use, the large customer gets a windfall we can't afford. The second is that sales conversations devolve into negotiating what's in each tier. We'd rather the conversation be "how many clusters?" than "can we add SAML to Team for $50 extra?"

## Why per cluster won

Three reasons, in decreasing order of importance.

**It aligns with our costs.** For every cluster connected to Radar Cloud, we hold open one long-lived WebSocket tunnel, route browser requests through it, and store one cluster's worth of registry, audit, and billing state in our control plane. When a customer adds a cluster, our cost goes up roughly linearly. When they add an engineer, our cost goes up by zero. Pricing that matches cost isn't greedy - it's how we avoid a subsidy war between small customers and large ones.

**It aligns with customer value.** Ask a platform lead "what does Radar save you?" and the answer is usually something like "we catch bad deploys in staging before they hit prod." That value doesn't scale with team size. It scales with how much infrastructure is under observation. One cluster = one production surface where something can break. That's the thing we should charge for.

**It rewards broad adoption.** A $149 monthly bill that lets your entire team (and the on-call rotation, and the security reviewer, and the skeptical manager) into the dashboard produces dramatically better outcomes than a $149 bill that gets shared across two seats. The tool works when more people look at it. Our pricing should pay for that, not tax it.

## Where per-cluster is a worse deal

I'd rather tell you this than have you discover it.

**If you run one giant cluster.** A single 400-node cluster with 30 tenants feels under-priced at $149/month on Team, because per-cluster pricing doesn't care how big the cluster is. That's a legitimate "we're getting a great deal" for the customer - and fine by us, because our cost is still the per-cluster cost.

**If you run many tiny dev clusters.** The flip side. A team with ten short-lived `kind` clusters for CI runners pays as much as a team with ten prod clusters. We're watching this and considering a "dev cluster" discount if the usage data says to, but we haven't landed on clean criteria that couldn't be gamed. For now: if you have a fleet of ephemeral CI clusters, pin them through one long-lived Radar-connected cluster or talk to us.

**If you need SCIM but have one cluster.** SCIM 2.0 provisioning ships on Enterprise, which is custom-priced. For a single-cluster team that happens to need SCIM for IT-automation reasons (SAML / OIDC SSO also sits on Enterprise), that's a painful jump from Team. We know. If this is you, talk to us - we've been doing one-off custom plans on a case-by-case basis while we figure out whether it's the tier or the price that needs to flex.

## What will change the pricing

We're not precious about any of this.

We'll revisit per-cluster if the data shows it misallocates cost - if one customer's cluster is consistently ten times more expensive to run than the average, or if the "dev cluster" complaint turns into a real pattern instead of an edge case. We'll revisit the tier prices if our infrastructure costs shift materially. We'll grandfather existing customers when we do. We'll announce changes in the blog, not in an email nobody reads.

One thing we won't change: visibility tools get better when more people look at them. That's the whole product. It's also why per-seat was off the table before we had a pricing meeting.

If you're evaluating Radar Cloud and the pricing math feels off for your specific fleet shape, tell us. We'd rather know.


---

### Why Radar Cloud Doesn't Cache Your Cluster State

- **URL**: https://radarhq.io/blog/why-radar-cloud-doesnt-cache-your-cluster-state
- **Date**: 2026-06-06
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Engineering
- **Tags**: radar-cloud, kubernetes, architecture, security, multi-cluster


The default architecture for a multi-cluster Kubernetes dashboard is: agent in every cluster, agents push state to a backend, backend stores a replica per cluster, UI reads from the backend.

That's the shape of most products in this category. We picked the opposite shape.

## The rule

Radar Cloud does not maintain a hosted copy of your Kubernetes resource state.

The Radar binary runs in each connected cluster. When you open a cluster in the Cloud UI, the browser talks to the Radar Cloud control plane, the control plane authenticates you, and the request is reverse-proxied over that cluster's existing outbound WebSocket to the in-cluster Radar pod.

The in-cluster Radar answers from the same live engine the OSS binary uses: informers, topology builders, timeline storage, Helm readers, GitOps integrations, audit checks, and MCP handlers.

**Cloud owns the team layer. The cluster owns the cluster data.**

![Radar Cloud architecture - reverse proxy, no server-side cache](/images/blog/radar-agent-architecture.png)

## The shape of the connection

In-cluster Radar opens one outbound TCP connection to `api.radarhq.io:443`, negotiates TLS, upgrades to a WebSocket, authenticates with a cluster-scoped bearer token, and runs [yamux](https://github.com/hashicorp/yamux) for stream multiplexing on top.

When a browser asks Radar Cloud for "Pods in namespace `prod`":

1. The control plane authenticates the user against the org and cluster.
2. It strips inbound `X-Forwarded-*` headers (anti-spoof).
3. Injects `X-Forwarded-User` and `X-Forwarded-Groups: cloud:<role>,cloud:user:<user_id>,...`.
4. Opens a fresh yamux stream over the existing WebSocket.
5. Forwards the HTTP request through that stream to the in-cluster Radar pod.
6. The pod runs the request against its local SharedInformer cache, with the user impersonated on the K8s API.
7. The response flows back through the same stream.

Logs, exec sessions, MCP tool calls, port-forwards - all the same machinery. Different streams, same WebSocket. Nothing is written to disk on the control plane side. Nothing is mirrored into a database for "fast queries later." Live K8s state is the answer; the control plane just brokers access to it.

## What lives in Cloud, what stays in the cluster

The control plane does have a database. It stores things that genuinely belong on the SaaS side.

| Cloud data | Cluster data |
| --- | --- |
| Users, orgs, members, roles, invitations | Resources and CRDs |
| Cluster registry metadata (id, name, env, labels, status) | Topology and traffic views |
| Cluster token hashes | Kubernetes events and the Radar timeline |
| Billing and subscription state | Helm releases and GitOps state |
| Org-scoped audit log | Logs, exec sessions, port-forward streams |
| Personal access tokens, notification preferences | Cluster audit findings |
| Slack and webhook destinations | MCP tool responses |

When Cloud needs anything in the right column, it asks the connected Radar pod. The pod reads the cluster and responds over the tunnel.

Disconnected cluster? The Cloud UI shows it as not reporting. We do not serve a stale hosted snapshot and pretend it is fresh.

## Why we picked this shape

Three reasons, in decreasing order of importance.

### Live state is more correct than cached state

A backend that mirrors your cluster is always racing the source of truth. Radar (the in-cluster pod) already maintains a SharedInformer cache fed by the K8s Watch API - that's the right tier to cache at. Mirroring it again on the SaaS side gives you a copy that's always 200ms (or 5s, or 30s) older than the cluster's own cache. Most of the time you don't notice. The times you do notice are during incidents, when a stale view actively misleads you.

We'd rather pay the millisecond round-trip through the WebSocket and serve you what the API server believes right now.

### The blast radius if we're compromised is bounded

The control plane never holds your cluster contents. If someone gets into our backend, they get: org metadata, audit history, billing records. They don't get a database-shaped snapshot of every customer's pods, ConfigMaps, and resource state.

The auth boundary is also clean. The cluster-scoped bearer token validates the WebSocket once at handshake time. Per-request, the control plane injects user identity into the request headers, but the K8s API decides what's allowed - we don't have a parallel permission system that could leak access. A compromised control plane can't exceed what the cluster's own RBAC permits, because every read and write goes through K8s impersonation.

### Multi-tenant cost is sane

If we held a server-side replica per connected cluster, our backend cost would scale with the cumulative object count across the entire fleet. A handful of customers with chatty CRDs (or accidental ConfigMap regeneration loops) would dominate our hosting bill, and we'd end up either rate-limiting noisy clusters or eating the cost.

Reverse-proxy cost scales with active browser sessions, not with cluster size. A 5,000-pod cluster sitting idle costs us roughly the same as an empty one. That's why we can charge per-cluster instead of per-node or per-event - our cost model and yours line up.

## What we give up

This isn't free. There are real tradeoffs.

**The dashboard depends on the in-cluster pod being reachable.** If the WebSocket drops, the cluster card goes "disconnected" in the UI and you can't drill into it until the pod reconnects. We send a notification when this happens (`cluster.disconnected`). For a hosted dashboard built on a server-side cache, you'd at least see stale data; with us, you see nothing for that cluster until it's back.

This is a tradeoff we accepted because (a) Radar reconnects with exponential backoff and the typical disconnect is brief, and (b) "stale data that looks fine" is actively dangerous during an incident. Honest unavailability beats deceptive freshness.

**Some queries that would be cheap against a server-side cache aren't free here.** "Show me everything across the fleet that's failing" goes wide-fan-out: the Hub opens a stream to each connected cluster, each pod answers from its local cache, the Hub aggregates. That works fine for tens of clusters and is sub-second; for a hundred or more clusters, the initial fleet-view load takes a few seconds with progressive rendering. It's slower than a pre-aggregated dashboard would be. We'd rather be a few seconds slower and tell you the truth.

**Cross-cluster topology and cross-cluster timeline don't exist yet.** The architecture doesn't preclude them - the data is reachable through the same multiplex - but they're meaningful product surface to build, and we've explicitly listed them under "what's NOT here today" in the docs. They're on the roadmap. We're not pretending they ship.

## Where the persistent timeline lives

In-cluster Radar can persist its event timeline to SQLite at `~/.radar/timeline.db`, bounded by an age budget (`--timeline-retention`, 7 days by default) and a size budget (`--timeline-max-size`, 1Gi by default). With SQLite and a PVC, events survive pod restarts and can give you a multi-week local history.

Cloud retains that history centrally too, and it's worth being precise about why that isn't a contradiction of everything above. The rule is about *state*, not *record*. A hosted replica of your live cluster state is the thing we won't keep: it goes stale, and stale is dangerous exactly when you need it. A record of events that already happened can't go stale. So the control plane pulls the history Radar already keeps - over the same outbound tunnel, no second agent - and serves it back through the same per-user namespace scoping, resolved live against your cluster. Live views still read the truth from your API server. See [Kubernetes Events Expire in an Hour](/blog/kubernetes-event-retention) for how the pull loop works.

What that isn't is a SIEM. If you need multi-year archives or one searchable store spanning every system you run, keep shipping events to your log backend. Retained timeline is incident-shaped history, not a system of record.

## What this does not mean

It does not mean Cloud has no audit log.

Cloud keeps an org-scoped activity log for Cloud actions: cluster registration, token rotation, member changes, invitations, SSO setup, PAT lifecycle, billing changes, and sign-ins. That audit log is stored in Postgres with plan-based retention.

It does mean Cloud audit logs are not Kubernetes audit logs. If someone scales a Deployment inside a cluster, Kubernetes remains the system of record for that API call. Radar Cloud records the Cloud-side action boundaries; the apiserver records in-cluster impersonated operations if you have Kubernetes audit logging enabled.

## The short version

The boring pitch for this architecture is: the K8s API server is the source of truth, the in-cluster Radar pod is the cache that's already correct, and the control plane's job is to authenticate humans and route their requests. Adding a third copy on the SaaS side would either be wrong (stale) or expensive (kept fresh at scale) or both.

If you're evaluating Radar Cloud against tools that ship a server-side replica, the questions worth asking are: **how stale can the replica get during an incident, what happens to my data if the vendor is breached, and whose budget pays when one of the clusters gets noisy?** Those answers are why we picked the shape we did.


---

### Agents, UIs, and CLIs: The False Choice in Kubernetes Operations

- **URL**: https://radarhq.io/blog/agent-or-ui-false-choice-kubernetes-operations
- **Date**: 2026-06-05
- **Author**: Roy Libman, CPO, Skyhook
- **Category**: Platform
- **Tags**: radar, radar-cloud, mcp, ai-agents, kubernetes


Several active debates in Kubernetes operations all sound binary.

The loudest one right now is agent-vs-UI. Do you go agent-first, with an AI assistant in Slack handling most of what humans used to do in a dashboard? Or stay UI-first, because production debugging is a job for eyes-and-cursor and you don't trust an agent to drive it?

The older debates haven't gone away either. Plain `kubectl` versus a TUI like `k9s` - one camp loves the scriptability, the other refuses to give up the live interactive view. Terminal-first versus dashboard-first - is a web UI a luxury or a necessity? Each of these arguments has long-standing camps with strong opinions, and each one quietly asks you to pick a side.

The common thread: all of these debates assume you have to pick one surface. For almost every team we work with, the honest answer is "all of them, depending on the moment" - and the right question to ask of a tool is whether the surfaces you reach for, the visual one and the agent one, are actually good at making sense of the cluster, not just at displaying it.

**TL;DR.** Kubernetes operators work across three surfaces - CLI, UI, and AI agent - and each wins at a different job. `kubectl` already owns the CLI; nobody needs a second one. The catch: a cluster is a large, constantly changing graph of related objects, sprawling across a huge third-party ecosystem - and raw YAML from the terminal is a poor way to make sense of it, whether you're a human or an LLM. The two higher-level surfaces, a visual UI and a structured agent layer, are where that sense-making should happen, and most tools do them badly. That's what Radar set out to fix, while leaving `kubectl` exactly where it is.

## Each surface earns its place

The first step is to stop ranking the surfaces. Each one has a legitimate, durable reason to exist.

**The CLI is for speed and muscle memory.** When you know exactly what you want, `kubectl get pods -n checkout-prod -o wide | grep CrashLoop` is faster than any UI. CLIs are scriptable, pipeable, automatable, and replayable - the foundation of everything from break-glass procedures to CI pipelines. They reward expertise. Serious operators live in a terminal for a meaningful fraction of their day.

**The UI is for navigation and pattern recognition.** Kubernetes state is dense, hierarchical, and fast-changing. A good UI lets you scan a topology, spot an outlier pod, drill into its logs, and flip back to the timeline in three keystrokes. The bandwidth of eyes-on-a-screen for "what is going on across this cluster?" is hard to beat - especially at 2am, when you do not yet know what you are looking for.

**The agent is for summarization and natural-language access.** A meaningful slice of Kubernetes operations is not pattern recognition; it is "summarize what changed in the last 20 minutes," "tell me which of these alerts are related," "explain why this deployment is failing readiness." That work is genuinely a fit for LLMs. Teams that have moved routine triage into Slack-resident agents have gotten real leverage out of it.

These three pictures are not in conflict. They describe different jobs:

| Surface | Best at | Weakest at |
|---|---|---|
| CLI | Speed, scripting, automation, deep familiarity | Discovery, cross-cutting views, onboarding |
| UI | Visual scanning, navigation, deep-linking, "what is happening?" | Repetition, batch operations, automation |
| Agent | Summarization, natural language, correlation across noisy state | Precision, trust at the sharp end, repeatability |

## The pattern we see in the field

Across the teams we work with, three archetypes show up repeatedly, and all three are reasonable.

**CLI-anchored teams** are often infra-leaning and deeply experienced - they have been operating Kubernetes from a terminal since before there were good dashboards, and the muscle memory is real. The stance has become a bit old-school, though: a UI gets installed grudgingly and rarely opened, an agent is dismissed as autocomplete for people who do not know `kubectl`. The risk is staying there by default and missing what the other surfaces are actually good at. Teams from this camp that give the UI and the agent an honest try almost always end up using all three, because cross-cutting views and natural-language summarization do not compete with terminal expertise - they compound with it.

**UI-anchored teams** are often platform or developer-experience focused. They want a single pane that is easy to onboard a new engineer into. They rely on dashboards for incident response and for self-serve developer workflows.

**Agent-leaning teams** have an internal AI assistant wired into Slack, docs, metrics, the IDP, and the cluster. Developers stop touching clusters directly; most everyday questions get asked in natural language. These teams move fast and the assistant absorbs a lot of toil.

Most real organizations are a mix of all three. The infra side keeps the CLI. The SRE side reaches for the UI during incidents. Some subset of the team is increasingly conversational with an AI assistant. People reach for what is convenient for the task in front of them, and that should be fine.

## The hard part is making sense of the graph

A Kubernetes cluster isn't a list of objects; it's a live, interconnected graph. A Deployment owns a ReplicaSet owns Pods. A Service selects some of those Pods, an Ingress routes to the Service, ConfigMaps and Secrets feed the containers, an HPA scales the workload, and a GitOps controller owns the whole thing. Then the third-party ecosystem piles its own CRDs and operators on top - Argo, cert-manager, Cilium, KEDA, half the CNCF landscape - each with its own objects and relationships. And all of it changes by the second.

Watch someone debug a 2am incident and what they are really doing is reconstructing a slice of that graph in their head. They want:

- Pod state now, and pod state three minutes ago, before the bad thing happened.
- Events for the namespace, filtered to the last 20 minutes.
- Recent Deployment changes from the GitOps controller.
- The last 200 lines from the three pods that crashed.
- Topology - what talks to what.
- Cluster context: nodes, capacity, the network policies in front of the failing service.

The CLI hands all of this back as raw YAML and flat text and leaves the reassembly to you. That is a fine trade when you know the one object you want. It is a bad trade when you are trying to understand how a dozen related objects are interacting - which is most of incident response, and most of onboarding.

That is the gap the higher-level surfaces exist to close. A human needs the graph rendered - topology, timelines, ownership chains, health rolled up - so the eye can do the pattern-matching it is good at. An agent needs it structured and enriched - not the same noisy YAML dumped into a context window, but a model of the graph it can actually reason over. The argument was never "agent or UI." It is which of those two does less to fight you on the task in front of you - and whether either is actually better than squinting at `kubectl` output.

## What we built, and why

`kubectl` is the CLI. It is excellent, it is not going anywhere, and we had no interest in shipping a worse one. What teams were missing was the other two surfaces done well, on the same foundation. So when we open-sourced Radar, we shipped two front ends on a single backend:

- **A web UI** - topology, event timeline, service traffic, resource browsing, logs, exec, Helm and GitOps - served by the single Radar binary you launch with `kubectl radar` (or the desktop app, no terminal at all).
- **A Model Context Protocol (MCP) server**, so any compliant agent (Claude, Cursor, in-house bots) reads the same cluster state through tool calls - deliberately *not* raw `kubectl`. Radar's MCP returns token-optimized, enriched data (topology graphs, health assessments, deduplicated events, scrubbed logs), never exposes Secret values, and separates read tools from seven explicit writes. Kubernetes RBAC enforces every write, and tool annotations let the AI client request confirmation. That is the layer agents actually need and raw `kubectl` can't give them.

Both are built on the same SharedInformer-backed model of the cluster graph, with the same access controls, and both sit alongside the `kubectl` you already use. We did not build the UI and the MCP server to settle the agent-vs-UI debate. We built them because the existing options on both surfaces were thin - dashboards that list resources without showing how they connect, and "AI integrations" that just pipe raw `kubectl` into a model - and a graph this tangled deserves better than that on either surface.

The reaction has been the most informative part. The teams that have responded most to Radar are not the people who care most about any single surface. They are the people who refuse to pick - the platform leads who were tired of dashboards that barely beat `kubectl get` and agents that choke trying to reason over raw YAML.

## What this looks like on a real incident

Imagine the 2am page. A user-facing API is returning intermittent 503s.

Here is how the incident plays out when no surface has been pre-empted:

1. **CLI.** The on-call engineer hits the terminal first, the way everyone does: `kubectl get pods -n checkout-prod`. Three pods in CrashLoopBackOff. That is all kubectl needs to tell them - it is fast and it is right there.
2. **UI.** To see *why*, they open Radar, deep-linked to that pod, and scroll the timeline. There it is: a Deployment 12 minutes ago. The topology shows a downstream dependency in degraded state. They start reading logs - the kind of cross-cutting picture a terminal can't draw.
3. **Agent.** In parallel, they ask Claude (via Radar's MCP server) to "summarize the last 20 minutes of events in `checkout-prod` and tell me what changed." Claude reads the same enriched backend the UI is reading - not raw `kubectl` output. It returns: "Deployment `checkout-api` rolled out at 02:14:32; three pods CrashLoopBackOff; new image `checkout-api:v2.41.7` failing readiness on `/health`."
4. **Back to the UI for the action.** The engineer decides to roll back. One click, from the dashboard - or they ask the agent to call the MCP rollback tool. Same backend, same action, same RBAC.
5. **Async.** Five minutes later, an SRE pulled in via PagerDuty opens the incident's deep link. They see the same view. They ask the agent for "anything similar in the last 90 days." It finds two prior incidents and links the timelines back into the UI.

Nothing about that flow privileges a single surface. kubectl answers the fast, precise question. The UI draws the picture from the graph - what owns what, what routes where, what changed when. The agent turns "what happened here" into a paragraph. Each does the part it is best at, and none of them makes you reassemble the cluster from raw YAML by hand.

If the team had been forced to pick "UI-first" or "agent-first" at the start of the year - and to give up one of them to get the other - at least half the moves above would be slower or impossible.

## The takeaway

It is fine to lean toward any one modality. Most teams will have a primary surface, and that is healthy - it is how culture and muscle memory build. CLI-anchored teams stay CLI-anchored. UI-anchored teams stay UI-anchored. Agent-leaning teams keep extracting leverage from their assistant.

What is worth pushing back on is the implicit assumption in a lot of current tooling positioning: that the modality you lean toward dictates the tool you buy, and that picking the "wrong" tool locks you out of the other two. That is only true if the tool has one front end and treats the others as roadmap items.

If you are evaluating tools for your team, the right question to ask is not "do you have an AI mode?" or "is the dashboard nice?" Either is easy to bolt on. The real question is whether the tool's UI and its agent actually make sense of the cluster graph - rendering the relationships for a human, modeling them for an agent - or whether they just dress up the same flat output you would get from `kubectl`.

If yes, you do not have to pick. Your engineers keep kubectl for the precise, scriptable questions, work in the dashboard when they need to see how things connect, and lean on the agent when they want it explained - each surface pulling its weight.

If no, you have bought a second and third way to read flat output, and your team will still be reassembling the cluster in their heads at 2am.

That is the bet we made with Radar. One engine that watches your clusters - the same SharedInformer foundation across [Radar OSS and Cloud](/blog/radar-oss-or-radar-cloud-an-honest-take), running at [fleet scale](/blog/the-fleet-visibility-gap) when you need it - that turns live cluster state into something both surfaces can actually use: a UI that renders the graph for humans and an MCP server that models it for agents. `kubectl` stays in your terminal for when raw and precise is exactly what you want.

Keep your CLI. Reach for the dashboard or the agent when the cluster is too tangled for raw YAML. Making those two genuinely good is on us.


---

### Radar's In-Cluster Architecture: Outbound-Only, Scoped, Live by Default

- **URL**: https://radarhq.io/blog/the-radar-cloud-agent-architecture
- **Date**: 2026-06-04
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Engineering
- **Tags**: radar-cloud, kubernetes, architecture, security


Every platform team we've talked to about Radar Cloud asks the same five questions before they'll install anything in their cluster:

1. Does it need inbound network access?
2. What Kubernetes permissions does it need?
3. What data leaves the cluster?
4. How are credentials handled?
5. What's the blast radius if Radar gets compromised?

These are the right questions. If you're responsible for a cluster that handles real workloads, "just install our Helm chart and give it cluster-admin" is not an acceptable answer. The rest of this post is how we answer each one, with the actual design choices we made and the tradeoffs that came with them.

![Radar in-cluster architecture](/images/blog/radar-agent-architecture.png)

## 1. No inbound access. Ever.

The simplest question first. Radar never opens a port. Not a NodePort, not a LoadBalancer, not an Ingress. It doesn't sit behind a Service that your cluster exposes to the internet, and it doesn't need you to punch holes in your firewall for a vendor CIDR range.

We rejected the inbound model early. The typical pitch goes: "just expose our controller on an Ingress and we'll call it when we need to." For most platform teams we've worked with, that's a non-starter. Every inbound path is a new attack surface, a new TLS cert to manage, a new firewall rule to audit, and a new thing your security team has to sign off on. Doing that for a vendor tool is a lot of ceremony for visibility.

So Radar dials out. On startup, it opens a single TCP connection to `api.radarhq.io:443`, negotiates TLS, upgrades to a WebSocket, and authenticates with a cluster-scoped bearer token it got at install time. On top of that one WebSocket we run [yamux](https://github.com/hashicorp/yamux) for stream multiplexing, so every Cloud-initiated request (topology fetch, log tail, exec session, MCP tool call) opens a fresh stream on the same connection instead of a new TCP dial. That connection stays open for the lifetime of the pod.

What this looks like from your side:

- One egress rule: allow `api.radarhq.io:443` (or the EU endpoint, depending on region).
- No inbound rules. No public IPs. No load balancers.
- TLS on the wire. Radar verifies the server cert against public CAs; the server authenticates Radar by SHA-256-hashing the presented bearer token and comparing it against the hash it stored when the cluster was onboarded.

The honest concession: if you run a cluster with zero egress to the public internet, Radar requires you to allowlist one FQDN. That's the minimum. We can't do visibility-as-a-service without a network path. For air-gapped environments, the open-source Radar is the right answer.

## 2. Read-only by default. Read-write is opt-in per feature.

The Helm chart installs one Deployment running one container, with one ServiceAccount bound to one ClusterRole. The default ClusterRole is read-only.

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: radar
rules:
  # Core resources
  - apiGroups: [""]
    resources:
      - pods
      - services
      - endpoints
      - configmaps
      - namespaces
      - nodes
      - persistentvolumes
      - persistentvolumeclaims
      - events
      - serviceaccounts
    verbs: [get, list, watch]

  # Workload controllers
  - apiGroups: ["apps"]
    resources: [deployments, statefulsets, daemonsets, replicasets]
    verbs: [get, list, watch]

  # Batch
  - apiGroups: ["batch"]
    resources: [jobs, cronjobs]
    verbs: [get, list, watch]

  # Networking
  - apiGroups: ["networking.k8s.io"]
    resources: [ingresses, networkpolicies]
    verbs: [get, list, watch]

  # Autoscaling
  - apiGroups: ["autoscaling"]
    resources: [horizontalpodautoscalers]
    verbs: [get, list, watch]

  # RBAC (metadata only)
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: [roles, rolebindings, clusterroles, clusterrolebindings]
    verbs: [get, list, watch]

  # Metrics (if metrics-server is installed)
  - apiGroups: ["metrics.k8s.io"]
    resources: [pods, nodes]
    verbs: [get, list]

  # CRDs - discovery only, so Radar can find Argo, Flux, Istio, etc.
  - apiGroups: ["apiextensions.k8s.io"]
    resources: [customresourcedefinitions]
    verbs: [get, list, watch]

  # Secrets - metadata only (names, types, timestamps), NOT values.
  - apiGroups: [""]
    resources: [secrets]
    verbs: [get, list, watch]
```

That's the baseline. It lets Radar watch resources, build the topology, correlate events, and show you Helm releases. It does not let it mutate anything, exec into pods, or read log content.

If you want specific features that need more, you opt in. Each feature maps to a named set of rules:

- `features.logs=true` adds `pods/log` get.
- `features.exec=true` adds `pods/exec` create. This is also gated per-user by Cloud RBAC, so Viewers never get a terminal.
- `features.helm=true` adds get/list/watch/create/update/patch/delete on Helm-managed resources (scoped via labels).
- `features.scale=true` adds update on `deployments/scale`, `statefulsets/scale`.
- `features.restart=true` adds patch on workloads.

You enable them in `values.yaml`. Nothing else flips on automatically.

## 3. The data contract

The question I always want asked and rarely get: what actually leaves the cluster, and when?

The short answer: **cluster state isn't pushed.** The control plane doesn't run an event ingest pipeline, doesn't keep a server-side replica of your resources, and doesn't store a "last known cluster snapshot" anywhere. When a browser asks Radar Cloud for a Pod, the Hub authenticates the user, opens a fresh stream over the existing WebSocket, and forwards the HTTP request through to the in-cluster Radar pod, which serves it live from its SharedInformer cache. The bytes go from cluster to browser via the Hub, on demand, and nothing in the middle is written to disk.

| Data that crosses the tunnel (on demand, in response to a user request) | Data that never crosses |
| --- | --- |
| The specific resources a user is currently looking at (with managedFields stripped) | Secret `data` values. Ever. |
| Filtered K8s events for the view the user has open | ConfigMap values annotated `radarhq.io/redact: "true"` |
| Helm release metadata when a user opens a Helm view | Logs, exec, port-forward at rest (all streamed; nothing persisted) |
| Topology relationships when a user opens topology | Raw kube-apiserver audit logs |
| Logs, exec, port-forward bytes (streamed live; closed when the tab closes) | Background telemetry - nothing ships you didn't ask for |
| MCP tool responses when an authorized AI client calls them | Anything that wasn't requested by an authenticated browser or PAT |

A few things worth being explicit about.

**Secret values never leave.** Radar lists Secrets so it can show you that a Secret named `db-credentials` exists and is mounted into a pod, but it does not read the `data` field. At the informer level, we strip the data before it enters the in-memory cache. If you "view" a Secret in the Radar UI, we show you the keys and type. We do not show the values.

**Logs, exec, and port-forward are streamed, not stored.** When a user in the UI asks to tail a pod's logs, the Hub opens a stream through the WebSocket to in-cluster Radar, Radar opens a streaming read against `pods/log`, and the bytes flow back to the user's browser through that same stream. Nothing is written to disk on our side. When the user closes the tab, the stream closes. Same pattern for `kubectl exec` and `kubectl port-forward` equivalents.

**managedFields gets stripped.** If you've ever looked at the raw JSON of a Kubernetes object, you know `managedFields` can be larger than the rest of the object combined. We strip it at informer callback time, before the object enters the in-cluster cache. That saves memory in-cluster and bytes on the wire when the resource flows out in response to a browser request.

**ConfigMaps can opt out via annotation.** If you have ConfigMaps with sensitive content (which you shouldn't, but people do), annotate them with `radarhq.io/redact: "true"` and Radar treats them like Secrets - metadata only, values redacted at the boundary.

**The control plane stores its own state, separately.** Org membership, roles, cluster registry metadata, audit log, PAT hashes, billing state, and a small set of hub-native event kinds (cluster.disconnected, member invitations, billing). That's what's in the control plane's database. Your cluster's resources aren't.

## 4. Credentials: cluster bearer tokens over TLS

Each cluster connection is bootstrapped with a bearer token issued from the Radar dashboard by an Owner. The raw token is shown exactly once at creation and only ever stored as a SHA-256 hash server-side, bound to one cluster record.

On every connection, Radar presents the token over TLS; the Radar Cloud server hashes the presented value and compares it against the stored hash before opening the tunnel. There's no separate enrollment handshake and no client-cert material to manage in-cluster: the token itself is the long-lived credential. An Owner can rotate the token at any time from the dashboard, which invalidates the previous hash and forces Radar to reconnect with the new value.

We don't handle your kubeconfig, your cloud credentials, or your cluster CA. Radar authenticates to the Kubernetes API using the projected ServiceAccount token that the kubelet gives it, same as any in-cluster controller.

## 5. Blast radius: what happens if Radar is compromised

The worst case: someone gets code execution inside the Radar pod. What can they do?

With the default read-only ClusterRole, they can read cluster state. That's a disclosure problem, not a destruction problem. They cannot scale workloads to zero, they cannot delete your PVCs, they cannot exec into pods and pivot. The ClusterRole is the ceiling.

With read-write features enabled, the ceiling rises to exactly what those features allow. If you enabled `features.scale=true`, an attacker can scale deployments. If you enabled `features.exec=true`, they can open a shell in any pod - the same pod an Admin user could exec into through the UI. This is why we make every read-write feature opt-in and surface the RBAC impact in the Helm chart's NOTES.txt when you install it.

The other containment: Radar runs in its own namespace (`radar` by default), with a PodSecurityContext that drops all capabilities, runs as non-root, has a read-only root filesystem, and disables privilege escalation. A compromised Radar container can't write to disk or escalate to root without breaking out of the kernel's sandbox.

## Why SharedInformer

In-cluster Radar uses the same `client-go` SharedInformer pattern as Radar OSS. A SharedInformer does one list call against the API server for a given resource kind, switches to a Watch stream for deltas, and maintains an in-memory cache that multiple consumers can read from.

Why this matters:

- **Low API server load.** One watch per kind, not N polls per second. On a cluster with 10,000 resources, we do 10k list reads at startup, then we're on watch streams. The kube-apiserver barely notices us.
- **Deltas, not snapshots.** When a pod transitions from Pending to Running, we ship one delta. Not the entire pod object repeatedly.
- **Memory efficiency.** On a cluster with a few hundred resources, Radar sits at ~32MB RSS. Memory grows roughly linearly with object count - a cluster with tens of thousands of pods will use more, but the constant factor is small because we strip `managedFields` and denormalize aggressively.

## The wire protocol

The uplink is a WebSocket over TLS, with yamux as the multiplexer on top. A few properties worth calling out:

- **One connection, many streams.** Every Cloud-initiated request (a browser loading topology, an MCP tool fetching resources, a log tail, a pod-exec session) is a fresh yamux stream on the same WebSocket. Streams are cheap (roughly 1KB of bookkeeping each); TCP dials are not.
- **Plain HTTP inside.** Each stream carries a normal HTTP request to the in-cluster Radar binary's HTTP router, including SSE for live updates and WebSocket upgrades for `kubectl exec`. There's no custom binary protocol to reverse-engineer; `helm template` the chart and read the manifests if you want to audit the surface area.
- **Keepalives.** yamux sends lightweight pings on idle connections so NATs and load balancers don't silently reap the tunnel, and so dead ends are detected quickly on both sides.
- **Back-pressure.** yamux's per-stream flow control keeps one slow consumer (say, a user tailing noisy logs) from starving every other stream on the same connection.

## Failure modes

Networks fail. Our backend sometimes has outages. Here's what Radar does when things go wrong.

**Uplink drops.** Radar reconnects with exponential backoff (1s, 2s, 4s, ..., capped at 60s). While disconnected, it keeps its informer caches warm so the moment the WebSocket reopens it can serve fresh requests immediately - there's no "rehydrate from a checkpoint" step because the cluster's API server is the source of truth and Radar's informers are already tracking it. The Hub fires a `cluster.disconnected` notification when the WebSocket drops past a grace period and `cluster.reconnected` when it comes back.

**Radar Cloud has an outage.** Your cluster keeps running. Radar is not in the data path for your workloads. It doesn't mutate anything, it doesn't proxy traffic, it doesn't gate admission. If we're down, you lose visibility in the Radar UI for the duration. That's the worst thing that happens.

**Radar crashes.** Kubernetes restarts it. On startup, it redials the tunnel with the bearer token from its Helm values, rebuilds its informer caches, and is back in the fleet view. Cold start to steady state is usually under 10 seconds on a small cluster, maybe 30 seconds on a big one. If you enabled SQLite-backed timeline persistence with a PVC, in-cluster event history survives across restarts.

## What we don't do

This is the part I care about most, because a lot of in-cluster tools in this space have grown tentacles.

- **No sidecar injection.** We don't mutate your pods.
- **No mutating admission webhooks.** We don't sit in the admission path. If Radar is down, your deploys still work.
- **No validating webhooks.** Same reason.
- **No CRDs of our own.** We read your CRDs (Argo, Flux, Istio, your own). We don't install ours.
- **No init containers.** Nothing piggybacks on your workloads.
- **No cert-manager dependency.** Radar authenticates with a static bearer token you supply at install time. Nothing in the chart asks your cluster to issue certs for us.

One Deployment. One ServiceAccount. One ClusterRole. One Secret. One namespace. That's it.

## Install

```bash
helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm repo update

helm install radar skyhook/radar -n radar --create-namespace \
  --set cloud.token=$RADAR_CLOUD_TOKEN
```

The token comes from the Radar dashboard when you click "Add cluster." By the time `helm install` exits, Radar is connected and your cluster shows up in the fleet view.

If you want to audit exactly what lands in your cluster before installing, `helm template` the chart and read the manifests. There are no surprises. That's the whole point.

## The short version

In-cluster Radar is a small Go binary that dials out to one FQDN over TLS, authenticates with a cluster-scoped bearer token, runs with a read-only ClusterRole unless you opt into more, serves on-demand requests reverse-proxied from the Radar Cloud control plane over a yamux-multiplexed WebSocket, and never stores logs or exec sessions at rest. The control plane doesn't cache cluster state - everything you see in the dashboard is served live from the in-cluster pod. It's ~32MB RSS at steady state on a typical cluster. If it gets compromised, the ClusterRole is the ceiling on what an attacker can do.

None of this is revolutionary. It's just the default every hosted Kubernetes tool should have been shipping for the last five years. Some do. Many don't. If you're evaluating one, these are the five questions to ask - ours or anyone else's.


---

### Radar OSS or Radar Cloud? An Honest Take on When to Use Each

- **URL**: https://radarhq.io/blog/radar-oss-or-radar-cloud-an-honest-take
- **Date**: 2026-06-02
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Open source
- **Tags**: radar, radar-cloud, open-source, comparison, kubernetes


The most common question in our GitHub issues is some variant of "do I need the Cloud version?"

Here's the honest answer: most people don't.

Radar OSS launched in January. Radar Cloud launched a month later. Since then, we've watched people agonize over the choice in ways that don't match how we actually think about it internally. This post is our attempt to stop that agonizing.

## What they share

Radar OSS and Radar Cloud are the same tool for most of what you do day to day. Same UI conventions, same keyboard shortcuts, same views: Resources, Topology, Timeline, Helm, GitOps, Traffic, Cluster audit, MCP. Same SharedInformer foundation under the hood. The React frontend is literally the same codebase, with fleet-scoped views layered on top for Cloud.

If you've used one, you already know the other. There is no relearning tax.

The thing that changes between them isn't the tool, it's the shape of your work. Are you one person poking at one cluster, or are you a team keeping an eye on many? That's the whole question.

## The five questions that decide it

Forget feature matrices for a minute. These five questions predict the right answer better than anything else:

1. **Are you working alone, or with a team?** If two or more engineers need to look at the same cluster state during the same incident, something hosted starts to earn its keep.
2. **Do you need shared, persistent identity?** OSS auth is whatever your kubeconfig grants. If you want SSO, an audit log of who did what, and per-user RoleBindings managed centrally, that's Cloud.
3. **Do you want notifications when a cluster goes dark while nobody's looking?** OSS is a tool you open. Cloud sends you a Slack or webhook ping when a cluster disconnects, a payment fails, or a teammate joins your org.
4. **Do you need more than one person to have scoped access?** If "Alice can read prod, Bob can edit staging" matters, you want SSO-driven access mapped to standard K8s RBAC, not a pile of kubeconfigs.
5. **Are you running one cluster, or six?** Fleet views only start paying for themselves once "which cluster is that pod in?" becomes a real question you ask weekly.

The more your answers trend toward team and multi-cluster, the more Cloud earns its place. If you're answering "alone, one cluster, I just want to look" to all five - stay on OSS. That's what it's for.

## When Radar OSS is the right answer

OSS isn't a stepping stone. For a large slice of users, it's the final answer.

- **Solo engineers** debugging a single cluster from their laptop. You don't need a fleet view of one thing.
- **Air-gapped or regulated environments** where outbound traffic to a hosted vendor isn't allowed. OSS runs entirely on your machine with your kubeconfig. No data leaves.
- **"I want to poke around for an hour"** moments. You inherited a cluster and want to understand it before touching anything. `radar` and you're in. No account, no token, no onboarding wizard.
- **Contributors and developers** who want to read the source, fork it, or build on top of it. Apache 2.0, single Go binary, React UI embedded via `go:embed`.
- **Teams deploying Radar in-cluster** as a read-only internal dashboard via the Helm chart. If you're fine with shared view and your own OIDC or proxy auth in front of it, that works.

Where OSS is a bad fit: a 12-person team trying to coordinate during a production incident at 2am. Everyone running their own local Radar against their own kubeconfig is not incident response, it's a conference call. That's the point where you want one URL everyone shares.

## When Cloud earns its price

Cloud starts making sense when your answers to the five questions flip.

- **Teams of 3+ engineers** who all need shared context. One URL, one cluster everyone sees through the same RBAC, one place changes are audited.
- **Fleets of 5+ clusters.** Fleet views exist because alt-tabbing between five browser tabs of Radar OSS is not a workflow.
- **On-call rotations.** Cloud notifies on the events the control plane actually owns - cluster disconnect and reconnect, billing, member invites - over Slack, webhook, or in-app. Conservative on purpose.
- **Compliance-driven audit needs.** If you need a record of who clicked what, when, against which cluster, audit logs ship on Free (7-day retention), Team (30 days), and Enterprise (365 days). SOC 2 Type 2 across the board.
- **You're tired of kubeconfig-based access control.** Cloud roles map to standard K8s RBAC via impersonation; Google and GitHub sign-in is on every plan including Free, and full SAML / OIDC SSO (Okta, Entra ID, Google Workspace, OneLogin, any spec-compliant provider) is on Enterprise.

Where Cloud is a bad fit: an engineer who will use Radar twice a week to check one cluster. There's no reason to pay for that. Use OSS.

## The hybrid pattern

A lot of teams end up using both, and we think that's correct.

Local laptop debugging? OSS. You're on a train, you've got kubeconfig, you want to check why a pod is CrashLooping. `radar` is faster than opening a browser tab and loading a web app.

Shared fleet oversight, alerts, audit trails, on-call? Cloud.

Both have the same mental model. You don't flip between "oh, this is the OSS way of doing it" and "this is the Cloud way of doing it." It's one tool with two deployment shapes. Keep both. The OSS binary is free forever, and the Cloud Free tier covers three clusters for a small team.

## What Cloud doesn't try to do

This is the part I want to be very clear about, because it's where trust in OSS tooling tends to break down.

**Radar Cloud is not a replacement for Radar OSS.** OSS stays Apache 2.0. OSS stays single-binary. OSS stays fully featured for single-cluster work. Resources, Topology, Timeline, Helm, GitOps, Traffic, Cluster audit, MCP - all of it stays in OSS. We are not gating features in OSS to push people toward Cloud.

Cloud adds things OSS can't meaningfully do on its own: multi-cluster aggregation, SSO mapped to standard K8s RBAC, an org-scoped audit log, hub-side notifications when a cluster disconnects, compliance attestations, BYOC for regulated environments. Those are genuinely different surface areas, not artificially withheld capabilities.

**We'll never rug-pull OSS.** Specifically:

- We won't move existing OSS features into a Cloud-only tier.
- We won't add mandatory telemetry or cloud check-ins to the OSS binary.
- We won't require an account to run `radar` locally.
- If we ever need to fundamentally change the license, it'll be a visible, discussed fork, not a quiet bait-and-switch shipped in a minor version bump.

We watched Lens do the mandatory-login dance in 2024. We're not doing that. It's why we open-sourced Radar in the first place.

## A word about pricing

The Free tier of Radar Cloud exists precisely so a solo engineer at a small team can try the hosted version without pulling out a credit card. 3 clusters, unlimited nodes, unlimited teammates, full SAML / OIDC SSO, the full product UX. If that's enough for you, stay there forever. We're fine with it.

Team is $149 per cluster per month with 30-day audit retention, unlimited nodes, unlimited teammates, Google and GitHub sign-in, Slack and webhook notifications, K8s-native RBAC via impersonation, and shareable deep links. That's the tier most teams in the 3-50 engineer range land on.

Enterprise is custom-priced and adds 365-day audit retention, SCIM 2.0 directory sync, BYOC / on-prem deployment of the control plane, US or EU data residency, a 99.9% SLA, and a dedicated CSM. Annual contracts get 20% off the Team list price.

We're not going to push you to a plan you don't need. The Free tier is a real product, not a 14-day trial dressed up.

## The side-by-side

| Capability | Radar OSS | Cloud Free | Cloud Team | Cloud Enterprise |
|---|---|---|---|---|
| Clusters | Unlimited (local) | 3 included | Unlimited ($149/cluster/mo) | Unlimited (custom) |
| Timeline | In-memory or SQLite (in-cluster) | Live via reverse-proxy | Live via reverse-proxy | Live via reverse-proxy |
| Audit logs | - | 7 days | 30 days | 365 days |
| Auth | kubeconfig | SAML / OIDC SSO | SAML / OIDC SSO | SSO + SCIM |
| Notifications | - | Slack, webhook, in-app | Slack, webhook, in-app | Slack, webhook, in-app |
| RBAC | - | K8s impersonation, default roles | K8s impersonation, default roles | + custom ClusterRole bindings, per-user RoleBindings |
| SLA | - | - | 99.5% | 99.9% |
| BYOC / on-prem | - | - | - | Yes |
| Fleet views | Single cluster | 3 clusters aggregate | All connected | All connected |
| Data residency | Your laptop | US | US | US, EU, or BYOC |
| Price | Free (Apache 2.0) | Free | $149 / cluster / month | Contact us |

## A short decision flow

If you want the three-second version:

- **One cluster, one person, ephemeral use?** Radar OSS. Done.
- **One cluster, small team, want a shared URL and SSO?** Cloud Free.
- **2-50 clusters, team of 3+, want notifications and proper access control?** Cloud Team.
- **Need 365-day audit retention, SCIM, BYOC / on-prem, or a 99.9% SLA?** Cloud Enterprise.
- **Air-gapped, or allergic to hosted vendors?** Radar OSS, deployed in-cluster via Helm.
- **Already on OSS and it works?** Stay there. Seriously.

The honest summary: if you're happy with Radar OSS, you don't need anything else from us. If you hit one of the walls above - multi-cluster, team coordination, retention, alerting, compliance - Cloud is the tool you should reach for, not because it's more powerful, but because it's shaped for that job.

Both tools are linked from [radarhq.io](https://radarhq.io). Pick the one that fits. We'd rather you use the right one than the expensive one.


---

### Five Questions You Can't Answer With kubectl

- **URL**: https://radarhq.io/blog/five-questions-you-cant-answer-with-kubectl
- **Date**: 2026-05-01
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Engineering
- **Tags**: kubernetes, kubectl, topology, observability, for-devops


kubectl is the right tool for almost everything. It is also, by design, a way to fetch one object at a time, as raw YAML, exactly as it exists right now.

Often that is precisely what you want. You are debugging one pod, in one namespace, checking its current state. kubectl is fast, scriptable, and built into every engineer's brain. Nothing is going to replace it.

But a Kubernetes cluster is not a list of objects - it is a living, interconnected graph, and a lot of the questions that matter are about the graph, not any single node of it. How do these objects relate? How do they actually behave, versus what their YAML declares? What is inside the artifacts they run? What did they look like an hour ago? Are they configured sensibly? kubectl can hand you the raw material for each, but it leaves the assembly to you. Here are five questions where that gap shows - all real ones our users brought us this year.

## 1. "What actually breaks if I change this?"

You are about to edit a ConfigMap, retarget a Service selector, or delete what looks like an unused Secret. What depends on it?

kubectl shows you the object:

```bash
kubectl get configmap app-config -n payments -o yaml
```

What it will not show you is the blast radius. To find that you go spelunking: which Pods mount this ConfigMap as a volume or pull it via `envFrom`, which Deployments own those Pods, which Service selects them, which Ingress routes to that Service. Each hop is a separate query, and the references run in directions JSONPath makes you walk by hand:

```bash
# which pods reference this ConfigMap? (volumes AND envFrom AND env valueFrom)
kubectl get pods -n payments -o json | jq '.items[] | select(
    (.spec.volumes[]?.configMap.name == "app-config") or
    (.spec.containers[].envFrom[]?.configMapRef.name == "app-config") or
    (.spec.containers[].env[]?.valueFrom.configMapKeyRef.name == "app-config")
  ) | .metadata.name'
```

That is one level, one kind of reference, one ConfigMap. The actual question - "show me everything connected to this, and how" - is a graph traversal, and kubectl returns objects, not graphs.

What you need is the cluster rendered as what it is: a graph of typed relationships. Radar's topology view models the edges between objects - which controller *manages* a workload, which Service *exposes* it, which ConfigMaps and Secrets *configure* it, which PDB or NetworkPolicy *protects* it, and the HPA it *uses* to scale - and lets you click any node to see everything wired to it. "What breaks if I touch this" becomes "look at the node and read its edges," instead of a dozen correlated `jq` queries you have to remember to keep in sync.

## 2. "Is this pod actually isolated, or wide open?"

Security asks: is the `payments` workload locked down, or can things reach it that shouldn't?

kubectl lists the policies:

```bash
kubectl get networkpolicies -n payments -o yaml
```

Now read the `podSelector`s, intersect them with the labels on the workloads you care about, cross-reference the ingress and egress rules and their namespace/pod selectors, and hold the result in your head. The most dangerous case is the *absence* of a policy - a workload that nothing selects, so it is wide open - and "find me the Pods that no NetworkPolicy covers" is not a query kubectl offers. You would enumerate every Pod, enumerate every policy's selector, and compute the set difference yourself. And even then you have only checked declared intent, not what is actually talking to that pod right now.

What you need is coverage plus reality. Radar flags which workloads have no NetworkPolicy selecting them - the wide-open ones - shows what each policy does cover, and, where you run Cilium's Hubble, Caretta, or Istio, overlays live traffic on top. "Nothing is protecting this destination, and here is what is currently reaching it anyway" becomes one view instead of a YAML reasoning exercise.

## 3. "What's actually inside this image?"

Trivy flags a critical CVE in a library. Is the vulnerable file even present in the image you ship, or did it come from a base layer you stripped? And while you are in there - why is this image 1.4GB?

kubectl's answer is exec, which only works if the container is running and ships a shell:

```bash
kubectl exec -it payments-api-7d9c8b4f-xq2mn -n payments -- /bin/sh
# sh: not found
```

Distroless image? No shell. Pod crash-looping? Nothing to exec into. Image not scheduled anywhere yet? Nothing to exec into at all. The thing you want to inspect is the image's filesystem, and kubectl operates on running containers, not image artifacts.

What you need is to read the image itself. Radar's image filesystem viewer lets you click any container image in a Pod and browse its complete filesystem - the full tree, with file sizes, permissions, and symlink targets - without pulling it locally or execing into anything. "Is `libfoo.so.1.2.3` actually in here" and "what are the ten biggest paths" become point-and-click, on any image, running or not.

## 4. "What changed last night?"

You walk in at 9am. Webhook delivery has been flaky since 2am. The on-call engineer has gone to bed. You want a timeline.

```bash
kubectl --context=prod-us get events -n payments --sort-by=.lastTimestamp
```

You see about thirty events, all from the last hour. The 2am window is gone: Kubernetes events have a default TTL of one hour, and the kube-apiserver garbage-collects them. By the time you ask, the answer has been deleted. A live API server is not a database - it tracks current state and lets the past evaporate, which is part of what makes it fast.

Your fallbacks are the usual three-you-have-one-of: audit logs (if enabled, shipped somewhere queryable, and retained), your metrics stack (which has the symptoms, rarely the cluster's narrative - "this Deployment rolled, that ConfigMap changed, that pod was OOMKilled"), and Argo's history (only for changes that came through Git).

What you need is a persistent timeline that subscribes to events and resource changes as they happen and keeps them past the TTL, queryable by time, namespace, and kind. Radar records exactly that - a unified timeline of Kubernetes events and resource changes you can scroll back to the minute something broke (persisted to SQLite when you want it to outlive a restart).

The real payoff is the question one step harder than "what changed." A pod restarted 17 times, twelve of them last Wednesday between 02:55 and 03:10. `kubectl describe` shows the latest termination reason; `kubectl logs --previous` gets you exactly one instance back, not twelve. The weekly pattern only exists in retained history. When we traced one of these for a team, the 3am Wednesday OOMKills turned out to be a CronJob in a *different* namespace whose memory spike was evicting the worker pods. Nobody spots that from live state - it was sitting in the timeline.

![Pod restart timeline showing weekly recurrence](/images/blog/pod-restart-timeline.png)

## 5. "What's quietly misconfigured before it pages me?"

Not "what is broken right now" - what is latent. The Deployment with no memory limit that gets OOMKilled under load. The container running as root. The Ingress with no TLS. The PDB that allows zero disruptions. None of these page you today; they page you on the worst day.

kubectl will show you each setting if you know to look:

```bash
kubectl get deploy -n payments -o json \
  | jq '.items[] | select(.spec.template.spec.containers[].resources.limits == null) | .metadata.name'
```

But that is one check, hand-written, for one antipattern, in one namespace. The real question - "scan everything here against the things experienced operators know to check, and tell me what is off" - is a judgment, and kubectl returns objects; it does not have an opinion about them.

What you need is a scanner that encodes those opinions. Radar ships a cluster audit - 36 checks across security, reliability, and efficiency, drawn from Polaris, Kubescape, Trivy, and the NSA/CISA hardening guidance - that runs instantly against its cache with nothing installed in the cluster, groups findings so you fix a class at a time, and respects Kubernetes inheritance so a check on a Deployment does not double-fire on its Pods.

## What these questions have in common

Look at them together and the pattern is not "kubectl is missing a flag." It is that each question is about something other than one object's current YAML:

| Question | What kubectl returns | What the question is really about |
| --- | --- | --- |
| What breaks if I change this? | One object's spec | Relationships - the graph |
| Is this pod isolated? | Policy YAML | Effective behavior + live traffic |
| What's inside this image? | A shell in a running container | The artifact itself |
| What changed last night? | Live state, 1h event TTL | History - the past |
| What's misconfigured? | Objects | Judgment over those objects |

kubectl is built to fetch one object, in one cluster, as it is right now, as text. That is the right primitive for an enormous amount of operational work. But comprehension - how things connect, how they behave, what is inside them, what they were, and whether they are sound - is not a fetch. It is the cluster rendered and assessed as the connected, living system it actually is. That is a different tool, sitting next to kubectl, not replacing it.

## Where kubectl is still right

To be clear, none of this is an argument against kubectl. We use it constantly. "Is this pod running," "tail these logs," "scale this Deployment," "patch this ConfigMap to test something right now" - it is the right tool, and anything trying to be "the new kubectl" is solving the wrong problem. The framing is kubectl *plus* something that understands the graph, not kubectl versus anything.

## The Radar take

Every one of those five is answered by [Radar](https://github.com/skyhook-io/radar) OSS - a single binary you launch with `kubectl radar` (or a desktop app), running locally against your kubeconfig with nothing installed in the cluster. Topology for the relationships, NetworkPolicy coverage and live traffic for isolation, the image filesystem viewer for what is inside, a persistent timeline for the past, and the [cluster audit](/blog/cluster-audit-the-31-checks-that-catch-what-you-forgot) for posture. All of it within one cluster, for free.

The point where you need more is when the same five questions go fleet-wide. "Is this CVE image running anywhere across my fourteen clusters?" "What is *actually* different between the staging cluster and the prod cluster?" "Who can exec into a prod pod in *any* cluster?" Same questions, cross-cluster scope - and that is what Radar Cloud adds on top of the same engine: a fleet-wide image inventory, cross-cluster compare, and a fleet RBAC index.

We did not set out to replace kubectl. We set out to render the cluster as the graph it already is, so the questions kubectl was never shaped for stop being afternoon-long shell-script projects. If any of the five above sound familiar, that is the gap we are aiming at.

If you have already hit this wall, you are not the only one - we wrote about [the broader fleet visibility gap](/blog/the-fleet-visibility-gap) for teams already past two clusters.


---

### Cluster Audit: The 31 Checks That Catch What You Forgot

- **URL**: https://radarhq.io/blog/cluster-audit-the-31-checks-that-catch-what-you-forgot
- **Date**: 2026-04-23
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Engineering
- **Tags**: radar, kubernetes, security, reliability, audit


Every cluster I've ever audited has the same handful of issues. Pods running as root. Containers without resource limits. A service account that's bound to cluster-admin because someone needed it for "just one thing" eight months ago. A `latest` tag in a Deployment that hasn't been updated since.

Each issue is small. The aggregate is the entire reason the security team is nervous about Kubernetes.

Radar ships with a built-in cluster audit that runs 31 of these checks against your live state and surfaces failures inline on each affected resource. No CRDs to install, no separate controller to operate, no Polaris-style YAML pipeline to maintain. It's part of the Radar binary.

<RadarScreenshot
  src="/images/blog/radar-resources.png"
  alt="Radar Resources view showing a CrashLoopBackOff Pod with detected issues and container status"
/>

## What "best practice" actually means here

Let's be specific about the source. The check set is inspired by [Polaris](https://github.com/FairwindsOps/polaris) and the [NSA / CISA Kubernetes hardening guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF). Both are good prior art - Polaris because it's the de-facto rule set for Kubernetes config validation, NSA / CISA because it's the standard most security teams point at when they want to argue for stricter defaults.

The result is opinionated but defensible. Every check has a reason. We don't flag YAML style preferences ("use camelCase in your annotations"). We flag things that have an actual blast radius if they go wrong.

The 31 checks split into three categories.

### Security (the ones the security team will ask about)

- Containers running as root.
- Privileged containers.
- `allowPrivilegeEscalation: true`.
- Writable root filesystems.
- Dangerous or insecure Linux capabilities.
- Host network, PID, or IPC namespaces.
- Container runtime socket mounts.
- Sensitive host path mounts.
- Secrets accidentally placed in ConfigMaps.
- Auto-mounted service account tokens.

### Reliability (the ones the SRE team will ask about)

- Missing readiness or liveness probes.
- Mutable image tags (e.g. `latest`).
- Pull policy mismatches on digest-pinned images.
- Single-replica Deployments or StatefulSets.
- Missing PodDisruptionBudgets on replicated workloads.
- Missing topology spread constraints.
- All replicas scheduled on one node.
- Services with no matching pods.
- Ingresses pointing at missing Services.
- Deprecated API versions.

### Efficiency (the ones the FinOps team will ask about)

- Missing CPU or memory requests.
- Missing CPU or memory limits.
- Resource utilization far below or above requests.
- Unused ConfigMaps or Secrets.

The checks carry framework labels where they map cleanly to NSA / CISA or CIS guidance. The goal is not to replace a full compliance program. It is to make the obvious misses visible before they become incident or audit material.

## How findings show up

The audit runs continuously. There's no "run scan" button - findings update as your resources change.

The **Cluster audit** sidebar entry has three views:

- **Summary** - findings broken down by category and severity.
- **By resource** - rows of resources sorted by issue count. Useful for "fix the worst offenders first."
- **By check** - rows of checks sorted by frequency. Useful for "we're going to standardize on `runAsNonRoot` across the fleet, what does that touch?"

In the resource browser, every row that has an audit finding shows a small chip. Click in, the **Audit** tab shows the per-resource breakdown with the rule, the severity, and a remediation snippet.

The useful moment is usually not "run a scanner once a quarter." It is "I'm already looking at this Deployment, and Radar tells me it has no readiness probe, one replica, and no PDB."

## Ignoring noise without disabling the check

The first thing teams want to do after enabling a check set is silence the things that are correct-but-flagged. Polaris-style global disables work but lose the signal everywhere - usually you only want to suppress for a specific namespace or workload.

Ignore patterns are configured in the Radar values:

```yaml
audit:
  ignore:
    # exact resource match
    - kind: DaemonSet
      namespace: kube-system
      name: cilium
      checks: [host_network, privileged]
    # selector match
    - namespaceLabels:
        environment: dev
      checks: [latest_tag, missing_resource_limits]
```

Selectors compose. The pattern most teams land on: a "production has strict rules, dev is intentionally lenient" carve-out, plus a small allow-list for system DaemonSets that legitimately need elevated access (Cilium, kube-proxy, the storage CSI driver, etc.).

For local Radar, the same shape lives in `~/.radar/audit-ignore.json`. Both formats round-trip; you can edit either.

Ignores are configuration, not deletion: the check still exists, but the UI stops treating that known exception as work.

## Programmatic access

Two surfaces beyond the UI.

The HTTP API:

```
GET /api/audit                                    # whole cluster
GET /api/audit/resource/{kind}/{namespace}/{name} # single resource
```

JSON output, filterable by category and severity. Useful for wiring findings into CI - a PR that introduces a new high-severity finding should fail before it lands in main, and `curl /api/audit | jq '.findings | map(select(.severity == "high"))'` is the easy way to ask.

The MCP tool `get_cluster_audit` is the same surface, packaged for AI tools. Filterable by category, severity, namespace. The use case we hear most is "ask Claude to explain this finding" or "have the AI propose a remediation patch and then dry-run-apply it."

## Cloud rolls it up across the fleet

In Radar Cloud, fleet checks fan out to connected clusters and merge the results.

That answers different questions:

- Which clusters have critical audit findings right now?
- Which check is failing across the most clusters?
- Did our policy change land everywhere?
- Which namespace owns most of the remaining hygiene debt?

The data still comes from the in-cluster Radar instances. Cloud is the coordination layer, not a hosted copy of every finding forever.

## What it isn't

Worth being explicit.

**Not a runtime security tool.** Cluster audit catches misconfiguration. It doesn't replace Falco, Tetragon, or whatever your eBPF-based runtime detection layer is. A privileged container that gets compromised at runtime is its problem; a privileged container that shouldn't have been deployed in the first place is ours.

**Not a CIS benchmark scanner.** kube-bench and Trivy do CIS benchmarks against the cluster control plane (etcd, kube-apiserver, kubelet config). Cluster audit runs against the workloads running on the cluster. Both are useful; they don't overlap.

**Not deterministic across check versions.** We add checks as patterns emerge in the wild. A new high-severity check shipping in a Radar release will surface findings that didn't exist before. The mitigation is the ignore-pattern config above and the changelog, which calls out new and changed checks per release.

**Not an upgrade-readiness scan.** Cluster audit checks today's hygiene against today's cluster. What breaks when you move to the *next* Kubernetes version - removed feature gates, APIs that stop being served, kubelet flags that keep a node from starting - is a separate, release-aware check set: the Upgrade impact view. [What breaks in Kubernetes 1.37](/blog/kubernetes-1-37-breaking-changes) walks through it on a real upgrade boundary.

**Not a capacity or scheduling diagnosis.** Cluster audit will tell you a Deployment has no resource limits. It won't tell you why that Deployment's pods are stuck Pending, which NodePool could have taken them, or why a node launched and never registered - that is the Capacity view, and [why a pod is pending on a Karpenter cluster](/blog/karpenter-troubleshooting) walks through it on a real cluster.

## Why bake it in instead of pointing at Polaris

We considered shipping Radar as "use Polaris and we'll render its output." Two reasons we didn't.

The first is the install cost. Polaris is good, but it's another Helm chart to deploy, another CRD set to track, and another upgrade cycle. For a tool that's supposed to give you visibility in five minutes, asking you to also deploy a separate audit controller is the wrong answer.

The second is integration. The audit findings show up next to the resource that has them, in the same UI you're already using to debug. The MCP integration lets an AI tool fetch findings the same way it fetches resources. The Cloud fleet view aggregates findings across clusters because it already aggregates everything else. Bolting Polaris's output onto our UI would have been a constant integration tax; building the check engine in-process is one decision we make once.

## The shape of it

Most clusters fail the same handful of checks. Most of those failures have boring fixes. The reason they don't get fixed is that nobody surfaces them in the same place where the engineers actually work.

Cluster audit is the same idea as the rest of Radar - put the information where you'd already be looking, don't make people deploy another thing to get it. The 31 checks aren't novel. The fact that you can see them inline next to the broken resource, with an MCP endpoint for your AI tools and a fleet rollup in Cloud, mostly is.

If you want to see what your cluster looks like under it, the open-source Radar is free for self-hosted and the audit is on by default - install instructions are at [radarhq.io/docs](https://radarhq.io/docs).


---

### The Fleet Visibility Gap: Why Teams With 5+ Clusters Hit a Wall

- **URL**: https://radarhq.io/blog/the-fleet-visibility-gap
- **Date**: 2026-02-27
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Platform
- **Tags**: radar-cloud, kubernetes, multi-cluster, platform-engineering, for-devops


It's the third time this week someone asked me which cluster our staging API actually runs in.

Not "is staging healthy." Not "what's the error rate." Just: where does it live. The answer turned out to be `stg-eu-2`, a cluster spun up four months ago for a GDPR workload that quietly became the default for anything EU-adjacent. Nobody wrote that down. The person who knew left the company in September.

![Fleet visibility gap hero](/images/blog/fleet-visibility-gap-hero.png)

One cluster is a debugging problem. Five clusters are an inventory problem, an access problem, and an incident coordination problem. If you're running one cluster, skip this post. If you're running two, bookmark it. If you're somewhere between five and fifty, you already know where this is going.

## How you end up with twelve clusters without planning to

Nobody sits down and says "let's run twelve Kubernetes clusters." You start with one. Then you need a staging environment, because prod-shaped accidents are expensive. Two.

Then someone points out that running staging and prod on the same control plane defeats the point, so you split the cloud accounts. Three, if you count dev. Then a customer in Frankfurt needs data residency. Four. Then your biggest customer wants a dedicated tenant for compliance. Five. Then the platform team decides per-team clusters are cleaner than shared namespaces for the new ML workloads. Eight. Then you acquire a company and inherit their GKE footprint. Eleven.

That's a real trajectory. I spoke to a platform lead at a 60-person company last month who has 14 clusters across 3 regions - EKS in us-east-1 and eu-west-1, GKE in asia-southeast1 for latency reasons, plus four "temporary" clusters that have existed for over a year. They have two engineers on the platform team.

The clusters aren't the problem. Kubernetes handles that part fine. The problem is that the tools you used to operate one cluster don't compose.

## The single-cluster assumption baked into every tool

Walk through the standard debugging kit. Every single one of these - [k9s, Lens, Headlamp, and the rest](/blog/best-kubernetes-dashboards-2026) - assumes you're looking at one cluster at a time.

**kubectl** has contexts. That's the official answer. In practice you end up with a `~/.kube/config` that's 400 lines long, a handful of `KUBECONFIG` env vars pointing at different files, and a shell alias wall that looks something like this:

```bash
# ~/.zshrc, three months into the job
alias kprod-us="kubectl --context=arn:aws:eks:us-east-1:1234:cluster/prod-us"
alias kprod-eu="kubectl --context=arn:aws:eks:eu-west-1:1234:cluster/prod-eu"
alias kstg-us="kubectl --context=arn:aws:eks:us-east-1:1234:cluster/stg-us"
alias kstg-eu="kubectl --context=arn:aws:eks:eu-west-1:1234:cluster/stg-eu-2"
alias kdev="kubectl --context=kind-dev"
alias kacme="kubectl --context=gke_acme-prod_us-central1_acme"
# ... and six more

# the function everyone writes eventually
kall() {
  for ctx in prod-us prod-eu stg-us stg-eu-2; do
    echo "=== $ctx ==="
    kubectl --context="$ctx" "$@"
  done
}
```

That `kall` function is a tell. It's what you write the first time you need to check "are any of our clusters seeing the same CrashLoopBackOff?" It works for trivial commands. It falls apart the moment you need to correlate anything, or the moment one context hangs for 30 seconds because the VPN dropped.

**k9s** is excellent. I use it daily. But it shows one cluster at a time. You switch contexts with `:ctx` and the whole UI reloads - events, pods, the lot. There's no "show me every failing pod across my fleet." Not k9s's job, and it's honest about that.

**Lens and its forks** (OpenLens, Freelens) technically let you add multiple kubeconfigs to the sidebar. Each one opens in a separate workspace pane. You can't see them at once in any useful way, and switching between them triggers a full reload of the cluster state. On a machine with six clusters loaded, memory usage gets unpleasant. Lens itself has the mandatory cloud-login baggage that pushed a lot of us to look for an alternative in the first place.

**Headlamp** supports multiple clusters better than most - it'll show them in the sidebar and you can click between them. But the views are per-cluster. There's no aggregated event feed, no cross-cluster search, no fleet dashboard. It's a competent single-cluster UI that tolerates being pointed at several kubeconfigs.

**Per-cluster dashboards** (Grafana, Datadog cluster view, the EKS console) work well for what they show, but they're separate dashboards. You end up with a bookmark folder of twelve URLs and a habit of opening them in sequence every morning.

### The honest comparison

| Tool              | Multiple clusters supported | Aggregate view | Persistent cross-cluster history | Who it's for                       |
|-------------------|-----------------------------|----------------|----------------------------------|------------------------------------|
| kubectl           | Via context switching       | No             | No                               | Everyone, always                   |
| k9s               | One at a time (fast switch) | No             | No                               | Terminal natives debugging one cluster |
| Lens / OpenLens   | Multiple kubeconfigs loaded | No             | No                               | GUI users on a single laptop       |
| Headlamp          | Sidebar-style multi-cluster | Partial        | No                               | Teams who want a browser-based UI  |
| Per-cluster dashboards | Yes, separately        | No             | Yes, per cluster                 | Ops teams with dedicated dashboards per env |

None of these are bad. They're solving the single-cluster problem well. The fleet problem is a different problem.

## The hidden cost of not having fleet visibility

You don't notice the gap all at once. It accumulates.

**Longer incidents.** The on-call engineer pages in, opens their laptop, and spends the first four minutes figuring out which cluster the alert came from. Was it `prod-us` or `prod-eu-2`? The alert says `api-gateway` but there are three of those across the fleet. By the time they've switched context, opened logs, and cross-referenced the deploy history, the customer impact is already on Twitter.

**Missed signal.** A ConfigMap change goes out to all production clusters via Argo CD. One of them rejects it because a CRD version is pinned to an older release. Nobody notices for six hours because the failure is buried in one cluster's events feed and nobody was looking at that tab.

**Onboarding tax.** The new engineer joins. They need to know how to connect to every cluster, which ones are safe to click around in, which ones have stricter RBAC, which ones have the weird Istio setup from 2023. The only documentation is a Notion page that's been out of date since February. They spend their first two weeks building a mental map that the rest of the team carries in their heads.

**Context reconstruction.** "What did we deploy to prod-eu on Tuesday?" is a question that should take five seconds. Without persistent cross-cluster history, it takes a Slack thread, a Git log, a CI run search, and someone eventually guessing.

These costs don't show up on a dashboard. They show up as fatigue, as longer MTTR, as "we should rebuild our platform" conversations that don't lead anywhere.

## What a fleet tool needs to do

If you were designing for the multi-cluster case from the start, a few properties fall out naturally:

**Aggregate problems first, drill-down second.** The default landing page should show every cluster you operate, with health, recent events, and workload counts. Clicking into a cluster gets you the familiar single-cluster view. Most tools flip that - you pick a cluster, then see its state.

**Search across clusters.** If you know a resource name, host, label, or package, you should not have to remember which cluster owns it.

**Roll up checks.** A policy failure in one cluster is a ticket. The same failure across twenty clusters is a platform issue.

**Show package drift.** Teams need to know which clusters are behind on cert-manager, Cilium, Argo CD, Karpenter, Linkerd, or any other package the tool can detect.

**A shared context that isn't a kubeconfig.** Kubeconfigs were designed for one user on one machine. For a team, you want shared enrollment - a cluster gets connected once, everyone authorized can see it, access is managed centrally. No more Slack DMs with `kubeconfig.yaml` attached.

**Outbound-only connectivity.** Nobody is opening an inbound port on their production cluster for a vendor dashboard. Any sane fleet tool dials out from the cluster, not the reverse.

## What Radar Cloud ships today

Radar Cloud's fleet section answers four of those questions today: **Problems, Search, Checks, and Packages.**

The views fan out to connected clusters over the tunnel and render progressively. For small fleets that is usually sub-second. For large fleets, expect the first load to take a few seconds as clusters answer.

One thing is still evolving beyond that first set of fleet views:

- **Cross-cluster topology** is not shipped. Radar topology is per-cluster today. Kubernetes does not have a native multi-cluster service graph, and pretending otherwise produces pretty diagrams that lie.

Cloud-backed timeline retention, which was on the roadmap when this post was written, has since shipped: the control plane pulls each cluster's event history over the tunnel it already holds open and retains it centrally, so history outlives the pod, the PVC, and the cluster. Details in [Kubernetes Events Expire in an Hour](/blog/kubernetes-event-retention).

That's the honest line. Cloud closes the practical fleet gap for current health, search, audit checks, and package drift, without making the hosted backend the live source of truth for every cluster object.

## The access problem

Fleet visibility isn't only a UI problem.

The team needs one enrollment path and one identity model. Otherwise every new engineer gets a zip file of kubeconfigs and a wiki page nobody trusts.

Radar Cloud handles that through org membership, SSO, roles, and Kubernetes impersonation. Cloud decides who the user is. Kubernetes still decides what they can do in each cluster.

That lets a platform team connect clusters once and manage humans centrally, without replacing Kubernetes RBAC.

## The honest state

If what you need is one team URL that tells you where the problems are, where a resource lives, which checks are failing, and which packages are drifting - that is exactly the product.

If you need a perfect service graph across meshes, regions, and DNS conventions, that is still hard. We're not pretending we shipped it.

In the meantime, if this post describes your week, you're not alone. The tooling gap is real. Recognizing it is the first step toward not papering over it with another wall of shell aliases.


---

### What We're Building in 2026: Radar OSS and Radar Cloud

- **URL**: https://radarhq.io/blog/what-were-building-in-2026-radar-oss-and-cloud
- **Date**: 2026-01-28
- **Author**: Eyal Dulberg, CTO, Skyhook
- **Category**: Announcements
- **Tags**: radar, radar-cloud, kubernetes, open-source, roadmap


Two shipping dates, one product line, and a clear split between what's free and what costs money.

In January 2026 we're releasing **Radar** as open source under Apache 2.0. In February 2026 we're releasing **Radar Cloud**, the hosted multi-cluster version. This post is the engineering view of what lands in each, what doesn't, and why we drew the line where we did.

## Why two products instead of one

We've spent the better part of a year talking to teams running Kubernetes at the messy middle of the curve: past the first production cluster, not yet big enough to have a platform team. The consistent pattern: they have three to twelve clusters, no good way to see them together, and a debugging experience that still leans on `kubectl` plus tabs.

Radar (the OSS tool we built for ourselves) solves the single-cluster debugging problem. It's a Go binary with the React UI embedded via `go:embed`, runs against your kubeconfig, and shows you resources, topology, a timeline, Helm releases, GitOps state, and traffic - live, via SharedInformers on top of the Watch API. No in-cluster install. No cloud account. No data leaving your laptop.

That covers one engineer debugging one cluster. It does not cover:

- Multiple clusters visible in one place.
- History that survives restarts and outlives your current kubeconfig session.
- Alerts when something breaks at 3am and nobody's looking.
- RBAC beyond whatever your kubeconfig already grants.
- A shared URL to a specific resource at a specific time for your incident channel.

Those are team problems. They need an identity layer, an org-scoped audit log, and a hub that's awake when you're not. Trying to solve them inside the OSS binary would make Radar slow, opinionated, and hard to run on a laptop. So we split.

## January 2026: Radar OSS

Radar OSS ships as a single Go binary. The React frontend is compiled in. On startup it reads your kubeconfig, opens your browser, and connects directly to the API server.

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

Also available via Homebrew, Scoop, and an in-cluster Helm chart for teams that want a shared instance.

What's in the v1 binary:

- **Resources view** - browse every resource type, YAML edit, logs, events, exec, port-forward, image filesystem browsing.
- **Topology view** - structured DAG of ownership, service routing, ingress paths, config dependencies.
- **Timeline view** - live stream of Kubernetes events and resource changes, in-memory by default, SQLite-backed if you pass `--timeline-storage sqlite`.
- **Helm view** - list, inspect, upgrade, rollback, uninstall; uses the Helm Go SDK directly, not shelling out.
- **GitOps view** - Argo CD Applications and Flux Kustomizations / HelmReleases / GitRepositories show up in topology with sync status, and you can trigger sync / reconcile from the UI.
- **Traffic view** - auto-detects Cilium / Hubble or Caretta and draws a live flow graph.
- **Cluster audit** - 36 best-practice checks across security, reliability, and efficiency, surfaced inline on the affected resources.
- **MCP server** - token-optimized, RBAC-aware cluster context for AI tools like Claude, Cursor, and Claude Code.

CRDs are auto-discovered via dynamic informers, so Argo Rollouts, Istio VirtualServices, and your own CRDs appear without plugin work.

Source goes public in January. Apache 2.0. We want PRs.

## February 2026: Radar Cloud

Radar Cloud is a hosted control plane plus Radar deployed in each cluster. In-cluster Radar is the same Go binary as OSS (~32MB RSS steady state). Instead of serving a local UI, it dials out to `api.radarhq.io:443`, holds an outbound WebSocket open, and lets the control plane reverse-proxy authenticated browser requests through to it on demand. Cluster state stays in the cluster.

The connection is **outbound-only**. No inbound ports. No NodePort, no LoadBalancer, no Ingress. If your cluster can reach the public internet, Radar works. If it can't, you stay on OSS.

```bash
helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm repo update

helm install radar skyhook/radar -n radar --create-namespace \
  --set cloud.token=$RADAR_CLOUD_TOKEN
```

The enrollment token is issued from the Radar dashboard. Radar runs with a scoped Kubernetes ServiceAccount - read-only by default, read / write if you opt in for features like rollback from the UI. Logs, exec streams, and port-forwards all go through Radar on demand and are never stored at rest.

In GA on February release:

- **Fleet views** across every connected cluster: problems, cross-cluster search, audit-check rollups, package drift.
- **Live timeline** served live through the reverse proxy from the in-cluster Radar pod.
- **SSO**: Google and GitHub sign-in on every plan; corporate SAML / OIDC (Okta, Google Workspace, Entra ID, OneLogin, generic SAML / OIDC) on Enterprise.
- **Kubernetes-native RBAC** via impersonation: three default roles (`owner`, `member`, `viewer`) bound to standard K8s ClusterRoles, plus per-user RoleBindings via `cloud:user:<id>` groups.
- **Audit log** with tier-based retention: 7 days on Free, 30 days on Team, 365 days on Enterprise.
- **Notifications** for hub events (cluster connect / disconnect, billing, member invites) over Slack, webhook, and an in-app inbox.
- **Shareable deep links** per resource and view.
- **REST API** for automation.
- **MCP server per cluster** for AI tools (Claude, Cursor, Claude Code, etc.).
- **SOC 2 Type 2** attestation.
- **Data residency** in US (us-east-1) or EU (eu-west-1).

SCIM 2.0 directory sync ships on Enterprise for teams that need directory-driven user and group lifecycle from their IdP. The control plane is Go microservices on PostgreSQL; it doesn't store cluster state - all cluster data is served live from the in-cluster Radar pod.

## The product boundary

| Concern | Radar OSS | Radar Cloud |
| --- | --- | --- |
| Cluster resources | Yes | Served through in-cluster Radar |
| Topology | Per-cluster | Per-cluster through tunnel |
| Timeline | Local memory or SQLite | Per-cluster through tunnel |
| Cluster audit | Yes | Per-cluster plus fleet rollups |
| MCP | Local endpoint | Per-cluster Cloud endpoint via PAT |
| Orgs and members | No | Yes |
| SSO | Self-managed OIDC / proxy if you deploy it | WorkOS SAML / OIDC |
| Audit log | Local / K8s context | Cloud control-plane activity |
| Fleet views | No | Problems, search, checks, packages |
| Billing | No | Stripe |

No cluster feature is held back from OSS just because Cloud exists.

## What's not in v1

Being specific about gaps is more useful than listing features.

- **No cross-cluster topology yet.** Fleet views give you the aggregate dashboard for problems, search, checks, and packages. A true cross-cluster topology graph (tracing a service mesh request from cluster A to cluster B) is on the roadmap, not a launch feature.
- **No cross-cluster timeline yet.** Per-cluster timeline works through the reverse proxy. A unified timeline that joins events across clusters is on the roadmap.
- **No long-term Cloud-backed event archive at launch.** At v1 events lived only in the cluster, with optional SQLite persistence. *(Shipped since: the control plane now pulls each cluster's timeline over its existing tunnel and retains it centrally - see [Kubernetes Events Expire in an Hour](/blog/kubernetes-event-retention). A SIEM is still the right answer for multi-year archives.)*
- **No Windows node support.** Radar ships as a Linux container only. We don't have Windows nodes in our test matrix, and we'd rather not claim support we haven't exercised.
- **No event-rule alerting on arbitrary K8s events.** Cloud notifications cover hub-side events only (connection, billing, invites). If you want pager-style alerting on K8s event streams, that's Prometheus / Alertmanager territory; we're not going to be that system.
- **Self-hosted control plane below Enterprise.** More on this below.

## The self-hosted question

We've been asked this enough that it deserves a paragraph.

Radar Cloud is a multi-tenant hosted service by default. Packaging the control plane into a single-tenant BYOC / on-prem install is a real project, which is why we only support it on the **Enterprise** tier. Free and Team are SaaS-only.

This matters for two groups: teams in air-gapped environments (defense, some finance, some regulated health workloads) and teams whose security policy prohibits outbound telemetry to a shared multi-tenant SaaS. If you need to keep data inside your own infrastructure, Enterprise BYOC is the path; if you don't need the Cloud backend at all, **Radar OSS is the right answer**, and it will stay the right answer. We are not going to cripple OSS to push you toward Cloud.

## When to use which

**Use Radar OSS when you're a single engineer** debugging your own cluster, when you're working in an air-gapped environment, when you need a fast local tool for incident response without logging in to anything, or when you want to see what a cluster is doing in under ten seconds flat. It's a better `kubectl` for most day-to-day visibility work.

**Use Radar Cloud when you're a team.** When you want a teammate's URL to land them on the same cluster you're looking at. When "who changed that ConfigMap" needs an audit log answer. When your engineers log in with Okta and you don't want to hand out kubeconfigs as the unit of access control. When a cluster going dark while nobody's watching needs to ping someone.

| | Radar (OSS) | Radar Cloud |
|---|---|---|
| Install location | Your laptop or a shared in-cluster pod | Hosted control plane; Radar per cluster |
| Multi-cluster | One context at a time | Fleet views across all connected clusters |
| Event timeline | In-memory or SQLite (in-cluster) | Live, served via reverse-proxy from the in-cluster pod |
| Audit log | - | 7 days Free / 30 days Team / 365 days Enterprise |
| Auth | Your kubeconfig | Google / GitHub sign-in on every plan; SAML / OIDC SSO and SCIM on Enterprise |
| RBAC | Whatever your kubeconfig grants | K8s impersonation - 3 default roles + per-user RoleBindings |
| Notifications | None | Slack, webhook, in-app inbox (hub events: connection, billing, invites) |
| Data residency | Your machine | US (us-east-1) or EU (eu-west-1); BYOC on Enterprise |
| SLA | None - it's a binary you run | 99.5% on Team, 99.9% on Enterprise |
| Pricing | Free, Apache 2.0 | Free (3 clusters), $149 / cluster / month Team, Enterprise custom |

## The rest of 2026

**Q2:** Cross-cluster topology, cross-cluster timeline, deeper provider-specific renderers, MCP tool expansion.

**Q3:** Cloud-backed timeline retention, deeper GitOps workflows (drift detection history, rollback orchestration across clusters), expanded Windows support if the demand signal is there.

**Q4:** The self-hosted control plane story for tiers below Enterprise, if customer signal warrants it.

If you want to follow along, the OSS source goes public in January and the Radar Cloud waitlist is open at [radarhq.io](https://radarhq.io). We'll post install-day walkthroughs for both.


---

### Introducing Radar: Modern Kubernetes Visibility

- **URL**: https://radarhq.io/blog/introducing-radar-modern-kubernetes-visibility
- **Date**: 2026-01-01
- **Author**: Nadav Erell, CEO, Skyhook
- **Category**: Announcements
- **Tags**: kubernetes, open-source, visualization, helm, gitops, for-devops


**TL;DR.** Radar is an open-source Kubernetes UI with a built-in MCP server for AI agents. See what's broken, why, and what changed. Run its Apache 2.0 Go binary locally against your kubeconfig or deploy it in-cluster with Helm to inspect root-cause issues, applications, topology, an event timeline, Helm, GitOps, live service traffic, cluster audits, and images - without creating an account or installing CRDs.

We got frustrated. So we built something and decided to give it away.

## The Problem

kubectl is always there. It works. But when you're debugging - jumping between `describe`, `logs`, `get events`, mentally mapping how resources connect - it's tedious.

The GUI tools that should make this easier all have their issues and limitations.

**Lens got acquired and changed direction.** Mirantis bought Lens in 2020. Mandatory logins and subscription tiers followed, and in 2023 Lens moved core features such as logs, exec, and shell into proprietary code. Lens remains capable, but its open-source story and account requirements no longer matched what we wanted from a local debugging tool.

**The open-source forks inherited the problems.** Freelens and OpenLens are community efforts to keep the old Lens alive, but they're forks of the same codebase. OpenLens stopped being maintained. Freelens is active, but the architectural baggage remains.

**The official Kubernetes Dashboard is archived.** SIG UI pointed users toward Headlamp, but Headlamp largely preserves the old Dashboard model: a generic resource browser extended by separately installed plugins, where plugins exist. It does not provide one integrated operational workflow across Issues and Applications, retained event and resource-change evidence, topology, Argo CD and Flux, Helm, live traffic, audits, image inspection, and an MCP server. That is the gap Radar was built to fill.

**k9s is great, but it's a terminal.** If you live in the terminal, k9s is fantastic - fast, keyboard-driven, no nonsense. But the learning curve is real (memorizing `:po`, `:deploy`, `:svc` shortcuts takes time), and there's no topology or visual overview. For some workflows - especially onboarding new team members or debugging unfamiliar clusters - a graphical interface is just faster.

**Enterprise platforms exist.** Komodor, Cast AI, and others cover parts of this problem, but often bring per-node pricing and a hosted-service operating model. Those tradeoffs can be reasonable for large teams; they were the wrong default for the local, open-source tool we wanted.

**Weave Scope is dead.** If you wanted topology visualization specifically, Weave Scope was the answer until Weaveworks shut down in 2024, leaving a gap for open-source, topology-first troubleshooting.

<div className="border border-border shadow-hard px-10 py-0 my-2 text-xl font-medium bg-red-50 dark:bg-red-950/30">
You're stuck choosing between slow and bloated, lightweight but limited, or expensive and cloud-dependent.<br/><br/>Time spent fighting your tools is time not spent fixing the problem.
</div>

## What We Built

We'd been using an internal tool at Skyhook for cluster debugging and demos. It started as a quick project to scratch our own itch - we wanted something fast, something that didn't require a cloud account, something that actually showed how resources relate to each other.

Eventually we realized the problem we solved for ourselves is the same problem everyone else has. So we open-sourced it.

**[Radar](https://radarhq.io)** is a single Go binary with the React frontend embedded inside. No Electron. It starts instantly, uses minimal memory, and runs entirely on your machine. Connect to your cluster via your existing kubeconfig, and a real-time dashboard opens in your browser.

Radar runs locally with no cluster-side installation, CRDs, or cloud account. Your cluster data stays on your machine.

```bash
curl -fsSL https://get.radarhq.io | sh
kubectl radar
```

Also available via Homebrew, Krew, or Helm for in-cluster deployment. See the [full install guide on radarhq.io](https://radarhq.io/open-source).

That's it. The dashboard opens in your browser, connected to whatever cluster context is active.

## What It Does

### Resources View

![Radar Resources View](/images/blog/radar-resources.png)

First, the table stakes. Everything you expect from a Kubernetes dashboard, plus a few things you don't:

- Browse all resource types, search by name, filter by status or problems
- Click any resource for YAML (view and edit), logs, events, exec, port-forwarding
- Browse container image filesystems directly - no pulling images or exec'ing in
- Smart columns per resource kind, status highlights, related resources at a glance

Argo CD and Flux resources show up with sync status out of the box - no plugins to install. It's a bit surprising that tools like Headlamp still treat GitOps as an afterthought when most production clusters run one of these two systems.

That's the baseline. Here's what else you get:

### Topology View

![Radar Topology View](/images/blog/radar-topology.png)

An interactive graph showing how your Kubernetes resources connect in real-time.

The key design decision: **structured DAG layout instead of force-directed physics.** Most open-source visualizers (KubeView, the old Weave Scope) use force-directed layouts where nodes bounce around based on simulated physics. This looks cool in a demo with 10 pods. It becomes an unreadable hairball in a real cluster.

Radar shows the actual relationships between resources:
- Ownership chains (Deployment → ReplicaSet → Pods)
- Service routing (which pods a Service selects)
- Ingress paths (Ingress → Service → backend)
- Configuration dependencies (which ConfigMaps and Secrets a workload uses)
- HPA scaling targets

Resources with problems light up in yellow or red, so you can spot issues at a glance without clicking through lists. Group by namespace, by app label, or view ungrouped. Filter by resource kind. Click any node for full details.

### Timeline View

![Radar Timeline View](/images/blog/radar-timeline.png)

A unified stream of Kubernetes events and resource changes as they happen. Filter by event type (all events or warnings only). See what changed in the last 5 minutes. Resources with recent warnings get a visual badge on the topology.

This captures most of the "what just happened?" value without requiring a separate storage backend. Events come straight from the Kubernetes API in real-time.

### Helm View

![Radar Helm View](/images/blog/radar-helm.png)

See all Helm releases across namespaces with status, chart version, and app version. Each release shows the health of its owned resources, so you know at a glance if something's wrong. Inspect values, compare revisions, view release history. Install, upgrade, rollback, or uninstall directly from the UI.

### Traffic View

![Radar Traffic View](/images/blog/radar-traffic.png)

If you have Cilium with Hubble or Caretta installed, Radar auto-detects them and shows live network traffic between services. Animated flow graph showing requests per second. If no traffic source is detected, there's a setup wizard to install one.

## Technical Details

Radar is a single Go binary with the React frontend embedded at compile time using `go:embed`. No separate static file server, no runtime dependencies. The binary talks directly to your Kubernetes API server using your kubeconfig credentials.

### How the real-time updates work

The backend uses `client-go` SharedInformers - the same pattern the Kubernetes controller runtime uses internally. On startup, Radar does a single list operation per resource type, then switches to the Watch API. The API server pushes deltas (add/update/delete) over a persistent connection. No polling.

When a resource changes, the informer callback fires, updates the in-memory cache, and broadcasts the change to connected browsers via Server-Sent Events (SSE). A pod crashes, the UI reflects it in milliseconds - not on your next manual refresh.

For CRDs and dynamic resources, we use dynamic informers that auto-discover API groups at startup. If your cluster has Argo Rollouts, Istio VirtualServices, or custom CRDs, Radar picks them up automatically.

GitOps tools get first-class treatment: Argo CD Applications and Flux resources (Kustomizations, HelmReleases, GitRepositories) show up in the topology with sync status, and you can trigger common operations like sync and reconcile directly from the UI.

### What this means in practice

- **Minimal API server load.** Watch streams are cheap. We're not hammering your cluster with list calls every 5 seconds.
- **Instant updates.** The latency is network RTT, not poll interval.
- **Memory-efficient.** We strip `managedFields` and other heavy metadata from cached objects. The cache holds what you need to see, not what kubectl stores internally.

### Other implementation details

- **Helm SDK integration.** Helm operations (list, upgrade, rollback, uninstall) use the Helm Go SDK directly - not shelling out to the `helm` CLI.
- **WebSocket for exec.** Pod terminal sessions use a WebSocket connection, same protocol as `kubectl exec`.
- **Port forwarding.** Managed sessions with automatic cleanup, exposed via the UI.
- **chi router.** Lightweight HTTP routing, no framework bloat.

Works with any conformant Kubernetes cluster: GKE, EKS, AKS, minikube, kind, k3s. Respects your existing kubeconfig contexts and RBAC permissions. If you can `kubectl get pods`, Radar can show them to you.

For teams that want shared access, there's a Helm chart to deploy Radar inside the cluster. Teams looking for managed multi-cluster, SSO, and retention can see [Radar Cloud pricing](https://radarhq.io/pricing):

```bash
helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespace
```

## What It Doesn't Do

Radar covers a lot of ground, but it's not trying to be everything.

- **No built-in persistence.** Timeline events are in-memory by default. You can enable SQLite storage with `--timeline-storage sqlite` for persistence across restarts, but there's no multi-week retention or time-travel queries.
- **Single cluster at a time.** The OSS version connects to one cluster context. You can switch contexts, but there's no aggregated multi-cluster view. For a [multi-cluster aggregated view, see Radar Cloud](https://radarhq.io/product).

## Why Open Source

A few reasons:

**The incumbents lost the plot.** Lens started as a genuinely useful tool. Then it got acquired, commercialized, bloated with features, and now requires cloud authentication. The pattern repeats across the industry - tools get popular, get acquired, get worse. We wanted something that stays simple.

**Local-first matters.** We've watched tool after tool add mandatory cloud logins, telemetry requirements, or "call home" features. For teams in regulated industries - finance, healthcare, defense - sending cluster metadata to a third-party cloud is a non-starter. Radar runs entirely on your machine. No accounts, no telemetry, no data exfiltration.

**Speed is a feature.** When you're debugging a production incident at 2am, you don't want to wait 30 seconds for your cluster to connect. You don't want to watch loading spinners every time you click something. You want to see what's happening now.

**We use it ourselves.** Radar started as an internal tool. Open-sourcing it means more eyes on the code, more bug reports, and more feature ideas. The best way to maintain software is to have other people depending on it.

## Get Started

```bash
# Quick install
curl -fsSL https://get.radarhq.io | sh

# Homebrew
brew install skyhook-io/tap/radar

# Krew
kubectl krew install radar

# In-cluster (Helm)
helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespace
```

Then just run:

```bash
kubectl radar
# or just
radar
```

The source is on GitHub: [github.com/skyhook-io/radar](https://github.com/skyhook-io/radar). Apache 2.0 license. Contributions welcome.

If you find bugs or have feature ideas, open an issue. We're building this because we need it - and we suspect you do too.

Looking for a managed, multi-cluster version? [Radar Cloud](https://radarhq.io) builds on the OSS core.

## Further reading

- [Radar: Open Source](https://radarhq.io/open-source)
- [Radar vs Lens](https://radarhq.io/vs/lens)
- [Radar vs k9s](https://radarhq.io/vs/k9s)
- [Radar for SRE](https://radarhq.io/for/sre)
- [Radar's MCP server for Kubernetes](https://radarhq.io/product/mcp)