En colaboración con: Fabio Moreno

Saludos amigos Kubernetes aficionados, este artículo se basa en  el capitulo #46 de la serie La Hora de Kubernetes, donde aprenderemos cómo ejecutar los Horizontal Pod Autoscalers utilizando la herramienta Prometheus y otras métricas personalizadas.

Introducción

Los Horizontal Pod Autoscalers (HPA) hacen parte de una de las dos capas de escalabilidad de kubernetes. Estos escalan el número de réplicas de pods. La mayoría de DevOps utilizan CPU y memoria como los propulsores para escalar pods basados en métricas genéricas, múltiples o incluso externas. De esta forma, nos ayudan a permitir la alta disponibilidad de nuestras aplicaciones y a optimizar los recursos del clúster.

Por otro lado tenemos Prometheus, que es una herramienta de monitoreo de código abierto utilizada para supervisar servidores, máquinas virtuales, bases de datos y aprovechar esos datos para analizar el rendimiento de sus aplicaciones e infraestructura. 

A continuación, describiremos estos conceptos para brindar un mayor entendimiento de cómo se aplican los Horizontal Pod Autoscalers utilizando la herramienta Prometheus.

¿Qué es un Autoscaler y qué ventajas tiene?

Vamos a dar una breve explicación sobre qué son Autoscalers con un caso que tomaremos de ejemplo: 

Tenemos un servicios de Kubernetes con dos réplicas y cada una de ellas tiene la capacidad de sostener un máximo de 600 demandas por segundo. El servicio distribuye esta carga de peticiones o demandas a través de sus réplicas, así que en total puede sostener 1200 demandas por segundo.

En un primer caso, tenemos 1000 demandas por segundo, podríamos distribuir nuestras réplicas y tendríamos que por cada una hay 500 demandas por segundo. Habíamos mencionado que cada una de nuestra réplicas soporta hasta 600 demandas por segundo, lo que significa que no habrá ningún problema en sostener esta carga de demandas. 

Ahora, supongamos un segundo caso en donde ocurre que tenemos una carga de 1500 demandas por segundo. Si dividiéramos estas demandas, tendríamos 750 por segundo. Nuestras réplicas no tienen la capacidad suficiente para sostener esta carga, lo que supondrá para el usuario experimentar retrasos importantes en la aplicación. 

El método tradicional implica un recorrido que comienza por una alerta notificando este fallo, la intervención de una persona, un análisis del problema y escalar el número de réplicas. Aunque este operador esté disponible a toda hora, el análisis no es puntual, sino más bien general.

Conociendo este contexto y su solución tradicional, ¿cómo nos ayudaría el Autoscaling?

El Autoscaling analiza el nivel de uso, calcula los requerimientos de escalabilidad adicionales basados en el código y finalmente escala el número de réplicas para poder sostener esa carga adicional. Este proceso es casi instantáneo, lo que permite una experiencia más agradable y sin retrasos importantes.

Como la capacidad límite de los servicios tienden a ser codificados y no documentados, estos no presentarán retrasos ya que son revisados con regularidad. Al ser codificados, también significa que las respuestas ante los fallos se ejecutarán de forma automática. Aún mejor, el Autoscaling presta atención a una sola tarea en específico. Como beneficio adicional, el Autoscaling reduce los costos de infraestructura debido a la baja sobrecarga operativa de todo el proceso de monitoreo y toma de decisiones.

¿Cómo funciona el Horizontal Pod Autoscaling (HPA)? 

Como primera instancia, el HPA intenta elevar el número de pods si alcanza el umbral especificado; posteriormente, actualiza el número de réplicas dentro del despliegue o control de réplicas y luego este escalará el número de pods de acuerdo a lo necesitado. 

Escalar es la operación de tiempo más sensible, puesto que desearás que tus pods y clúster escalen rápidamente antes de que tus usuarios experimenten alguna ruptura o daño en la aplicación. Así que deberías considerar el tiempo promedio que le pueden tomar a tus pods y clúster para escalar.

¿Qué es la herramienta Prometheus y para qué sirve?

Prometheus es una herramienta independiente de monitoreo de código abierto. Esta herramienta monitorea y colecciona todas las métricas que están expuestas a través del kube-metrics. Podemos también agregar métricas que estén dentro de nuestras aplicaciones desplegadas. 

Sus características principales abarcan el ser un modelo multi-dimensional con datos de series de tiempo identificados por el nombre de las métricas y los pares key/value; emplear un lenguaje de consulta PromQL, de carácter flexible que va bien para aprovechar esta dimensionalidad; no depende del almacenamiento distribuido, esto quiere decir que los nodos de un solo servidor son autónomos; la recopilación de series de tiempo ocurre a través de un modelo de extracción sobre HTTP; múltiples modos de soporte de gráficos y tableros.

Arquitectura de Prometheus

Prometheus extrae métricas de trabajos instrumentados, almacena todas las muestras extraídas localmente y ejecuta reglas sobre estos datos para agregar y registrar nuevas series de tiempo a partir de datos existentes o generar alertas.

Ventajas de utilizar la herramienta Prometheus

Se pueden agregar métricas que exportan otros componentes. También, Prometheus trabaja bien a la hora de registrar cualquier serie de tiempo puramente numérica. Su fortaleza principal es su colección de datos multi-dimensional. Este sistema será utilizado para diagnosticar problemas de forma automática y cada servidor de Prometheus es único, que no depende de un almacenamiento de red u otros servicios remotos.

Desventajas que enfrenta la herramienta Prometheus

Prometheus no es fuerte en la precisión de las estadísticas que no son bien detalladas o lo suficientemente completas, tales como facturaciones por solicitud. 

Prometheus-adapter solo funciona con Prometheus, mientras que, en una comparación realizada y adjunta en el apartado de Demo en este artículo, hacemos la comparación con kube-metrics-adapter, que sí nos permite consumir estas métricas a través e Prometheus, Pod Collector e InfluxDB y otros tipos de métrica consumiendo directamente de la aplicación.

Demo

En el siguiente vídeo tenemos preparado los conceptos y el demo de despliegue que te permitirá conocer aún más sobre Horizontal Pod Autoscalers Usando Prometheus y métricas personalizadas.

Conclusiones

Utilizamos la herramienta Prometheus para autoescalar despliegues basados en algunas métricas predefinidas, así mismo, lo hemos hecho con otras métricas más personalizadas.

Para poder monitorear estas métricas a través de Los HPA, necesitaremos un adaptador que se encargue de utilizar las métricas coleccionadas por la herramienta Prometheus y convertirlo a un tipo de métrica para así poder calcular si aumentar o disminuir el número de instancias de acuerdo a los requerimientos.

Recordemos que Prometheus lleva una configuración de dificultad alta y una definición de métrica genérica, además de que la fuente de datos que utiliza para la métrica solo debe ser Prometheus, en comparación con el adaptador de Kube-metrics que ofrece una configuración baja, una definición de la métrica personalizada y puede utilizar varias fuentes de datos para las métricas tales como Prometheus, Pod Collector, InfluxDB, entre otros.

Si deseas sumergirte en el tema y obtener más información, te puedes dirigir a nuestro Canal Cuemby en Youtube, nuestra comunidad está creciendo y nuestro equipo está dispuesto a ayudarte. ¡No dudes en enviarnos un mensaje en cualquier momento con tus preguntas y nos aseguraremos de responder!