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:
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/kedakubectl 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 10mAhora, 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
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.📚 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.
