KEDA proporciona un entorno rico para escalar su aplicación aparte del enfoque tradicional de HPA usando CPU y Memoria
El escalado automático es una de las grandes ventajas de los entornos nativos de la nube y nos ayuda a proporcionar un uso optimizado de las operaciones. Kubernetes ofrece muchas opciones para hacerlo, siendo una de ellas el enfoque del Escalador Automático de Pods Horizontal (HPA).
HPA es la forma en que Kubernetes detecta si es necesario escalar alguno de los pods, y se basa en métricas como el uso de CPU o memoria.
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
A veces esas métricas no son suficientes para decidir si el número de réplicas que tenemos disponibles es suficiente. Otras métricas pueden proporcionar una mejor perspectiva, como el número de solicitudes o el número de eventos pendientes.
Escalado Automático Basado en Eventos de Kubernetes (KEDA)
Aquí es donde KEDA viene a ayudar. KEDA significa Escalado Automático Basado en Eventos de Kubernetes y proporciona un enfoque más flexible para escalar nuestros pods dentro de un clúster de Kubernetes.
Se basa en escaladores que pueden implementar diferentes fuentes para medir el número de solicitudes o eventos que recibimos de diferentes sistemas de mensajería como Apache Kafka, AWS Kinesis, Azure EventHub y otros sistemas como InfluxDB o Prometheus.
KEDA funciona como se muestra en la imagen a continuación:
Tenemos nuestro ScaledObject que vincula nuestra fuente de eventos externa (es decir, Apache Kafka, Prometheus ..) con el Despliegue de Kubernetes que nos gustaría escalar y registrar eso en el clúster de Kubernetes.
KEDA monitoreará la fuente externa y, basado en las métricas recopiladas, comunicará al Escalador Automático de Pods Horizontal para escalar la carga de trabajo según lo definido.
Probando el Enfoque con un Caso de Uso
Entonces, ahora que sabemos cómo funciona, haremos algunas pruebas para verlo en vivo. Vamos a mostrar cómo podemos escalar rápidamente una de nuestras aplicaciones usando esta tecnología. Y para hacer eso, lo primero que necesitamos hacer es definir nuestro escenario.
En nuestro caso, el escenario será una aplicación nativa de la nube simple desarrollada usando una aplicación Flogo que expone un servicio REST.
El primer paso que necesitamos hacer es desplegar KEDA en nuestro clúster de Kubernetes, y hay varias opciones para hacerlo: gráficos Helm, Operación o archivos YAML. En este caso, vamos a usar el enfoque de gráficos Helm.
Entonces, vamos a escribir los siguientes comandos para agregar el repositorio helm y actualizar los gráficos disponibles, y luego desplegar KEDA como parte de nuestra configuración de clúster:
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/kedaDespués de ejecutar este comando, KEDA se despliega en nuestro clúster K8S, y al escribir el siguiente comando kubectl get all proporcionará una situación similar a esta:
pod/keda-operator-66db4bc7bb-nttpz 2/2 Running 1 10m pod/keda-operator-metrics-apiserver-5945c57f94-dhxth 2/2 Running 1 10m
Ahora, vamos a desplegar nuestra aplicación. Como ya se comentó, para hacerlo vamos a usar nuestra Aplicación Flogo, y el flujo será tan simple como este:
- La aplicación expone un servicio REST usando /hello como el recurso.
- Las solicitudes recibidas se imprimen en la salida estándar y se devuelve un mensaje al solicitante
Una vez que tenemos nuestra aplicación desplegada en nuestra aplicación de Kubernetes, necesitamos crear un ScaledObject que sea responsable de gestionar la escalabilidad de ese componente:
Usamos Prometheus como un disparador, y debido a eso, necesitamos configurar dónde está alojado nuestro servidor Prometheus y qué consulta nos gustaría hacer para gestionar la escalabilidad de nuestro componente.
En nuestro ejemplo, usaremos el flogo_flow_execution_count que es la métrica que cuenta el número de solicitudes que son recibidas por este componente, y cuando esto tiene una tasa superior a 100, lanzará una nueva réplica.
Después de golpear el servicio con una Prueba de Carga, podemos ver que tan pronto como el servicio alcanza el umbral, lanza una nueva réplica para comenzar a manejar solicitudes como se esperaba.
Todo el código y los recursos están alojados en el repositorio de GitHub que se muestra a continuación:
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
Resumen
Este post ha mostrado que tenemos opciones ilimitadas para decidir las opciones de escalabilidad para nuestras cargas de trabajo. Podemos usar las métricas estándar como CPU y memoria, pero si necesitamos ir más allá, podemos usar diferentes fuentes externas de información para activar ese escalado automático.