Escalar a cero en Kubernetes: una inmersión profunda en Elasis

Elástico es una solución innovadora de código abierto diseñada para optimizar el uso de los recursos de Kubernetes al permitir que los servicios se reduzcan a cero durante los períodos de inactividad y se amplíen según demanda. Diseñada con una arquitectura de dos componentes (un controlador de Kubernetes y un solucionador de solicitudes), ELASTI administra sin problemas la disponibilidad de los servicios y minimiza los costos. El objetivo de esta publicación es ofrecer un recorrido técnico sobre su arquitectura, instalación y flujos operativos, para garantizar que pueda integrar y ampliar Elasti de forma eficaz en sus entornos de Kubernetes.

💡 Esta función está incluida en la suite de escalado automático de Truefoundry. Para obtener más información, consulta la documentación.

El panorama de la escala a cero

Si bien Kubernetes ofrece sólidas capacidades de escalado a través de HPA y soluciones como KEDA, escalar a cero réplicas sigue siendo un desafío. Los enfoques existentes suelen clasificarse en dos categorías:

1. Escalado nativo de KEDA - Si bien KEDA puede escalar las implementaciones a cero mediante métricas de eventos, esto crea una ventana en la que las solicitudes entrantes pueden perderse durante el período de arranque en frío de la ampliación.
2. Mallas de servicio completo (por ejemplo, Knative): proporcionan una escala completa hasta cero, pero requieren cambios arquitectónicos significativos y conllevan una gran sobrecarga operativa.
3. Proxies HTTP (por ejemplo, el complemento HTTP de KEDA): mantenga capas de proxy persistentes que introduzcan latencia incluso después de que los servicios se amplíen.

¿Por qué Elatis?

Elati se creó para abordar estas limitaciones con tres objetivos de diseño clave:

1. Integración ligera - Trabaje con los despliegues o servicios existentes sin cambiar el código.
2. Sin gastos de proxy - Salga de la ruta de solicitud una vez que los servicios se amplíen.
3. Escalado con optimización de costos - Verdadera escala cero sin mantener los componentes siempre activos.

Cómo funciona

Elati se compone de dos componentes principales que funcionan en conjunto para gestionar la escalabilidad de los servicios:

Controlador (operador):‍

• Supervisa los recursos de ElastiService en su clúster de Kubernetes.
• Escala los servicios de forma dinámica entre 0 y 1 en función de las métricas de tráfico en tiempo real.

Resolvedor:

• Actúa como un proxy para interceptar las solicitudes entrantes cuando el servicio se reduce.
• Pone en cola estas solicitudes y notifica al controlador que amplíe el servicio para garantizar que no se pierda ninguna solicitud.

Flujo estable de solicitudes de servicios

En este modo, todas las solicitudes las gestionan directamente los service pods. El solucionador de Elatti no entra en la ruta de la solicitud. El controlador Elasis sigue sondeando a Prometheus con la consulta configurada y comprueba el resultado con un valor umbral para ver si el servicio se puede reducir.

Reducir a 0 cuando no haya solicitudes

Si la consulta de prometheus devuelve un valor inferior al umbral, Elatis reducirá el servicio a 0. Antes de escalar a 0, redirige las solicitudes para que se reenvíen al solucionador de Elatis y, a continuación, modifica el despliegue o la implementación para tener 0 réplicas. A continuación, también detiene Keda (si se está utilizando Keda) para impedir que amplíe el servicio, ya que Keda está configurado con minReplicas como 1.

Aumente la escala desde 0 cuando llegue la primera solicitud.

Como el servicio se reduce a 0, todas las solicitudes llegarán al solucionador de Elatti. Cuando llegue la primera solicitud, Elatti ampliará el servicio hasta las minTargetReplicas configuradas. A continuación, reanuda Keda para continuar con el escalado automático en caso de que se produzca una ráfaga repentina de solicitudes. También cambia el servicio para que apunte a los módulos de servicio reales una vez que el módulo está activo. Las solicitudes que llegan a ElastiResolver se vuelven a intentar hasta 6 minutos y la respuesta se devuelve al cliente. Si el pod tarda más de 6 minutos en aparecer, la solicitud se descarta.

Cómo empezar

Despliegue de una aplicación sencilla con Elasi

1. Creación de un clúster local

inicio de minikube


o

tipo create cluster --name elasti-demo

o

‍
Crea un clúster local con Docker Desktop

2. Configuración de Prometheus

helm repo agrega prometheus-community https://prometheus-community.github.io/helm-charts
actualización del repositorio de helm
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack\
--supervisión del espacio de nombres\
--crear-espacio de nombres\
--set alertmanager.enabled=false\
--set grafana.enabled=false\
--set Prometheus.PrometheusSpec.ServiceMonitorSelectorSelectorNiLuseShelmValues=false

Instala y configura prometheus en control espacio de nombres

Prometheus se utilizará para leer las métricas de nginx ingress, que luego serán utilizadas por elasti para consultar las métricas en función de las cuales decidirá cuándo escalar un servicio desde y hacia cero.

3. Configuración de nginx ingress

helm repo agregar ingress-nginx https://kubernetes.github.io/ingress-nginx
actualización del repositorio de helm
helm install ingress-nginx ingress-nginx/ingress-nginx\
--espacio de nombres ingress-nginx\
--set controller.metrics.enabled=true\
--set controller.metrics.ServiceMonitor.enabled=true\
--create-namespace

Implementa un controlador nginx en el ingress-nginx espacio de nombres

El controlador se utilizará para dirigir el tráfico a nuestro servicio httpbin de demostración.

4. Configuración de Elati:

helm repo agrega elasti https://charts.truefoundry.com/elasti
actualización del repositorio de helm
helm install elasti oci: //tfy.jfrog.io/tfy-helm/elasti\
--namespace elasti --create-namespace


Instalación de Elasis con helm en el espacio de nombres elasti

Una vez instalado Elati, verás que sus dos componentes clave se están ejecutando:

• Controlador/operador: Gestiona la conmutación y el escalado del tráfico supervisando las métricas.
• Resolvedor: Intercepta, pone en cola y envía por proxy las solicitudes entrantes

Para configuraciones más avanzadas, consulta valores.yaml para ver todas las opciones de configuración en el archivo de valores del timón.

5. Implemente una aplicación de demostración

kubectl crea un espacio de nombres elastici-demo
kubectl apply -n elasti-demo -f\
https://raw.githubusercontent.com/truefoundry/elasti/refs/heads/main/playground/config/demo-application.yaml

Implementación de un servicio httpbin en demo elástica espacio de nombres

Este servicio httpbin se utilizará para demostrar cómo configurar un servicio para gestionar el tráfico a través de elasti.

6. Creación de un recurso de ElastiService:

Crea un archivo yaml con la siguiente configuración para un ElastiService.

Versión de API: elasti.truefoundry.com/v1alpha1
tipo: ElastiService
metadatos:
nombre: httpbin-elasti
espacio de nombres: elasti-demo
especificación:
Número mínimo de réplicas de Target: 1
servicio: httpbin
Período de enfriamiento: 5
Referencia de objetivo de escala:
Versión de API: aplicaciones/v1
tipo: despliegues
nombre: httpbin
desencadenantes:
- tipo: prometheus
metadatos:
consulta: sum (rate (nginx_ingress_controller_nginx_process_requests_total [1m])) o vector (0)
Dirección del servidor: http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090
umbral: «0.5"

demo-elasti-service.yaml

Una vez creado el archivo, aplique el ElastiService

kubectl apply -f https://raw.githubusercontent.com/truefoundry/elasti/refs/heads/main/playground/config/demo-elastiService.yaml

Algunos campos clave de la especificación CRD son:

• Réplicas minTarget: Número mínimo de réplicas que se deben mostrar cuando llegue la primera solicitud.
• Período de enfriamiento: Tiempo mínimo (en segundos) de espera después de la ampliación antes de considerar la reducción
• disparadores: Lista de condiciones que determinan cuándo reducir la escala (actualmente solo admite las métricas de Prometheus)
• Scale TargetRef: Referencia al objetivo de escala similar al utilizado en HorizontalPodAutoScaler.

Para obtener más información y configurar un ElastiService para su caso de uso, consulte este documento.

Probar la configuración

Con estos pasos, ahora tiene:

• Ingreso | nginx ejecutándose como su controlador de Ingress.
• Prometeo configurado para extraer métricas (incluidas las de Ingress NGINX).
• httpbin desplegado y accesible a través de una ruta de ingreso.

Esta configuración le ayuda a probar escenarios de enrutamiento reales y a supervisar el rendimiento y las métricas del tráfico de entrada.

Para probar esta configuración, puedes enviar solicitudes al balanceador de cargas de nginx y monitorear los pods de nuestro servicio de demostración.

kubectl svc/nginx-ingress-nginx-controller\
-n ingress-nginx 80:80:80


Reenvío de puertos al controlador nginx

kubectl obtiene pods -n elasti-demo -w


Inicie un reloj en el servicio httpbin

Ahora puedes enviar una solicitud a http://localhost:8080/httpbin y puede ver cómo elasti escala el servicio a 1 réplica.

curl -v http://localhost:8080/httpbin

Enviar una solicitud al servicio httpbin

Luego, el servicio se reducirá nuevamente después de que no haya actividad durante Período de enfriamiento segundos especificados en ElastiService (5 segundos en este caso).

Desinstalación de Elasis

Para desinstalar Elastos, primero tendrá que eliminar todos los ElastiServices instalados. A continuación, simplemente borre el archivo de instalación.

kubectl elimina elastiservices --todos
helm uninstall elasti -n elasti
kubectl elimina el espacio de nombres elasti

^{Comparaciones}

Tabla de comparación de funciones:

Cuándo elegir Elasis

Elati es la mejor opción cuando:

• Necesidad de añadir capacidad de escalado a cero a los servicios HTTP existentes
• Quiere garantizar que no haya ninguna pérdida de solicitudes durante las operaciones de escalado
• Prefiere una solución ligera con una configuración mínima
• Necesita integrarse con los escaladores automáticos existentes (HPA/KEDA)

Palabras finales

Elasti se desarrolló a partir de la necesidad de abordar un desafío específico de Kubernetes: implementar una verdadera escala a cero sin sacrificar la integridad de las solicitudes ni imponer una sobrecarga excesiva. Esta solución admite el escalado automático nativo con HPA y KEDA, lo que garantiza que las configuraciones de servicio existentes permanezcan inalteradas y, al mismo tiempo, se logre una utilización eficiente de los recursos.

Con el código abierto de esta herramienta, nuestro objetivo es proporcionar una solución sólida para los entornos que requieren una verdadera escalabilidad a cero, cero pérdidas de solicitudes y un espacio operativo mínimo.

Agradecemos las contribuciones y los comentarios de la comunidad. Explore el documento de desarrollo para obtener más información.

‍