Talos Linux es un sistema operativo inmutable que solo sirve para ejecutar Kubernetes y que se administra entero por una API, sin SSH ni consola. Esta guía crea un primer clúster con talosctl cluster create docker, despliega una carga, cambia la configuración de un nodo en marcha y actualiza Kubernetes de 1.37.0 a 1.37.1, todo con Talos v1.14.2, publicado el 29 de septiembre de 2026. Lo ejecuté el 30 de septiembre de 2026 en una máquina Linux arm64. La segunda mitad explica qué cambia en hardware real o en máquinas virtuales de Proxmox, y separa lo que probé de lo que solo documento. Si todavía dudas entre Talos, k3s y k0s, empieza por la comparativa de k3s, k0s y Talos. Tienes también la versión en inglés de esta guía.

Puntos clave

  • talosctl cluster create docker levanta un panel de control y un nodo de trabajo en contenedores, hace el bootstrap de etcd y deja listos talosconfig y kubeconfig.
  • La imagen ghcr.io/siderolabs/talos:v1.14.2 no trae shell: docker exec con sh falla con executable file not found in $PATH. Se depura con talosctl logs, dmesg, services y dashboard.
  • Talos 1.14 parte la configuración en documentos pequeños: un controlplane.yaml recién generado tiene 28 y un worker.yaml, 14. Los parches antiguos sobre machine.install ya no validan.
  • talosctl upgrade-k8s actualizó el clúster de 1.37.0 a 1.37.1 sin cortar el servicio: 196 peticiones a la aplicación durante la operación, ninguna fallida.
  • talosctl upgrade no funciona en Docker. En hardware real el sistema se actualiza con una imagen de instalador de la Image Factory y un esquema A/B que revierte si el nuevo arranque falla.

Qué es Talos Linux y qué cambia frente a un Linux con SSH

Talos Linux es una distribución de Linux reducida a lo que Kubernetes necesita, escrita casi entera en Go por Sidero Labs. No tiene gestor de paquetes, ni utilidades GNU, ni acceso por SSH. Toda la administración pasa por una API gRPC con TLS mutuo, y el cliente de esa API es talosctl.

La consecuencia práctica es que no instalas Kubernetes sobre Talos: Talos ya lo trae y lo arranca. Tampoco configuras el sistema editando ficheros en el disco. Escribes un documento YAML, la configuración de máquina, y se lo entregas al nodo. Si vienes de k3s, el cambio es parecido a pasar de administrar un servidor a administrar un aparato, como explica la guía para instalar k3s en un homelab desde el otro lado.

Qué necesitas antes de empezar

La parte en Docker solo pide un anfitrión Linux con Docker y dos binarios en el PATH. Yo lo probé en una máquina virtual Linux arm64 de 18 núcleos (OrbStack sobre Apple silicon) con Docker Engine 29.5.2, compartida con otros trabajos. Necesitas:

  • Docker 18.03 o posterior, según la documentación de Talos para Docker
  • talosctl de la misma versión que la imagen de Talos que vas a usar, aquí v1.14.2
  • kubectl para hablar con el clúster, aquí v1.37.1
  • Unos 2 GiB de memoria libre por nodo, que es el límite por defecto de cada contenedor

Descarga los dos binarios de sus publicaciones oficiales. El binario de talosctl para Linux arm64 pesa 110,9 MB:

BASE=https://github.com/siderolabs/talos/releases/download
curl -sL -o talosctl "$BASE/v1.14.2/talosctl-linux-arm64"
curl -sL -o kubectl https://dl.k8s.io/release/v1.37.1/bin/linux/arm64/kubectl
chmod +x talosctl kubectl
sudo mv talosctl kubectl /usr/local/bin/
talosctl version --client --short

En un equipo x86 cambia arm64 por amd64 en las dos URL. La última orden debe responder Talos v1.14.2.

Cómo crear un clúster de Talos en Docker con talosctl

Una sola orden crea la red, los contenedores, las claves y el clúster de etcd. Por defecto escribe en ~/.talos/config y ~/.kube/config; yo exporté dos variables para que los ficheros quedaran en el directorio de trabajo y no pisaran otras configuraciones:

export TALOSCONFIG=$PWD/talosconfig KUBECONFIG=$PWD/kubeconfig
talosctl cluster create docker --name b7p9-talos \
  --state $PWD/state --talosconfig-destination $PWD/talosconfig \
  --subnet 10.59.0.0/24 --workers 1 \
  --kubernetes-version 1.37.0 \
  --exposed-ports 26980:30080/tcp --host-ip 127.0.0.1

