Kubernetes monitoring: EFK operator

Continuando con la serie de artículos centrada en la instalación de las principales herramientas de monitorización en Kubernetes haciendo uso de los operadores, hoy es el turno de EFK, la solución más popular del momento para la centralización de los logs.

En el presente artículo se pretende describir los componentes que conforman el stack EFK así como detallar los pasos a seguir para instalar dicha solución.

Caso de uso

Se dispone de una cluster “vanilla” de Kubernetes, compuesto por un único nodo y con varios microservicios desplegados, en el que se quiere instalar un stack de EFK haciendo uso de los correspondientes operadores.

¿Que es EFK?

Las siglas EFK hace referencia a “Elasticsearch“, “Fluentd” y “Kibana“, tres soluciones open-source que combinadas permiten confeccionar un completo sistema de centralización de logs.

Elasticsearch

Elasticsearch es una base de datos distribuida orientada a documentos que cuenta con un potente motor de búsquedas de cadenas de texto en tiempo real, gracias a la inclusión de Apache Lucene.

Fluentd

Fluentd es un colector de datos open-source para unificar la infraestructura de logging. Básicamente se encarga de recopilar eventos de distintas fuentes de datos y escribirlos después en archivos, RDBMS, NoSQL, IaaS, SaaS o Hadoop, entre otros.

Kibana

Kibana es una herramienta open-source para visualizar y explotar datos almacenados en Elasticsearch. Su potente Web-UI permite crear un sinfín de histogramas, gráficos, o mapas de calor con los que sacar el mayor partido a la información recolectada.

Funcionamiento

El funcionamiento es bien sencillo, Fluentd se encarga de recolectar y procesar los logs de los distintos aplicativos y persistirlos en Elasticsearch. Posteriormente los usuarios pueden explotar esta información haciendo uso de la interfaz proporcionada por Kibana.

Instalación

Elasticsearch

Elasticsearch, al contrario de otros productos descritos anteriormente, dispone de un operador oficial desarrollado por el equipo de Elastic, si bien por el momento no es posible instalarlo haciendo uso de Helm.

Dicho esto, el primer paso será desplegar el operador haciendo uso del ya tradicional kubectl.

kubectl apply -f https://download.elastic.co/downloads/eck/0.9.0/all-in-one.yaml

Con el operador ya desplegado, es el momento de definir la configuración del cluster mediante un CRD de tipo “Elasticsearch”. En el presente ejemplo se definen 3 nodos, dado que es el mínimo establecido por la documentación oficial para la confección de un cluster productivo.

cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1alpha1
kind: Elasticsearch
metadata:
  name: elasticsearch
  namespace: elastic-system
spec:
  version: 7.2.0
  nodes:
  - nodeCount: 3
    config:
      node.master: true
      node.data: true
      node.ingest: true
    volumeClaimTemplates:
      - metadata:
          name: data
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 10Gi
    podTemplate:
      spec:
        containers:
          - name: elasticsearch
            resources:
              limits:
                memory: 3Gi
                cpu: 0.3
              requests:
                memory: 2Gi
                cpu: 0.2
EOF

Es importante aclarar una serie de conceptos antes de continuar.

En primera instancia, toda la configuración del producto que tradicionalmente se ubicaba en el fichero “elasticssearch.yaml”, ahora deberá ser definida en el objeto “Elasticsearch” de Kubernetes, concretamente bajo la rama “config”, es decir, al nivel de “node.master”.

En segundo lugar y dado que XPack, la extensión que provee funciones de seguridad, alertas, monitoring, reporting o machine learning a Elasticsearch es gratuita desde las versiones 6.8.0 y 7.1.0, tanto la comunicación interna entre los nodos como los accesos externos están securizados vía TLS y se requiere de un usuario/password para acceder a ellos.

El usuario por defecto es “elasticsearch”, mientras que la password se encuentra almacenada en un Secret de Kubernetes denominado “elasticsearch-es-elastic-user” en el namespace “elastic-system”.

El siguiente comando permite obtener su valor de forma sencilla:

PASSWORD=$(kubectl -n elastic-system get secret elasticsearch-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode)

Kibana

Una vez instalado Elasticsearch, es hora de proceder con la instalación de Kibana.

Dado que ambos productos comparten el mismo operador, simplemente habrá que crear un CRD de tipo Kibana con la configuración deseada.

cat <<EOF | kubectl apply -f -
apiVersion: kibana.k8s.elastic.co/v1alpha1
kind: Kibana
metadata:
  name: kibana
  namespace: elastic-system
spec:
  version: 7.2.0
  nodeCount: 1
  elasticsearchRef:
    name: elasticsearch
    podTemplate:
      spec:
        containers:
          - name: kibana
            resources:
              limits:
                memory: 0.7Gi
                cpu: 0.3
              requests:
                memory: 0.5Gi
                cpu: 0.2
EOF

Fluentd

Una vez instalado el sistema de persistencia, es hora de proceder con el despliegue de Fluentd haciendo uso del operador logging-operator desarrollado Banzaicloud.

Este operador se encargará de instalar todas las herramientas necesarias para la ingesta de logs.

Por un lado está Fluentbit, el daemonset encargado de recolectar y enriquecer los logs de los contenedores para enviarlos finalmente a Fluentd, el cual realizara los filtrados y transformaciones requeridas para almacenarlos depuse en el sistema de persistencia definido.

La instalación del operador se realizará a través del chart de Helm desarrollado para ello y como siempre es recomendable revisar el fichero values, por si se quisiera modificar alguno de sus valores, pero en principio no es necesario para el caso de uso actual. Es importante saber que en esto punto se instalará únicamente el operador.

helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com
helm repo update
helm install --namespace fluent-system --name logging banzaicloud-stable/logging-operator

Con el operador ya desplegado, es el momento de definir la configuración de instalación de Fluentd y Fluentbit mediante los CRDs correspondientes.

Este proceso se realizará mediante el chart de Helm desarrollado para ello y como siempre es recomendable revisar el fichero values, por si se quisiera modificar alguno de sus valores, pero de nuevo, no es necesario para el caso de uso actual.

helm install -n fluent-system banzaicloud-stable/logging-operator-logging

El siguiente paso es configurar el sistema de persistencia de Fluentd, en este caso, el Elasticsearch instalado anteriormente, mediante un CRD de tipo ClusterOutput.

Dado que no existe un chart de Helm para ello, será necesario hacer uso del ya conocido kubectl. Recordar sustituir la password de Elasticsearch de la configuración adjuntada por la obtenida previamente.

cat <<EOF | kubectl -n logging apply -f -
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
  name: elasticsearch-output
  namespace: fluent-system
spec:
  elasticsearch:
    host: elasticsearch-es.elastic-system.svc
    port: 9200
    scheme: https
    user: elastic
    password: my-password
EOF

Finalmente solo queda definir los contenedores de los que se quiere recolectar logs mediante un CRD de tipo ClusterFlow.

Dado que no existe un chart de Helm para ello, será necesario hacer uso de nuevo del cliente kubectl.

cat <<EOF | kubectl -n logging apply -f -
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
  name: elasticsearch-clusterflow
  namespace: fluent-operator
spec:
  filters:
    - tag_normaliser: {}
  selectors: {}
  outputRefs:
    - elasticsearch-output
EOF

Conclusiones

En conclusión combinando de forma sencilla los operadores de Elasticsearch y Fluend es posible construir un robusto sistema de centralización de logs.

Eso sí, para los entornos productivos se recomienda encarecidamente revisar todas las configuraciones con el objetivo de encontrar aquella que mejor se ajuste al caso de uso.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s