Kubernetes ha introducido como su versión alfa en su lanzamiento de Kubernetes 1.27 la capacidad de Autoscaling Vertical de Pods para proporcionar la opción de que la carga de trabajo de Kubernetes pueda escalar utilizando el enfoque «vertical» al agregar más recursos a un pod existente. Esto aumenta las capacidades de escalado automático de sus cargas de trabajo de Kubernetes que tiene a su disposición, como KEDA o Autoscaling Horizontal de Pods.
Escalado Vertical vs Escalado Horizontal
El escalado vertical y horizontal son dos enfoques utilizados para aumentar el rendimiento y la capacidad de los sistemas informáticos, particularmente en sistemas distribuidos y computación en la nube. El escalado vertical, también conocido como escalado hacia arriba o escalado verticalmente, implica agregar más recursos, como potencia de procesamiento, memoria o almacenamiento, a una sola instancia o servidor. Esto significa actualizar los componentes de cómputo existentes o migrar a una infraestructura más potente. El escalado vertical a menudo es sencillo de implementar y requiere cambios mínimos en la arquitectura del software. Se utiliza comúnmente cuando las demandas del sistema pueden ser satisfechas por una sola infraestructura más potente.
Por otro lado, el escalado horizontal, también llamado escalado hacia afuera o escalado horizontalmente, implica agregar más instancias o servidores para distribuir la carga de trabajo. En lugar de actualizar una sola instancia, se emplean múltiples instancias, cada una manejando una parte de la carga de trabajo. El escalado horizontal ofrece la ventaja de aumentar la redundancia y la tolerancia a fallos, ya que múltiples instancias pueden compartir la carga. Además, proporciona la capacidad de manejar cargas de trabajo más grandes simplemente agregando más máquinas al clúster. Sin embargo, el escalado horizontal a menudo requiere arquitecturas de software más complejas, como balanceo de carga y sistemas de archivos distribuidos, para distribuir y gestionar eficientemente la carga de trabajo entre las máquinas.
En resumen, el escalado vertical implica mejorar las capacidades de un solo objeto, mientras que el escalado horizontal implica distribuir la carga de trabajo entre múltiples instancias. El escalado vertical es más fácil de implementar, pero puede tener limitaciones en términos de los recursos máximos disponibles en una sola máquina. El escalado horizontal proporciona mejor escalabilidad y tolerancia a fallos, pero requiere una infraestructura de software más compleja. La elección entre el escalado vertical y horizontal depende de factores como los requisitos específicos del sistema, la carga de trabajo esperada y los recursos disponibles.
¿Por qué el Autoscaling Vertical de Kubernetes?
Este es un tema interesante porque hemos estado viviendo en un mundo donde el estado era que siempre era mejor escalar hacia afuera (usando el Escalado Horizontal) en lugar de escalar hacia arriba (usando el Escalado Vertical) y especialmente este era uno de los mantras que escuchabas en desarrollos nativos de la nube. Y eso no ha cambiado porque el escalado horizontal proporciona muchos más beneficios que el escalado vertical y está bien cubierto con las capacidades de Autoscaling o proyectos paralelos como KEDA. Entonces, en ese caso, ¿por qué Kubernetes está incluyendo esta característica y por qué estamos usando este sitio para discutirlo?
Porque con la transformación de Kubernetes para ser la alternativa de facto para cualquier implementación que realices hoy en día, las características y capacidades de las cargas de trabajo que necesitas manejar se han ampliado y por eso necesitas usar diferentes técnicas para proporcionar la mejor experiencia a cada uno de los tipos de cargas de trabajo.
¿Cómo el Autoscaling Vertical de Kubernetes?
Aquí encontrarás toda la documentación sobre esta nueva característica que, como se comentó, todavía está en la etapa «alfa», por lo que es algo para probar en modo experimental en lugar de usarlo a nivel de producción Documentación de HPA
El Escalado Vertical funciona de manera que podrás cambiar los recursos asignados al pod, CPU y memoria sin necesidad de reiniciar el pod y cambiar la declaración del manifiesto, y ese es un claro beneficio de este enfoque. Como sabes, hasta ahora si quieres cambiar los recursos aplicados a una carga de trabajo necesitas actualizar el documento del manifiesto y reiniciar el pod para aplicar los nuevos cambios.
Para definir esto necesitas especificar el resizePolicy agregando una nueva sección al manifiesto del pod como puedes ver aquí:
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-5
namespace: qos-example
spec:
containers:
- name: qos-demo-ctr-5
image: nginx
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired
- resourceName: memory
restartPolicy: RestartContainer
resources:
limits:
memory: "200Mi"
cpu: "700m"
requests:
memory: "200Mi"
cpu: "700m"
Por ejemplo, en este caso definimos para los diferentes nombres de recursos la política que queremos aplicar, si vamos a cambiar la CPU asignada no requerirá un reinicio, pero en caso de que estemos cambiando la memoria, requeriría un reinicio.
Eso implica que si deseas cambiar la CPU asignada, puedes parchear directamente el manifiesto como puedes ver en el fragmento a continuación y eso proporciona una actualización de los recursos asignados:
kubectl -n qos-example patch pod qos-demo-5 --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'
¿Cuándo usar el Escalado Vertical son los escenarios objetivo?
Dependerá de muchos escenarios diferentes del caso de uso, pero también de la pila tecnológica que está utilizando tu carga de trabajo para saber cuáles de estas capacidades pueden aplicarse. Como algo normal, el cambio de CPU será fácil de adaptar a cualquier tecnología, pero el de memoria sería más difícil dependiendo de la tecnología utilizada, ya que en la mayoría de las tecnologías la memoria asignada se define en el momento del inicio.
Esto ayudará a actualizar componentes que han cambiado sus requisitos como un escenario promedio o cuando estás probando nuevas cargas de trabajo con carga en vivo y no quieres interrumpir el procesamiento actual de la aplicación o simplemente cargas de trabajo que no admiten el escalado horizontal porque están diseñadas en modo de réplica única.
Conclusión
En conclusión, Kubernetes ha introducido el Autoscaling Vertical de Pods, permitiendo el autoscaling vertical de cargas de trabajo de Kubernetes al agregar recursos a pods existentes. El autoscaling vertical de Kubernetes permite cambios de recursos sin reiniciar pods, proporcionando flexibilidad en la gestión de asignaciones de CPU y memoria.
El autoscaling vertical de Kubernetes ofrece una opción valiosa para adaptarse a las necesidades cambiantes de las cargas de trabajo. Complementa el escalado horizontal al proporcionar flexibilidad sin la necesidad de arquitecturas de software complejas. Al combinar enfoques de escalado vertical y horizontal, los usuarios de Kubernetes pueden optimizar sus implementaciones en función de las características específicas de la carga de trabajo y los recursos disponibles.
📚 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.
