AUTOSCALING ANIDADO
Es un poco complejo implementar el escalado, ya que en mi caso requerà de mucha información y parametrización para poder implementar lo que le llamamos escalado horizontal anidado.
TenÃamos una aplicación corriendo en Kubernetes y que tenÃa mÃnimo 1 pod y máximo 3 corriendo. Todo bien, después con el tiempo nos dimos cuenta de que la usabilidad de la aplicación iba creciendo exponencialmente y al no estar preparados la aplicación comenzó a experimentar fallos (a pesar de usar kubernetes en AWS).
Que decidimos hacer?
- medimos las horas pico de usabilidad
- medimos la cantidad de recursos que se utilizan en esas horas
- con base a ello se parametrizó de manera más eficiente la cantidad de pods que se utilizarán y los disparadores que crearán estos pods.
Pero la legión del mal atacó nuevamente. Sin embargo esta vez el servidor que servÃa como worker node estaba saturado por lo que tenÃamos que tomar una decisión:
¿Le incrementamos en recursos?
SabÃamos que incrementar en recursos no era muy eficiente, puesto que solo se utilizarÃa en cierta cantidad de tiempo. Por otro lado el hecho de incrementarle recursos implicaba apagar la máquina virtual asà como tratar de parametrizar la hora más eficiente para subir los recursos
¿Qué decidimos hacer??
- volver a medir, medir y medir.
- separamos el plano de datos (media) que vivÃan en el servidor (worker node) y lo implementamos via EFS con el fin de evitar inconsistencias de datos.
- implementamos crecimiento horizontal de los worker nodes con el uso de autoscaling groups.
- voila (como dicen en España ese servicio no lo tumba ni Dios)
¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.