Clientes de escritorio para Kubernetes en 2026: la nueva ola más allá de Lens (probados en un clúster real)

Durante años, la respuesta a «¿qué GUI de Kubernetes instalo?» era algún miembro de la familia Lens. Luego Lens se volvió comercial, OpenLens se estancó, y FreeLens recogió el fork de la comunidad. He cubierto esa saga en detalle en FreeLens vs OpenLens vs Lens, y las opciones web en Kubernetes Dashboard Alternatives y Headlamp vs FreeLens vs Lens.

Sin embargo, en los últimos seis meses ha pasado algo más. Ha aparecido una nueva hornada de clientes de escritorio, y la mayoría comparten tres rasgos: no son Electron, incluyen integración con IA o MCP como funcionalidad de primera clase, y están construidos por equipos muy pequeños que se mueven muy rápido. Varios de ellos contactaron conmigo directamente: a través de comentarios en mis artículos de Medium, por email o en LinkedIn.

En lugar de repetir las listas de características de los fabricantes, los instalé todos en la misma máquina, los apunté al mismo clúster con las mismas credenciales de solo lectura, y medí qué hacen realmente y cuánta memoria consumen. Este artículo es el resultado.

TL;DR

• Radar sigue siendo la opción open source más completa y ahora incluye una app de escritorio y un servidor MCP local. También es la más pesada de la nueva hornada en mi prueba.
• PodSteer es la recién llegada más interesante: Apache 2.0, Go + Wails, una evaluación de clúster genuinamente útil, y un servidor MCP de solo lectura. Tiene tres meses de vida.
• Aptakube es el cliente no-Electron más maduro y pulido, pero es propietario y solo es gratuito hasta 5 nodos.
• Spinoza tiene las funciones de seguridad más contundentes (protección de clúster, planes de drain), pero usa la Functional Source License, que no es open source.
• KubeSpade es la única app Electron del grupo. Aporta un cliente para iPad y un modelo «trae tu propio agente de IA». Código cerrado.
• Seabird (GTK4, GNOME) parece abandonado: sin releases en 14 meses.
• «No ser Electron» no implica automáticamente «ser más ligero». La diferencia entre los nuevos clientes fue menor de lo que sugiere el marketing.

Cómo lo probé

Todos los clientes se probaron contra el mismo clúster: mi homelab, un clúster de Talos Linux de tres nodos con Kubernetes 1.37 y unos 95 pods repartidos en 20 namespaces (descrito en la migración de MicroK8s a Talos sobre Proxmox).

Para mantener la prueba justa y segura, creé una ServiceAccount dedicada vinculada al ClusterRole integrado view más acceso de lectura a nodos, CRDs y unas pocas APIs de ámbito de clúster. Sin secrets, sin exec, sin port-forward, sin verbos de escritura. Esa restricción resultó ser en sí misma una prueba útil: se aprende mucho de un cliente por cómo se comporta cuando no es cluster-admin.

Cada app se ejecutó en un directorio home aislado sobre Debian 12 (x86_64), una a la vez, bajo una pantalla X virtual. La memoria es el PSS (proportional set size) de todo el árbol de procesos, medido aproximadamente un minuto después de conectar con el clúster. El PSS contabiliza las librerías compartidas de forma justa, así que es una comparación mejor que sumar el RSS de todos los procesos auxiliares.

Dos matizaciones antes de los números. Primero, esto es Linux con renderizado por software, así que los valores absolutos serán distintos en macOS. Segundo, esto es un clúster. Un lector de mi artículo sobre Radar me comentó que Lens «tranquilamente llegaba a 2 GB» con varios clústeres abiertos, y lo creo: la memoria crece con el número de clústeres y de recursos que cachea cada cliente.

La comparativa de un vistazo

Como referencia, FreeLens 1.10.3 (Electron) usaba ~630 MB conectado al mismo clúster bajo las mismas condiciones.

Radar: sigue siendo el referente

Escribí una review completa de Radar en mayo y la actualicé este mes con capturas de la v1.16, así que aquí me centro en lo que ha cambiado.

Radar ahora incluye una app de escritorio en toda regla (radar-desktop) además del plugin kubectl radar y la instalación in-cluster vía Helm. La pantalla de inicio muestra algo que ninguno de los demás tenía hace unos meses: un servidor MCP local en 127.0.0.1, de modo que un agente de código puede consultar el clúster a través del modelo que Radar tiene de él en vez de tirar de kubectl por línea de comandos.

