Kubernetes Autoscaling 1.26: ¿Un cambio de juego para los usuarios de KEDA?

Introducción

El autoescalado de Kubernetes ha sufrido un cambio dramático. Desde el lanzamiento de Kubernetes 1.26, todos los componentes deben migrar sus objetos HorizontalPodAutoscaler de la versión v1 a la nueva versión v2 que ha estado disponible desde Kubernetes 1.23.

HorizontalPodAutoscaler es un componente crucial en cualquier carga de trabajo desplegada en un clúster de Kubernetes, ya que la escalabilidad de esta solución es uno de los grandes beneficios y características clave de este tipo de entorno.

Un poco de Historia

Kubernetes ha introducido una solución para la capacidad de autoescalado desde la versión Kubernetes 1.3 hace mucho tiempo, en 2016. Y la solución se basaba en un bucle de control que se ejecuta en un intervalo específico que puedes configurar con los parámetros de la propiedad --horizontal-pod-autoscaler-sync-period que pertenecen al kube-controller-manager.

Entonces, una vez durante este período, obtendrá las métricas y evaluará a través de la condición definida en el componente HorizontalPodAutoscaler. Inicialmente, se basaba en los recursos de cómputo utilizados por el pod, memoria principal y CPU.

Esto proporcionó una excelente característica, pero con el paso del tiempo y la adopción del entorno de Kubernetes, se ha mostrado un poco limitado para manejar todos los escenarios que deberíamos tener, y aquí es donde otros proyectos impresionantes que hemos discutido aquí, como KEDA entran en escena para proporcionar un conjunto de características mucho más flexible.

Capacidades de Autoescalado de Kubernetes Introducidas v2

Con el lanzamiento de la v2 de los objetos de la API de Autoescalado, hemos incluido una gama de capacidades para mejorar la flexibilidad y las opciones disponibles ahora. Las más relevantes son las siguientes:

• Escalado en métricas personalizadas: Con el nuevo lanzamiento, puedes configurar un objeto HorizontalPodAutoscaler para escalar usando métricas personalizadas. Cuando hablamos de métricas personalizadas, hablamos de cualquier métrica generada desde Kubernetes. Puedes ver una guía detallada sobre el uso de métricas personalizadas en la documentación oficial
• Escalado en múltiples métricas: Con el nuevo lanzamiento, también tienes la opción de escalar basado en más de una métrica. Así que ahora el HorizontalPodAutoscaler evaluará cada condición de regla de escalado, propondrá un nuevo valor de escala para cada una de ellas, y tomará el valor máximo como el final.
• Soporte para la API de Métricas: Con el nuevo lanzamiento, el controlador de los componentes de HoriztalPodAutoscaler recupera métricas de una serie de APIs registradas, como metrics.k8s.io, custom.metrics.k8s.io, external.metrics.k8s.io. Para más información sobre las diferentes métricas disponibles, puedes echar un vistazo a la propuesta de diseño
• Comportamiento de Escalado Configurable: Con el nuevo lanzamiento, tienes un nuevo campo, behavior, que permite configurar cómo se comportará el componente en términos de actividad de escalado hacia arriba o hacia abajo. Así, puedes definir diferentes políticas para el escalado hacia arriba y otras para el escalado hacia abajo, limitar el número máximo de réplicas que se pueden agregar o eliminar en un período específico, para manejar los problemas con los picos de algunos componentes como las cargas de trabajo de Java, entre otros. También, puedes definir una ventana de estabilización para evitar el estrés cuando la métrica aún está fluctuando.
  

Kubernetes Autoscaling v2 vs KEDA

Hemos visto todos los nuevos beneficios que proporciona Autoscaling v2, así que estoy seguro de que la mayoría de ustedes se están haciendo la misma pregunta: ¿Está Kubernetes Autoscaling v2 matando a KEDA?

Desde las últimas versiones de KEDA, KEDA ya incluye los nuevos objetos bajo el grupo autoscaling/v2 como parte de su desarrollo, ya que KEDA se basa en los objetos nativos de Kubernetes, y simplifica parte del proceso que necesitas hacer cuando quieres usar métricas personalizadas o externas, ya que tienen escaladores disponibles para prácticamente todo lo que podrías necesitar ahora o incluso en el futuro.

Pero, incluso con eso, todavía hay características que KEDA proporciona que no están cubiertas aquí, como las capacidades de escalado “desde cero” y “a cero” que son muy relevantes para tipos específicos de cargas de trabajo y para obtener un uso muy optimizado de los recursos. Aún así, es seguro decir que con las nuevas características incluidas en el lanzamiento de autoscaling/v2, la brecha ahora es más pequeña. Dependiendo de tus necesidades, puedes optar por las capacidades listas para usar sin incluir un nuevo componente en tu arquitectura.