Rediseño de la aplicación web aws EKS para Azure Kubernetes Service (AKS)

Ahora que conoce mejor las diferencias de plataforma entre AWS y Azure, vamos a examinar la arquitectura de aplicaciones web en AWS y las modificaciones necesarias para que sea compatible con Azure Kubernetes Service (AKS).

Arquitectura de aplicaciones de Yelb

La aplicación web de ejemplo de Yelb consta de un componente front-end denominado yelb-ui y un componente de aplicación denominado yelb-appserver.

Diagrama de arquitectura de la aplicación web de Yelb.

yelb-ui sirve código JavaScript al explorador. Este código se compila desde una aplicación de Angular . El yelb-ui componente también puede incluir un nginx proxy en función del modelo de implementación. yelb-appserver es una aplicación de Sinatra que interactúa con un servidor de caché (redis-server) y una base de datos back-end de Postgres (yelb-db). Redis Cache almacena el número de vistas de página, mientras PostgreSQL mantiene los votos. Ambos servicios se implementan en Kubernetes sin usar ningún servicio administrado para almacenar datos en AWS o Azure.

La aplicación Yelb original es independiente y no depende de servicios externos, por lo que puede migrarla de AWS a Azure sin ningún cambio de código. En Azure, puede usar Azure Cache for Redis y Azure Database for PostgreSQL como reemplazos de los servicios de Redis Cache y PostgreSQL implementados en AKS.

La aplicación Yelb de ejemplo permite a los usuarios votar sobre un conjunto de alternativas (restaurantes) y actualizar dinámicamente gráficos circulares en función del número de votos recibidos. La aplicación también realiza un seguimiento del número de vistas de página y muestra el nombre de host de la yelb-appserver instancia que atiende la solicitud de API tras un voto o una actualización de página. Esta característica le permite demostrar la aplicación de forma independiente o colaborativa.

Captura de pantalla de la interfaz del servicio Yelb.

Arquitectura en AWS

Para ayudar a proteger las aplicaciones web y las API frente a vulnerabilidades de seguridad web comunes, AWS ofrece AWS Web Application Firewall (WAF) y AWS Firewall Manager.

Mapear servicios de AWS a servicios de Azure

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. En la tabla siguiente, se resume la asignación de servicios:

Asignación de servicios	Servicio de AWS	Servicio de Azure
Firewall de acceso web	Firewall de aplicaciones web (WAF) de AWS	Firewall de aplicaciones web (WAF) de Azure
Equilibrio de carga de la aplicación	Equilibrador de carga de aplicaciones (ALB)	Azure Application Gateway Application Gateway para Contenedores (AGC)
Red de entrega de contenido	Amazon CloudFront	Azure Front Door (AFD)
Orquestación	Elastic Kubernetes Service (EKS)	Azure Kubernetes Service (AKS)
Almacén de secretos	AWS Key Management Service (KMS)	Azure Key Vault
Registro de contenedor	Amazon Elastic Container Registry (ECR)	Azure Container Registry (ACR)
Sistema de nombres de dominio (DNS)	Amazon Route 53	DNS de Azure
Almacenamiento en memoria caché	Amazon ElastiCache	Azure Cache for Redis
NoSQL	Amazon DynamoDB	Azure Database para PostgreSQL

Para obtener una comparación completa entre los servicios de Azure y AWS, consulte Comparación de servicios de AWS a Azure.

Arquitectura en Azure

En esta solución, la aplicación Yelb se implementa en un clúster de AKS y se expone a través de un controlador de entrada como el controlador de entrada NGINX. El servicio del controlador de entrada se expone a través de un equilibrador de carga interno (o privado). Para más información sobre cómo usar un equilibrador de carga interno para restringir el acceso a las aplicaciones en AKS, consulte Uso de un equilibrador de carga interno con Azure Kubernetes Service (AKS).

Este ejemplo admite la instalación de un controlador de entrada NGINX administrado con el complemento de enrutamiento de aplicaciones o un controlador de entrada NGINX no administrado mediante el gráfico de Helm. El complemento de enrutamiento de aplicaciones con el controlador de entrada NGINX proporciona las siguientes características:

Configuración sencilla de controladores de entrada NGINX administrados basados en el controlador de entrada NGINX de Kubernetes.
Integración con Azure DNS para la administración de zonas públicas y privadas.
Terminación SSL con certificados almacenados en Azure Key Vault.

Para ver otras configuraciones, consulte los siguientes artículos:

La aplicación Yelb está protegida con un recurso de Azure Application Gateway implementado en una subred dedicada dentro de la misma red virtual que el clúster de AKS o en una red virtual emparejada. Puede proteger el acceso a la aplicación Yelb mediante Azure Web Application Firewall (WAF), que proporciona protección centralizada de las aplicaciones web frente a vulnerabilidades y vulnerabilidades comunes.

Diseño de la arquitectura de la solución

