Skip to main content

Fargate con EKS

¿Es Fargate la solución de AWS con la que siempre soñamos para evitar manejar infraestructura con Kubernetes? Sí, pero…

Fargate

 

Fargate es un servicio de Amazon Web Service para evitar que debamos pensar en el aprovisionamiento y escalado de instancias EC2 en sus servicios de contenedores, ya sea su servicio propio, ECS, o en más estándar para Kubernetes, EKS.

La idea básica es la siguiente: no te preocupes por aprovisionar infraestructura, tú únicamente lanza contenedores y ya nos preocupamos nosotros por asignarles infraestructura en la que ejecutarse. Y lo hace.

Desde el punto de vista del usuario, el funcionamiento sería como si AWS dispusiera de un pool de máquinas EC2 y cuando lanzamos un contenedor, AWS lo pone en una de esas máquinas y le asigna una Interfaz de red de nuestra subred.

Ventajas

 

Esta nueva forma de ejecutar contenedores tiene grandes ventajas:

· Es gestionado por AWS: no necesitamos preocuparnos por gestionar la infraestructura y el dimensionamiento. Únicamente debemos preocuparnos de la configuración inicial y de pagar la factura.

· Se evita el sobreaprovisionamiento: al menos a nivel de infraestructura, ya que se va pidiendo según se necesita y a los contenedores se les asigna (y factura) exactamente lo indicado. Continuará existiendo sobreaprovisionamiento a nivel de contenedor, puesto que no querremos tener la CPU ni la memoria al 100%.

· Es más seguro: la infraestructura base está absolutamente aislada, no se puede acceder a ella, únicamente al contenedor a través de la interfaz de red creada para nuestro cluster.

· Es posibleutilizar ambos sistemas a la vez, Fargate y EC2, en función de algunas reglas, como namespace o labels a nivel de pod.

Limitaciones

 

Sin embargo, no son todo buenas noticias y existen algunas limitaciones. Vamos a centrarnos en EKS, que es el gestor de contenedores que hemos utilizado. Algunos pueden aplicar en ECS y otros no:

· La más importante podría ser el tiempo de aprovisionamiento. Una vez Kubernetes solicita el pod a Fargate, este tarda al menos 30 segundos en estar disponible, lo cual aumenta el tiempo de arranque. La importancia de este factor dependerá del tiempo de arranque de nuestro pod y la necesidad del mismo pero, en general, hará que aumente el sobreaprovisionamiento a nivel de pod, al bajar el margen para escalar. Además, este tiempo no es fijo y hemos llegado a registrar tiempos de 120 y 180 segundos. Este es claramente un punto a mejorar.

· Los recursos limitados perjudican el escalado: Al pod se le asignará el tamaño solicitado en función de las configuraciones admitidas. El pod no puede pasar de este límite, lo que supondrá escalar más lento. Veámoslo con un ejemplo:

Supongamos el caso de máquinas EC2 con un pod que requiere CPU de 500m. Si pasa de ahí, podría llegar a utilizar 1vCPU, por ejemplo. La métrica en Kubernetes sería de un 200%. Si tenemos configurado un escalado al 50%, eso significa que Kubernetes levantará otros 3 pod para que cada uno utilice 250m de CPU. Si hacemos el mismo ejercicio con Fargate, el pod nunca podrá pasar de 500m, por lo que estará al 100% y Kubernetes levantará un único pod. Una vez levantado, consumirán en torno a 1vCPU, de nuevo el 100% y esta vez sí levantará otros 2 pods.

Hemos necesitado dos pasos de escalado para alcanzar el mismo nivel, además, tenemos que contar con el tiempo de aprovisionamiento extra de Fargate, por lo que nuestro escalado ha sido más lento.

Una forma de mejorar esto es utilizar otras métricas no dependientes de los recursos siempre que sea posible (tamaño de una cola, número de conexiones al balanceador, llamadas, etc.).

· Daemonsets: no es posible utilizar daemonsets en Fargate. Es necesario utilizar otras estrategias, como inyección de contenedores sidecard o lanzar nuevos pods que realicen las tareas necesarias.

· Volúmenes persistentes (solucionado): en un principio no era posible conectar volúmenes persistentes, sin embargo, esta limitación ha sido solucionada, incorporando la capacidad de montar volúmenes EFS.

· Acceso a los nodos: no es posible conectar con un nodo de Fargate mediante SSH, como sí podríamos hacer con EC2. A pesar de ser una limitación, podría considerarse como una mejora de la seguridad.

· Para los balanceadores, en el ingress únicamente es posible utilizar el modo de conexión (target-type) mediante IP, no de instancia.

Uso con EKS

 

Lo más sencillo es utilizar la herramienta eksctl que proporciona AWS y que nos ahorrará un montón de configuraciones manuales y dolores de cabeza. En caso de no querer utilizarlo (en nuestro caso, queríamos que todo estuviera en Terraform sin utilizar herramientas externas), existen infinidad de detalles que configurar y plantillas para instalar todo lo necesario, como agentes de CloudWatch para los logs, openId, IAM, el Ingress Controller, etc.

Toda esta configuración ocurre aparte del recurso EKS por lo que, o se configura a mano, o se utiliza eksctl.

Además, es conveniente configurar Prometheus para recuperar las métricas de nuestras aplicaciones, así como recuperar las métricas de Cloudwatch (Cloudwatch metrics add-on) para que estén disponibles en Kubernetes, de forma que podamos crear reglas de escalado basadas en otras métricas, como las de los balanceadores, API Gateway o colas.

Entonces, ¿Debería usar Fargate?

 

Fargate nos ahorrará mucho tiempo a la hora de pensar, configurar y gestionar la escalabilidad de nuestros nodos, proporcionando un entorno flexible y dinámico donde solo pagaremos por las necesidades de nuestros pods, sin necesitar sobreaprovisionamiento de infraestructura.

Probablemente sea lo más indicado en la mayoría de los casos, sin embargo, creo que no es recomendable para todos los usos, por lo que haré una lista de excepciones:

· Necesitas daemonsets y sería muy complicado o no existe tiempo/voluntad para modificarlo.

· Restricciones por el tipo de conexión de los balanceadores, acceso a nodos u otras limitaciones.

· Necesitas un escalado muy rápido, en segundos y no minutos (por el tiempo de creación de los nodos). Necesitarás sobreaprovisionamiento en EC2.

· Necesitas escalar de 1 a muchos de forma ágil (por la asignación de recursos que limitan la velocidad de escalado al inicio). También aplica para escalados de varios órdenes de magnitud (de 10 a 1000). Necesitarás sobreaprovisionamiento en EC2 o una buena automatización en la creación de nodos.

También podría ser factible utilizar Fargate con otra métrica no dependiente de recursos. Podrá ayudar bajar los tiempos de registro y consulta de métricas (en CloudWatch y en el scraping de Prometheus si usas el stack de AWS) y bajar el objetivo de CPU para escalado, de forma que se absorban mejor picos puntuales.

Recuerda que es posible utilizar ambos sistemas a la vez, Fargate y EC2, esto puede ayudarte en tu estrategia de escalado.

Esto es todo, espero haber ayudado a entender Fargate y lo que significa incluirlo en nuestra arquitectura.

Autor del artículo

Alejandro Ladera, senior specialist de Consultoría Tecnológica de Deloitte.