k3s vs k0s vs Talos Linux: qué Kubernetes ligero elegir

Quieres Kubernetes en casa o en un puñado de servidores, y las tres respuestas que salen siempre son k3s, k0s y Talos Linux. El primer error está en tratarlas como tres versiones de lo mismo. Dos son distribuciones que instalas sobre un Linux que sigues administrando tú; la tercera sustituye ese Linux entero.

Este artículo compara qué trae cada una, cómo se administra, cómo se actualiza y qué máquina pide, y termina con una recomendación por escenario. La instalación se queda fuera a propósito.

Puntos clave

• k3s y k0s se instalan sobre el Debian o el Ubuntu que ya administras. Talos Linux es el sistema operativo, y no admite nada instalado encima.
• No existe la combinación «k3s sobre Talos». Son alternativas excluyentes, y quien te venda lo contrario no ha arrancado ninguna de las dos.
• El README de k3s desmiente el tópico que repiten las comparativas: hoy solo quita dos cosas de Kubernetes, los controladores de almacenamiento y el proveedor de nube integrados en el árbol.
• k0s no incluye controlador de entrada ni balanceador; k3s trae Traefik y ServiceLB desde el primer arranque. Esa es la diferencia que más se nota el primer día.
• Talos no tiene consola, ni SSH, ni gestor de paquetes. A cambio se actualiza con un esquema A/B que revierte solo si el sistema nuevo no arranca.

Por qué k3s y k0s no juegan en la misma categoría que Talos

Una distribución de Kubernetes es software que instalas sobre un sistema operativo existente. Lanzas un instalador en tu Debian y esa máquina pasa a tener un clúster. Conserva además todo lo que ya tenía: su gestor de paquetes, su systemd, su usuario root y su acceso por SSH. Eso son k3s y k0s, y la documentación de k0s se define exactamente así: «an open source, all-inclusive Kubernetes distribution, which is configured with all of the features needed to build a Kubernetes cluster and packaged as a single binary for ease of use».

Talos Linux ocupa otro sitio: es el sistema operativo entero, con Kubernetes original dentro. Su README lo resume sin adornos, «All system management is done via an API, there is no shell or interactive console», y la página de filosofía va más lejos: «We have no shell. We have no SSH. We have none of the GNU utilities, not even a rollup tool such as busybox». Como casi todo el sistema está escrito en Go desde cero, la imagen SquashFS resultante mide menos de 80 MB.

De ahí sale la regla que resuelve la confusión de partida: eliges una de las tres, no dos. Si te quedas con Talos, no hay dónde instalar k3s ni gestor de paquetes que lo acepte.

Qué trae de serie cada una

k3s es la que más decisiones toma por ti. Empaqueta containerd y runc, Flannel, CoreDNS, Metrics Server, Traefik como controlador de entrada y Klipper-lb como balanceador. Añade el controlador de políticas de red de kube-router, un controlador de Helm, Kine, un aprovisionador de volúmenes locales y utilidades como iptables y socat. Todo eso queda funcionando tras el primer arranque, y todo se puede desactivar o sustituir.

Aquí conviene corregir un tópico que circula en casi todas las comparativas. Se repite que k3s recorta APIs alfa y funciones heredadas, y el propio README lo desmiente: «This is a common point of confusion because it has changed over time. Early versions of K3s had much more removed than the current version. K3s currently removes two things: 1. In-tree storage drivers 2. In-tree cloud provider». Nada más.

Ambos tienen sustituto fuera del árbol mediante CSI y CCM, y se quitaron para reducir el binario, no para recortar Kubernetes. El ahorro de memoria viene de ejecutar los componentes del plano de control dentro de un mismo proceso.

k0s es deliberadamente más seco: containerd, kube-router (con Calico como alternativa integrada), CoreDNS, Metrics Server y etcd o SQLite según tengas uno o más de un nodo. Lo que no trae es controlador de entrada ni balanceador, que su documentación de red deja como extensiones opcionales con MetalLB, NGINX o Traefik a tu cargo. Su binario es «a single, self-extracting binary that embeds Kubernetes binaries», y cada componente del plano de control se ejecuta como un proceso independiente supervisado, sin motor de contenedores ni kubelet en los controladores.

Talos no empaqueta ninguna distribución porque despliega Kubernetes él mismo. Lo que sustituye al gestor de paquetes son las extensiones de sistema. Si necesitas un controlador de GPU o gVisor, generas una imagen nueva con la Image Factory a partir de un esquema, y esa imagen es la que instalas. El esquema recibe un identificador derivado de su contenido, así que dos personas con el mismo esquema obtienen la misma imagen.

Cómo se administra cada uno en el día a día

Con k3s y k0s la respuesta es la de siempre: entras por SSH, miras journalctl, reinicias un servicio de systemd, editas un fichero en /etc. Todo lo que sabes de administrar Linux sigue valiendo. También sigue vigente el trabajo que da: parches del sistema base, deriva de configuración y el día que alguien entra a arreglar algo a mano sin apuntarlo.

Con Talos no hay puerta de entrada. La máquina se configura aplicando un fichero, y se consulta y se opera con talosctl contra una API gRPC protegida con TLS mutuo.

ssh admin@nodo1
sudo systemctl status k3s
sudo journalctl -u k3s -f

talosctl --nodes 10.0.0.11 apply-config --file controlplane.yaml
talosctl --nodes 10.0.0.11 logs kubelet
talosctl --nodes 10.0.0.11 dmesg

La consecuencia buena es que la deriva desaparece: el estado de la máquina es el fichero que aplicaste. La mala es que todos tus reflejos de depuración dejan de servir el primer día.

Cómo se actualiza cada uno

k3s se actualiza volviendo a lanzar el guion de instalación, que descarga el binario nuevo, ajusta la unidad de systemd y reinicia el servicio; también vale cambiar el binario de /usr/local/bin/k3s a mano. Para más de un nodo existe el system-upgrade-controller.

k0s se actualiza con k0sctl apply tras subir la versión en el fichero de configuración. La documentación detalla el orden: primero los controladores «one at a time», sin caída si hay más de uno, y después los trabajadores «in batches of 10%». En una sola máquina: k0s stop, cambiar el binario y k0s start.

Talos es el que más se aparta. La actualización es una llamada a la API que entrega al nodo la imagen del instalador: «Upgrades use an A-B image scheme in order to facilitate rollbacks. This scheme retains the previous Talos kernel and OS image following each upgrade. If an upgrade fails to boot, Talos will roll back to the previous version». Hay marcha atrás manual con talosctl rollback. Y un detalle que sorprende: desde la versión 1.0, actualizar el sistema operativo no actualiza Kubernetes.

Cuánta máquina pide cada uno

Los tres proyectos publican requisitos mínimos, pero los midieron en momentos distintos, en equipos distintos y contando cosas distintas. No forman una tabla comparable, y quien saque de ahí un ranking de consumo se lo está inventando. Lo que sí se puede citar es cada cifra con su fuente.

k3s pide 2 núcleos y 2 GB de memoria en un nodo servidor, y 1 núcleo con 512 MB en un agente, advirtiendo de que son valores base que «do not include resources consumed by the workload itself». En k0s el listón baja a 1 vCPU y 1 GB en un controlador, y 1 vCPU con 0,5 GB en un trabajador. Talos es el más exigente sobre el papel. Pide 2 GiB y 2 núcleos mínimos en el plano de control, 4 GiB y 4 recomendados, y 10 GiB de disco frente a los 100 GiB recomendados.

k0s es el único que publica una medida real del consumo de su controlador: 510 MB con un trabajador y ningún pod adicional, y 3.300 MB con 200 trabajadores y 20.000 pods. La letra pequeña importa, porque esa medición se hizo con k0s v1.22.4, catorce versiones de Kubernetes atrás.

Lo que sí he medido yo, el 30 de agosto de 2026, es el tamaño de los artefactos que te descargas. La cifra sale del campo size de los activos de la última publicación de cada repositorio en la API de GitHub:

