Radar

Radar

La interfaz de Kubernetes de código abierto que faltaba.
Un solo binario. Sin cuenta requerida. Gratis para siempre.

🌐 radarhq.io · Documentación · Lanzamientos

Topología, recursos, Helm, GitOps, tráfico, auditoría, impacto de actualizaciones y contexto MCP para agentes de IA — desde tu laptop o dentro del clúster.

Instala y ejecuta en 30 segundos:

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

Más opciones de instalación ↓

¿Por qué Radar?

• Cero instalación en tu clúster — se ejecuta en tu laptop, se comunica directamente con la API de K8s
• Un solo binario — sin dependencias, sin agentes, sin CRDs
• Rápido en clústeres grandes — probado con decenas de miles de pods, con vistas responsivas y actualizaciones en vivo bajo cambios reales del clúster
• Privado por diseño — los datos de tu clúster permanecen en tu máquina. Sin cuenta, sin agentes, sin sincronización en la nube. El informe de uso está desactivado a menos que optes por activarlo, y entonces envía solo conteos de uso anónimos y datos generales del clúster: versión de Kubernetes, plataforma, rango de número de nodos, integraciones conocidas (lo que Radar envía)
• Compatible con entornos aislados — se ejecuta como un solo binario contra la API de Kubernetes y funciona en entornos restringidos con salida de red bloqueada
• En tiempo real — observa tu clúster mediante informers, envía actualizaciones al navegador vía SSE
• Funciona en todas partes — GKE, EKS, AKS, minikube, kind, k3s, o cualquier clúster conforme
• Listo para IA — el servidor MCP integrado permite que los agentes de IA inspeccionen, investiguen y operen tu clúster a través de Radar
• Opción dentro del clúster — despliega con Helm para acceso compartido del equipo con permisos limitados por RBAC

"Tengo Radar desplegado en el trabajo. En cuanto a paneles de Kubernetes, este es uno de los mejores." — u/TheRealNetroxen

Instalación

Instalación rápida:

curl -fsSL https://get.radarhq.io | sh

Homebrew:

brew install skyhook-io/tap/radar

Luego ejecuta: kubectl radar. La instalación rápida, PowerShell, Homebrew y Scoop también configuran el atajo radar. Krew y las descargas directas usan kubectl radar a menos que agregues tu propio enlace simbólico radar.

kubectl krew install radar

scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar

irm https://get.radarhq.io/install.ps1 | iex

curl -fsSL https://get.radarhq.io | INSTALL_DIR="$HOME/.local/bin" sh

brew install --cask skyhook-io/tap/radar-desktop

sudo apt install ./radar-desktop_*.deb

sudo rpm -i radar-desktop_*.rpm

scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket
scoop install radar-desktop

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm install radar skyhook/radar -n radar --create-namespace

Uso

# Opens browser automatically
kubectl radar

# Quick install, PowerShell, Homebrew, and Scoop also set up the bare command
radar

Para inspeccionar una instalación de Radar Cloud dentro del clúster sin modificarla:

radar cloud status
radar cloud status --context my-cluster
radar cloud status --context my-cluster --namespace radar --release radar

El comando informa la propiedad de la instalación, el chart y la imagen, la preparación del agente y la configuración de Cloud sin imprimir el token de conexión. Pasar tanto --namespace como --release selecciona una instalación exacta. El estado del túnel en vivo lo informa Radar Cloud usando el token en el Secret de Kubernetes referenciado. Si el Secret o el Hub no están disponibles, los diagnósticos locales de instalación aún se ejecutan. Las terminales interactivas usan colores de estado moderados; establece NO_COLOR (o canaliza la salida) para texto plano. Las URLs, tokens y comandos sugeridos permanecen sin estilo.

Banderas de CLI

La tabla siguiente cubre las banderas de inicio comunes. Consulta la referencia completa de CLI; radar --help es la autoridad para la versión instalada.

Consulta la Guía de configuración para detalles sobre la precedencia de conexión al clúster, múltiples archivos kubeconfig y cambio de contexto.

Ajuste para clústeres lentos o de alta latencia

Los plazos predeterminados (30 s para cambio de contexto, 5 m de respaldo para el primer renderizado, 5 s para LIST de namespaces, 20 candidatos de ámbito) están ajustados para clústeres saludables alcanzados por conexiones rápidas y de baja latencia. Son demasiado estrictos para clústeres alcanzados a través de túneles SSH, planos de control geográficamente distantes, o cuentas sujetas a limitación del servidor de API, donde se manifiestan como uno de tres síntomas:

• Notificaciones "Context switch timed out" cuando la caché finalmente se sincroniza
• "Limited list — RBAC doesn't allow listing all namespaces" aunque la cuenta tenga permiso de listado a nivel de clúster (el LISTADO expiró, no RBAC)
• Tipos marcados silenciosamente como denegados porque el namespace donde residen superó el límite de 20 entradas candidatas

Amplíe las cuatro banderas mediante CLI o mediante las variables de entorno correspondientes (RADAR_CONTEXT_SWITCH_TIMEOUT, RADAR_FIRST_PAINT_BACKSTOP, RADAR_NAMESPACE_LIST_TIMEOUT, RADAR_MAX_SCOPE_CANDIDATES) — las variables de entorno mantienen los secretos fuera de ps y permiten que los despliegues dentro del clúster obtengan los valores de un ConfigMap:

# CLI
kubectl radar \
  --context-switch-timeout=120s \
  --first-paint-backstop=10m \
  --namespace-list-timeout=30s \
  --max-scope-candidates=200

# Environment (e.g. in a Deployment manifest)
RADAR_CONTEXT_SWITCH_TIMEOUT=120s \
RADAR_FIRST_PAINT_BACKSTOP=10m \
RADAR_NAMESPACE_LIST_TIMEOUT=30s \
RADAR_MAX_SCOPE_CANDIDATES=200 \
  kubectl radar

Los valores predeterminados se conservan cuando ni la bandera ni la variable de entorno están configuradas, por lo que los despliegues existentes no se ven afectados.

Vistas

Topología

Gráfico interactivo que muestra cómo están conectados sus recursos de Kubernetes en tiempo real.

Vista de Topología — Visualice las relaciones entre recursos

• Dos modos: Recursos (jerarquía completa) y Tráfico (ruta de flujo de red)
• Agrupar por namespace, etiqueta de aplicación, o ver sin agrupar
• Filtrar por tipo de recurso — haga clic en cualquier nodo para ver detalles completos
• Diseño automático impulsado por ELK.js, actualizaciones en vivo vía SSE

Recursos

Explorador de recursos basado en tablas con columnas inteligentes por tipo de recurso.

Vista de Recursos — Explore y filtre todos los recursos del clúster

• Explore todos los tipos de recursos, incluidos los CRD
• Busque por nombre, filtre por estado o problemas (CrashLoopBackOff, ImagePullBackOff, etc.)
• Agregue columnas personalizadas desde cualquier etiqueta o anotación — ordenables, filtrables y redimensionables
• Haga clic en cualquier recurso para ver el manifiesto YAML, recursos relacionados, registros y eventos
• Establezca imágenes de contenedores regulares o de inicio en Deployments, StatefulSets, DaemonSets y Argo Rollouts, con progreso de despliegue en vivo en tablas, paneles laterales, vistas de cargas de trabajo y Aplicaciones

Visor de Sistemas de Archivos de Imágenes

Inspeccione los sistemas de archivos de imágenes de contenedores directamente desde la vista de Pod — sin necesidad de extraer imágenes localmente o ejecutar comandos dentro de los contenedores.

Visor de Sistemas de Archivos de Imágenes — Explore el contenido de las imágenes de contenedores

• Haga clic en cualquier imagen de contenedor en un Pod para explorar su sistema de archivos completo
• Vista de árbol con tamaños de archivo, permisos y destinos de enlaces simbólicos
• Busque archivos por nombre en toda la imagen
• Descargue archivos individuales para inspección
• Funciona con imágenes públicas (Docker Hub, Quay, GHCR) y registros privados (GCR, ECR, ACR) usando los ImagePullSecrets de su clúster
• Caché de capas basada en disco para acceso rápido repetido

Línea de Tiempo

Línea de tiempo unificada de eventos de Kubernetes y cambios de recursos.

Vista de Línea de Tiempo — Siga la actividad del clúster en tiempo real

• Filtre por tipo de evento (todos o solo advertencias)
• Diffs de cambios de recursos que muestran qué cambió (réplicas, imágenes, etc.)
• Actualizaciones en tiempo real a medida que ocurren nuevos eventos

Helm

Gestione los lanzamientos de Helm desplegados en su clúster — inspeccione valores y manifiestos renderizados, compare revisiones, identifique actualizaciones fallidas y patrones de rollback después de fallos, diagnostique hooks fallidos, actualice, revierta y desinstale. Radar rastrea las actualizaciones de charts disponibles (desde sus repositorios configurados o sus propios registros OCI) y le permite elegir una versión objetivo específica. Consulte Soporte de Helm para el comportamiento detallado y los límites.

Vista de Helm — Gestione sus despliegues de Helm

• Vea todos los lanzamientos en todos los namespaces con estado, versión del chart, versión de la aplicación, salud de recursos, namespace de almacenamiento y propiedad de Flux
• Inspeccione valores, compare revisiones entre valores/manifiestos/notas/recursos y vea el historial de lanzamientos
• Superficie de actualizaciones fallidas, operaciones pendientes atascadas, historial de rollbacks y rollbacks atómicos inferidos
• Correlacione hooks fallidos o en ejecución con evidencia restante de Jobs, Pods, Eventos y registros redactados
• Actualice, revierta o desinstale lanzamientos directamente desde la interfaz

Comparar Recursos

Compare dos recursos de Kubernetes del mismo tipo lado a lado — como comparar un Deployment de staging con su gemelo de producción, o dos pods que deberían ser idénticos pero no lo son.

Vista de Comparación — Diff YAML lado a lado con resaltado a nivel de campo

• Dos puntos de entrada: un botón Compare en el panel de detalles del recurso, o el modo de comparación en la tabla de recursos (alternar, seleccionar dos filas, presionar Comparar)
• Vista lado a lado o unificada, con intercambio de un clic de A ↔ B
• Modo solo-diff colapsa las regiones sin cambios para que solo vea lo que difiere
• Modo solo-spec elimina los campos status para enfocarse en la intención en lugar del estado observado
• El ruido asignado por el servidor (managedFields, resourceVersion, kubectl.kubernetes.io/last-applied-configuration) se elimina automáticamente para que el diff mantenga la señal — active Metadatos crudos si realmente quiere verlo
• Los candidatos del mismo namespace aparecen primero en el selector — generalmente el recurso contra el que quiere comparar
• URLs compartibles: /compare?kind=&apiGroup=&a=ns/name&b=ns/name

Modo de comparación en la tabla de recursos — seleccione dos filas, presione Comparar

Gestión de Certificados TLS

Vea los detalles de certificados TLS y fechas de expiración en todos los namespaces — detecte certificados que expiran antes de que causen interrupciones.

• Analiza secretos TLS para mostrar el sujeto del certificado, el emisor y el período de validez
• Resumen de expiración de certificados a nivel de panel
• Disponible desde la vista de detalle de recursos para cualquier Secret de tipo TLS

GitOps

Monitoree, diagnostique y gestione recursos de FluxCD y ArgoCD desde un espacio de trabajo GitOps dedicado.

Vista de flota GitOps — aplicaciones Argo + Flux lado a lado con estado de sincronización, salud, fuente, destino y ciclo de vida

• Vista de flota + página de detalle por aplicación (pestañas Topología / Cambios / Actividad) para ArgoCD (Application, ApplicationSet, AppProject) y FluxCD (GitRepository, OCIRepository, HelmRepository, Bucket, Kustomization, HelmRelease, Alert)
• Pipeline de diagnóstico — deriva a nivel de campo, eventos recientes por recurso, detección de bucles de deriva atascados, fallos de operación analizados, remediación estructurada de un clic
• Conciencia del ciclo de vida — la etiqueta Terminating reemplaza las insignias obsoletas de Sync/Salud; la severidad aumenta con la edad de eliminación; las operaciones mutantes se niegan en zombies
• Enlazado cruzado desde el resto de Radar — etiqueta Managed by en paneles de recursos, enrutamiento GitOps desde Topología + Línea de Tiempo + vista de Helm, panel Consumed by en CRs de fuente Flux
• Integración MCP — manage_gitops expone sync / suspend / resume / reconcile / rollback con rechazo consciente del ciclo de vida

Consulte la guía de GitOps para la matriz completa de funciones, requisitos de RBAC, clúster de demostración y notas sobre el alcance de un solo clúster.

