Uso de GitOps con Amazon Elastic Kubernetes Service con Landbay

En el cambiante panorama de los préstamos digitales, Landbay, un aclamado prestamista hipotecario en el mercado de compra para alquiler del Reino Unido, está revolucionando su infraestructura digital. Landbay, que cuenta con la mejor plataforma de corretaje del sector y que respalda sus operaciones de inversión, se basa en los servicios de AWS e incluye aproximadamente 60 microservicios con una arquitectura de tres niveles, que combina servidores web, Amazon Elastic Kubernetes Service (Amazon EKS) y una capa de datos de varios niveles. Al combinar la potencia de los servicios en la nube de AWS con los proyectos de código abierto, Landbay pudo aprovechar este nuevo enfoque para crear la mejor arquitectura del sector basada en Amazon Elastic Kubernetes Service.

La ventaja de GitOps

A medida que las arquitecturas de microservicios ganan protagonismo, GitOps se ha convertido en un nuevo estándar para este mecanismo de despliegue. Dentro de la Fundación de Computación Nativa en la Nube (CNCF) han surgido dos productos notables: Flux y ArgoCD. Landbay seleccionó a Flux por su integración nativa con Kubernetes al exponer definiciones de recursos (CRD) personalizadas para definir los despliegues, gestionar las versiones, las kustomizaciones y mucho más. Esto, a su vez, permitió a los ingenieros de software dominar Kubernetes y, por lo tanto, comprender mejor cómo Flux encaja en el ecosistema.

Información general de la solución

Para ofrecer una comprensión completa de la implementación de Landbay en GitOps, revisemos los componentes arquitectónicos clave y sus relaciones dentro del ecosistema de AWS:

• Amazon Elastic Container Registry (ECR): Landbay utiliza Amazon ECR para almacenar gráficos de Helm e imágenes de Docker.
• Controladores externos de DNS y AWS Elastic Load Balancing: estos controladores se usan para configurar Route53 y los equilibradores de carga, lo que garantiza el acceso externo a las entradas de Kubernetes.
  
• Integración de AWS Secrets Manager: por motivos arquitectónicos y de seguridad, Landbay ha optado por la integración directa con AWS Secrets Manager, en lugar de utilizar herramientas externas, como el controlador de secretos externo, que se alinea con el modelo de responsabilidad compartida de AWS y mejora la postura de seguridad general de la solución.
  
• Gestión de la configuración de Terraform: Terraform se puede usar para cerrar la brecha proporcionando un ConfigMap y resumiendo los elementos clave de la configuración (puntos de enlace, CIDR de subredes, etc.). Luego, Flux puede usar el mapa de configuración a través de su característica posterior a la compilación (vea la figura 2).
  

Arquitectura de datos y entorno de Kubernetes de Landbay

Landbay es un entusiasta adoptador de Terraform y toda su infraestructura está codificada con infraestructura como código (IAC). Este enfoque garantiza la sincronía entre los entornos de prueba y producción y garantiza que todos los cambios en la infraestructura pasen por el proceso estándar del ciclo de vida del desarrollo de software.

Para garantizar que no haya ningún tiempo de inactividad durante las actualizaciones de Amazon EKS, Landbay utiliza grupos de nodos gestionados por EKS con tres grupos de nodos gestionados, cada uno dirigido a una zona de disponibilidad específica. Esta configuración les permite utilizar volúmenes persistentes, gracias al controlador CSI de Amazon Elastic Block Store (EBS). Además, Landbay usa topologySpreadConstraints (DoNotSchedule) para garantizar que los StatefulSets estén distribuidos en todas las zonas de disponibilidad.

Para los servicios críticos, las clases de prioridad personalizadas se utilizan para desalojar los despliegues de menor prioridad.

Para reducir los costos en el entorno de prueba, Landbay aprovecha la potencia de las instancias de spot de Amazon EC2 a través de grupos de nodos administrados por Terraform y Amazon EKS.