El nombre lleva el prefijo b7p9 de mi laboratorio. Sin --name, el clúster se llama talos-default y usa la red 10.5.0.0/24. Pedí Kubernetes 1.37.0, una versión por debajo de la de fábrica, para poder probar la actualización más adelante. --exposed-ports publica el puerto 30080 del panel de control en el 26980 del anfitrión, y --host-ip 127.0.0.1 deja todos los puertos publicados en la interfaz local.

La salida recorre las comprobaciones de salud y termina con el resumen del clúster. Este es un extracto, sin la columna DISK:

bootstrapping cluster
waiting for etcd to be healthy: OK
waiting for apid to be ready: OK
waiting for kubelet to be healthy: OK
waiting for all k8s nodes to report ready: OK
waiting for coredns to report ready: OK
waiting for all k8s nodes to report schedulable: OK

NAME                         TYPE           IP          CPU    RAM
/b7p9-talos-controlplane-1   controlplane   10.59.0.2   2.00   2.1 GB
/b7p9-talos-worker-1         worker         10.59.0.3   2.00   2.1 GB

La columna RAM es el límite de cada contenedor, no el consumo. El paso bootstrapping cluster es el que en hardware real haces tú a mano con talosctl bootstrap, y lo verás más abajo.

Qué ha creado exactamente

Cada nodo es un contenedor privilegiado de la imagen ghcr.io/siderolabs/talos:v1.14.2, que ocupa 316 MB en disco. La API de Talos (puerto 50000) y la de Kubernetes (6443) se publican en puertos aleatorios del anfitrión, que talosctl anota por su cuenta en los dos ficheros de configuración. En mi caso fueron 127.0.0.1:41833 y 127.0.0.1:46855, así que no puedes elegirlos con este proveedor.

Antes de consultar los nodos, dile a talosctl a qué IP dirigir cada orden. Después, services muestra los procesos que Talos gestiona en el panel de control:

talosctl config nodes 10.59.0.2 10.59.0.3
talosctl -n 10.59.0.2 services

La respuesta lista siete servicios en estado Running y salud OK: apid, containerd, cri, etcd, kubelet, machined y trustd. No hay sshd, ni cron, ni systemd. machined es el servicio central de Talos: arranca los demás y aplica la configuración que recibe por la API.

Cómo conectar kubectl y desplegar una primera aplicación

El kubeconfig ya apunta al clúster, así que kubectl funciona sin más pasos:

$ kubectl get nodes
NAME                        STATUS   ROLES           VERSION
b7p9-talos-controlplane-1   Ready    control-plane   v1.37.0
b7p9-talos-worker-1         Ready    <none>          v1.37.0

Recorté columnas para que quepa. La columna KERNEL-VERSION completa revela algo que conviene saber: en Docker los nodos corren sobre el núcleo del anfitrión (7.0.14-orbstack en mi caso), no sobre el Linux 6.18.54 que trae Talos 1.14.2. Por eso este modo sirve para aprender la API y probar manifiestos, pero no para evaluar el sistema operativo.

Para la primera carga, guarda este Deployment de dos réplicas de nginx como hola.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hola
spec:
  replicas: 2
  selector:
    matchLabels: {app: hola}
  template:
    metadata:
      labels: {app: hola}
    spec:
      containers:
        - name: web
          image: mirror.gcr.io/library/nginx:1.29-alpine
          ports: [{containerPort: 80}]

Añade al mismo fichero, separado por ---, un Service de tipo NodePort en el puerto 30080, el que publicaste al crear el clúster:

apiVersion: v1
kind: Service
metadata:
  name: hola
spec:
  type: NodePort
  selector: {app: hola}
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

Aplica el fichero y espera al despliegue. Después pide la página por el puerto del anfitrión:

kubectl apply -f hola.yaml
kubectl rollout status deploy/hola --timeout=180s
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:26980/

La respuesta fue 200, y las dos réplicas se programaron en el nodo de trabajo. El panel de control lleva la marca NoSchedule, así que no acepta cargas salvo que lo permitas en la configuración.

Por qué kubectl avisa al aplicar el manifiesto

Talos activa Pod Security Admission con el perfil baseline en modo obligatorio y el perfil restricted en modo aviso. El apply anterior devolvió un Warning: would violate PodSecurity "restricted:latest" por no declarar runAsNonRoot ni seccompProfile, pero creó los pods. Un pod privilegiado, en cambio, se rechaza:

$ kubectl run priv --image=mirror.gcr.io/library/busybox:1.37 \
    --privileged --restart=Never -- sleep 5
Error from server (Forbidden): pods "priv" is forbidden:
violates PodSecurity "baseline:latest": privileged (container
"priv" must not set securityContext.privileged=true)

Partí el mensaje en líneas para que se lea. Si un operador de almacenamiento o de red necesita privilegios, etiqueta su espacio de nombres con pod-security.kubernetes.io/enforce: privileged, como describe la documentación de Pod Security Admission[1], en lugar de relajar el valor para todo el clúster.

Cómo se depura un nodo sin SSH ni consola

Sin SSH, cada herramienta de diagnóstico es una orden de talosctl contra la API del nodo. Comprobé primero que la puerta de atrás no existe: ssh al puerto 22 del nodo devolvió Connection refused, y docker exec b7p9-talos-controlplane-1 sh falló con exec: "sh": executable file not found in $PATH. La imagen no trae ni sh ni ls.

Estas son las órdenes que sustituyen al terminal, todas probadas en el laboratorio:

talosctl -n 10.59.0.3 logs kubelet --tail 5
talosctl -n 10.59.0.2 dmesg
talosctl -n 10.59.0.3 containers --namespace cri
talosctl -n 10.59.0.2 ls /var/log
talosctl -n 10.59.0.2 read /proc/loadavg
talosctl -n 10.59.0.2 etcd members
talosctl -n 10.59.0.2 health
talosctl dashboard

Qué hace cada una:

  • logs <servicio>: el registro de un servicio del sistema; con --namespace cri lee el de un contenedor de Kubernetes
  • dmesg: el anillo del núcleo; en Docker muestra el del anfitrión, con sus interfaces veth
  • containers --namespace cri: los pods y contenedores que ve containerd, con su imagen y estado
  • ls y read: listar directorios y leer ficheros del nodo, en modo solo lectura
  • etcd members: los miembros de etcd, con sus URL de pares y de clientes
  • health: la misma batería de comprobaciones que ejecutó cluster create
  • dashboard: una interfaz de texto con el estado del nodo, registros en vivo y pestañas de monitorización

El dashboard es lo más parecido a sentarse delante de la máquina. Muestra la versión de Talos y de Kubernetes, la etapa de arranque, la conectividad y los registros del núcleo, con una pestaña por cada nodo en la barra inferior. La imagen de portada de este artículo es ese panel, capturado sobre el panel de control del laboratorio.

Si nada de eso basta, existe talosctl debug. Arranca en el nodo un contenedor de depuración a partir de la imagen o del archivo .tar que le pases, y su ayuda pone de ejemplo una Alpine con /bin/sh. No lo necesité en esta prueba.

Cómo cambiar la configuración de un nodo en marcha

La configuración de un nodo se cambia con un parche, y Talos decide si el cambio exige reinicio. Desde la versión 1.14 la configuración ya no es un único documento v1alpha1: se reparte en documentos pequeños con su propio kind, y los campos antiguos quedan obsoletos. Las etiquetas de nodo, por ejemplo, pasaron de .machine.nodeLabels al documento KubeNodeConfig.

Mi primer intento usó el nombre de campo antiguo dentro del documento nuevo, y --dry-run lo paró antes de tocar nada:

$ talosctl -n 10.59.0.3 patch mc --patch @label-patch.yaml --dry-run
error decoding document v1alpha1/KubeNodeConfig/ (line 1): unknown
keys found during decoding:
nodeLabels:
    jacar.es/rol: laboratorio

El campo correcto se llama labels, según la referencia de KubeNodeConfig. Este es el parche que funcionó, guardado como label-patch.yaml:

apiVersion: v1alpha1
kind: KubeNodeConfig
labels:
  jacar.es/rol: laboratorio

Con --dry-run, Talos muestra el diff y anuncia Applied configuration without a reboot (skipped in dry-run). Sin él, aplica el cambio y la versión de la configuración del nodo pasa de 1 a 2. Recorté la columna AGE de la salida de kubectl:

$ talosctl -n 10.59.0.3 patch mc --patch @label-patch.yaml
patched MachineConfigs.config.talos.dev/v1alpha1 at the node 10.59.0.3
Applied configuration without a reboot
$ kubectl get nodes -L jacar.es/rol
NAME                        STATUS   ROLES           VERSION   ROL
b7p9-talos-controlplane-1   Ready    control-plane   v1.37.0
b7p9-talos-worker-1         Ready    <none>          v1.37.0   laboratorio

patch mc es un atajo: lee la configuración del nodo, le aplica el parche y la devuelve. Con un fichero completo harías lo mismo con talosctl apply-config --file. Talos 1.14 retiró --mode=reboot de apply-config: la documentación lista qué cambios exigen reinicio, y el resto se aplica en caliente.

Cómo actualizar Kubernetes con talosctl upgrade-k8s

Kubernetes y Talos se actualizan por separado, y upgrade-k8s se encarga de la parte de Kubernetes en todo el clúster con una sola llamada. Envíala a un nodo del panel de control y ensaya antes con --dry-run, que comprueba la compatibilidad y descarga las imágenes sin cambiar nada:

talosctl -n 10.59.0.2 upgrade-k8s --to 1.37.1 --dry-run
talosctl -n 10.59.0.2 upgrade-k8s --to 1.37.1

La ejecución real sigue un orden fijo: kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy y, al final, el kubelet de cada nodo. Este es un extracto de la salida:

automatically detected the lowest Kubernetes version 1.37.0
discovered controlplane nodes ["10.59.0.2"]
discovered worker nodes ["10.59.0.3"]
updating "kube-apiserver" to version "1.37.1"
 > "10.59.0.2": starting update
 > "10.59.0.2": machine configuration patched
 > "10.59.0.2": waiting for kube-apiserver pod update
 < "10.59.0.2": successfully updated
updating kubelet to version "1.37.1"
 < "10.59.0.3": successfully updated
updating manifests
 < configured DaemonSet/kube-system/kube-proxy
waiting for kubernetes objects to be fully reconciled
done

Antes de tocar nada, la orden confirmó que Talos 1.14.2 es compatible con Kubernetes 1.37.1 en ambos nodos. La línea machine configuration patched explica el mecanismo: upgrade-k8s no ejecuta instaladores, cambia la etiqueta de imagen en la configuración de cada nodo y espera, con avisos config version mismatch, a que Talos recree el componente. Mientras tanto, un bucle en el anfitrión pidió la página de nginx sin parar: 196 peticiones, las 196 con código 200. Los dos pods siguieron con 0 reinicios, y al terminar kubectl version informaba Server Version: v1.37.1.

Qué pasa con talosctl upgrade dentro de Docker

La actualización del sistema operativo no se puede probar en Docker, y la documentación lo dice sin rodeos: "Due to the fact that Talos will be running in a container, certain APIs are not available. For example upgrade, reset, and similar APIs don’t apply in container mode". Lo intenté igualmente para ver el error:

$ talosctl -n 10.59.0.3 upgrade --wait=false \
    --image factory.talos.dev/metal-installer/ce4c9805[…]:v1.14.2
10.59.0.3: pulled image factory.talos.dev/metal-installer/[…]
error during upgrade: error from node 10.59.0.3: rpc error:
code = FailedPrecondition desc = method is not supported in
container mode

El nodo descargó la imagen del instalador y se negó a continuar. En hardware real, esa misma orden instala el sistema nuevo junto al anterior y reinicia con kexec. Según la guía de actualización, el esquema A/B conserva el núcleo y la imagen anteriores, y si el arranque nuevo falla Talos vuelve a la versión previa; también puedes forzarlo con talosctl rollback. Eso no lo pude comprobar.

Dos reglas de la guía que conviene tener presentes:

  • Ruta de versiones: la migración solo se prueba entre versiones menores adyacentes, así que de 1.12 a 1.14 pasas por el último parche de 1.13
  • Imagen del instalador: desde 1.14 ya no se publica ghcr.io/siderolabs/installer; usa factory.talos.dev/metal-installer/<id>:v1.14.2 con el identificador del esquema con el que instalaste el nodo, o las extensiones desaparecen

Qué cambia en hardware real o en Proxmox

En máquinas reales, el clúster no se crea con una orden: arrancas Talos desde una ISO, le entregas la configuración y lanzas el bootstrap tú. Esta parte no la ejecuté contra ningún nodo, porque no usé un hipervisor. Sí ejecuté gen config, validate y las llamadas a la Image Factory. El orden de la guía oficial de Proxmox es este:

  1. Genera la imagen en la Image Factory, con las extensiones que necesites
  2. Crea las máquinas virtuales y arráncalas desde la ISO; quedan en modo mantenimiento
  3. Genera controlplane.yaml, worker.yaml y talosconfig con talosctl gen config
  4. Aplica cada fichero con apply-config --insecure; Talos se instala en disco y reinicia
  5. Ejecuta talosctl bootstrap una sola vez, en un solo nodo del panel de control
  6. Descarga el kubeconfig y comprueba la salud del clúster

Cómo generar la imagen con la Image Factory

La Image Factory sustituye al gestor de paquetes: describes las extensiones en un esquema y ella construye la ISO y el instalador. Para Proxmox, la extensión útil es siderolabs/qemu-guest-agent, que permite apagar la máquina virtual desde el hipervisor. Envié este esquema a la API:

cat > schematic.yaml <<'EOF'
customization:
  systemExtensions:
    officialExtensions:
      - siderolabs/qemu-guest-agent
EOF
curl -s -X POST --data-binary @schematic.yaml \
  https://factory.talos.dev/schematics

La respuesta fue el identificador ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515, el mismo que cita la guía de Proxmox, porque el identificador es un hash del contenido del esquema. Con él, la ISO queda en https://factory.talos.dev/image/ce4c9805[…]/v1.14.2/metal-amd64.iso y ocupa 366,3 MB. El catálogo de la versión 1.14.2 tenía 90 extensiones oficiales cuando lo consulté, entre ellas iscsi-tools e intel-ucode.

Qué ajustes pide la máquina virtual en Proxmox

La guía de Talos para Proxmox fija unos valores de partida para cada máquina virtual. Si ya gestionas Proxmox con otra interfaz, como las que repasa la comparativa de PegaProx frente a la interfaz de Proxmox VE 9, los campos son los mismos:

Ajuste Valor recomendado
BIOS y máquina ovmf (UEFI) y q35
Tipo de CPU host, porque Talos exige x86-64-v2
Núcleos y memoria 2 y 4 GB en el panel de control, 4 y 8 GB en los nodos de trabajo
Controlador de disco VirtIO SCSI, nunca VirtIO SCSI Single
Globo de memoria Desactivado
Agente QEMU Solo si la ISO lleva la extensión

El aviso del controlador de disco viene de la incidencia #11173 que enlaza la guía: con VirtIO SCSI Single, el bootstrap se queda colgado. Y activar el agente QEMU en Proxmox sin la extensión solo genera ruido en los registros.

Cómo generar y validar la configuración

talosctl gen config crea las claves del clúster y los tres ficheros. Si el disco de la máquina virtual es /dev/vda y usas la imagen con el agente QEMU, pásalo todo en la misma orden:

ID=ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515
IMG=factory.talos.dev/metal-installer/$ID:v1.14.2
talosctl gen config homelab https://192.168.1.50:6443 \
  --install-disk /dev/vda --install-image "$IMG"
talosctl validate --config controlplane.yaml --mode metal

La dirección 192.168.1.50 es un ejemplo: pon la IP que muestra la consola del nodo del panel de control. Lo que más sorprende al abrir los ficheros es su tamaño: controlplane.yaml tiene 28 documentos y worker.yaml, 14, entre ellos UnattendedInstallConfig, KubeNodeConfig y SecurityProfileConfig.

Esa división rompe los parches de tutoriales anteriores a 1.14. La guía de Proxmox todavía sugiere cambiar install.disk, y un parche con machine.install.disk se fusiona sin quejarse, pero validate lo rechaza:

$ talosctl validate --config cp-old.yaml --mode metal
1 error occurred:
    * UnattendedInstallConfig config is incompatible with v1alpha1
config (.machine.install)

El disco se elige ahora con una expresión CEL dentro de UnattendedInstallConfig, como disk.dev_path == "/dev/vda". Si ya tienes el fichero generado, parchea ese documento en lugar del campo antiguo, y valida siempre antes de aplicar.

Cómo aplicar la configuración y hacer el bootstrap

Con los nodos en modo mantenimiento, la secuencia es la de la guía oficial. --insecure hace falta porque el nodo aún no tiene certificados, y esa API de mantenimiento no pide autenticación, así que no la expongas fuera de tu red:

talosctl apply-config --insecure -n 192.168.1.50 --file controlplane.yaml
talosctl apply-config --insecure -n 192.168.1.51 --file worker.yaml
export TALOSCONFIG=$PWD/talosconfig
talosctl config endpoint 192.168.1.50
talosctl config node 192.168.1.50
talosctl bootstrap
talosctl kubeconfig ./kubeconfig
talosctl health

bootstrap inicializa etcd y solo se ejecuta una vez. En el clúster de Docker comprobé qué ocurre si lo repites: rpc error: code = AlreadyExists desc = etcd data directory is not empty. talosctl kubeconfig con una ruta escribe un fichero aparte en lugar de fusionarlo con tu ~/.kube/config; lo probé en el laboratorio y dejó un kubeconfig de 2270 bytes.

Docker o Proxmox: qué camino elegir para empezar

Los dos caminos enseñan la misma API, pero solo uno prueba el sistema operativo. Esta tabla resume lo que vi en Docker y lo que documenta Sidero Labs para máquinas reales:

Aspecto Docker (cluster create docker) Proxmox o hardware real
Arranque del clúster Una orden, bootstrap incluido ISO, apply-config y bootstrap
Núcleo que ejecuta El del anfitrión El de Talos (Linux 6.18.54)
talosctl upgrade y reset No disponibles Disponibles, con esquema A/B
upgrade-k8s y parches Funcionan Funcionan
Extensiones de sistema No aplican: usa la imagen estándar Vía Image Factory
Uso razonable Aprender, CI, probar manifiestos Homelab o producción

Empieza en Docker para aprender talosctl sin miedo a romper nada, y pasa a Proxmox en cuanto quieras probar actualizaciones del sistema, discos o red. Para un homelab de verdad, tres máquinas virtuales pequeñas en un mismo Proxmox te dan un panel de control y dos nodos de trabajo con los que practicar todo lo anterior.

Preguntas frecuentes

¿Puedo ejecutar cargas en el panel de control de Talos?

Sí. Por defecto el panel de control tiene la marca NoSchedule, y desde 1.14 esa marca aparece de forma explícita en el documento KubeNodeConfig. Para un clúster de un solo nodo, quítala en la configuración con un parche antes de aplicarla.

¿Talos Linux funciona en arm64?

Sí. Todo este laboratorio corrió en arm64 con imágenes multiarquitectura, y la Image Factory ofrece ISO metal-arm64 para la misma versión. En Docker, eso sí, el núcleo es el del anfitrión, así que el soporte de tu placa concreta se comprueba en la propia placa.

¿Cómo borro el clúster de Docker?

Con talosctl cluster destroy --name b7p9-talos, cambiando el nombre por el tuyo, o sin --name si usaste talos-default. Elimina los contenedores y la red; los ficheros talosconfig y kubeconfig que exportaste siguen en tu directorio.

Conclusión

Instalar Talos Linux en Docker lleva una orden. En esa prueba cabe casi todo el día a día: consultar nodos por API, desplegar, parchear la configuración sin reiniciar y actualizar Kubernetes sin cortar el servicio. Lo que Docker no enseña es el propio sistema operativo: su núcleo, la instalación en disco y la actualización A/B.

El siguiente paso es montar tres máquinas virtuales en Proxmox con la ISO de la Image Factory, generar la configuración con gen config y validarla antes de aplicarla. Si aún no tienes claro que Talos sea tu opción, la comparativa de k3s, k0s y Talos resume qué ganas y qué pierdes frente a las otras dos.

Fuentes: [1] Notas de Talos v1.14.2[2], [2] Notas de Talos v1.14.0[3], [3] Talos en Docker, documentación oficial[4], [4] Guía de inicio de Talos[5], [5] Talos en Proxmox[6], [6] Actualizar Talos[7], [7] Actualizar Kubernetes en Talos[8], [8] Referencia de KubeNodeConfig[9], [9] Image Factory de Talos[10], [10] Image Factory, servicio público[11], [11] Pod Security Admission en Kubernetes[1].

Fuentes

  1. documentación de Pod Security Admission
  2. Notas de Talos v1.14.2
  3. Notas de Talos v1.14.0
  4. Talos en Docker, documentación oficial
  5. Guía de inicio de Talos
  6. Talos en Proxmox
  7. Actualizar Talos
  8. Actualizar Kubernetes en Talos
  9. Referencia de KubeNodeConfig
  10. Image Factory de Talos
  11. Image Factory, servicio público