04 de octubre de 2023

Kubernetes en AWS by acens sin complicaciones

En este post sobre AWS by acens, Manuel Eusebio de Paz Carmona (AWS Enterprise Architect en acens), te explica cómo abstraer la complejidad de una plataforma de orquestación de contenedores utilizando EKS blueprints, un potente framework que nos permite desplegar y utilizar técnicas de GitOps y está listo para producción en muy poco tiempo.

En general tendemos a describir los frameworks tecnológicos como una capa de abstracción sobre un lenguaje de programación; un añadido o constructo que incluye una serie de funcionalidades, herramientas y una propuesta estructural. Mientras que extender un lenguaje de programación con módulos adicionales es más o menos sencillo por su propia naturaleza, crear abstracciones formadas por herramientas y entidades lógicas que sean más o menos útiles en varios contextos es bastante más complejo.

Basándome en esta definición, quería compartir mi experiencia utilizando EKS blueprints, un framework impulsado por AWS y mantenido por la comunidad en torno a Kubernetes. Construido en dos sabores: terraform y CDK, este software ha sido desarrollado para facilitar la creación de una plataforma de orquestación de contenedores sobre EKS, en condiciones productivas y con una amplia selección de herramientas

¿Qué son los EKS Blueprints?

En el caso de EKS Blueprints, las herramientas adicionales son utilidades para gestión de despliegues, librerías… en su mayoría parte de la CNCF. GitOps como filosofía para manejar y estructurar los proyectos, Terraform/CDK como lenguajes para extenderlo y una serie de entidades lógicas para representar los roles de las personas que operan una plataforma de contenedores basada en Kubernetes. Según esta definición, cada equipo trabajaría en su área, pero escribiendo en un lenguaje común (yaml), y en el lenguaje particular de su área (terraform o CDK), o el lenguaje de su aplicación respectivamente.

El anterior diagrama de arquitectura representa un entorno EKS que se puede configurar e implementar con EKS Blueprints. El diagrama ilustra un clúster EKS que se ejecuta en tres zonas de disponibilidad, se arranca con una amplia gama de complementos de Kubernetes y aloja cargas de trabajo de varios equipos diferentes.

Breve análisis del framework

En la documentación de la herramienta existen diversos ejemplos de complejidad incremental, un sistema de versionado semántico y varios repositorios. Para la versión de terraform, en el momento de escribir estas líneas, acaban de lanzar la versión 4.29.0 y ya se especula con los cambios de la versión 5, que como ya indican en su repositorio supondrá un importante punto de ruptura en cuanto al manejo de dependencias y estructuración de los módulos. Por otro lado, también existe abundante documentación y material didáctico en forma de talleres, que compartiremos al final del artículo.

Pros

El principal punto fuerte de esta herramienta es la facilidad de despliegue de un entorno listo para producción. Creando una stack de terraform relativamente sencillo, podemos definir nuestro cluster EKS y en el mismo contexto añadir módulos de funcionalidad variada pero esencial: observabilidad, despliegues, gestión del sistema de archivos y un largo etcétera.

Este constructo nos permite sentar las bases para recibir cargas de trabajo y dar autonomía a otros equipos para que las operen bajo las condiciones y límites que definamos. Las posibilidades son enormes y el ahorro de tiempo notable. Además, está vinculado al uso de roles de AWS para su operación, lo que se adapta muy bien al contexto de gobierno de la nube. Finalmente, también tiene espacio para estructuras más complejas, como los clústeres multitenant.

Contras

Como punto de mejora, creo que ayudaría mucho centralizar y mejorar la organización del código y los ejemplos en una organización GitHub, ya que la mayor parte del material está repartido entre tres grandes organizaciones y numerosos directorios y ramas, resultado de lo que parece ser un crecimiento orgánico unido al uso de herramientas de distribución automatizada.

¿Qué motivo me llevaría a utilizarlo?

La principal razón para utilizar esta herramienta es que combina experiencia con orquestación de contenedores de última generación, además de ser una solución de código abierto. Contar con este recurso, o al menos valorarlo, nos hace productivos en poco tiempo y de forma sostenible.

Algunos procesos deben realizarse alguna vez durante el aprendizaje. Esta práctica forma parte de muchos itinerarios de aprendizaje, pero además, experimentando por uno mismo se consigue una mejor comprensión e interiorización de los conceptos y dependencias. En este sentido, montar un clúster de Kubernetes, configurarlo y conectarlo con herramientas como argocd, gestionar permisos, etc., es una buena forma de lograrlo, sin embargo, esto no es siempre posible de aplicar.

Como punto adicional, no se trataría de una decisión irreversible, ya que se puede operar en el contexto de los contenedores sin esta parafernalia, aunque de forma mucho menos cómoda.