En el diagrama siguiente se muestra la arquitectura recomendada en Azure:

La arquitectura de la solución consta de lo siguiente:

Application Gateway controla la terminación TLS y se comunica con la aplicación back-end a través de HTTPS.
El agente de escucha de Application Gateway usa un certificado SSL obtenido de Azure Key Vault.
La directiva de WAF de Azure asociada al agente de escucha ejecuta reglas de OWASP y reglas personalizadas en las solicitudes entrantes y bloquea los ataques malintencionados.
La configuración HTTP de back-end de Application Gateway invoca la aplicación Yelb a través de HTTPS en el puerto 443.
El grupo de back-end y el sondeo de estado de Application Gateway llaman al controlador de entrada NGINX a través del equilibrador de carga interno de AKS mediante HTTPS.
El controlador de entrada NGINX usa el equilibrador de carga interno de AKS.
El clúster de AKS está configurado con el Proveedor de Azure Key Vault para el complemento del controlador CSI del almacén de secretos para recuperar secretos, certificados y claves de Azure Key Vault a través de un Volumen CSI.
SecretProviderClass recupera el mismo certificado usado por Application Gateway desde Azure Key Vault.
Un objeto de entrada de Kubernetes emplea el controlador de entrada NGINX para exponer la aplicación a través de HTTPS a través del equilibrador de carga interno de AKS.
El servicio Yelb es de tipo ClusterIP y se expone a través del controlador de entrada NGINX.

Para obtener instrucciones completas sobre cómo implementar la aplicación Yelb en AKS mediante esta arquitectura, consulte el ejemplo complementario.

Soluciones alternativas

Azure ofrece varias opciones para implementar una aplicación web en un clúster de AKS y protegerla con un firewall de aplicaciones web:

Application Gateway Ingress Controller (AGIC) es una aplicación de Kubernetes, por lo que puede aprovechar el equilibrador de carga L7 de Application Gateway nativo de Azure para exponer software en la nube a Internet para las cargas de trabajo de Azure Kubernetes Service (AKS). AGIC supervisa el clúster de Kubernetes en el que se hospeda y actualiza continuamente una instancia de Application Gateway para que los servicios seleccionados se expongan a Internet.

El controlador de entrada se ejecuta en su propio pod en el clúster de AKS. AGIC supervisa un subconjunto de recursos de Kubernetes para ver los cambios, traduce el estado del clúster a una configuración específica de Application Gateway y lo aplica a Azure Resource Manager (ARM). Para más información, consulte ¿Qué es el controlador de entrada de Application Gateway?.

En la tabla siguiente se describen las ventajas y desventajas del controlador de entrada de Application Gateway (AGIC):

Ventajas	Desventajas
• Integración nativa: AGIC proporciona integración nativa con los servicios de Azure, específicamente Azure Application Gateway, lo que permite un enrutamiento sin problemas y eficaz del tráfico a los servicios que se ejecutan en AKS. • Implementaciones simplificadas: la implementación de AGIC como complemento de AKS es sencilla y sencilla en comparación con otros métodos. Permite una configuración rápida y sencilla de una instancia de Application Gateway y un clúster de AKS con AGIC habilitado. • Servicio totalmente administrado: AGIC como complemento es un servicio totalmente administrado, lo que proporciona ventajas como actualizaciones automáticas y mayor soporte técnico de Microsoft. Garantiza que el controlador de entrada permanece actualizado y agrega una capa adicional de compatibilidad.	• Enfoque de nube único: AGIC se adopta principalmente por los clientes que adoptan un enfoque de nube única. Es posible que no sea la mejor opción si necesita una arquitectura multinube en la que la implementación en distintas plataformas en la nube es un requisito. En este caso, es posible que quiera usar un controlador de entrada independiente de la nube, como NGINX, Traefik o HAProxy para evitar problemas de dependencia del proveedor.

Ventajas

Desventajas

• Integración nativa: AGIC proporciona integración nativa con los servicios de Azure, específicamente Azure Application Gateway, lo que permite un enrutamiento sin problemas y eficaz del tráfico a los servicios que se ejecutan en AKS.
• Implementaciones simplificadas: la implementación de AGIC como complemento de AKS es sencilla y sencilla en comparación con otros métodos. Permite una configuración rápida y sencilla de una instancia de Application Gateway y un clúster de AKS con AGIC habilitado.
• Servicio totalmente administrado: AGIC como complemento es un servicio totalmente administrado, lo que proporciona ventajas como actualizaciones automáticas y mayor soporte técnico de Microsoft. Garantiza que el controlador de entrada permanece actualizado y agrega una capa adicional de compatibilidad.

• Enfoque de nube único: AGIC se adopta principalmente por los clientes que adoptan un enfoque de nube única. Es posible que no sea la mejor opción si necesita una arquitectura multinube en la que la implementación en distintas plataformas en la nube es un requisito. En este caso, es posible que quiera usar un controlador de entrada independiente de la nube, como NGINX, Traefik o HAProxy para evitar problemas de dependencia del proveedor.

