Saltar al contenido

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.

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

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.

Related articles:

Desbloqueando el Rendimiento y la Adaptabilidad: Explorando el Autoscaling Vertical de Kubernetes Escalado automático de Kubernetes: Aprende a escalar tus implementaciones de Kubernetes de manera dinámica Opciones mejoradas de AutoScaling para aplicaciones impulsadas por eventos Promtail: El eslabón perdido entre registros y métricas para tu plataforma de monitoreo
Etiquetas:

Kubernetes Autoscaling 1.26: A Game-Changer for KEDA Users?

Introduction

Kubernetes Autoscaling has suffered a dramatic change. Since the Kubernetes 1.26 release, all components should migrate their HorizontalPodAutoscaler objects from the v1 to the new release v2that has been available since Kubernetes 1.23.

HorizontalPodAutoscaler is a crucial component in any workload deployed on a Kubernetes cluster, as the scalability of this solution is one of the great benefits and key features of this kind of environment.

A little bit of History

Kubernetes has introduced a solution for the autoscaling capability since the version Kubernetes 1.3 a long time ago, in 2016. And the solution was based on a control loop that runs at a specific interval that you can configure with the property --horizontal-pod-autoscaler-sync-period parameters that belong to the kube-controller-manager.

So, once during this period, it will get the metrics and evaluate through the condition defined on the HorizontalPodAutoscaler component. Initially, it was based on the compute resources used by the pod, main memory, and CPU.

Kubernetes Autoscaling 1.26: A Game-Changer for KEDA Users?

This provided an excellent feature, but with the past of time and adoption of the Kubernetes environment, it has been shown as a little narrow to handle all the scenarios that we should have, and here is where other awesome projects we have discussed here, such as KEDA brings into the picture to provide a much more flexible set of features.

Kubernetes AutoScaling Capabilities Introduced v2

With the release of the v2 of the Autoscaling API objects, we have included a range of capabilities to upgrade the flexibility and options available now. There most relevant ones are the following:

  • Scaling on custom metrics: With the new release, you can configure an HorizontalPodAutoscaler object to scale using custom metrics. When we talk about custom metrics, we talk about any metric generated from Kubernetes. You can see a detailed walkthrough about using Custom metrics in the official documentation
  • Scaling on multiple metrics: With the new release, you also have the option to scale based on more than one metric. So now the HorizontalPodAutoscalerwill evaluate each scaling rule condition, propose a new scale value for each of them, and take the maximum value as the final one.
  • Support for Metrics API: With the new release, the controller from the HoriztalPodAutoscaler components retrieves metrics from a series of registered APIs, such as metrics.k8s.io, custom.metrics.k8s.io ,external.metrics.k8s.io. For more information on the different metrics available, you can take a look at the design proposal
  • Configurable Scaling Behavior: With the new release, you have a new field, behavior, that allows configuring how the component will behave in terms of scaling up or scaling down activity. So, you can define different policies for the scaling up and others for the scaling down, limit the max number of replicas that can be added or removed in a specific period, to handle the issues with the spikes of some components as Java workloads, among others. Also, you can define a stabilization window to avoid stress when the metric is still fluctuating.

Kubernetes Autoscaling v2 vs KEDA

We have seen all the new benefits that Autoscaling v2 provides, so I’m sure that most of you are asking the same question: Is Kubernetes Autoscaling v2 killing KEDA?

Since the latest releases of KEDA, KEDA already includes the new objects under the autoscaling/v2 group as part of their development, as KEDA relies on the native objects from Kubernetes, and simplify part of the process you need to do when you want to use custom metric or external ones as they have scalers available for pretty much everything you could need now or even in the future.

But, even with that, there are still features that KEDA provides that are not covered here, such as the scaling “from zero” and “to zero” capabilities that are very relevant for specific kinds of workloads and to get a very optimized use of resources. Still, it’s safe to say that with the new features included in the autoscaling/v2 release, the gap is now smaller. Depending on your needs, you can go with the out-of-the-box capabilities without including a new component in your architecture.

Related articles:

Desbloqueando el Rendimiento y la Adaptabilidad: Explorando el Autoscaling Vertical de Kubernetes Escalado automático de Kubernetes: Aprende a escalar tus implementaciones de Kubernetes de manera dinámica Opciones mejoradas de AutoScaling para aplicaciones impulsadas por eventos Promtail: El eslabón perdido entre registros y métricas para tu plataforma de monitoreo
Etiquetas:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *