Rediseño de la carga de trabajo del flujo de trabajo basado en eventos (EDW) para Azure Kubernetes Service (AKS)
Ahora que conoce algunas diferencias clave de la plataforma entre AWS y Azure relevantes para esta carga de trabajo, echemos un vistazo a la arquitectura de flujo de trabajo; podemos cambiarla para trabajar en AKS.
La carga de trabajo de AWS es un ejemplo básico del patrón de diseño de consumidores competidores. La implementación de AWS es una arquitectura de referencia para administrar la escala y el coste de los flujos de trabajo controlados por eventos mediante Kubernetes, el escalado automático controlado por eventos (KEDA) de Kubernetes y Karpenter.
Una aplicación de productor genera carga mediante el envío de mensajes a una cola, y una aplicación de consumidor que se ejecuta en un pod de Kubernetes procesa los mensajes y escribe los resultados en una base de datos. KEDA administra el escalado automático de pods a través de un enlace declarativo a la cola del productor y Karpenter administra el escalado automático de nodos con un proceso suficiente para optimizar el coste. La autenticación en la cola y la base de datos usa la proyección de volumen de token de cuenta de servicio basada en OAuth.
La carga de trabajo consta de un clúster de AWS EKS para organizar que los consumidores lean mensajes de un Amazon Simple Queue Service (SQS) y guarden los mensajes procesados en una tabla de Amazon DynamoDB. Una aplicación de productor genera mensajes y las coloca en la cola de Amazon SQS. KEDA y Karpenter escalan dinámicamente el número de nodos y pods EKS usados para los consumidores.
En el diagrama siguiente se representa la arquitectura de la carga de trabajo de EDW en AWS:
Para volver a crear la carga de trabajo de AWS en Azure con cambios mínimos, use un equivalente de Azure para cada servicio de AWS y mantenga los métodos de autenticación similares a los originales. En este ejemplo no se requieren las características avanzadas de Azure Service Bus o Azure Event Hubs. En su lugar, puede usar Azure Queue Storage para poner en cola el trabajo y Azure Table Storage para almacenar los resultados.
En la tabla siguiente, se resume la asignación de servicios:
Asignación de servicios | Servicio de AWS | Servicio de Azure |
---|---|---|
Cola | Simple Queue Service | Azure Queue Storage |
Persistencia | DynamoDB (sin SQL) | Azure Table Storage |
Orquestación | Elastic Kubernetes Service (EKS) | Azure Kubernetes Service (AKS) |
Identidad | AWS IAM | Microsoft Entra |
En el diagrama siguiente se representa la arquitectura de la carga de trabajo de Azure EDW mediante la asignación de servicios de AWS a Azure:
En función de las consideraciones de costes y la resistencia a la posible expulsión de nodos, puede elegir entre diferentes tipos de proceso.
En AWS, puede elegir entre el proceso a petición (más caro, pero sin riesgo de expulsión) o las instancias de acceso puntual (más baratas, pero con riesgo de expulsión). En AKS, puede elegir un grupo de nodos a petición o un grupo de nodos de acceso puntual en función de las necesidades de la carga de trabajo.
Microsoft se encarga del mantenimiento de este artículo. Los siguientes colaboradores lo escribieron originalmente:
- Ken Kilty | TPM de entidad de seguridad
- Russell de Pina | TPM de entidad de seguridad
- Jenny Hayes | Desarrollador de contenido sénior
- Carol Smith | Desarrollador de contenido sénior
- Erin Schaffer | Desarrollador de contenido 2
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: