Autoescalar tus aplicaciones en Kubernetes con KEDA
En los últimos artículos que he escrito sobre Kubernetes me estoy centrando en todo lo que tiene que ver con la monitorización, tanto con Prometheus como con Azure Monitor por ahora, y el autoescalado. Hoy quiero hablarte de KEDA, otra forma de autoescalar tus aplicaciones en base a eventos externos.
¿Qué es KEDA?
KEDA son las siglas de Kubernetes-based Event Driven Autoscaling. Se trata de un componente que puedes desplegar en tu clúster de Kubernetes, esté donde esté, y que te ayuda a autoescalar tus aplicaciones en base a diferentes eventos, utilizando lo que llama scalers. Estos pueden ser mensajes en colas de mensajería de diferentes plataformas (Apache Kafka, AWS SQS Queue, RabbitMQ Queue, Azure Event Hubs, etc), bases de datos (MySQL, PostgreSQL) o incluso servidores de métricas como Prometheus, AWS Cloudwatch o Azure Monitor. La lista va creciendo cada vez más y más.
Una vez decidido cuál será el evento que hará escalar tu aplicación, se crea un recurso llamado ScaledObject con el scaler oportuno y KEDA, por debajo, crea un HorizontalPodAutoscaler por nosotros y lo asocia a dicho recurso para saber cuándo tiene que subir o bajar el número de réplicas de nuestro Deployment o Job.
Arquitectura de KEDA
Instalar KEDA en tu clúster
Antes de comenzar a utilizar KEDA necesitas desplegarlo en tu Kubernetes. La forma más sencilla es a través de Helm:
En este ejemplo estoy utilizando Helm 3 en Mac. Si no lo tienes instalado puedes hacerlo a través de Homebrew con la primera línea del código anterior. Añade el repo de KEDA y asigna a kubectl las credenciales del clúster donde quieres desplegarlo. Crea un namespace llamado keda y en él instala los componentes a través del chart kedacore/keda. Si todo ha salido bien deberías de ver dos pods dentro de ese namespace:
Como puedes ver es un Nginx básico con una sola réplica. Al desplegarlo deberías de ver algo como lo siguiente:
Lo último que te queda por definir es en base a qué escalamos esta aplicación.
Crear un ScaledObject para tu despliegue
Como te decía al principio de este artículo, existen diferentes scalers sobre los que puedes basar el autoescalado. Para este ejemplo voy a utilizar el tipo Azure Storage Queue. Por ello, antes que nada, necesito crear una cola de mensajería en Azure Storage, que llamaré tasks.
Además, como puedes ver en el código anterior, lo último que hago es crear un secreto que guardará la cadena de conexión de la cuenta de almacenamiento donde está mi cola. Por último, creo el recurso ScaledObject que indicara los umbrales asociados a la misma:
Para poder asociar la cadena de conexión al ScaledObject necesito hacer uso de otro recurso llamado TriggerAuthentication, al que a su vez asocio al secreto creado anteriormente, aunque existen otras formas de autenticación.
Una vez que apliques los cambios ocurrirán dos cosas: por un lado se creará un recurso del tipo ScaledObject con el trigger azure-queue:
Y por otro un HPA asociado a dicho objecto:
Probar el autoescalado con KEDA
Para comprobar que todo funciona correctamente, con Azure CLI puedes generar varios mensajes de una forma sencilla:
Si vigilas el HPA asociado comprobarás que poco a poco va subiendo en replicas:
Para comprobar el efecto contrario, elimina los mensajes de la cola con el comando clear:
Verás que a los pocos minutos volverás a tener cero réplicas de tu aplicación:
.png)