En la lección anterior resolvimos el problema de las cargas con estado: el StatefulSet da a cada réplica su nombre, su disco y su turno. Pero hay una familia de procesos para los que la pregunta "¿cuántas réplicas quiero?" no tiene sentido. Un recolector de logs no necesita tres copias ni diez: necesita exactamente una en cada nodo, porque los ficheros de log que debe leer están en el disco de cada nodo. Si mañana el clúster crece a doce nodos, hacen falta doce copias, sin que nadie tenga que acordarse de editar un replicas.

Ese es el trabajo del DaemonSet: garantizar que hay un pod —uno, exactamente uno— por cada nodo que cumpla unos criterios, y mantener esa invariante cuando se añaden o se quitan nodos.

Es un objeto que, curiosamente, llevas usando desde la primera lección sin haberlo mirado: el kube-proxy que estudiamos en 04-01 y el plugin de red del CNI son DaemonSets. En esta lección los entenderemos por dentro y desplegaremos el primer agente de infraestructura propio de Rutas Norte: un recolector de logs que lee los ficheros de los contenedores de todos los nodos.

1. Una carga de trabajo por nodo: qué es y qué la distingue
2. Los cuatro casos de uso canónicos
3. Anatomía del manifiesto: por qué no hay replicas
4. Dónde corre: nodeSelector, affinity y tolerations
5. Acceso privilegiado: hostPath, hostNetwork, hostPID y su coste
6. Estrategias de actualización
7. Práctica: recolector de logs para Rutas Norte
8. Comprobación: qué pasa al añadir un nodo
9. Recursos: por qué un DaemonSet mal dimensionado es caro

Un DaemonSet parece un Deployment en el que alguien hubiera puesto replicas igual al número de nodos. La diferencia es sustancial, y está en quién decide dónde va cada pod.

Con un Deployment, el kube-scheduler reparte las réplicas según recursos disponibles, afinidad y equilibrio. Nada garantiza que haya una por nodo: podrían caer tres en el mismo nodo si tiene sitio. Con un DaemonSet, el controlador crea un pod con el nodo ya asignado, uno por cada nodo elegible, y vigila permanentemente esa correspondencia.

La consecuencia práctica más importante es la elasticidad automática frente al clúster. Si activas el autoescalado de nodos (que veremos en 09-03) y el clúster pasa de 3 a 20 nodos en un pico de un puente festivo, los 17 nodos nuevos reciben su recolector de logs y su agente de métricas sin intervención humana. Esa propiedad es la razón de ser del objeto.

Prácticamente todo lo que se despliega como DaemonSet cae en una de estas cuatro categorías. La regla que las une: el pod necesita algo que solo existe en el nodo donde corre.

Fluent Bit, Fluentd, Vector, Promtail. Leen los ficheros de /var/log/containers/ del nodo —donde el runtime de contenedores escribe la salida estándar de todos los pods de ese nodo—, los enriquecen con metadatos de Kubernetes y los envían a un backend central.

No podrían ser un Deployment: un pod solo puede leer los ficheros del nodo en el que está. Para leer los logs de todos los nodos hace falta un pod en cada nodo.

Node Exporter de Prometheus, agentes de Datadog o New Relic. Leen /proc y /sys del nodo para exponer CPU, memoria, disco, red y temperatura del hardware. También aquí, la información es estrictamente local al nodo.

El metrics-server que activamos como addon de minikube en 01-04 es un caso distinto: no es un DaemonSet, sino un Deployment que consulta la API de cada kubelet. Lo veremos en 07-02.

Calico, Cilium, Flannel, Weave. En 04-01 dijimos que "el CNI programa las rutas del nodo". Quien lo hace es un pod de un DaemonSet que escribe configuración en /etc/cni/net.d, instala binarios en /opt/cni/bin y manipula las tablas de rutas y las reglas de iptables/eBPF del nodo.

Ahí está: kube-proxy, el componente que estudiamos en 04-01 y que traduce los Services a reglas de red, es un DaemonSet. Tiene todo el sentido: cada nodo necesita su propio conjunto de reglas.

Los drivers CSI que vimos en 05-05 se despliegan en dos piezas: un controlador (Deployment o StatefulSet, uno por clúster, que habla con la API del proveedor para crear volúmenes) y un node plugin (DaemonSet, que monta y desmonta los volúmenes en el sistema de ficheros del nodo). El montaje solo puede hacerlo alguien que esté en ese nodo.

Un DaemonSet mínimo:

Comparado con un Deployment falta una sola cosa: spec.replicas. Y su ausencia no es un olvido de la API, es la definición del objeto. El número de pods no es un valor que tú declares, es una consecuencia del estado del clúster: tantos como nodos elegibles haya. Si intentas añadirlo, la API lo rechaza:

Por lo demás, selector y template funcionan igual que en Deployments y StatefulSets, y spec.selector es inmutable igual que allí. La template sigue las mismas convenciones de Rutas Norte: solo app y entorno en el selector, app.kubernetes.io/part-of como etiqueta informativa.

El estado se lee de una forma característica:

Si DESIRED es menor de lo que esperas, el problema está en el apartado siguiente: hay nodos que el DaemonSet no considera elegibles.

Por defecto, "un pod por nodo" significa todos los nodos. Hay tres mecanismos para restringir o ampliar ese conjunto.

Solo se crean pods en nodos que tengan esa etiqueta. Es lo que hace kube-proxy en la salida de antes: en un clúster mixto con nodos Windows, el binario de Linux no serviría.

Un caso propio de Rutas Norte: si en producción hay un grupo de nodos con SSD etiquetado disco: ssd, un agente que solo interese ahí se restringe así:

Cuando el filtro no es una igualdad simple, se usa afinidad de nodo. Aquí solo lo justo para que funcione; el mecanismo completo, con sus operadores y sus variantes preferidas, es la lección 06-05.

Este ejemplo excluye del recolector los nodos dedicados a analítica.

Este es el mecanismo clave de los DaemonSets y merece detenerse.

Algunos nodos llevan un taint, una marca que dice "no coloques pods aquí salvo que estén expresamente autorizados". El caso más habitual es el plano de control, que en un clúster estándar viene con:

Ese taint impide que las aplicaciones normales acaben compitiendo por CPU con el apiserver y etcd. Pero un recolector de logs sí debe correr ahí: los logs del apiserver son justo los que más falta hacen en una incidencia.

La forma de decir "yo sí puedo" es una toleration:

Léase: "tolero el taint cuya clave existe con ese efecto". No es una preferencia por ir al plano de control; es un permiso para no ser rechazado si el DaemonSet me lleva ahí.

Los agentes de infraestructura que deben correr absolutamente en todos los nodos, pasase lo que pasase usan una toleration universal:

Es lo que hace el CNI: si el plugin de red no corre en un nodo, ese nodo no tiene red, así que ninguna condición debe impedírselo. Úsala con criterio: para tu recolector de logs es probablemente excesiva, porque también lo colocaría en nodos marcados como no listos o bajo presión de memoria.

Hay además una cortesía que Kubernetes concede automáticamente a los DaemonSets: el controlador añade por su cuenta tolerations a ciertos taints del sistema (node.kubernetes.io/not-ready, unreachable, disk-pressure, memory-pressure, pid-pressure, unschedulable) para que los agentes no sean desalojados justo cuando el nodo tiene problemas y más falta hace la telemetría. Puedes verlo si inspeccionas un pod de DaemonSet:

La mecánica completa de taints, efectos y tolerationSeconds es el contenido de 06-05.

Los agentes de nodo necesitan ver cosas que un pod normal no ve. Kubernetes lo permite, y cada permiso amplía la superficie de ataque de forma que conviene entender antes de escribirla en un manifiesto.

Monta un directorio del sistema de ficheros del nodo dentro del contenedor. Lo vimos en 05-01 como volumen efímero peligroso; aquí es imprescindible.

Detalle técnico que sorprende a mucha gente: los ficheros de /var/log/containers son enlaces simbólicos a /var/log/pods, que a su vez suelen apuntar al directorio de datos del runtime (/var/lib/docker/containers o el equivalente de containerd). Si solo montas el primero, el contenedor ve enlaces rotos. Por eso los recolectores montan los dos o tres directorios.

Riesgo: un hostPath con permiso de escritura sobre un directorio sensible del nodo (/etc, /var/lib/kubelet, el socket del runtime) equivale a control del nodo. Monta siempre en solo lectura (readOnly: true) lo que solo necesitas leer.

El pod comparte la pila de red del nodo: sus puertos son puertos del nodo y ve las interfaces reales. Es obligatorio para los plugins CNI y para agentes que capturan tráfico. Nótese el dnsPolicy: sin él, un pod con hostNetwork usaría el DNS del nodo y perdería la resolución de nombres de Kubernetes que estudiamos en 04-03.

Riesgo: se salta el aislamiento de red, y con él las NetworkPolicies de 04-06, que operan sobre las IP de pod. Un pod con hostNetwork en rutas-norte-pro no está sujeto al deny-all.

El contenedor ve todos los procesos del nodo. Necesario para agentes de perfilado o de seguridad que inspeccionan procesos.

Riesgo: alto. Ver el árbol de procesos del host permite leer líneas de comando (que a veces contienen credenciales) y, combinado con privilegios, entrar en el espacio de nombres de otros contenedores.

La regla de oro: cada uno de estos campos convierte a tu DaemonSet en parte del plano de confianza del clúster. Un atacante que comprometa la imagen de tu recolector de logs con hostPath de escritura tiene los mismos poderes que si comprometiera el kubelet. Y como corre en todos los nodos, el compromiso es total, no parcial. En 08-02 endureceremos estos contenedores con securityContext, capacidades y sistemas de ficheros de solo lectura.

Igual que los otros controladores, el DaemonSet define cómo propaga un cambio de plantilla.

Actualiza nodo a nodo. maxUnavailable limita cuántos pods pueden estar simultáneamente no disponibles; con 1 en un clúster de 3 nodos, la actualización tarda tres pasos pero nunca deja más de un nodo sin agente.

maxSurge (estable desde 1.25) permite lo contrario: crear el pod nuevo antes de quitar el viejo, para no dejar ningún hueco de cobertura. Como en un nodo caben los dos temporalmente, exige que ambos puedan coexistir: si el agente usa hostNetwork con un puerto fijo, maxSurge: 1 provoca conflicto de puertos. Reglas:

No pueden ser ambos cero, y no pueden ser ambos distintos de cero.

Los pods se actualizan solo cuando los borras a mano o cuando el nodo se recrea. Es lo habitual para plugins CNI: actualizar la red de un nodo en producción es una operación que se quiere hacer con supervisión, nodo a nodo y con un plan de vuelta atrás.

El historial y la vuelta atrás funcionan como en los Deployments de 02-04:

Vamos a desplegar un agente que lea los logs de los contenedores de todos los nodos y —de momento— los muestre por su propia salida estándar. La pila completa de registro centralizado (Elasticsearch, Fluentd, Kibana) se monta en 07-05; aquí el objetivo es el DaemonSet, no el destino de los datos.

Usamos Fluent Bit, ligero y estándar en la industria.

Qué hace cada bloque:

• [INPUT] tail sigue los ficheros de /var/log/containers/ cuyo nombre contenga rutas-norte-pro. El nombre de esos ficheros tiene la forma <pod>_<namespace>_<contenedor>-<id>.log, así que ese patrón filtra por namespace. DB guarda la posición leída de cada fichero para no reenviar todo tras un reinicio del agente: es un fichero de estado, y por eso lo colocaremos en un hostPath.
• [FILTER] kubernetes consulta la API para añadir a cada línea el pod, el namespace, las etiquetas y el nodo. Esto es lo que permitirá filtrar por app: api-reservas en 07-05, y requiere permisos de lectura sobre pods.
• [OUTPUT] stdout vuelca a la salida estándar del propio agente. En 07-05 se sustituirá por un output hacia Elasticsearch.

El filtro de Kubernetes necesita leer pods y namespaces del clúster entero. Siguiendo la práctica de 03-06, una ServiceAccount dedicada:

Solo verbos de lectura y solo sobre dos recursos: el mínimo necesario. El detalle de RBAC —qué es un ClusterRole, cómo se acota, cómo se audita— es la lección 08-01; aquí lo damos hecho para que el ejemplo funcione.

Fíjate en que este pod sí necesita montar su token de ServiceAccount, al contrario que casi todos los componentes de Rutas Norte.

Decisiones que merece la pena explicar:

• priorityClassName: system-node-critical: si el nodo se queda sin memoria, este pod no debe ser el primero en caer. La mecánica de prioridades y desalojo es contenido de 06-05.
• Las tolerations: solo la del plano de control. No usamos operator: Exists sin clave porque no queremos que el recolector se coloque en los nodos de analítica que taintaremos en 06-05.
• readOnly: true en los dos hostPath de logs: el agente lee, no escribe. El único con escritura es el directorio de estado, y apunta a una ruta propia bajo /var/lib/rutasnorte, no a un directorio del sistema.
• readOnlyRootFilesystem: true con las capacidades a cero: endurecimiento básico que ampliaremos en 08-02.
• La variable NODO viene de la Downward API de 03-03 y sirve para que el propio agente sepa dónde está sin consultar nada.

Un pod por nodo, y la columna NODE lo confirma: no hay dos en el mismo sitio.

