Procesos en segundo plano en todos los nodos de Kubernetes con DaemonSet
Cuando te hablé de los Deplwoyments y ReplicaSets hablábamos de aplicaciones que tienen un número de réplicas determinadas y es el clúster el que decide en qué nodos va a desplegarlas, con el fin de tener alta disponibilidad del aplicativo. Sin embargo, existen otro tipo de aplicaciones las cuales necesitamos que estén presentes en todos los nodos que componen nuestro Kubernetes. Para ello, hay un recurso especial llamado DaemonSet, que suele utilizarse para escenarios típicos de monitorización, recolección de logs, etcétera. Además, como su propio nombre indica, suelen ser aplicaciones que trabajan en segundo plano. En este artículo te cuento cómo funcionan.
Cómo funciona un DaemonSet
Lo primero que creo que es interesante saber es cómo consultar los DaemonSets que tienes en tu clúster. Para ello, puedes utilizar uno de estos dos comandos:
Si estás trabajando con Azure Kubernetes Services, un buen ejemplo es el servicio omsagent, el cual se utiliza para enviar métricas a Azure Monitor, (puedes habilitarlo siguiendo este artículo). Este DaemonSet es el que gestiona el número de réplicas que debe haber, por lo que si consultas todos los pods que hay en tu clúster, dependiendo de cuántos nodos tengas, tendrás tantas réplicas de omsagent como nodos:
kubectl get pods –all-namespaces -o wide
En la imagen anterior verás que sólo tengo un agente ejecutándose. Esto es así porque sólo tengo un nodo en mi clúster. Sin embargo, si escalo hasta tres nodos:
Verás que ahora el número de pods asciende a tres de manera automática:
Ahora mi DaemonSet omsagent tiene como DESIRED el número de nodos actual.
kubectl get ds –all-namespaces
Es típico que este tipo de servicios necesiten acceder de alguna forma al host que lo ejecuta. Puedes revisar el YAML de este agente a través del siguiente comando:
No lo incluyo como parte del artículo ya que es bastante extenso, pero si le echas un vistazo podrás comprobar que la clave en este tipo de servicios es mapear diferentes rutas del nodo dentro del contenedor, utilizando el tipo de volumen hostPath, con el fin de enviar lo recolectado, en este caso a Azure Monitor:
Volumenes mapeados con rutas del host
Este es solo un ejemplo para que entiendas cómo funcionan. Otros agentes en forma de DaemonSet bastante frecuentes son para fluentd, filebeat, new relic, entre otros.
¡Saludos!