Parece imposible administrar un servidor en el que no se puede entrar. Y, sin embargo, esa es exactamente la idea. Esta es la primera entrega de “Talos desde cero”. Veremos qué es Talos Linux, por qué está hecho así y levantaremos un clúster con Docker.
¡Gracias por pasarte por aquí! 🙌
Si te interesa seguir recibiendo guías prácticas sobre Kubernetes, Azure, DevOps y contenedores directamente en tu email…
Suscríbete gratis y no te pierdas ninguna novedad. 🚀
Un día cualquiera a las tres de la mañana
Administras un clúster de Kubernetes con varias máquinas Ubuntu. Funciona.
Un nodo deja de responder a las tres de la mañana. Entras por SSH, el disco está lleno de logs, los borras, reinicias el kubelet y vuelves a la cama. No lo apuntas.
Seis meses después ese nodo tiene un logrotate que los otros nodos no tienen, una versión de containerd distinta porque alguien hizo un apt upgrade a medias, y un fichero en /etc que nadie sabe quién puso. Ninguno de los nodos es igual a los otros, y el único que lo sabe es quien entró a las tres de la mañana.
A eso se le llama deriva (configuration drift), y es el enemigo real. No da error. Se acumula en silencio hasta que un Pod se comporta distinto en un nodo que en otro y nadie sabe por qué, porque la diferencia no está en ningún manifiesto.
El problema no es Kubernetes. Kubernetes declara el estado deseado de los Pods y lo persigue sin descanso. Lo que nadie declara es el estado deseado del nodo.
Qué es Talos Linux
Talos no es una distribución de Linux con Kubernetes preinstalado. Es un sistema operativo escrito para una sola cosa: ejecutar Kubernetes. Lo desarrolla Sidero Labs, es código abierto (licencia MPL 2.0) y la versión actual es la 1.14.X.
Del Linux se conserva el kernel y unas pocas piezas imprescindibles, como containerd o udev. Lo que gestiona la máquina (el arranque, los servicios, la red, los discos) está escrito en Go.
Cuando una máquina Linux normal arranca, el kernel lanza systemd como primer proceso (PID 1) y systemd lanza decenas de servicios. En Talos el PID 1 es machined: lee la configuración, levanta la red y arranca un puñado de servicios. Los principales son apid (la API), containerd, el kubelet y, en los control plane, etcd y trustd.
La idea es la misma que ya conoces de Kubernetes: declaras el resultado, no los pasos. Solo que ahora lo que declaras no es un Deployment, es la configuración de la máquina.
Tres decisiones de diseño
Talos se resume en tres decisiones de diseño, y cada una ataca la deriva desde un lado.
Es inmutable
Talos arranca desde una imagen comprimida de solo lectura que no se modifica nunca. No hay /usr en el que escribir ni paquetes que actualizar.
Actualizar no es parchear lo que hay: se escribe la imagen nueva entera en un segundo hueco de la partición de arranque y se reinicia sobre ella. Si la versión nueva no arranca, la máquina vuelve sola a la anterior. Dos nodos con la misma versión de Talos, las mismas extensiones y la misma configuración (lo que Image Factory llama un schematic, que veremos en otros posts) arrancan con la misma imagen, bit a bit.
Es mínimo
No hay shell, ni utilidades de GNU, ni busybox, ni Python. Hay lo que Kubernetes necesita para ejecutar Pods: un kernel con la seguridad reforzada de serie, containerd, el kubelet, etcd en los control plane y los servicios propios de Talos.
La consecuencia es doble. Hay muy poco que parchear. Y quien consiga ejecutar algo dentro del nodo se encuentra con que no tiene herramientas con las que seguir.
Se gestiona por API
No hay SSH, ni usuarios, ni contraseñas, ni sudo. Toda la máquina se describe en un fichero YAML, el machine config, y todo lo que se puede hacer con ella: leer sus logs, cambiar la red, reiniciarla o actualizarla, se hace con talosctl contra una API gRPC en el puerto 50000, con certificados de cliente.
Para que te hagas una idea, esto es lo que en Ubuntu sería ip addr:
talosctl -n 192.168.10.11 get addressesNo entras en la máquina: le preguntas. La configuración es la única forma de cambiar cómo está, y la API la única forma de mirarla. Eso no impide que alguien aplique un arreglo a las tres de la mañana sin pasar por Git, pero el arreglo ya no es invisible: queda en la configuración del nodo, y a las nueve cualquiera puede leerla y compararla con la del repositorio.
Talos frente a un nodo Ubuntu
No hay acceso. Quien no sepa cómo funciona buscará cómo entrar, y la respuesta es que no se entra. Cada gesto de “entro y miro” tiene su comando de talosctl equivalente, y hay que aprenderlos.
No se instala nada. Un agente de monitorización, un cliente de VPN o un driver tienen que existir como extensión del sistema, que se incorpora a la imagen. Talos proporciona varios drivers de GPU, herramientas de iSCSI, agentes de hipervisor, Tailscale. También puedes crear y distribuir tu propia extensión.
No hay scripts de arranque. La configuración no ejecuta código: declara estado. Si tu aprovisionamiento dependía de ejecutar cosas en el nodo, hay que repensarlo.
Ni un Pod privilegiado puede con todo. Talos elimina de todos los procesos dos capabilities del kernel: CAP_SYS_MODULE, que permite cargar módulos, y CAP_SYS_BOOT, que permite reiniciar la máquina. Los módulos se declaran en la configuración y los carga Talos.
La máquina se convierte en un objeto más, como un Deployment: tiene un manifiesto, un estado que se consulta, se sustituye en lugar de repararse, y se versiona en Git. Si un nodo se rompe, no se arregla: se reinstala con la misma configuración. Y la deriva deja de ser invisible, porque se puede comparar lo que tiene cada máquina con lo que dice el repositorio.
Cuándo no usar Talos
Talos no es la respuesta a todo, y conviene saberlo antes de enamorarse. Hay cinco casos en los que no es la herramienta:
Necesitas instalar en el nodo algo que no se puede meter en un contenedor. Un agente corporativo que solo se distribuye como .deb, y que tu empresa exige instalar tal cual. Si puedes empaquetarlo en una imagen, tienes dos salidas: una extensión del sistema o, desde la 1.14, un documento ContainerConfig, que ejecuta un contenedor directamente en el nodo, sin Kubernetes.
Tu hardware no tiene driver en el kernel de Talos. Una tarjeta de red exótica o una controladora RAID antigua. Se puede construir una imagen propia, pero es trabajo que se repite en cada nueva versión de Talos.
Tu equipo no tiene tiempo de desaprender. La curva no es larga, pero es abrupta: al principio nadie sabe dónde mirar.
Un clúster gestionado ya te vale. Si estás en una nube y EKS, AKS o GKE cubren lo que necesitas, Talos te da control sobre el nodo a cambio de operarlo tú.
Quieres un servidor, no un clúster. Talos no está pensado para una máquina suelta con tres contenedores. Puedes montar un clúster de un solo nodo, pero sigue siendo un clúster, con su etcd y su API server.
Tu primer clúster Talos
Talos puede ejecutarse en contenedores de Docker, cada uno haciendo de nodo. Es la forma más rápida de trabajar con él.
Necesitas:
Docker (Docker Desktop en macOS o Windows).
kubectl.
Unos 8 GB de memoria libres: cada nodo puede usar hasta 2 GB por defecto, y vamos a crear cuatro. En macOS y Windows lo que cuenta es la memoria asignada a Docker Desktop (Settings → Resources), no la de tu equipo.
talosctl, la herramienta de línea de comandos de Talos. En macOS o Linux se instala conbrew install talosctlo con el script oficial:curl -sL https://talos.dev/install | sh. Este post está probado con la versión 1.14.X.
La versión de talosctl importa: cluster create arranca los nodos con la imagen de Talos de su misma versión. Puedes comprobar cuál tienes con talosctl version --client.
Ejecuta: talosctl cluster create docker --workers 3
Si usas Docker Desktop en macOS y el comando falla diciendo que no encuentra el daemon de Docker, la guía oficial lo resuelve con un enlace simbólico al socket:
sudo ln -s "$HOME/.docker/run/docker.sock" /var/run/docker.sock
En unos minutos tienes un clúster de Kubernetes con un control plane y tres workers. Por debajo han pasado varias cosas:
Docker ha creado cuatro contenedores, uno por nodo, en una red propia, la 10.5.0.0/24. El control plane es el primero, 10.5.0.2.
talosctlha generado la configuración de cada nodo y se la ha aplicado al arrancar. Esa configuración es la protagonista de los siguientes posts sobre Talos.Ha guardado tu credencial para hablar con Talos en
~/.talos/config.Ha añadido el clúster a tu
~/.kube/config, así quekubectlya funciona.
Ejecuta kubectl get nodes -o wide
Trabajando con el clúster
Intenta entrar en un nodo: no hay docker exec que valga, porque dentro no hay shell que ejecutar. Lo que sí puedes hacer es preguntarle.
¿Qué servicios tiene el control plane?
talosctl -n 10.5.0.2 servicesVerás los servicios de Talos: apid, machined, trustd, containerd, cri, etcd y el kubelet. Fíjate en que hay dos containerd: el primero ejecuta los servicios del propio Talos y el segundo, cri, los Pods de Kubernetes. Lo que despliegues nunca comparte runtime con el sistema. Esa lista corta es la decisión de ser mínimo.
¿Cómo está el nodo en tiempo real?
talosctl -n 10.5.0.2 dashboardEs un panel en la terminal con la memoria, la CPU, los procesos y los logs del nodo. En una máquina física es también lo que se ve en su monitor.
¿Está funcionando correctamente el clúster entero?
talosctl -n 10.5.0.2 healthComprueba etcd, los componentes de Kubernetes y que todos los nodos se han unido.
La tabla de comandos
Todos llevan el parámetro -n (--nodes) con la IP del nodo al que preguntas.
Endpoint y nodo
talosctl maneja dos direcciones, y confundirlas es un error común en los primeros días:
El endpoint (-e) es la puerta por la que accedes: siempre a tráves de un control plane.
El nodo (
-n) es la máquina a la que le preguntas.
Cuando son distintos, tu petición es atendida por el control plane y él la reenvía al nodo. Tu portátil solo necesita llegar al control plane; de los workers se encarga él. En Docker apenas se nota, porque todo está en tu máquina, pero en una red real significa que no tienes que poder llegar a cada worker para administrarlo:
talosctl -n 10.5.0.3 servicesNo has escrito ningún -e: cluster create ya dejó el endpoint configurado en ~/.talos/config. Puedes verlo con:
talosctl config info
Y -n admite una lista. Es la forma de obtener la información de todos los nodos de una vez:
talosctl -n 10.5.0.2,10.5.0.3,10.5.0.4,10.5.0.5 version --shortEn la salida, cada respuesta lleva un campo NODE con la IP del nodo que la ha dado.
Desplegar aplicaciones
Un clúster vacío no enseña mucho, así que vamos a desplegar una aplicación de verdad: la tienda de Kubernetes 101, mi libro para aprender Kubernetes desde cero. Tiene una web, una API, una base de datos y una caché en el Namespace tienda, y un agente que lee los logs de los nodos en el Namespace plataforma. El libro la despliega con manifiestos, Kustomize y Helm; aquí usaremos Kustomize. El código está en GitHub.
Antes hay que resolver una cosa: la tienda guarda datos, y este clúster no trae ningún aprovisionador de volúmenes. Usamos local-path, que crea los volúmenes en el disco de cada nodo:
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml
kubectl annotate storageclass local-path storageclass.kubernetes.io/is-default-class=true
kubectl label namespace local-path-storage pod-security.kubernetes.io/enforce=privilegedLa tercera línea es la interesante. Sin ella, la base de datos de la tienda se queda en Pending: para crear su directorio, el aprovisionador lanza un Pod auxiliar con un volumen hostPath, y Pod Security lo rechaza. Talos configura el API server para que aplique baseline a todos los Namespaces que no digan lo contrario, y para que avise y registre lo que no cumpla restricted. La excepción se pone en el Namespace del aprovisionador, no en el de la tienda.
Es la primera prueba práctica de que Talos viene seguro de fábrica: lo que en otras distribuciones tendrías que activar tú, aquí ya está activado, y lo que tienes que hacer es abrir la excepción a propósito.
Ojo: esto funciona en Docker, pero no lo copies tal cual en un Talos instalado en máquinas virtuales o físicas. Allí la ruta por defecto del aprovisionador, /opt/local-path-provisioner, es de solo lectura, y hay que configurar un volumen propio y apuntarlo a él. Lo veremos cuando montemos el clúster en VMs.
Con el aprovisionador listo, toca la tienda. En el libro se trabaja con kind, donde las imágenes, como tienda/web:1.4.2, se construyen y se cargan a mano con kind load. Aquí no existe ese paso, así que usamos el overlay ghcr del repositorio: los mismos manifiestos de k8s/, pero con las imágenes ya publicadas en ghcr.io/fjvela.
git clone https://github.com/fjvela/kubernetes-101
cd kubernetes-101
kubectl apply -k kustomize/overlays/ghcr
kubectl get pods -n tienda -o wideUna vez los Pods están en ejecución, ejecuta kubectl port-forward -n tienda svc/web 8080:80y abre http://localhost:8080. Tendrás la tienda funcionando sobre Talos, usamos port-forward porque el clúster no trae controlador de Ingress: el Ingress de la web se crea, pero no hace nada.
Dos detalles que enlazan con lo que acabas de leer:
Pod Security ya estaba pensado. Los Namespaces de la tienda llevan sus propias etiquetas:
tiendaen baseline yplataformaen privileged, porque el agente monta/var/logdel nodo. Ahí encuentra los logs de los Pods y también los de los servicios de Talos, que el sistema escribe en ese mismo directorio. Desde tu portátil se consultan con talosctl logs, y también se pueden enviar fuera, algo que veremos en otros posts de la saga.Las NetworkPolicies no filtran. Talos instala Flannel como red de Pods, y Flannel, tal como viene, no aplica NetworkPolicies. Las de la tienda
db-solo-desde-apiycache-solo-desde-api) se crean, pero cualquier Pod puede hablar con la base de datos. Desde la 1.13 se activan con un parche en la configuración del control plane:
apiVersion: v1alpha1
kind: KubeFlannelCNIConfig
kubeNetworkPoliciesEnabled: trueLo que Docker no puede hacer
El modo Docker es perfecto para aprender y para probar, pero no es un Talos completo. Los cuatro nodos comparten el kernel del host (en macOS y Windows, el de la máquina virtual de Docker Desktop):
No hay kernel propio. El hardening, los módulos firmados y los sysctls de Talos no se aplican.
No hay discos. No existen las particiones EFI, STATE ni EPHEMERAL: son volúmenes de Docker.
No hay instalación. Ni ISO, ni arranque, ni modo mantenimiento: el contenedor nace ya configurado.
No se actualiza. talosctl upgrade y talosctl reset no están soportados en este modo, porque no hay dónde escribir la imagen nueva.
La red la pone Docker. No hay IP virtual, ni bonds, ni el cortafuegos de Talos.
No hay Secure Boot ni cifrado. No hay firmware ni TPM a los que preguntar.
Por eso en los siguientes posts desplegaremos Talos en máquinas virtuales de verdad.
Borrarlo todo
Cuando termines ejecuta:
talosctl cluster destroyEn los próximos posts de la saga veremos el machine config a fondo, instalaremos Talos en máquinas virtuales y crearemos imágenes a medida con Image Factory.
Si este post te ha ayudado o aclarado algo, me harías muy feliz con un ❤️
Y si crees que le puede servir a alguien más… ¡compártelo! 🙌
Nos leemos.
Javi
Referencias
https://docs.siderolabs.com/talos/v1.14/overview/what-is-talos
https://www.javivela.dev/libros/kubernetes-101/
https://github.com/fjvela/kubernetes-101
https://docs.siderolabs.com/kubernetes-guides/cni/flannel