Por último, Landbay ha adoptado Bottlerocket al presentar una superficie expuesta a ataques muy reducida. Su operador Kubernetes se utiliza para actualizar gradualmente los nodos de un clúster utilizando el concepto de ondas. Si bien el acceso al sistema de archivos raíz está bloqueado, la integración con IAM y Systems Manager (SSM) satisface los requisitos fundamentales de Landbay.

Complementos de Amazon EKS

Además del complemento CNI de Amazon Virtual Private Cloud (Amazon VPC), Landbay ejecuta los siguientes complementos:

1. CoreDNS: garantiza la resolución del servicio DNS dentro del clúster
2. KubeProxy: sustenta la detección de servicios y la creación de redes en Kubernetes.
   
3. CNI de Amazon VPC con enableNetworkPolicy: permite la aplicación de políticas de red, lo que ayuda a Landbay a proteger varios accesos a los espacios de nombres y los pods.
   
4. Controlador CSI de Amazon EBS: permite el uso de volúmenes persistentes.
   

Configuración de administración de acceso

Landbay utiliza AWS IAM Identity Center para controlar todos los accesos a las API de AWS. Amazon EKS permite asignar los roles de SSO a grupos de Kubernetes, lo que permite la asignación indirecta a grupos de Azure Entra ID a través del equipo de administración de TI. Este enfoque garantiza la separación de las preocupaciones entre el equipo de administración de TI y el resto de la organización.

El fragmento anterior se puede usar para configurar un recurso aws_auth de kubernetes_config_map_v1-data:

Para evitar la proliferación de roles, Kubernetes proporciona un mecanismo para acumular los permisos de otras versiones de Helm en los grupos existentes mediante el método “agregar para administrar”:

Controlador de equilibrador de carga de AWS

Para mejorar la integración entre los servicios, Landbay ha aprovechado el controlador de equilibrador de carga de AWS (LBC) y el controlador de DNS externo.

El controlador de equilibrador de carga de AWS permite el aprovisionamiento de equilibradores de carga directamente desde Ingresses, así como la capacidad de reutilizar los equilibradores de carga administrados externamente y asignar pods de destino. Al separar el aprovisionamiento de los equilibradores de carga en un proyecto independiente, los equipos de DevOps pueden tener más privilegios en un repositorio de código fuente y, al mismo tiempo, ofrecer las herramientas necesarias a los ingenieros que gestionan los objetivos.

El controlador también administra los grupos de seguridad según sea necesario en el backend entre el equilibrador de carga y sus objetivos. Además, al usar la anotación group.name, se puede compartir el mismo equilibrador de carga con varios grupos objetivo en segundo plano

Landbay también usa el controlador de equilibrador de carga de AWS para aprovisionar de equilibradores de carga de red a fin de permitir el ingreso de las funciones de AWS Lambda que se ejecutan de la VPC a la infraestructura de EKS.

Como añadido, el controlador DNS externo permite a los pods de Kubernetes un acceso de escritura limitado a Route53. Esta característica facilita la exposición automática de los servicios externos con nombres DNS fáciles de usar de forma automática, lo que mejora la experiencia general del usuario.

Desde el punto de vista de la seguridad, el equilibrador de carga de aplicación (ALB) y el controlador DNS externo requieren un conjunto limitado de permisos de IAM, que se pueden bloquear de forma estricta. Por ejemplo, el controlador de DNS solo necesita acceso de escritura a zonas específicas de Route 53 (route53:ChangeResourceRecordSets), así como algunos permisos de Lista.

Gestión de secretos en Kubernetes

Si bien la mayoría de las soluciones abordan problemas relacionados con la administración de secretos, como la rotación de secretos y la integración, el uso del almacenamiento de secretos de Kubernetes o la sincronización de secretos externos con Kubernetes hará que los secretos se almacenen en texto sin cifrar en el etcd subyacente de Kubernetes. Si bien el uso de “secretos cifrados en EKS” ayuda a mitigar los vectores de ataque físicos, el acceso a través de la API de Kubernetes expone los valores sin procesar del secreto, según el modelo de responsabilidad compartida de AWS.

El uso del controlador Container Storage Interface (CSI) proporcionado por AWS ofrece beneficios, pero también aleja la arquitectura de la administración nativa de Kubernetes. Teniendo en cuenta que tanto el controlador CSI como la solución de un proveedor externo requieren una integración directa con el proveedor de secretos externo, Landbay decidió integrar sus microservicios directamente con AWS Secret Manager.

La opción de integración directa evita introducir más complejidad en el entorno, lo que de otro modo podría generar mayores costos de mantenimiento y soporte. También evita la presencia de secretos sin texto en los volúmenes de los contenedores, lo que mejora aún más la seguridad.

Aprovisionamiento de Flux en el entorno de AWS

Flux, la solución GitOps elegida por Landbay, proporciona un proveedor de Terraform para activar clústeres de EKS. A intervalos regulares y configurables, Flux se asegura de que todos los manifiestos de Kubernetes definidos en el repositorio de Git se concilien con los recursos existentes desplegados en Kubernetes, lo que anula cualquier desviación detectada. Una vez que se activa, Flux puede realizar su primera reconciliación e instalar los servicios configurados, los pods, los conjuntos con estado, etc., en el clúster de Kubernetes, tal y como se muestra en la siguiente figura.

Flux puede aprovechar AWS Elastic Container Registry (ECR) como repositorio de Helm, ya que ECR cuenta con un soporte de primera clase para artefactos de OCI. Esto permite a Flux actuar como enlace entre ECR y EKS, utilizando Kustomizations para aplicar configuraciones específicas del entorno.

Una ventaja clave de este enfoque es la separación lógica entre la parte de integración continua (CI) del proceso de despliegue (compilación, prueba y paquete) y la parte de despliegue continuo (CD) (entrega al entorno). Desde el punto de vista de la seguridad, Flux impulsa los cambios, lo que permite bloquear significativamente los permisos de acceso para los despliegues diarios. Para evitar demoras en el despliegue, el único permiso que se requiere es que la herramienta de compilación “notifique” a Flux una reconciliación temprana, lo que se puede realizar mediante un kubeconfig bloqueado con un usuario restringido.

Como resultado, implementar, revertir o promover un nuevo microservicio es tan sencillo como actualizar un fragmento de control de versiones semánticas (semver) en un archivo YAML o revertir una confirmación. Al observar un cambio en Git, Flux activa una reconciliación con Kubernetes y actualiza el servicio correspondiente en consecuencia.

Estructura del repositorio de Flux y componentes compartidos

Flux proporciona documentación completa sobre las estructuras de repositorio recomendadas. El enfoque de Landbay es relativamente sencillo y sigue estas mejores prácticas.

Las configuraciones de clúster se definen en sus propias carpetas dedicadas, cada una de las cuales hace referencia a los componentes compartidos. Dentro de estas carpetas de clústeres, el uso extensivo de Kustomizations garantiza el aislamiento entre los clústeres. Esto permite realizar configuraciones específicas del entorno, como el control de versiones y la memoria.

La estructura ilustrada anteriormente logra un equilibrio entre el código compartido y la retención de la naturaleza declarativa y explícita del paradigma de GitOps, lo que permite a un ingeniero leer un repositorio de Git y determinar qué componentes, versiones o paquetes se han instalado en el clúster.

Al separar los componentes, Landbay puede agilizar el proceso de creación de nuevos clústeres. A partir de aquí, la configuración de los clústeres pasa a ser una cuestión de elegir “ladrillos LEGO” y ensamblarlos con alguna configuración específica para el entorno.

Además, si bien algunos clústeres funcionan en la nube y requieren componentes adicionales, otros clústeres pueden estar dirigidos a ingenieros de DevOps que trabajan localmente. Este enfoque de desarrollo local proporciona un ciclo de retroalimentación más rápido y no incluye componentes directamente relacionados con los servicios de AWS.

El desarrollo local como trampolín

Este enfoque de desarrollo local también es el trampolín para despliegues rápidos de entornos de desarrollo efímeros basados en la nube. Al utilizar los espacios de nombres de Kubernetes y eliminar las dependencias de los servicios gestionados de AWS, Landbay puede utilizar Flux para arrancar rápidamente nuevos entornos autónomos.