Para obtener más información, consulte los siguientes recursos:

Azure Application Gateway for Containers proporciona equilibrio de carga y administración dinámica del tráfico para aplicaciones en clústeres de Kubernetes.

Características clave

Azure Application Gateway for Containers se basa en las funcionalidades del controlador de entrada de Application Gateway (AGIC) y permite usar el equilibrador de carga nativo de Application Gateway de Azure. Entre las características clave se incluyen:

Equilibrio de carga: distribuye eficazmente el tráfico entrante entre varios contenedores para lograr un rendimiento y escalabilidad óptimos.
Implementación de la API de puerta de enlace: admite la API de puerta de enlace, lo que le permite definir reglas y directivas de enrutamiento de forma nativa de Kubernetes.
Sondeos de salud personalizados: defina sondeos de salud personalizados para supervisar la salud del contenedor y enrutar automáticamente el tráfico lejos de instancias no saludables.
Afinidad de sesión: proporciona afinidad de sesión, enrutando las solicitudes posteriores del mismo cliente al mismo contenedor para una experiencia de usuario coherente.
Directiva TLS: admite la terminación TLS, lo que permite que el cifrado SSL/TLS y el descifrado se descarguen en la puerta de enlace.
Reescritura de encabezados: reescribe los encabezados HTTP de las solicitudes de cliente y respuestas de los destinos back-end mediante la IngressExtension definición de recursos personalizados. Para más información, consulte API de entrada y API de puerta de enlace.
Reescrituras de direcciones URL: modifique la dirección URL de las solicitudes de cliente, incluido el nombre de host o la ruta de acceso, e incluya la dirección URL recién reescrita al iniciar solicitudes a destinos de back-end. Para más información, consulte API de entrada y API de puerta de enlace.

Limitaciones

Actualmente, Azure Application Gateway para contenedores no admite las siguientes características:

Para más información, consulte Implementación de un clúster de Azure Kubernetes Service (AKS) con Application Gateway for Containers.

Azure Front Door es un equilibrador de carga de nivel 7 global que expone y protege de forma segura las cargas de trabajo que se ejecutan en AKS mediante Azure Web Application Firewall y un servicio Azure Private Link .

Esta solución usa Azure Front Door Premium, cifrado TLS de un extremo a otro, Firewall de aplicaciones web de Azure y un servicio Private Link para exponer y proteger de forma segura una carga de trabajo que se ejecuta en AKS.

Funcionalidad de descarga de TLS y capa de sockets seguros (SSL) de Azure Front Door para finalizar las conexiones TLS y descifrar el tráfico entrante en el front-end. Azure Front Door vuelve a cifrar el tráfico entrante antes de reenviarlo a la aplicación web hospedada en AKS. Esta práctica aplica el cifrado TLS de un extremo a otro para todo el proceso de solicitud, desde el cliente hasta el origen. Para obtener más información, consulte Asegure su origen con Private Link en Azure Front Door Premium.

El controlador de entrada NGINX expone la aplicación web alojada en AKS. Está configurado para usar una dirección IP privada como una configuración ip de front-end del kubernetes-internal equilibrador de carga interno y usa HTTPS como protocolo de transporte para exponer la aplicación web. Para obtener más información, consulte Creación de un controlador de entrada mediante una dirección IP interna.

Se recomienda esta solución para escenarios en los que va a implementar la misma aplicación web en varios clústeres regionales de AKS para la continuidad empresarial y la recuperación ante desastres, o incluso en varias plataformas en la nube o instalaciones locales. En este caso, Front Door puede reenviar llamadas entrantes a uno de los back-end (también conocidos como orígenes) mediante uno de los métodos de enrutamiento siguientes:

Latencia: el enrutamiento basado en latencia garantiza que las solicitudes se envíen a los orígenes de latencia más bajos aceptables dentro de un intervalo de confidencialidad. En otras palabras, las solicitudes se envían al conjunto de orígenes más cercano con respecto a la latencia de red.
Prioridad: puede establecer prioridades en los orígenes cuando desee configurar un origen principal para atender todo el tráfico. El origen secundario puede ser una copia de seguridad en caso de que el origen principal deje de estar disponible.
Ponderado: Puede asignar un peso a sus orígenes cuando desee distribuir el tráfico entre varios orígenes de forma uniforme o según los coeficientes de ponderación. El tráfico se distribuirá en función del valor ponderado si las latencias de los orígenes se encuentran dentro del intervalo de confidencialidad de latencia aceptable que se establezca para el grupo de orígenes.
Afinidad de sesión: puede configurar la afinidad de sesión para los hosts o dominios de front-end para asegurarse de que las solicitudes del mismo usuario final se envían al mismo origen.

Para más información, consulte Uso de Azure Front Door para proteger las cargas de trabajo de AKS.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-04-11

Compartir a través de