Ahí está el resultado: una línea de log de api-reservas enriquecida con el pod, el namespace, las etiquetas y el nodo. Ese enriquecimiento es lo que hará posible en 07-05 buscar "todos los errores de api-reservas en producción de las últimas dos horas".

La propiedad central del DaemonSet se demuestra en treinta segundos con minikube:

Nadie ha tocado el manifiesto. El controlador de DaemonSet vigila los nodos, ha visto uno nuevo elegible y ha creado su pod. Es exactamente el mismo bucle de reconciliación que describimos en 01-02, aplicado a la relación "un pod por nodo".

Al revés funciona igual:

DESIRED ha vuelto a 3 por sí solo. Nótese la diferencia con un Deployment: cuando desaparece un nodo, el Deployment recoloca sus réplicas en los demás nodos para mantener el número; el DaemonSet no recoloca nada, porque el pod tenía sentido únicamente en ese nodo.

Aquí está la consecuencia económica que se olvida con más frecuencia.

Cuando pides 200 MiB a un Deployment de tres réplicas, pides 600 MiB. Cuando pides 200 MiB a un DaemonSet, pides 200 MiB × número de nodos, y ese número crece con el clúster.

Un ejemplo con números realistas de un clúster de 50 nodos y cuatro DaemonSets habituales:

Diez CPU y diecisiete gigas reservados antes de desplegar una sola línea de código de Rutas Norte. Y son requests: capacidad apartada por el scheduler, esté usándose o no, que reduce lo que queda para api-reservas y tienda-web.

Peor aún si te equivocas por exceso. Poner requests.memory: 512Mi en un recolector que consume 60 MiB "por si acaso" desperdicia 22 GiB en ese clúster: más de un nodo entero pagado para nada.

Consejos concretos:

• Mide antes de fijar. Despliega con requests bajos en rutas-norte-dev, observa con kubectl top pod (07-02) durante unos días de tráfico real y ajusta.
• Pon límites de memoria siempre. Un recolector con una fuga o con un pico de logs puede consumir toda la memoria del nodo y provocar desalojos de las aplicaciones. Mem_Buf_Limit en la configuración de Fluent Bit es la primera línea de defensa; el limits.memory del contenedor es la segunda.
• Cuidado con los límites de CPU. Un recolector estrangulado por CPU acumula retraso y pierde líneas cuando el nodo está más cargado, que es justo cuando más falta hacen los logs. Un límite generoso o ninguno es defendible aquí.
• Revisa las cuotas. Los ResourceQuota por namespace de 03-04 se aplican también a los pods del DaemonSet. Si el quota de rutas-norte-pro se agota, los pods del DaemonSet en nodos nuevos no se crearán, y lo descubrirás cuando falten logs.
• Pregúntate si de verdad hace falta uno por nodo. Es el consejo más rentable. Un agente que consulta la API de Kubernetes no necesita estar en cada nodo: le basta un Deployment de una réplica.

Intentar poner replicas en el manifiesto. La API lo rechaza. Si vienes de Deployments es el primer tropiezo, y es sano: te obliga a interiorizar que el número de pods lo dicta el clúster.

No poner tolerations y perder los nodos del plano de control. El síntoma es sutil: el DaemonSet aparece 3/3 y todo parece bien, pero faltan los logs del apiserver. Compara siempre DESIRED con kubectl get nodes | wc -l.

Montar solo /var/log/containers. Como son enlaces simbólicos a /var/log/pods, el agente ve nombres pero no contenido, y falla con errores de fichero no encontrado que despistan mucho. Monta ambos.

hostPath con type incorrecto. Con type: Directory, si la ruta no existe en el nodo el pod se queda en ContainerCreating con un evento MountVolume.SetUp failed. Para directorios de estado propios usa DirectoryOrCreate.

Olvidar dnsPolicy: ClusterFirstWithHostNet con hostNetwork: true. El pod hereda el /etc/resolv.conf del nodo, deja de resolver nombres de Services y falla al hablar con cualquier componente interno. Es un error que cuesta horas de diagnóstico.

maxSurge: 1 con hostNetwork y puerto fijo. El pod nuevo no puede arrancar porque el viejo tiene el puerto ocupado, y la actualización se queda bloqueada. Con hostNetwork usa siempre maxSurge: 0.

Creer que un DaemonSet garantiza cobertura durante la actualización. Con maxUnavailable: 1 y maxSurge: 0 hay siempre un nodo sin agente durante unos segundos. Para logs de auditoría eso puede ser inaceptable: usa maxUnavailable: 0 y maxSurge: 1 si el agente lo permite.