En este caso, el entorno de desarrollo de Landbay podría reemplazar el servicio de base de datos relacional de Amazon (RDS) por un contenedor MariaDB simple, Amazon OpenSearch Service por el contenedor OpenSearch equivalente. Si bien este enfoque mantiene los entornos de desarrollo “en sintonía” desde el punto de vista arquitectónico (por ejemplo, la asignación de nombres, la detección de servicios o la creación de redes similares), la desventaja es la falta de resiliencia operativa, que puede resultar aceptable en algunos entornos de desarrollo.

Integración de los servicios de EKS, GitOps y AWS

En Landbay, la infraestructura de AWS está gestionada en su totalidad por Terraform . Por lo tanto, es imprescindible cerrar la brecha entre los elementos aprovisionados por Terraform (RDS, OpenSearch, etc.) y otros pods que se ejecutan en el clúster. La forma nativa de acceder a la configuración de Kubernetes en microservicios es a través de ConfigMaps.

El siguiente diagrama muestra la interrelación entre nuestros proyectos Terraform y Flux.

El primer proyecto de Terraform es responsable de configurar todas las redes básicas, los equilibradores de carga conectados a Internet y los servicios gestionados de AWS. El segundo proyecto establece el clúster de EKS, inicia Flux en el clúster, activa el clúster de EKS, configura cualquier rol de IAM y gestiona problemas de bajo nivel, como los grupos de nodos gestionados que ejecutan Bottlerocket. Este proyecto crea un ConfigMap de entorno que consulta en AWS todas las variables ambientales y las inyecta en Kubernetes.

El proyecto final es un proyecto dedicado a Flux. Esto define la configuración del clúster para el entorno, enlaza a un conjunto de componentes compartidos y, posteriormente, kustomiza las versiones de Helm y los manifiestos de Kubernetes para adaptarlos al entorno correspondiente. Luego, el ConfigMap de entorno se puede usar como parte de las personalizaciones dentro del repositorio de Flux. Flux también ofrece una característica de sustitución de variables posterior que permite el uso de sustituciones de variables con un amplio conjunto de funciones de reemplazo de cadenas de bash bien definidas.

Por ejemplo, en un gráfico de Helm, los valores pueden utilizar la sustitución de variables después de la creación. Como se puede ver en la siguiente ilustración, este enfoque mejora el repositorio de GitOps para que los componentes compartidos sean independientes del entorno.

Conclusión

La decisión de Landbay de adoptar GitOps a través de Flux, que está estrechamente integrado tanto con Amazon EKS como con el ecosistema más amplio de AWS, ha supuesto un punto de inflexión. Al adoptar este enfoque vanguardista, Landbay ha obtenido una miríada de beneficios que han simplificado sus operaciones y elevado su postura de seguridad. Quizás una de las ventajas más importantes haya sido la obtención de eficiencias de ingeniería en todos los ámbitos. La integración de GitOps con los servicios de EKS y AWS ha revolucionado los procesos de desarrollo de Landbay, desde despliegues más rápidos y tiempos de espera reducidos hasta un aprovechamiento perfecto de las soluciones de terceros.

Además, el panorama de seguridad de Landbay se ha fortalecido y se ha vuelto más sólido y rentable de mantener. Al aprovechar Bottlerocket, segregar las funciones mediante permisos SCM/Git y permitir actualizaciones sencillas a través de Helm, Landbay ha consolidado su compromiso con la seguridad y, al mismo tiempo, ha optimizado los costos operativos.

El impacto más profundo de este viaje transformador radica en la mayor visibilidad y transparencia del estado y los cambios de la carga de trabajo de EKS. Con GitOps, la configuración se declara mediante YAML y todas las modificaciones se almacenan como confirmaciones de Git. Este cambio de paradigma ha supuesto importantes ventajas para los equipos de soporte, riesgo, cumplimiento y auditoría de Landbay, ya que les ha permitido disponer de una visión y un control sin precedentes sobre sus sistemas de misión crítica.

Si tiene todo listo para transformar su startup como Landbay, únase a AWS Activate para obtener acceso a plantillas desplegables, créditos de AWS y oportunidades de aprendizaje.