De ahí sale una corrección pequeña pero real: la portada de k3s.io sigue anunciando «a single <70 MB binary» y el binario amd64 actual mide 75,3 MB. Solo las compilaciones para ARM siguen por debajo de 70 MB; el «less than 100 MB» del README sí se cumple. Y el binario de k0s pesa más del triple porque lleva dentro los ejecutables de Kubernetes, no porque sea más pesado en ejecución.

Comparativa lado a lado

Un nodo, varios nodos y alta disponibilidad

En una sola máquina las tres funcionan y k3s es la más corta: un servidor con SQLite embebido y ya tienes clúster. k0s hace lo mismo con su binario único. Talos monta un clúster de un nodo permitiendo que el plano de control acepte cargas, que es un ajuste del fichero de configuración.

Cuando quieres tolerancia a fallos manda etcd. En k3s hay dos caminos, «Three or more server nodes» con etcd embebido o «Two or more server nodes» apoyados en una base de datos externa. Por su parte k0s usa etcd en cuanto hay más de un nodo, y admite MySQL, PostgreSQL, SQLite o dqlite a través de Kine. Talos usa etcd y el mismo quórum de tres controladores.

Si quieres refrescar qué ha cambiado por debajo, el balance de Kubernetes 1.35 y el resumen de la 1.34 cubren lo que las tres heredan del proyecto original. Y las tres montan sobre containerd.

ARM y Raspberry Pi

Este apartado descarta candidatos rápido. La lista de k3s cubre x86_64, arm64 y armhf, o sea también ARM de 32 bits. La de k0s añade armv7l y menciona riscv64 «with no pre-compiled binaries or CI coverage», que en la práctica quiere decir que te lo compilas tú. Talos publica imágenes metal para amd64 y arm64, y nada más.

Con placas concretas la diferencia se agranda. La documentación de Talos para Raspberry Pi es explícita: solo se ha comprobado oficialmente en la Raspberry Pi 4. La comunidad ha validado además una única variante del Compute Module 4 sobre placas Super 6C.

Funciona, pero es terreno mucho menos pisado que el de k3s, que lleva años siendo la respuesta por defecto en ese hardware. Un aviso que vale para las tres: los requisitos de k3s recomiendan disco SSD externo en Raspberry Pi porque «etcd is write intensive; SD cards and eMMC cannot handle the IO load». Las microSD se mueren, y pronto.

Qué se rompe cuando no hay consola

El día que algo falle en Talos, tus herramientas no están. No hay grep, no hay vi, no hay un ps al que recurrir. Lo que hay es talosctl: registros por servicio, dmesg, lectura de ficheros del sistema y un volcado de diagnóstico completo. Cubre lo que antes hacías por SSH, pero el aterrizaje es duro si llevas quince años arreglando servidores a mano.

Conviene matizar el eslogan, porque la propia documentación lo matiza. Existe talosctl debug, que «starts a privileged container using an image you supply, then drops you into that shell», con el sistema de ficheros del anfitrión colgado en /host y el contenedor destruido al salir. Puedes incluso empujar la imagen por la API si el nodo no llega al registro.

Así que la frase precisa no es que Talos te deje sin depuración, sino que la convierte en un acto explícito y efímero en lugar de una sesión permanente. Que es justo lo que buscaba el diseño.

Comunidad y respaldo

Los números de GitHub, leídos el 30 de agosto de 2026, dibujan tres proyectos de tamaños distintos. Por estrellas manda k3s, con 33.850, y suma 301 colaboradores. Talos va detrás en estrellas con 11.050 pero lidera en colaboradores con 347, y k0s es el pequeño con 6.456 y 157.

Hay una asimetría que conviene tener presente. Tanto k3s como k0s son proyectos alojados por la CNCF, aceptados en el Sandbox el 19 de agosto de 2020 y el 19 de enero de 2025. Talos no lo es.

La fundación lo lista como distribución certificada de Kubernetes, pero el proyecto es de Sidero Labs, que además vende encima un orquestador comercial llamado Omni. No es motivo para descartarlo, con MPL-2.0 y 347 colaboradores no hablamos de un experimento, pero sí es una diferencia de gobernanza que merece saberse antes de montar veinte nodos.