Tráfico

Visualice el tráfico de red en vivo entre servicios usando Hubble, Caretta, Istio o Beyla.

Vista de Tráfico — Vea cómo se comunican los servicios en tiempo real

• Detecta automáticamente Hubble (Cilium), Istio, Caretta o Grafana Beyla como fuentes de datos de tráfico
• Beyla (independiente o vía Grafana Alloy) proporciona visibilidad eBPF L4 + HTTP sin malla de servicios, leída desde Prometheus
• Beyla necesita su función network habilitada, y los bordes por puerto adicionalmente necesitan dst.port y transport nombrados en attributes.select — ambos están desactivados por defecto, y Radar lo indica en la vista de Tráfico en lugar de mostrar bordes parciales silenciosamente
• Gráfico de flujo animado que muestra solicitudes por segundo entre servicios
• Filtre por namespace, protocolo o código de estado
• Asistente de configuración para instalar una fuente de tráfico si no se detecta ninguna

Métricas de Cargas de Trabajo

Abra la pestaña Métricas de un Deployment, StatefulSet o DaemonSet para investigar la tasa de solicitudes, errores HTTP, latencia, CPU, memoria y throttling. Radar lee un backend compatible con Prometheus existente; los gráficos de recursos no requieren instrumentación HTTP, y los gráficos de solicitudes usan observaciones compatibles de Beyla o Istio.

• El historial de cargas de trabajo incluye réplicas anteriores cuando se conservan métricas y propiedad
• Compare Pods actuales para encontrar valores atípicos de recursos
• Descubrimiento automático y verificaciones de identidad, con datos faltantes o parciales etiquetados explícitamente

Consulte Métricas de cargas de trabajo para capturas de pantalla, requisitos previos, configuraciones compatibles y limitaciones de configuración multi-clúster local.

Capacidad (Karpenter)

Diagnóstico de solo lectura para flotas gestionadas por Karpenter — ¿por qué mi pod está pendiente, qué NodePool podría tomarlo, por qué mis nodos no se unen, qué está haciendo la disrupción a mi flota? Aparece automáticamente cuando se detectan NodePools de Karpenter (restringido por RBAC).

• Resumen — KPIs de flota con detalle del ciclo de vida de reclamos, barra de capacidad de programación del clúster (solicitudes vs asignables, en vuelo más allá del borde, demanda pendiente como conteo honesto no a escala), señales operativas priorizadas e inventario de NodePools
• Detalle de NodePool — libro mayor de capacidad (límite configurado, aprovisionado, espacio libre, asignable, solicitudes programadas, no asignado, uso real), ciclo de vida de reclamos, composición de flota y atribución de cargas de trabajo
• Demanda — pods pendientes agrupados por firma de programación, cada grupo evaluado contra las restricciones declaradas de cada NodePool con evidencia por predicado; filtrable por estado, pool y carga de trabajo
• Actividad — episodios de aprovisionamiento / disrupción / interrupción clasificados desde el vocabulario exacto de eventos de Karpenter, con confianza por evidencia
• Cada cantidad lleva certeza por valor (= ≥ ≤ ?) — lo no disponible nunca se renderiza como cero, lo parcial nunca se renderiza como exacto
• Problemas, paneles de Pods pendientes y la tarjeta de postura de Inicio enlazan profundamente al diagnóstico correcto

Consulte docs/capacity.md para la referencia completa.

Información de Costos

Siga el gasto de Kubernetes desde métricas de OpenCost en un backend compatible con PromQL o un Kubecost 3 Aggregator. El modo automático mantiene las métricas de costos de Prometheus que funcionan y luego descubre un Kubecost Aggregator local; un clúster federado solo de agentes puede usar la URL de su Aggregator central en Configuración, configuración o Helm. Radar lee la moneda configurada de una carga de trabajo OpenCost o Kubecost en ejecución cuando está disponible y de lo contrario usa USD. Los cambios de fuente se prueban y aplican por separado de la preferencia de moneda de visualización, que se puede guardar incluso cuando una fuente no está disponible. Radar etiqueta los valores pero no los convierte.

• Costo de carga de trabajo asignado con alcance de namespace señalado por separado del costo de capacidad de nodos a nivel de clúster
• Gráficos de tendencia de costos con selector de rango 6h/24h/7d cuando el historial de Prometheus está disponible
• Desgloses de costos a nivel de namespace y carga de trabajo con puntuación de eficiencia
• Costos de nodos con tipo de instancia y precios por región
• Aparece automáticamente cuando se detectan métricas de Prometheus compatibles o datos de asignación actual de Kubecost

Auditoría de Clúster

Escáner proactivo de mejores prácticas con 31 verificaciones en seguridad, confiabilidad y eficiencia — inspirado en Polaris, Kubescape, Trivy y las pautas de NSA/CISA. Se ejecuta instantáneamente contra datos en caché con cero instalación en el lado del clúster.

• Seguridad: contenedores privilegiados, escalada de privilegios, capacidades peligrosas/inseguras, namespaces de host, montajes de sockets del runtime de contenedores, rutas de host sensibles, secretos en ConfigMaps, tokens de cuenta de servicio montados automáticamente
• Fiabilidad: probes faltantes, etiqueta de imagen latest, despliegues de réplica única, PDB/difusión de topología faltantes, riesgo de HA de pods (todas las réplicas en el mismo nodo), servicios/ingresses huérfanos, versiones de API obsoletas
• Eficiencia: solicitudes y límites de CPU/memoria faltantes, ConfigMaps/Secretos huérfanos
• Cola de remediación agrupada por checks con búsqueda y filtros por categoría, severidad y framework; expande un check para ver los recursos afectados
• Cada hallazgo incluye descripción y guía de remediación, con acciones de ocultamiento en línea para un check o categoría
• Configurable: namespaces ignorados (con patrones comodín), checks deshabilitados, persistente entre sesiones
• Etiquetas de framework: NSA/CISA, benchmarks CIS
• Herramienta MCP (get_cluster_audit) para análisis de clúster asistido por IA

Diagnóstico de Ruta de Red

Diagnóstico ordenado por saltos para Service, Ingress, HTTPRoute, GRPCRoute y Gateway, respondiendo: "si el tráfico se envía hacia este recurso, ¿llega a un proceso saludable y, si no, qué salto se rompe primero?"

• Compone las detecciones que Radar ya ejecuta (Service backend faltante, desajustes de puerto, endpoints sin listos, ruta no Aceptada por el Gateway padre, probe de readiness apuntando al puerto incorrecto) en una forma de ruta ordenada a lo largo del flujo de tráfico
• Los upstreams (Ingresses / Rutas que apuntan a un Service) se evalúan de forma independiente: un Ingress roto no condena las otras rutas de entrega
• El primer salto crítico se nombra explícitamente para que el operador localice la ruptura sin leer toda la lista; cada hallazgo incluye un reproductor de kubectl
• Prueba de alcanzabilidad opcional de un solo disparo ejecuta probes DNS / TCP / TLS / HTTP contra la ruta declarada: TCP directo cuando Radar está en el clúster, proxy del servidor de API de K8s cuando se ejecuta desde una laptop, para que el mismo botón funcione sin importar dónde se ejecute Radar. Las probes nunca anulan el veredicto estático; añaden evidencia.
• Las NetworkPolicies que seleccionan los pods del sujeto se evalúan estáticamente para sus reglas de ingreso independientes del llamador: una predicción WARNING de "bloquearía" cuando ninguna regla admite el puerto de la ruta, un aviso restringido por fuente o una nota de egress saliente. Es una predicción, nunca un veredicto: el CNI es la única autoridad de aplicación, por lo que la probe en vivo en el clúster lo confirma o lo degrada
• El rastreo estático son funciones puras sobre la caché de informador en memoria. La prueba activa desde una laptop usa el RBAC normal del clúster (get services/proxy, get pods/proxy); el modo en clúster va directamente a la ruta de datos.
• Expuesto a través de la pestaña Reachability en la vista de detalle del recurso (y a través de la rama de red de la herramienta MCP diagnose para consumidores de IA): consulta docs/reachability.md

Impacto de Actualización de Kubernetes

Abre Checks → Upgrade impact antes de actualizar el plano de control. Radar compara el clúster actual con un minor de Kubernetes objetivo y ordena los checks de compatibilidad, salud, admisión, drenaje, runtime y configuración con evidencia por acción requerida. Los checks específicos de una versión solo aparecen cuando su minor de Kubernetes está en la ruta de actualización seleccionada; el catálogo actual se revisa hasta Kubernetes 1.37.

• Encuentra bloqueadores como versiones minor omitidas, APIs eliminadas en la versión objetivo, desviación no compatible de kubelet o kube-proxy, PodDisruptionBudgets superpuestos, el driver de volumen gitRepo deshabilitado en Kubernetes 1.36 y feature gates u objetos scheduling.k8s.io/v1alpha2 eliminados o bloqueados de Kubernetes 1.37
• Señala impacto operativo probable como exposición de FlexVolume y métricas renombradas del plano de control como advertencias, mientras que la configuración dependiente de intención como el Service externalIPs obsoleto permanece en revisión
• Inspecciona recursos en vivo, disponibilidad de API agregadas, manifiestos de releases de Helm, configuración last-applied de kubectl, métricas de uso del servidor de API y expresiones de PrometheusRule
• Distingue Passed, Review, Warning, Blocked, Incomplete y Not applicable en lugar de aplanar hallazgos de asesoría, impacto probable y evidencia faltante en un solo estado
• Escanea cada namespace que la identidad actual puede leer; el selector de namespace del encabezado sigue siendo un filtro de navegación y no reduce el análisis de actualización
• Muestra el límite del catálogo incluido y el alcance de la evidencia para datos muestreados o no disponibles

Consulta la guía de impacto de actualización de Kubernetes para el catálogo de checks, semántica de cobertura y notas de RBAC.

Control de Acceso (visibilidad RBAC)

Inspecciona lo que cualquier ServiceAccount puede hacer realmente, sin tres llamadas kubectl describe.

• Detalle de ServiceAccount: bindings directos, permisos efectivos (vista plana por binding y deduplicada), concesiones heredadas a través de grupos implícitos (system:authenticated, system:serviceaccounts) y "Usado por Pods" que cierra el ciclo
• Detalle de Pod: sección "Permissions" que muestra las reglas más permisivas que otorga el SA del Pod, más una alerta de radio de explosión cuando el SA tiene comodines, cluster-admin, verbos de escalada o create pods a nivel de clúster
• Detalle de Workload (Deployment / StatefulSet / DaemonSet): misma sección de Permissions enmarcada a nivel de workload: cada Pod que el workload genera hereda estas concesiones
• Detalle de Namespace: resumen de RBAC con RoleBindings configurados aquí + ClusterRoleBindings cuyos sujetos referencian este namespace
• Detalle de Role / ClusterRole: quién está vinculado a este rol, con resúmenes de sujetos en línea
• Detalle de RoleBinding: vista previa en línea de las reglas que otorga el binding + advertencias cuando los sujetos incluyen grupos amplios (system:authenticated, system:unauthenticated, system:masters)
• Panel "My Permissions": SelfSubjectRulesReview en vivo con ámbito de namespace para el usuario actual, para depuración rápida de "por qué no puedo hacer X"
• MCP: la herramienta get_subject_permissions expone los mismos datos a agentes de IA para consultas como "¿está este SA sobre-privilegiado?" / "¿radio de explosión si se ve comprometido?"

La visibilidad de solo lectura se entrega primero; los seguimientos considerados (checks de auditoría RBAC, matriz de verbo × recurso, explorador de sujetos, vista de grafo, ediciones en la UI, consultas "can-i") se rastrean en #1090.

Integración de IA (MCP)

Radar incluye un servidor Model Context Protocol (MCP) integrado que permite a agentes de IA (Claude Code, Codex, Cursor, GitHub Copilot (VS Code y CLI), OpenCode, Google Antigravity y cualquier otro cliente MCP) inspeccionar, investigar y operar tu clúster a través de Radar.

En lugar de salida cruda de kubectl (YAML verboso que consume las ventanas de contexto de LLM), tu IA obtiene datos preprocesados y optimizados en tokens: grafos de topología, evaluaciones de salud, eventos deduplicados y logs filtrados. El diagnóstico es de solo lectura por defecto; el sondeo de rutas opcional en el clúster usa pods de sondeo de corta duración y autodestrucción. Operaciones de escritura como reinicio, escala, apply y rollback se identifican para confirmación del cliente y se aplican a través del RBAC de Kubernetes.

Habilitado por defecto. Deshabilítalo con --no-mcp. Consulta la Guía MCP para instrucciones de configuración.

Autenticación

Para despliegues compartidos en el clúster, Radar admite autenticación de usuario opcional con RBAC de Kubernetes por usuario.

• Modo proxy: funciona con oauth2-proxy, Pomerium, Cloudflare Access o cualquier proxy de autenticación que establezca encabezados reenviados
• Modo OIDC: inicio de sesión integrado a través de Google, Okta, Dex, Keycloak o cualquier proveedor OIDC
• Alcance de namespace por usuario y autorización de escritura mediante impersonación de K8s
• La UI se adapta automáticamente: los botones solo aparecen si el usuario tiene permiso RBAC

Sin autenticación por defecto (uso local). Consulta la Guía de Autenticación para configuración.

Recursos Soportados

Radar auto-descubre cualquier CRD en tu clúster. Las herramientas populares obtienen integraciones dedicadas con bordes de topología, vistas de detalle y resúmenes de IA.

El RBAC del chart por defecto cubre los tipos de Kubernetes integrados que se enumeran a continuación: Workloads, Networking (incluyendo NetworkPolicies y PodDisruptionBudgets), Configuration, Storage (PersistentVolumes, PersistentVolumeClaims, StorageClasses), HorizontalPodAutoscalers, ServiceAccounts, LimitRanges, ResourceQuotas, Nodes, Namespaces y Events. En Kubernetes 1.37, Radar también muestra las APIs Workload, PodGroup, CompositePodGroup, PodCertificateRequest y ClusterTrustBundle cuando el servidor de API las anuncia; las APIs de programación están detrás de feature gates, mientras que las APIs de certificados son estables y están habilitadas por defecto. Estas usan el navegador de recursos genérico en lugar de renderizadores dedicados. Los objetos RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) son opcionales mediante rbac.viewRBAC=true. Las integraciones basadas en CRD (Gateway API, VerticalPodAutoscaler, Calico, ArgoCD, FluxCD, cert-manager, etc.) necesitan tanto el CRD instalado en tu clúster como acceso de lectura otorgado: la mayoría de los grupos están activados por defecto bajo rbac.crdGroups.<name> (por ejemplo, gatewayApi, verticalPodAutoscaler, calico); consulta values.yaml o agrega reglas personalizadas mediante rbac.additionalRules.

El impacto de actualización también obtiene acceso de solo listado a CSIStorageCapacities, FlowSchemas, PriorityLevelConfigurations y PodSecurityPolicies en clústeres donde esos tipos se sirven. Estas lecturas inspeccionan evidencia de manifiestos fuente y no agregan los tipos al navegador de recursos de Radar.

Atajos de teclado

Topología: Desplazar (arrastrar), Zoom (rueda), Seleccionar (clic), Selección múltiple (Shift+clic)

Seguridad

Radar lee tu clúster a través de tus propias credenciales y mantiene los datos del clúster de forma local. No sube manifiestos, registros, eventos, métricas ni datos de recursos a Skyhook, y no requiere cuenta, agente ni backend en la nube. ¿Encontraste una vulnerabilidad? Por favor, repórtala de forma privada a security@skyhook.io — consulta SECURITY.md para conocer el proceso y los plazos de respuesta.

Desarrollo

Consulta la Guía de desarrollo para compilar desde el código fuente y contribuir. Para automatización e integraciones, consulta la referencia de la API HTTP.

Inicio rápido:

git clone https://github.com/skyhook-io/radar.git
cd radar
make deps

# Terminal 1: Frontend with hot reload (port 9273)
make watch-frontend

# Terminal 2: Backend with hot reload (port 9280)
make watch-backend

Contribuciones

¡Las contribuciones son bienvenidas! Lee nuestra Guía de contribución para conocer los detalles del flujo de trabajo de desarrollo, el proceso de pull requests y los estándares de codificación.

¿Preguntas o ideas? GitHub Discussions es el lugar — o saluda en radarhq.io/community.

Acerca de

Radar es creado y mantenido por Skyhook (YC W23) y es de código abierto bajo Apache-2.0. La versión OSS tiene todas las funciones y es la forma recomendada de ejecutar Radar.

Para equipos que quieren Radar multi-clúster alojado con SSO y paneles compartidos, también ofrecemos Radar Cloud.

Licencia

Apache 2.0 — consulta LICENSE

Código abierto. Gratis para siempre.
_{Creado por Skyhook}