Lo que me gustó en la prueba con permisos restringidos: Radar me decía exactamente qué no podía ver. El timeline avisaba de que «algunos tipos de recurso no se monitorizan por restricciones de RBAC» y el panel de Helm decía «permisos insuficientes» en lugar de afirmar que no había releases. La nueva vista de Upgrade impact (APIs eliminadas, PDBs que bloquearían un drain, conversion webhooks sin un Service detrás) es también algo que ningún otro cliente de esta comparativa ofrece.

El precio a pagar es el peso. Con ~610 MB fue el más pesado de los clientes nuevos, prácticamente a la par con FreeLens. Radar construye en memoria una topología completa y un timeline de eventos, y eso se paga. El propio Radar es Apache 2.0. Radar Cloud, la versión alojada multi-cluster, arranca en 149 $ por clúster al mes en el plan Team.

Elígelo si quieres el cliente open source más completo, tráfico en vivo desde tu mesh o tu herramienta de eBPF, y la opción de ejecutarlo in-cluster para todo un equipo.

PodSteer: el recién llegado más prometedor

PodSteer es un cliente de escritorio nativo de Cloudresty, escrito en Go sobre Wails, que usa el webview propio del sistema operativo en lugar de empaquetar Chromium. Es Apache 2.0, no necesita cuenta, y el repositorio tiene solo unos meses: la primera release (v0.1.0) es del 31 de agosto de 2026 y la v0.6.0 salió el 3 de octubre.

Lo encontré a través de un comentario que su autor dejó en mi artículo de Headlamp. Esto es una aclaración, no un motivo para restarle valor, porque fue el cliente que más me sorprendió.

La primera pantalla tras conectar no es una lista de pods sino una evaluación: mi clúster aparecía como Degraded con dos hallazgos de advertencia, seguido de un panel de capacidad que divide CPU y memoria en solicitado, usado, planificable («schedulable») y «eficiencia». La cifra de 154% de eficiencia de memoria (más memoria usada que solicitada) es exactamente el tipo de señal difícil de ver en otras GUI.

También es cuidadoso con los datos que no tiene. Un banner indicaba que la evaluación se había ejecutado «sin los filesystems de los nodos — esas cifras faltan en vez de aparecer a cero». Después de la prueba con permisos de solo lectura, ese tipo de honestidad es lo que más valoro en una herramienta para clústeres.

La vista de Applications agrupa los recursos por la label app.kubernetes.io/instance y muestra quién gestiona cada uno (Helm, un operator) y su versión. Incluso te dice cuántos objetos se quedan fuera por no tener las labels recomendadas.

El resto de la lista de funciones es ambicioso para un proyecto de tres meses: topología con tráfico observado desde Istio, Linkerd, Hubble, Caretta o Beyla; vistas de Argo CD, Flux y Helm; inspección de RBAC; operaciones de día 2 como scale, restart, rollback y drain; y un servidor MCP de solo lectura para agentes de código.

Memoria: ~330 MB. La vista de topología es el único área que necesita trabajo en un namespace con mucha carga: con el zoom por defecto, 81 objetos se renderizaban como cajitas minúsculas. Cuenta con alguna aspereza. El repositorio tenía 7 estrellas cuando lo comprobé, así que eres un early adopter.

Elígelo si quieres un cliente open source, sin Electron, que te diga qué falla en un clúster, no solo qué hay en él.

Aptakube: maduro, pulido, no open source

Aptakube es el veterano de este grupo. Existe desde 2022, está escrito en Rust con Tauri, y su repositorio en GitHub (875 estrellas) se usa para releases e issues, no para el código fuente. La versión 1.22.0 salió el 27 de octubre de 2026. Rob Kooper lo recomendó en los comentarios de mi artículo de Radar, y le prometí que estaría en la siguiente comparativa. Aquí está.

Es el cliente más acabado de esta comparativa. Al abrir un clúster vas directo a un resumen limpio de las workloads, y la lista de pods es densa pero de la buena manera: CPU y memoria con barras de uso frente a los límites, contadores de restarts, hora y motivo del último restart, y nodo.

Las funciones que lo diferencian tienen que ver con trabajar con varios clústeres a la vez: vistas multi-cluster en una sola ventana, diff de recursos entre clústeres, etiquetas de contexto con «protección de cambios» para producción, además de vistas de Argo CD, Flux, Gateway API y Karpenter. No necesita instalar nada en el clúster.

Con ~300 MB fue el cliente más ligero de mi prueba.

El inconveniente es la licencia. Aptakube es propietario. Es gratuito con todas las funciones en clústeres de hasta 5 nodos. Por encima de eso tienes una prueba de 15 días, y después el plan Personal cuesta 7 €/mes o 79 €/año y el plan Team 5 €/puesto/mes o 59 €/puesto/año, con gestión de licencias basada en SSO en el plan Team. Para un homelab o clústeres pequeños es prácticamente gratis. Para una empresa con clústeres reales es una partida de gasto pequeña pero real.

Elígelo si gestionas muchos clústeres, valoras el acabado por encima de la apertura del código, y no te importa pagar una pequeña suscripción.

Spinoza: seguridad con criterio propio, source-available

Spinoza, de Sophotech, me contactó por LinkedIn en agosto. Es un único binario de Go con un front end en React que funciona tanto en una pestaña del navegador como en una ventana de escritorio. Cuando lo miré por primera vez iba por la v1.13 con un mes de historial. Ahora está en la v2.2.5 (19 de octubre de 2026), así que avanza rápido.

Su personalidad gira en torno a las barreras de seguridad. La primera vez que me conecté, me ofreció proteger el clúster: una vez que un clúster está protegido, borrar, hacer drain, escalar a cero o desinstalar requiere escribir el nombre del objeto. Los drains muestran el plan de evicción antes de ejecutarlo. De todos los clientes que probé, Spinoza es el que más piensa en el clic destructivo.

La vista que usaría a diario es Reserved against used: por namespace (o por workload), CPU y memoria solicitadas frente a las realmente usadas, con la capacidad sobrante resaltada. Es la forma más rápida que he visto de detectar namespaces sobredimensionados.

Spinoza también destaca en GitOps (Flux y Argo CD uno junto al otro, con un grafo de dependencias) y lee los releases de Helm directamente del almacenamiento de Helm sin necesidad del binario helm. En mi prueba de solo lectura eso significó que Helm no mostraba nada. Helm guarda los releases en Secrets, y mi ServiceAccount no podía leerlos. Spinoza lo indicó con claridad («Partial data: secrets could not be listed cluster-wide»), que es el comportamiento correcto.

Memoria: ~350 MB.

En cuanto a la licencia, hay que ser preciso. Spinoza usa FSL-1.1-ALv2, la Functional Source License: puedes leer y usar el código, pero los usos que compitan con el producto están restringidos, y cada versión pasa a Apache 2.0 dos años después de su publicación. Eso es source-available, no open source. Después de la saga de licencias de Lens, esa distinción importa.

Elígelo si quieres un cliente que proteja activamente los clústeres de producción frente a errores y te resulta cómoda una licencia fair-source.

KubeSpade: Electron, iPad y trae tu propio agente de IA

El desarrollador de KubeSpade me escribió un correo tras leer mi comparativa de Headlamp. Funciona en macOS, Windows y Linux, tiene una versión para iPad (listada como «próximamente» en la App Store), guarda las credenciales en el keychain de cada plataforma, y puede conectarse a EKS, GKE y AKS directamente con credenciales cloud, no solo mediante un kubeconfig.

La web lo describe como «un cliente de Kubernetes rápido y nativo». Al descomprimir el build de Linux, resultó ser Electron 43 con un backend en Go 1.25 enlazado estáticamente que habla con la API de Kubernetes. Así que es la única app Electron de esta nueva oleada. El código fuente está en repositorios privados: el repositorio público de GitHub solo alberga los releases. Es gratuito y no requiere cuenta. Ha habido 11 releases desde el 13 de agosto de 2026.

Conectarse es sencillo: detectó mi kubeconfig y me dejó elegir qué contextos importar. La vista general es limpia, con nodos, namespaces, versión de Kubernetes y warnings en la parte superior, seguidos de medidores de CPU, memoria y pods que muestran uso, requests, limits y lo asignable uno junto al otro.

Su función distintiva es la IA. En lugar de incluir su propio modelo, KubeSpade lanza el agente de codificación que ya uses, como Claude Code, Codex, Gemini, Copilot o Cursor, en una terminal integrada. El agente recibe herramientas MCP para los clústeres conectados, y las acciones de escritura necesitan tu aprobación. La shell se arranca deliberadamente sin kubeconfig, de modo que el agente pasa por las herramientas de KubeSpade en lugar de usar kubectl directamente. En el primer uso detectó las dos CLI que tenía instaladas.

Aquí está la sorpresa: con ~335 MB, esta app de Electron usaba más o menos la misma memoria que los clientes Wails y Tauri, y aproximadamente la mitad que FreeLens. Una UI ligera con un backend en Go haciendo el trabajo pesado importa más que la «carcasa» que la envuelve.

Matices: es muy joven (unas 260 descargas en total entre todas las releases cuando lo comprobé) y de código cerrado, así que estás confiando en un proveedor pequeño con las credenciales de tu cluster. Las credenciales se quedan en el dispositivo por diseño, pero no puedes auditarlo.

Elígela si quieres manejar clusters desde un iPad, o te gusta la idea de que tu agente de IA actual trabaje a través de una GUI con puntos de aprobación.

Seabird: un cliente para GNOME que se quedó estancado

Seabird es un IDE de Kubernetes construido para el escritorio GNOME con GTK4 y libadwaita, licenciado bajo MPL-2.0 pero distribuido como «software de pago con prueba gratuita ilimitada». Tiene unas saludables 1,4k estrellas.

Por desgracia, tanto la última release (v0.6.0) como el último push al repositorio son de agosto de 2025. El binario precompilado para Linux no arrancaba en Debian 12 porque necesita una GLib más reciente que la que trae Bookworm; el build de Flathub es la forma práctica de ejecutarlo. Con 14 meses de silencio, hoy no estandarizaría un equipo en torno a él. Lo menciono porque todavía aparece en muchas listas de «GUIs de Kubernetes».

¿»No ser Electron» significa ser más ligero?

Esta era la afirmación que más quería poner a prueba, porque es el argumento estrella de casi todos los clientes nuevos.

El panorama es más matizado que un simple «Electron malo, nativo bueno»:

• Los clientes con webview del sistema son más ligeros que FreeLens, pero por ~2x, no en un orden de magnitud.
• KubeSpade demuestra que Electron no es toda la historia. Un renderer ligero con un backend en Go cae en el mismo rango que Tauri y Wails.
• Lo que un cliente cachea importa más que su shell. Radar es Go más un webview del sistema, igual que Spinoza, y aun así consume casi lo mismo que FreeLens porque mantiene una topología en vivo y un timeline de todo lo que observa.

En macOS, donde WebKit es el motor del sistema, los clientes con webview suelen quedar aún mejor. El beneficio más grande de Wails y Tauri suele estar en el tamaño de descarga (el AppImage de PodSteer pesa 15 MB, frente a los 141 MB de KubeSpade y los 199 MB de FreeLens) y en menos actualizaciones de seguridad de Chromium que perseguir.

¿Cuál deberías elegir?

• Quieres código abierto, sin discusión: Radar o PodSteer. Radar por profundidad y madurez, PodSteer si valoras el enfoque «assessment-first» y una huella más ligera.
• Gestionas muchos clusters y quieres acabado pulido: Aptakube, y reserva unos euros al mes por puesto si tus clusters superan los 5 nodos.
• Te preocupa que alguien vacíe producción por error: la protección de clusters de Spinoza es aquí la mejor barrera de seguridad.
• Quieres que una IA opere el cluster a través de una GUI, con aprobación: el modelo «bring-your-own-agent» de KubeSpade, o los servidores MCP de Radar y PodSteer si prefieres mantener el agente en tu propia terminal.
• Gestionas clusters desde un iPad: KubeSpade es la única opción de esta lista.
• Necesitas extensiones y una gran comunidad hoy mismo: quédate en FreeLens con sus extensiones, o pasa a Headlamp, que cuenta con el respaldo de Kubernetes SIG UI (comparativa aquí).

Mi propia configuración tras esta prueba: Radar se queda como mi cliente principal, y PodSteer pasa a mi lista de seguimiento. Si mantiene este ritmo durante otros seis meses, será un candidato serio.

Transparencia

El desarrollador de KubeSpade me contactó por correo electrónico y el equipo de Spinoza por LinkedIn. El creador de PodSteer lo recomendó en un comentario de uno de mis artículos. Nadie pagó por la cobertura ni vio este artículo antes de su publicación. Todas las pruebas usaron los builds públicos disponibles el 28 de octubre de 2026.

Preguntas frecuentes