En el artículo anterior, describimos qué capacidad proporciona BanzaiCloud Logging Operator y sus características principales. Así que hoy vamos a ver cómo podemos implementarlo.
Lo primero que necesitamos hacer es instalar el operador en sí, y para hacerlo, tenemos un chart de helm a nuestra disposición, así que lo único que necesitaremos hacer son los siguientes comandos:
helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com
helm upgrade --install --wait --create-namespace --namespace logging logging-operator banzaicloud-stable/logging-operator
Eso creará un namespace de logging (en caso de que aún no lo tengas), y desplegará los componentes del operador en sí, como puedes ver en la imagen a continuación:
Así que, ahora podemos empezar a crear los recursos que necesitamos usando el CRD que comentamos en el artículo anterior, pero para hacer un resumen. Estos son los que tenemos a nuestra disposición:
- logging – El recurso de logging define la infraestructura de logging para tu clúster que recoge y transporta tus mensajes de log. También contiene configuraciones para Fluentd y Fluent-bit.
- output / clusteroutput – Define una Salida para un flujo de logging, donde se envían los mensajes de log. output será basado en namespace, y clusteroutput será basado en clúster.
- flow / clusterflow – Define un flujo de logging usando filtros y salidas. El flujo dirige los mensajes de log seleccionados a las salidas especificadas. flow será basado en namespace, y clusterflows serán basados en clúster.
Así que, primero que nada, vamos a definir nuestro escenario. No quiero hacer algo complejo; deseo que todos los logs que mis cargas de trabajo generen, sin importar en qué namespace estén, sean enviados a una instancia de Grafana Loki que también he instalado en ese clúster de Kubernetes en un endpoint específico usando la configuración Simple Scalable para Grafana Loki.
Así que, comencemos con los componentes que necesitamos. Primero, necesitamos un objeto de Logging para definir mi infraestructura de Logging, y lo crearé con el siguiente comando.
kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: Logging
metadata:
name: default-logging-simple
spec:
fluentd: {}
fluentbit: {}
controlNamespace: logging
EOF
Mantendremos la configuración predeterminada para fluentd y fluent-bit solo por el bien del ejemplo, y más adelante en próximos artículos, podemos hablar sobre un diseño específico, pero eso es todo.
Una vez que el CRD se procese, los componentes aparecerán en tu namespace de logging. En mi caso, que estoy usando un clúster de 3 nodos, veré 3 instancias de fluent-bit desplegadas como un DaemonSet y un solo ejemplo de fluentd, como puedes ver en la imagen a continuación:
Así que, ahora necesitamos definir la comunicación con Loki, y como me gustaría usar esto para cualquier namespace que pueda tener en mi clúster, usaré la opción ClusterOutput en lugar de la normal Output que está basada en namespace. Y para hacer eso, usaremos el siguiente comando (por favor asegúrate de que el endpoint sea el correcto; en nuestro caso, este es loki-gateway.default ya que está ejecutándose dentro del clúster de Kubernetes:
kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
name: loki-output
spec:
loki:
url: http://loki-gateway.default
configure_kubernetes_labels: true
buffer:
timekey: 1m
timekey_wait: 30s
timekey_use_utc: true
EOF
Y prácticamente tenemos todo; solo necesitamos un flujo para comunicar nuestra configuración de Logging al ClusterOutput que acabamos de crear. Y nuevamente, iremos con el ClusterFlow porque nos gustaría definir esto a nivel de Clúster y no de manera basada en namespace. Así que usaremos el siguiente comando:
kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
name: loki-flow
spec:
filters:
- tag_normaliser: {}
match:
- select: {}
globalOutputRefs:
- loki-output
EOF
Y después de un tiempo para recargar la configuración (1-2 minutos más o menos), comenzarás a ver en los rastros de Loki algo como esto:
Y eso indica que ya estamos recibiendo el envío de logs de los diferentes componentes, principalmente el elemento fluentd que configuramos en este caso. Pero creo que es mejor verlo gráficamente con Grafana:
¡Y eso es todo! Y cambiar nuestra configuración de logging es tan simple como cambiar el componente CRD que definimos, aplicando coincidencias y filtros, o enviándolo a un nuevo lugar. De manera sencilla, tenemos esto completamente gestionado.
📚 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.