Consejo: kubectl get pods -o wide es tu verificación. La columna NODE es la única forma directa de confirmar la invariante "uno por nodo". Añade --sort-by=.spec.nodeName para leerlo cómodo.

Consejo: un DaemonSet es un vector de ataque de alcance total. Corre en todos los nodos, suele tener hostPath y a veces hostNetwork. Fija la imagen por etiqueta inmutable —mejor aún, por digest—, revisa qué RBAC pide y aplica el endurecimiento de 08-02 y el escaneo de imágenes de 08-05.

En rutas-norte-dev de tu minikube (perfil rutas-norte, al menos dos nodos), despliega un DaemonSet llamado sonda-nodos con busybox:1.36 que cada 30 segundos escriba en su salida estándar el nombre del nodo (obtenido por Downward API) y el espacio libre de / del nodo, leyendo /host-raiz montado en solo lectura desde hostPath: /.

Verifica que hay un pod por nodo y consulta la salida.

Comprueba si el pod de sonda-nodos se ha creado en el nodo del plano de control. Si no, averigua por qué e incorpora la toleration necesaria. Verifica que DESIRED aumenta.

Cambia la imagen de sonda-nodos a busybox:1.37 con una estrategia que no deje ningún nodo sin agente en ningún momento. Comprueba el comportamiento observando los pods durante la actualización y explica qué diferencia habrías visto con la estrategia por defecto.

Solución 1

Los recursos son mínimos a propósito: es un DaemonSet y todo lo que pida se multiplica por el número de nodos.

Solución 2

Tres nodos pero DESIRED es 2: falta el plano de control. La causa:

(En un minikube de un solo nodo este taint no está puesto, precisamente para que se puedan desplegar aplicaciones; en un clúster multinodo o real sí aparece.)

La solución es tolerar ese taint:

Obsérvese que la toleration no atrae al pod hacia el plano de control: simplemente deja de excluirlo. Quien lo coloca ahí es la lógica de "uno por nodo" del DaemonSet.

Solución 3

Para no dejar huecos hay que crear antes de destruir, es decir maxUnavailable: 0 y maxSurge: 1. Es viable porque sonda-nodos no usa hostNetwork ni puertos de host, así que dos pods pueden coexistir un instante en el mismo nodo.

Durante la actualización se observa este patrón en cada nodo:

El pod nuevo llega a Running antes de que el viejo empiece a terminar: en ningún momento el nodo m02 se queda sin agente.

Con la estrategia por defecto (maxUnavailable: 1, maxSurge: 0) el orden sería el inverso: primero Terminating el viejo, después la descarga de la imagen nueva y el arranque. Entre ambos momentos —que con una imagen no cacheada pueden ser decenas de segundos— ese nodo no tiene recolector y sus logs se pierden.

El DaemonSet es el controlador de las cargas de trabajo que pertenecen al nodo, no a la aplicación. Se distingue de un Deployment en que no tiene replicas: el número de pods es una consecuencia de cuántos nodos elegibles hay, y se ajusta solo cuando el clúster crece o mengua. Los cuatro usos canónicos —logs, métricas, plugins CNI y node plugins CSI— comparten un rasgo: necesitan algo que solo existe en el nodo donde corren, y por eso kube-proxy y el propio CNI de tu clúster son DaemonSets.

Hemos visto cómo se acota su alcance con nodeSelector y affinity, y sobre todo cómo se amplía con tolerations para llegar a los nodos del plano de control. Hemos revisado el precio de los permisos privilegiados que estos agentes suelen pedir (hostPath, hostNetwork, hostPID), que convierten al DaemonSet en parte del plano de confianza del clúster. Hemos desplegado el recolector de logs de Rutas Norte —cuyo destino final montaremos en 07-05—, comprobado que un nodo nuevo recibe su pod sin intervención, y calculado por qué unos requests mal ajustados se multiplican por el número de nodos hasta costar servidores enteros.

Nos queda una familia entera de cargas de trabajo por cubrir. Deployments, StatefulSets y DaemonSets tienen algo en común: sus pods están pensados para correr indefinidamente, y si un contenedor termina, el sistema lo considera un fallo y lo reinicia. Pero hay trabajo que consiste precisamente en terminar: generar un informe, migrar un esquema, procesar un lote. Para eso Kubernetes tiene otros dos objetos, y con ellos desplegaremos por fin el componente que falta en Rutas Norte, informes-ocupacion. Es el tema de la siguiente lección: Trabajos y CronJobs.