Ya hemos hablado sobre la importancia de la Agregación de Logs en Kubernetes y por qué el cambio en el comportamiento de los componentes lo convierte en un requisito obligatorio para cualquier nueva arquitectura que implementemos hoy.
Para resolver esa parte, tenemos muchas pilas diferentes de las que probablemente hayas oído hablar. Por ejemplo, si seguimos el camino tradicional de Elasticsearch, tendremos la pila ELK pura de Elasticsearch, Logstash y Kibana. Ahora esta pila se ha ampliado con los diferentes «Beats» (FileBeat, NetworkBeat, …) que proporcionan un reenviador de logs ligero para ser añadido a la tarea.
Además, puedes cambiar Logstash por un componente de CNCF como Fluentd del que probablemente hayas oído hablar, y en ese caso, estamos hablando de una pila EFK siguiendo el mismo principio. Y también, tener la vista de Grafana Labs usando promtail, Grafana Loki, y Grafana para paneles de control siguiendo una perspectiva diferente.
Luego puedes cambiar y modificar cualquier componente por el de tu preferencia, pero al final, tendrás tres tipos diferentes de componentes:
- Reenviador: Componente que escuchará todas las entradas de logs, principalmente la salida stdout/stderr de tus contenedores, y lo enviará a un componente central.
- Agregador: Componente que recibirá todos los rastros del reenviador, y tendrá algunas reglas para filtrar algunos de los eventos, formatear y enriquecer los recibidos antes de enviarlos al almacenamiento central.
- Almacenamiento: Componente que recibirá los rastros finales para ser almacenados y recuperados por los diferentes clientes.
Para simplificar la gestión de eso en Kubernetes, tenemos un gran Operador de Kubernetes llamado BanzaiCloud Logging Operator que intenta seguir ese enfoque de manera declarativa / política. Así que veamos cómo funciona, y para explicarlo mejor, usaré su diagrama central de su sitio web:
Este operador utiliza las mismas tecnologías de las que estábamos hablando. Cubre principalmente los dos primeros pasos: Reenvío y Agregación y la configuración para ser enviada a un Almacenamiento Central de tu elección. Para hacer eso, trabaja con las siguientes tecnologías, todas ellas parte del Paisaje CNCF:
- Fluent-bit actuará como un reenviador desplegado en modo DaemonSet para recopilar todos los logs que hayas configurado.
- Fluentd actuará como un agregador definiendo los flujos y reglas de tu elección para adaptar el flujo de rastros que estás recibiendo y enviando a la salida de tu elección.
Y como este es un Operador de Kubernetes, esto funciona de manera declarativa. Definiremos un conjunto de objetos que definirán nuestras políticas de registro. Tenemos los siguientes componentes:
- logging – El recurso de logging define la infraestructura de registro para tu clúster que recopila y transporta tus mensajes de log. También contiene configuraciones para Fluentd y Fluent-bit.
- output / clusteroutput – Define una Salida para un flujo de registro, donde se envían los mensajes de log. output será basado en el espacio de nombres, y clusteroutput será basado en el clúster.
- flow / clusterflow – Define un flujo de registro usando filtros y salidas. El flujo dirige los mensajes de log seleccionados a las salidas especificadas. flow será basado en el espacio de nombres, y clusterflows será basado en el clúster.
En la imagen a continuación, verás cómo estos objetos están «interactuando» para definir tu arquitectura de registro deseada:
Y aparte del modo de política, también incluye muchas características geniales como:
- Aislamiento de espacio de nombres
- Selectores de etiquetas nativos de Kubernetes
- Comunicación segura (TLS)
- Validación de configuración
- Soporte para múltiples flujos (multiplicar logs para diferentes transformaciones)
- Soporte para múltiples salidas (almacenar los mismos logs en múltiples almacenamientos: S3, GCS, ES, Loki, y más…)
- Soporte para múltiples sistemas de registro (múltiples despliegues de Fluentd, Fluent Bit en el mismo clúster)
En próximos artículos hablaremos sobre cómo podemos implementar esto para que puedas ver todos los beneficios que este enfoque basado en CRD y políticas puede proporcionar a tu arquitectura.
📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.
