La gestión de infraestructura distribuida on-premises a escala, especialmente en entornos con requisitos de soberanía de datos o conectividad intermitente, presenta desafíos fundamentales de consistencia, automatización y observabilidad. La proliferación de hardware heterogéneo y la necesidad de mantener planos de control de Kubernetes localmente, como con EKS Anywhere, exacerban la complejidad. Este artículo propone un patrón arquitectónico para centralizar la orquestación y el estado en la nube, mientras se mantiene la ejecución de operaciones en el borde, desacoplando el plano de control del plano de datos. Esto permite aplicar principios de gestión de infraestructura como código y automatización de ciclo de vida a entornos tradicionalmente manuales y fragmentados, escalando desde decenas a miles de máquinas.
El problema subyacente es la coordinación de estado y la ejecución de operaciones en un sistema distribuido geográficamente disperso, donde la latencia y la fiabilidad de la red son variables. La solución se apoya en un modelo de 'event-driven architecture' para desacoplar los componentes y permitir la resiliencia ante fallos parciales, y en un 'single source of truth' para el estado de la infraestructura, lo que es crítico para evitar la deriva de configuración y garantizar la consistencia operativa. La elección de tecnologías serverless en AWS para el plano de control centralizado reduce la carga operativa de la propia infraestructura de orquestación.
Arquitectura del Sistema
La arquitectura se compone de tres capas principales: un motor de orquestación centralizado en AWS, infraestructura on-premises distribuida con clusters EKS Anywhere, y conectividad híbrida. El motor de orquestación se basa en un 'Inventory Management System' que utiliza Amazon DynamoDB como repositorio central de estado para recursos como sitios, servidores, clusters y órdenes. DynamoDB almacena configuraciones de hardware (versiones de BIOS/firmware), detalles de red, estado operacional, configuraciones de Kubernetes y relaciones entre clusters.
El motor de orquestación es 'event-driven', con Amazon API Gateway exponiendo una interfaz RESTful para operaciones CRUD. Las funciones AWS Lambda procesan las solicitudes, validan parámetros e inician operaciones. La capa de orquestación utiliza AWS Step Functions para ejecutar 'state machines' que integran servicios AWS para cómputo, almacenamiento y red. Step Functions soporta un patrón de 'callback' crucial para operaciones híbridas de larga duración, pausando el workflow hasta que un sistema on-premises señala su finalización. El estado 'Distributed Map' de Step Functions permite escalar operaciones a miles de recursos simultáneamente. Amazon EventBridge proporciona automatización basada en eventos, disparando workflows de Step Functions en respuesta a cambios de estado en el inventario. La seguridad se gestiona con AWS Systems Manager Parameter Store para configuraciones, AWS Secrets Manager para credenciales, AWS IAM para control de acceso y AWS IAM Roles Anywhere para acceso seguro desde on-premises sin credenciales de larga duración. AWS Systems Manager Hybrid Activations registra instancias on-premises para una gestión unificada. La gestión de órdenes coordina operaciones a escala, utilizando reglas de EventBridge para mapear operaciones de API a workflows de Step Functions, registrando el estado en DynamoDB y permitiendo el seguimiento asíncrono del ciclo de vida de la orden.
Flujo de Creación de Cluster EKS Anywhere
- 1 Operador Solicita creación de cluster vía API Gateway
- 2 Lambda API Handler Valida request, crea Order en DynamoDB, emite evento
- 3 EventBridge Ruta evento a Step Functions workflow
- 4 Step Functions Workflow Orquesta pasos: selección de hardware, pre-checks, bootstrapping Admin machine
- 5 SSM / Batch Ejecuta comandos EKS Anywhere CLI en servidores on-premises
- 6 EKS Anywhere (On-Premises) Network boot, instala OS y Kubernetes, levanta cluster
- 7 Step Functions Workflow Espera callback de finalización de EKS Anywhere
- 8 ADOT Collector Envía métricas a Prometheus/Grafana en AWS
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | AWS Step Functions | Motor de workflow para orquestar operaciones de ciclo de vida, con lógica de reintento, manejo de errores y soporte para callbacks asíncronos para tareas on-premises de larga duración. vs Apache Airflow, Temporal.io Uso de Distributed Map state para escalar operaciones a miles de recursos; Callback pattern para integración con sistemas on-premises. |
| storage | Amazon DynamoDB | Base de datos NoSQL para el 'Inventory Management System', actuando como 'single source of truth' para el estado de la infraestructura (sitios, servidores, clusters, órdenes). vs Amazon Aurora, Amazon RDS Uso de DynamoDB Streams para disparar eventos en cambios de estado, integrando con Lambda para actualizaciones de DNS. |
| compute | AWS Lambda | Funciones serverless para la capa API, procesando solicitudes CRUD, validando parámetros e iniciando operaciones de orquestación. vs AWS Fargate, Amazon EC2 |
| messaging | Amazon EventBridge | Bus de eventos para la arquitectura 'event-driven', enrutando eventos desde la API y cambios de estado del inventario a los workflows de Step Functions. vs Amazon SQS, Amazon SNS Reglas de EventBridge para mapear operaciones de API a workflows específicos de Step Functions. |
| orchestration | Amazon EKS Anywhere | Plataforma para desplegar y operar clusters Kubernetes en infraestructura on-premises, utilizando la misma distribución de EKS de la nube. vs OpenShift, Rancher Kubernetes Engine Soporte para bare-metal provider; integración con AWS Systems Manager para ejecución de comandos on-premises. |
| security | AWS IAM Roles Anywhere | Proporciona credenciales AWS de corta duración a cargas de trabajo on-premises, eliminando la necesidad de almacenar claves de larga duración en el borde. vs IAM roles con OIDC, AWS Access Keys Uso de certificados de CA de cluster como 'trust anchors' para la emisión de credenciales. |
| observability | AWS Distro for OpenTelemetry (ADOT) | Colector de telemetría desplegado en cada cluster EKS Anywhere para raspar y reenviar métricas de servidor, Kubernetes y aplicación a servicios de monitoreo en AWS. vs Prometheus Node Exporter, Fluent Bit Integración con Amazon Managed Service for Prometheus y Amazon Managed Grafana. |
| networking | Redfish APIs | Protocolo estándar para la gestión de hardware, proporcionando APIs agnósticas al proveedor para control de servidores bare-metal (BIOS, firmware, energía, salud). vs IPMI, Vendor-specific APIs |
Fundamentos Teóricos
El problema de mantener la consistencia del estado y coordinar operaciones en sistemas distribuidos geográficamente dispersos ha sido un tema central en la investigación de sistemas distribuidos desde sus inicios. Conceptos como el 'two-phase commit' o 'three-phase commit' (Gray, 1978) abordan la consistencia transaccional, aunque con limitaciones de disponibilidad y latencia en entornos WAN. La arquitectura propuesta, al centralizar el estado en DynamoDB, se alinea con el principio de 'single source of truth', un concepto fundamental en la gestión de configuración y automatización.
El uso de un motor de orquestación 'event-driven' con 'callbacks' y 'state machines' en Step Functions refleja patrones de 'workflow management' que se han estudiado en la academia para garantizar la progresión y la resiliencia de procesos de negocio complejos. La gestión de inventario como un 'eventual consistency' store, donde los cambios de estado disparan acciones asíncronas, es un patrón común en sistemas distribuidos a gran escala, donde la consistencia fuerte global es prohibitivamente costosa en términos de latencia y disponibilidad, como se describe en el teorema CAP (Brewer, 2000) y su extensión PACELC (Abadi, 2012). La capacidad de EKS Anywhere para operar en entornos DDIL (Disconnected, Disrupted, Intermittent, or Limited) resalta la necesidad de arquitecturas que puedan tolerar particiones de red, un desafío clásico en la computación distribuida.