Talos Linux dejará de ser exclusivamente un sistema operativo diseñado alrededor de Kubernetes. Sidero Labs ha anunciado Talos Hypervisor, una capa de virtualización basada en KVM e integrada directamente en Talos que permitirá ejecutar máquinas virtuales sin desplegar KubeVirt ni utilizar Kubernetes para gestionarlas. El proyecto también prepara la ejecución directa de contenedores OCI fuera de Kubernetes, especialmente orientada a entornos edge. La primera versión alfa se mostrará en octubre y la disponibilidad general está prevista para diciembre de 2026.
Las claves del nuevo Talos Hypervisor en 20 segundos
- Talos Linux incorporará un hipervisor nativo basado en KVM para ejecutar máquinas virtuales.
- Sidero Labs ha decidido no utilizar KubeVirt ni exigir Kubernetes para gestionar las VM.
- Talos también podrá programar contenedores OCI directamente, una opción pensada especialmente para el edge.
- El hipervisor será código abierto bajo MPL-2.0.
- El anuncio coincide con la adquisición de Sidero Labs por Yardi Systems.
El movimiento resulta llamativo porque cuestiona una de las tendencias que ha ganado terreno en los últimos años: utilizar Kubernetes como plataforma común para administrar tanto contenedores como máquinas virtuales.
Sidero Labs ha elegido otro camino. En lugar de colocar la virtualización dentro de Kubernetes, quiere que sea el propio Talos Linux quien gestione ambos tipos de carga.
La compañía sostiene que desplegar Kubernetes únicamente para ejecutar máquinas virtuales introduce una complejidad innecesaria para determinados operadores. Es una valoración de Sidero Labs, no una limitación inherente a KubeVirt, que continúa siendo una opción válida para organizaciones que precisamente quieren administrar las VM como recursos de Kubernetes.
Talos intenta resolver un problema diferente.
Talos quiere competir también como plataforma de virtualización
Talos Linux nació con una filosofía bastante particular: reducir el sistema operativo que ejecuta Kubernetes a lo estrictamente necesario.
No tiene un entorno tradicional de administración con SSH, shell interactiva o gestor de paquetes. La configuración se realiza mediante una API protegida con TLS mutuo (mTLS), el sistema es inmutable y las actualizaciones se aplican de forma atómica.
Hasta ahora Kubernetes era prácticamente la razón de ser de esa arquitectura.
Talos Hypervisor cambia esa relación.
La virtualización estará integrada directamente en el sistema mediante KVM (Kernel-based Virtual Machine), la tecnología de virtualización incluida en el kernel Linux. Las máquinas virtuales podrán ejecutarse y administrarse sobre Talos sin necesidad de levantar un clúster Kubernetes.
Sidero Labs resume su planteamiento alrededor de una infraestructura común:
| Talos tradicional | Nuevo modelo de Talos |
|---|---|
| Kubernetes como carga principal | Kubernetes, VM y contenedores |
| Contenedores gestionados por Kubernetes | También contenedores sin Kubernetes |
| Talos como Kubernetes OS | Talos también como hipervisor |
| API de Talos para los nodos | Una API para administrar el host |
| Sin SSH ni shell | Mantiene el modelo inmutable |
| Kubernetes necesario para las cargas | Algunas cargas podrán funcionar sin Kubernetes |
Las máquinas virtuales utilizarán formatos estándar sobre KVM, mientras que los contenedores continuarán utilizando imágenes compatibles con Open Container Initiative (OCI). Sidero Labs destaca este punto para defender que la nueva plataforma no introducirá un formato propietario para encapsular las cargas.
Hay además una diferencia importante respecto a la situación actual.
Talos ya puede ejecutarse dentro de una máquina virtual alojada en plataformas como KVM, Proxmox, VMware, Hyper-V o Xen. La documentación del proyecto lleva tiempo incluyendo instrucciones para esos entornos.
Talos Hypervisor invierte la relación: ahora será Talos quien pueda actuar como host de las máquinas virtuales.
La alternativa a KubeVirt busca quitar Kubernetes de donde no sea necesario
KubeVirt permite incorporar máquinas virtuales a Kubernetes y tratarlas mediante recursos y herramientas del propio ecosistema.
Tiene sentido cuando una organización quiere un modelo operativo centrado en Kubernetes y necesita conservar determinadas cargas virtualizadas.
Sidero Labs considera que ese planteamiento no encaja en todos los escenarios.
Si una empresa únicamente necesita ejecutar varias VM, desplegar Kubernetes para conseguirlo supone mantener componentes y conocimientos adicionales que quizá no aporten valor a ese caso concreto.
Talos Hypervisor pretende eliminar esa dependencia.
Una máquina podrá ejecutarse sobre Talos utilizando KVM sin que Kubernetes intervenga en su ciclo de vida. Al mismo tiempo, otro nodo Talos podrá seguir funcionando como parte de un clúster Kubernetes convencional.
Incluso podrían convivir diferentes cargas sobre la misma plataforma.
La propuesta recuerda conceptualmente a la convergencia que buscan otras plataformas de infraestructura, aunque la implementación de Sidero Labs parte de una base distinta: un sistema operativo mínimo, inmutable y administrado exclusivamente mediante API.
La compañía argumenta que esto permite reducir el número de sistemas que hay que parchear, auditar y administrar cuando una organización mantiene simultáneamente Kubernetes y una plataforma de virtualización tradicional.
Es una propuesta que habrá que contrastar cuando exista código suficientemente maduro y despliegues reales. Reducir componentes no garantiza por sí mismo una operación más sencilla: almacenamiento distribuido, redes virtuales, migraciones, alta disponibilidad, copias de seguridad y gestión del ciclo de vida de las VM siguen siendo problemas complejos independientemente del hipervisor utilizado.
Y ahí estará buena parte del examen técnico de Talos Hypervisor.
También habrá contenedores sin Kubernetes
La segunda novedad resulta casi tan interesante como las máquinas virtuales.
Talos permitirá programar contenedores directamente sin Kubernetes.
A primera vista puede resultar extraño en un sistema operativo cuya descripción histórica ha sido precisamente «un sistema operativo moderno para Kubernetes». Pero hay escenarios donde desplegar un clúster completo para ejecutar unos pocos contenedores supone más infraestructura de la necesaria.
El edge computing es uno de ellos.
Una organización puede tener cientos o miles de ubicaciones remotas donde únicamente necesita ejecutar uno o varios servicios. Un nodo industrial, una tienda, una antena de telecomunicaciones o una instalación remota no necesitan necesariamente todo el plano de control de Kubernetes.
Sidero Labs quiere que Talos pueda ejecutar esos contenedores directamente y que Talos Omni gestione la flota.
Omni es el plano de administración de Sidero Labs para gestionar máquinas y clústeres Talos de forma centralizada. La compañía lo ofrece tanto como servicio como en despliegues autogestionados, incluidos entornos aislados.
La idea que empieza a dibujarse es más amplia que añadir un hipervisor.
Talos quiere pasar de ser un sistema operativo especializado en Kubernetes a convertirse en una capa común para Kubernetes, máquinas virtuales y contenedores independientes.
Eso también modifica el mercado con el que compite.
Hasta ahora su comparación natural estaba en las distribuciones y sistemas operativos especializados en Kubernetes. Con un hipervisor integrado empieza a acercarse al terreno ocupado por plataformas de virtualización y nubes privadas.
La compañía tiene previsto mostrar públicamente la versión alfa durante TalosCon, que se celebrará en Ámsterdam los días 15 y 16 de octubre de 2026. La disponibilidad general está anunciada para diciembre.
Hasta entonces conviene tratar muchas de sus ventajas como objetivos de diseño y afirmaciones del fabricante, no como resultados demostrados en producción.
Sidero Labs ha sido adquirida por Yardi
El cambio tecnológico llega acompañado por una noticia empresarial que probablemente será observada con tanta atención como el propio hipervisor.
Yardi Systems ha adquirido Sidero Labs. Ambas compañías anunciaron la operación el 14 de septiembre, aunque no han hecho públicos los términos económicos.
Yardi es una compañía estadounidense de software empresarial especialmente vinculada al sector inmobiliario y cuenta con más de 10.000 empleados, según sus propios datos. No era hasta ahora un nombre especialmente asociado al ecosistema cloud native.
Sidero Labs afirma que continuará funcionando como empresa independiente dentro de Yardi y que la adquisición proporcionará recursos adicionales para desarrollar Talos.
La cuestión especialmente sensible para su comunidad es el futuro del código abierto.
La compañía asegura que Talos Linux seguirá publicado bajo MPL-2.0 y que Talos Hypervisor será igualmente abierto. Su web actual señala además que la edición comunitaria no quedará limitada por la aparición de las nuevas versiones empresariales.
Hay una distinción que merece atención: Talos Linux y el nuevo hipervisor se presentan como código abierto bajo MPL-2.0, mientras que Talos Omni utiliza BSL 1.1, según la información actual de Sidero Labs.
La adquisición no implica por sí misma que vaya a producirse un cambio de licencia o de gobernanza. Tampoco hay actualmente información que permita afirmar que Yardi vaya a cerrar Talos.
Pero resulta razonable que una comunidad de código abierto observe lo que ocurra después de una adquisición.
La garantía realmente comprobable no estará únicamente en los compromisos publicados el día del anuncio, sino en las decisiones posteriores: desarrollo abierto, aceptación de contribuciones, disponibilidad de funcionalidades, licencias y relación entre las ediciones comunitaria y empresarial.
El calendario permitirá comprobarlo relativamente pronto.
Talos Hypervisor llegará primero como alfa en octubre y Sidero Labs espera alcanzar disponibilidad general en diciembre. Si cumple su planteamiento, Talos dejará de responder únicamente a la pregunta de cómo ejecutar Kubernetes sobre un sistema operativo mínimo.
La propuesta será bastante más ambiciosa: utilizar ese mismo sistema para decidir cuándo hace falta Kubernetes y cuándo una máquina virtual o un contenedor pueden ejecutarse perfectamente sin él.