Cuál elegir en cada escenario

Una máquina para aprender Kubernetes. k3s, sin dudarlo. Es la que menos pasos pide, la que más tutoriales tiene detrás y la única que te deja un controlador de entrada funcionando sin decidir nada. Para el detalle del arranque, la guía para instalar k3s en un homelab cubre el proceso completo.

Tres o cuatro nodos tuyos, con Kubernetes lo más limpio posible. k0s. Un binario sin dependencias del sistema y Kubernetes certificado sin extras, y su k0sctl es la forma más ordenada de actualizar más de un nodo de las tres. El precio es que la entrada, el balanceo y el almacenamiento los montas tú.

Un aparato que no quieres volver a tocar. Talos. Sin consola no hay deriva, sin gestor de paquetes no hay parches sueltos, y el esquema A/B convierte una actualización fallida en un reinicio en lugar de en una noche larga. Asume una semana de curva de aprendizaje.

Algo parecido a producción, con más de una persona tocándolo. Talos por la inmutabilidad y el TLS mutuo de serie, o k3s si el equipo necesita poder entrar a la máquina y no vas a ganar esa discusión.

Raspberry Pi u otra placa ARM pequeña. k3s, y con margen: es la única con binarios de 32 bits y la que tiene detrás años de experiencia ajena en ese hardware.

Una nota sobre el coste: pasados dos nodos, lo que duele no es el clúster sino lo que metas dentro. Kubecost y OpenCost miden eso en cualquiera de las tres, porque por debajo son Kubernetes normal.

Preguntas frecuentes

¿Se puede instalar k3s sobre Talos Linux?

No, y la pregunta revela la confusión más común. Talos no tiene gestor de paquetes, ni consola, ni sistema de ficheros escribible donde dejar un binario, y además ya ejecuta su propio Kubernetes. No hay mecanismo para hacerlo. Elige una de las dos.

¿Cuál de las tres consume menos memoria?

No hay respuesta honesta a partir de fuentes oficiales: cada proyecto publica mínimos medidos con métodos y en fechas distintas, y ninguno mide a los otros dos. Las cifras que circulan por blogs comparando los tres consumos no citan método ni hardware. Si necesitas el dato, mídelo en tu equipo con tu carga.

¿Talos es más seguro que k3s por no tener SSH?

Reduce superficie de ataque de forma medible: sin consola, sin utilidades GNU y con la imagen del sistema en modo lectura, hay clases enteras de ataque que dejan de aplicar. Pero el plano de control, los pods y las políticas de red son los mismos en los tres, así que un despliegue mal configurado sigue siendo un despliegue mal configurado en Talos.

Conclusión

Una frase por herramienta. Con k3s tienes un clúster funcionando en dos minutos y las decisiones ya tomadas, y con k0s, Kubernetes certificado sin extras y el resto lo pones tú. Talos te quita el sistema operativo de encima a cambio de que aprendas a operar sin consola. El error habitual es elegir por consumo de memoria, cuando lo que decide es cuántos nodos vas a tener y si quieres seguir entrando en ellos.

La versión en inglés de este artículo está en k3s vs k0s vs Talos Linux.

Fuentes

1. k3s, documentación oficial
2. k3s, requisitos de hardware
3. k3s, arquitectura del clúster
4. k3s, actualización manual
5. k3s-io/k3s, repositorio del proyecto
6. k0s, documentación oficial
7. k0s, requisitos del sistema
8. k0s, arquitectura
9. k0s, red y CNI
10. k0s, actualizar el clúster
11. Talos Linux, filosofía del proyecto
12. Talos Linux, requisitos de hardware
13. Talos Linux, actualizar el sistema
14. Talos Linux, consola de depuración
15. Talos Linux, Image Factory y extensiones
16. Talos Linux, instalación en Raspberry Pi
17. siderolabs/talos, repositorio del proyecto
18. CNCF, ficha del proyecto k3s
19. CNCF, ficha del proyecto k0s