Radar: dashboard Kubernetes en un binario Go de 30 MB
Radar es una interfaz de Kubernetes local-first distribuida como un binario único de Go de aproximadamente 30 MB que se conecta directo a tu cluster usando kubeconfig, sin cloud, sin cuenta, sin agentes en el cluster. La desarrolló Skyhook (YC W23) y está disponible desde 2026 como proyecto open source con una capa Cloud opcional.
En 30 segundos
- Radar es un dashboard de Kubernetes en un binario Go único (~30 MB), sin dependencias externas ni registro de cuenta para arrancar.
- Se instala con un solo comando (brew, curl o krew) y levanta una UI web en localhost en segundos.
- Muestra topología del cluster, tráfico entre servicios, logs en streaming, ejecución de comandos en pods y gestión de Helm releases.
- No necesita instalar nada en el cluster para el modo local: usa tu kubeconfig existente y listo.
- La versión open source es gratis; Radar Cloud agrega multi-cluster y features de equipo (precio no publicado aún).
Qué es Radar: la interfaz Kubernetes moderna que te esperabas
Si alguna vez abriste Kubernetes Dashboard y pensaste “esto parece de 2014 con un baño de pintura”, no sos el único. La interfaz oficial de Kubernetes cumple su función, pero su curva de aprendizaje para visualizar qué está pasando entre tus pods es, en el mejor de los casos, frustrante.
Radar es una interfaz Kubernetes local-first desarrollada por Skyhook, una empresa de Y Combinator (batch W23), que apunta exactamente a ese problema. El concepto es simple: un binario único compilado en Go, sin instaladores, sin sidecars, sin cuentas obligatorias. Abrís una terminal, ejecutás un comando, y tenés un dashboard web levantado en localhost en menos de 15 segundos.
Lo que lo diferencia no es solo la velocidad de instalación. Radar corre completamente en tu máquina, leyendo tu kubeconfig. No hay ningún servicio cloud intermediario recibiendo información de tu cluster, y eso, para equipos que trabajan con datos sensibles o en entornos regulados, no es un detalle menor.
Según el blog oficial de Skyhook, Radar soporta más de 20 integraciones con herramientas del ecosistema CNCF (ArgoCD, Flux, Istio, entre otras) y tiene soporte para visualizar topología de red, tráfico entre servicios e inspección de filesystems de imágenes de contenedores, todo desde la misma interfaz.
Arquitectura local-first vs dashboards en la nube
El modelo local-first tiene implicaciones concretas que vale la pena entender antes de elegir.
En el modo local, Radar corre en tu máquina y se conecta al cluster a través del mismo canal que usa kubectl: tu kubeconfig. No instala agentes en el cluster, no manda telemetría a ningún lado, y no necesita internet para funcionar una vez instalado. Arrancás, ves lo que pasa, cerrás. Los datos de tu cluster nunca salen de tu red.
Eso contrasta con dashboards que requieren un componente cloud para funcionar, donde básicamente estás pasando metadata de tu infraestructura por un tercero. Para desarrollo local o clusters de staging esto puede no importar demasiado. Para producción con datos sensibles, cambia el análisis. Recomendamos revisar nuestra cobertura de implementación SEO en herramientas distribuidas.
Eso sí: el modelo local tiene limitaciones reales. Sin el componente Cloud, Radar no agrega múltiples clusters en una vista unificada. Tampoco tiene alertas persistentes ni historial de métricas (no es un reemplazo de Prometheus). Si manejás una flota de 15 clusters, la versión open source te va a quedar chica. Para eso existe Radar Cloud, aunque los precios no están publicados todavía.
Instalación: 15 segundos para empezar
El requisito único es tener un kubeconfig válido en ~/.kube/config. Con eso, podés instalar Radar de tres formas:
Modo local (solo en tu máquina)
Con Homebrew en macOS/Linux:
brew install skyhook-io/tap/radar
radarCon curl (Linux/macOS):
curl -fsSL https://get.radarhq.io | sh
radarCon krew (plugin de kubectl):
kubectl krew install radar
kubectl radarEn todos los casos, el binario levanta un servidor web local y abre el dashboard en tu browser automáticamente. No hay paso de configuración adicional.
Modo en-cluster (via Helm)
Si preferís que Radar corra dentro del cluster y sea accesible desde cualquier máquina del equipo:
helm repo add skyhook https://charts.skyhook.io
helm install radar skyhook/radar -n radar --create-namespaceDespués accedés via port-forward o configurando un Ingress. Este modo tiene sentido cuando querés un dashboard compartido para el equipo de DevOps sin que cada uno instale el binario local.
Características principales: topología, eventos y tráfico
Ponele que tenés un microservicio que no responde y no sabés si el problema está en la red, en el pod, o más arriba en el Ingress. Con kubectl tenés que abrir cuatro terminales, ejecutar get pods, describe service, logs, y encadenar mentalmente qué está conectado con qué.
Radar te muestra la topología del cluster en una vista gráfica donde ves los recursos y sus relaciones. Pasás a la vista de tráfico y ves el flujo entre servicios en tiempo real. Sin query, sin YAML parsing manual. Tema relacionado: ventajas de la filosofía local-first.
Las funcionalidades confirmadas según el repositorio oficial incluyen:
- Visualización de recursos en modo topología y modo tráfico de red
- Timeline de eventos del cluster (útil para entender qué cambió antes del incidente)
- Streaming de logs con filtros en tiempo real
- Exec interactivo en pods desde la UI web
- Inspección de filesystems de imágenes de contenedores (sin correr el contenedor)
- Gestión de Helm releases: ver releases, historial, rollback
- Soporte para GitOps: integración con ArgoCD y Flux, mostrando el estado de sincronización
- Integraciones con más de 20 herramientas CNCF
La inspección de filesystems de imágenes merece una mención aparte porque es una feature que pocas herramientas tienen en la misma interfaz. Podés ver el contenido de una imagen directamente desde Radar sin necesidad de bajarla localmente con docker pull. Para debugging de seguridad o simplemente para verificar qué versión de una librería tiene un contenedor, es útil.
Comparación con k9s, Headlamp y Aptakube
El mercado de herramientas de visualización para Kubernetes no está vacío. Antes de adoptar Radar, conviene entender dónde encaja.
| Herramienta | Interfaz | Binario único | Multi-cluster | En-cluster | Costo | Curva aprendizaje |
|---|---|---|---|---|---|---|
| Radar | Web | Sí (~30 MB) | Solo Cloud | Sí (Helm) | Gratis / Cloud N/P | Baja |
| k9s | CLI (TUI) | Sí | Sí (contexts) | No | Gratis | Media |
| Headlamp | Web / Desktop | Sí | Sí | Sí | Gratis | Media |
| Aptakube | Desktop (Electron) | No | Sí | No | USD 8/mes | Baja |
| Kubernetes Dashboard | Web | No (en-cluster) | No | Sí | Gratis | Media |
k9s sigue siendo la referencia para quienes viven en la terminal. Si tu flujo es SSH + tmux, k9s es difícil de superar: es rápido, liviano, y tiene atajos para todo. Radar no lo reemplaza para ese perfil.
Headlamp es el competidor más directo. También tiene binario standalone, también corre en-cluster, también es open source. La diferencia principal es que Radar apuesta más fuerte por la visualización de topología y tráfico de red, mientras que Headlamp es más genérico en features pero tiene un ecosistema de plugins más maduro.
Aptakube tiene la mejor experiencia multi-cluster en un solo panel (podés ver pods de 5 clusters en la misma vista), pero cuesta plata y no tiene modo en-cluster. Para equipos pequeños con un solo cluster, no cierra el precio.
Casos de uso reales: de desarrollo local a equipos de DevOps
Tres escenarios concretos donde Radar tiene sentido:
Desarrollador con minikube o kind en su laptop
Tenés un cluster local corriendo y querés ver qué está pasando sin abrir cinco terminales. Radar en modo local es ideal: instalás con brew, ejecutás radar, y tenés la topología de tus servicios en el browser. Cuando terminás, cerrás la terminal. Sin configuración persistente, sin overhead.
Equipo DevOps revisando un deploy en staging
El equipo instala Radar via Helm en el namespace de monitoreo del cluster de staging. Todos acceden a la misma URL interna. Cuando hay un deploy, pueden ver en tiempo real cómo cambia el estado de los pods, revisar el historial de Helm y hacer rollback si algo sale mal, sin necesitar acceso SSH a los nodos. Más contexto en costos de depender de servicios centralizados.
Debugging de conectividad entre microservicios
Tenés un servicio A que no llega al servicio B y no sabés si el problema es el Service, el NetworkPolicy, o el Ingress. La vista de tráfico de Radar te muestra el flujo real de conexiones. En la práctica, esto reduce el tiempo de diagnóstico considerablemente comparado con ir a kubectl describe service + kubectl get networkpolicy + revisar logs uno por uno.
Lo que Radar no hace (y por qué importa)
Honestidad básica: Radar no es un reemplazo de Prometheus + Grafana. No persiste métricas históricas. Si necesitás ver cómo evolucionó el CPU de un pod en las últimas dos semanas, necesitás otra herramienta.
Tampoco tiene SSO ni control de acceso granular en la versión open source. En un entorno empresarial donde querés que distintos equipos vean solo sus namespaces, eso es una limitación real. Según el sitio de Skyhook, estas features vienen con Radar Cloud, pero los precios y el alcance exacto no están publicados todavía. ¿Alguien verificó fechas de lanzamiento del tier Cloud? Todavía no hay confirmación oficial.
Para multi-cluster real, la versión gratuita no alcanza. Podés cambiar de context en kubectl y usar Radar con cada uno por separado, pero no tenés una vista unificada de todos tus clusters al mismo tiempo. Para eso, o pagás Radar Cloud (precio a confirmar) o mirás Aptakube o Headlamp con sus plugins multi-cluster.
Dicho esto, para el 80% de los casos de uso de un equipo pequeño-mediano con uno o dos clusters, la versión open source cubre todo.
Errores comunes al usar dashboards de Kubernetes
Exponer el dashboard en la red sin autenticación
Kubernetes Dashboard tiene un historial largo de instalaciones con acceso anónimo habilitado por default o con un token de admin pegado en la URL. Con Radar en modo local no tenés ese problema porque solo corre en localhost. Pero si lo instalás via Helm y configurás un Ingress sin autenticación, el problema es el mismo: cualquiera con acceso a esa URL puede ver y modificar tu cluster. Siempre poné autenticación delante del Ingress, ya sea OAuth2 Proxy, un header de autenticación básica, o acceso via VPN.
Usar el dashboard como reemplazo de kubectl para cambios en producción
Un dashboard es una herramienta de observabilidad, no de gestión de configuración. Si estás editando deployments en producción desde una UI web, perdés el historial de git, los hooks de CI/CD y cualquier revisión de pares. Usá el dashboard para observar, usá GitOps (ArgoCD, Flux) para cambiar. Radar lo entiende así: sus integraciones con ArgoCD y Flux son de solo lectura por diseño. Lo explicamos a fondo en containerización de aplicaciones con Docker.
Asumir que la topología visual es siempre precisa
Cualquiera que haya usado herramientas de visualización de red sabe que la vista de tráfico es tan buena como la instrumentación que tiene debajo. Si tu cluster no tiene un service mesh o métricas de red configuradas, la vista de tráfico de Radar va a mostrar relaciones estáticas inferidas de la configuración, no tráfico real en tiempo real. Tomalo con pinzas cuando hagas debugging de conectividad en clusters sin Istio o Cilium.
Preguntas Frecuentes
¿Qué es una interfaz Kubernetes local-first?
Una interfaz Kubernetes local-first corre en tu propia máquina y se conecta al cluster directamente usando tu kubeconfig, sin intermediarios en la nube. Radar es un ejemplo: descargás un binario, lo ejecutás, y tenés un dashboard web en localhost. Ningún dato del cluster sale a servidores externos en el modo local.
¿Cómo instalar un dashboard Kubernetes sin dependencias externas?
Radar es hoy la opción más directa: brew install skyhook-io/tap/radar en macOS, o curl -fsSL https://get.radarhq.io | sh en Linux. El binario pesa ~30 MB, no requiere Docker, no requiere instalar nada en el cluster para el modo local. El único requisito es tener un kubeconfig válido apuntando a tu cluster.
¿Cuál es la mejor alternativa a Kubernetes Dashboard en 2026?
Depende del caso de uso. Para uso en terminal, k9s sigue siendo la referencia. Para visualización web con binario local sin configuración, Radar y Headlamp son las mejores opciones open source. Radar tiene mejor visualización de topología y tráfico; Headlamp tiene un ecosistema de plugins más maduro. Para multi-cluster con interfaz de escritorio, Aptakube (USD 8/mes) es la opción más pulida aunque no es gratuita.
¿Se puede ver la topología de un cluster Kubernetes sin instalar agentes?
Sí. Radar en modo local construye la vista de topología leyendo los recursos del cluster via la API de Kubernetes a través de tu kubeconfig, sin necesidad de instalar ningún agente o componente adicional en el cluster. Para la vista de tráfico de red en tiempo real, sí necesitás un service mesh como Istio o Cilium configurado en el cluster.
¿Radar es gratuito o de pago?
El core de Radar es open source y gratuito, disponible en GitHub. Radar Cloud es un tier pago que agrega multi-cluster, features de equipo y posiblemente SSO, pero los precios no están publicados aún. Para un equipo con uno o dos clusters, la versión gratuita cubre todos los casos de uso principales.
Conclusión
Radar resuelve algo concreto: la brecha entre la complejidad real de operar Kubernetes y la pobreza de las herramientas visuales disponibles hasta ahora. Un binario único, sin cuenta, sin agentes, con visualización de topología y tráfico, integraciones con el ecosistema CNCF y gestión de Helm en la misma interfaz. Para equipos pequeños y desarrolladores que trabajan con clusters locales o de staging, es difícil justificar no probarlo. El costo de instalarlo son 15 segundos.
Lo que Skyhook apuesta acá es que la monetización viene del tier Cloud (multi-cluster, features empresariales), y el open source es el vector de adopción. Es una estrategia que vimos funcionar con otras herramientas del ecosistema cloud native. Si el proyecto mantiene el ritmo de desarrollo y las integraciones siguen creciendo, puede ser el dashboard de referencia para clusters únicos en 2026.
Si manejás infraestructura en un VPS o en la nube y necesitás un cluster Kubernetes, donweb.com ofrece servidores donde montar todo el stack sin complicaciones.
