Blog de Amazon Web Services (AWS)
Ejecución de contenedores multiarquitectura con Amazon EKS
Por Lucas Duarte, Arquitecto de Soluciones, WWPS Brasil,
Vinicius Silva, Arquitecto de Soluciones, WWPS Brasil y
Ernesto dos Santos, Solutions Architect, WWPS Brasil
Los clientes han buscado utilizar arquitecturas mixtas para optimizar costos o mejorar la relación precio – rendimiento. Podemos nombrar, por ejemplo, uno de los pilares del marco de buena arquitectura de AWS en relación con el rendimiento, la capacidad de utilizar eficientemente los recursos informáticos para cumplir con los requisitos del sistema y mantener esta eficiencia a medida que cambia la demanda y evolucionan las tecnologías.
Amazon Web Services personaliza los procesadores AWS Graviton, utilizando núcleos ARM Neoverse de 64 bits para ofrecer el mejor costo para las cargas de trabajo en la nube que se ejecutan en Amazon EC2.
Tras el lanzamiento de AWS Graviton2 en AWS re:Invent 2020, surgieron varias preguntas, como las siguientes:
- ¿Podemos ejecutar cualquier aplicación en procesadores con arquitectura ARM?
- ¿Qué necesitamos modificar en nuestra aplicación para que pueda ejecutarse en procesadores ARM?
- ¿Qué ventajas podemos obtener con AWS Graviton2 en comparación con AMD o Intel?
Las instancias EC2 basadas en AWS Graviton2 ofrecen un mejor rendimiento de hasta un 40%, reduciendo los costos hasta en un 20% en comparación con instancias en versiones Intel o AMD. De esta forma, los procesadores AWS Graviton2 añaden aún más opciones para ayudar a los clientes a optimizar el rendimiento y los costos de sus cargas de trabajo.
En esta entrada de blog le mostraremos como crear una imagen Docker que admita el uso de varias arquitecturas (x86 y ARM), con poca o casi ninguna modificación en el código fuente de la aplicación, implementando esta imagen en un clúster de Amazon EKS.
¿Y qué son las imágenes multiarquitectura?
Por lo general, cuando creamos una imagen Docker, nos basamos en una arquitectura de procesador específica, pero hay una forma que nos permite crear una imagen que puede contemplar varias arquitecturas de procesador.
Estamos aquí hablando de la funcionalidad de «Docker manifest”.
Para crear una imagen Docker que pueda ejecutarse en arquitecturas ARM, la mayor parte del tiempo no necesitamos modificar el código de nuestra aplicación, simplemente construirlo en una instancia con arquitectura de procesador ARM.
AWS CodeBuild admite de forma nativa el uso de instancias Intel/AMD, así como instancias ARM para crear (compilar) imágenes Docker. De esta manera, las imágenes creadas para admitir ARM se ejecutan en instancias con arquitectura ARM, y las creadas para admitir x86 (Intel/AMD) se ejecutan en instancias con arquitectura x86.
Desde la consola de AWS CodeBuild, puede seleccionar la arquitectura del procesador de la instancia que se utilizará para la compilación de la imagen de Docker.
Figura 1: Elegir la imagen en la consola de AWS CodeBuild
¿Y cómo sabré qué imagen elegir cuando ejecuto mi aplicación?
En el ejemplo que trajimos, construimos una imagen para dos arquitecturas: x86 y ARM. Cada una de las imágenes construidas tiene un URI, y este URI debe informarse en el manifiesto de implementación basado en la arquitectura del nodo.
Para abordar este detalle, Amazon ECR admite el almacenamiento de imágenes de varias arquitecturas, creadas a través del Docker Manifest.
Idealmente, se crea una lista de manifiesto a partir de imágenes que son idénticas en función, para diferentes combinaciones de sistemas operativos y/o arquitecturas.
Por esta razón, las listas de manifiesto a menudo se denominan «imágenes multiarquitectura».
Sin embargo, un usuario puede crear una lista de manifiesto que apunta a dos imágenes, por ejemplo: una para Windows en AMD64 y otra a Darwin en AMD64.
La arquitectura de clúster de Amazon EKS
En nuestra demostración, utilizaremos un clúster de Amazon EKS con dos grupos de nodos administrados distintos, uno con x86 como arquitectura y el otro con ARM.
Utilizaremos la imagen de Docker multiarquitectura construida, para ejecutar la aplicación en nuestro clúster utilizando el mismo URI para ambos nodos, sin tener que cambiar el manifiesto de implementación , ya que Amazon EKS identificará la arquitectura de la imagen y la ejecutará en el nodo correcto.
Figura 2: Arquitectura de clústeres de Amazon EKS utilizado na para demostración.
Al ejecutar el siguiente comando, podemos ver que para cada uno de los nodos de nuestro clúster tenemos una etiqueta de arquitectura específica.
~> kubectl get nodes --show-labels
Esta operación funciona gracias al motor de etiquetado Kubernetes, donde la etiqueta kubernetes.io/arch identifica la arquitectura de la instancia donde se ejecuta el agente Kubernetes, colocando el POD correcto en el Nodo con la arquitectura adecuada.
La canalización para crear las imágenes multiarquitectura
En nuestra demostración desarrollamos una canalización para crear imágenes de arquitectura múltiple mediante servicios de AWS como AWS CodePipeline y AWS CodeBuild. Utilizamos GitHub para alojar nuestros archivos, que serán utilizados por AWS CloudFormation y AWS CodeBuild para aprovisionar la pila necesaria y la compilación de imágenes Dockers, respectivamente, que son compatibles con cada arquitectura de procesador (x86 y ARM).
AWS CodePipeline se encarga de automatizar las fases de: compilar, probar e implementar el proceso de lanzamiento siempre que se detecte un cambio en el código, de acuerdo con el modelo de despliegue que haya definido. Puede integrar fácilmente AWS CodePipeline con servicios de terceros, como GitHub.
En nuestra canalización de AWS CodePipeline definimos etapas, que son unidades lógicas que puede utilizar para aislar un entorno y limitar el número de cambios simultáneos en ese entorno. Cada etapa contiene acciones que se realizan en artefactos de aplicación y se compone de un conjuto de acciones que se ejecutan en serie o en paralelo.
Para nuestro caso, hemos definido tres etapas: la primera etapa Source responsable de identificar los cambios en el repositorio de GitHub, y si ocurre algún cambio, iniciar la canalización. La segunda etapa de Build tiene dos acciones que se realizan en paralelo, una para crear una imagen Docker compatible con ARM y la otra para crear otra imagen compatible con arquitecturas x86. La tercera etapa BuildManifest crea una imagen Docker, que es el resultado de unir las dos imágenes construidas en la segunda etapa de Build. Nuestro clúster de Amazon EKS utilizará esta imagen para admitir varias arquitecturas.
A continuación se muestra un diseño de la arquitectura propuesta para lo que se mencionó anteriormente:
Figura 3: Arquitectura de canalizaciones de construcción de imágenes Docker
Implementación de la solución
Para que pueda experimentar este escenario en la práctica, creamos un repositorio en Github con los detalles técnicos de la implementación de esta Pipeline. Encontrará el repositorio en este enlace.
Conclusión
En este blog le mostramos cómo puede crear y utilizar imágenes de contenedor en múltiples arquitecturas de manera simple, desde la compilación hasta la implementación , en el caso de un clúster de Kubernetes gestionado por Amazon EKS.
Las imágenes de contenedor que se ejecutan en instancias de Graviton 2 son económicas y ofrecen mejor rendimiento en comparación con las instancias de la misma configuración x86, por lo que podemos utilizar esta nueva versión para optimizar nuestras cargas de trabajo que se ejecutan en un clúster de Kubernetes.
Este artículo fue traducido del Blog de AWS en Portugués
Sobre los autores
Lucas Duarte es Arquitecto de Soluciones de AWS. Actúa con clientes de la industria, es entusiasta con la automatización, la nube y la cultura de DevOps. Con experiencia previa en proyectos enfocados a este segmento en empresas como iFood, Guiabolso y Mandic. Ha estado trabajando en diferentes proyectos relacionadas principalmente con la orquestación de contenedores y microservicios.
Vinicius Silva es Arquitecto de Soluciones en AWS. Apoya a clientes de la educación, el gobierno, las organizaciones sin fines de lucro y la atención de la salud para alcanzar sus objetivos con la nube de AWS. Interesado en desarrollo y cultura de DevOps, tiene contribuciones anteriores en el desarrollo de plataformas web distribuidas y escalables.
Ernesto dos Santos es Arquitecto de Soluciones de AWS. Actos de asistencia y apoyar a los clientes del sector público en su viaje a la nube de AWS, trabajando en proyectos que implican arquitecturas distribuidas y escalables. Tiene gran interés en el área de seguridad de la información, infraestructura, redes y sin servidor.
Revisor
Cristian Castellanos es Arquitecto de Soluciones en Amazon Web Services para el Sector Público. Cristian ha ayudado a múltiples instituciones educativas y de gobierno en la adopción de nuevas tecnologías e implementación de soluciones de analítica.
Referencias: