Hoy nos complace ofrecer una nueva solución para enlazar Azure Kubernetes Service (AKS) y Application Gateway. La nueva solución proporciona un controlador de entrada de Application Gateway (AGIC) de código abierto para Kubernetes, que permite a los clientes de AKS aprovechar Application Gateway para exponer su software de la nube en Internet.

Al reunir las ventajas de Azure Kubernetes Service, nuestro servicio de Kubernetes administrado, que facilita el funcionamiento de entornos avanzados de Kubernetes y Azure Application Gateway, nuestro equilibrador de carga L7 nativo, escalable y de alta disponibilidad ha sido muy solicitado por nuestros clientes.

¿Cómo funciona?

El controlador de entrada de Application Gateway se ejecuta en su propio pod en la instancia de AKS del cliente. El controlador de entrada supervisa un subconjunto de recursos de Kubernetes en busca de cambios. El estado del clúster de AKS se traduce a una configuración específica de Application Gateway y se aplica a Azure Resource Manager. La reconfiguración continua de Application Gateway garantiza un flujo de tráfico ininterrumpido hacia los servicios de AKS. En el diagrama siguiente se muestra el flujo de cambios de estado y configuración desde la API de Kubernetes, a través del controlador de entrada de Application Gateway, hasta Resource Manager y, después, Application Gateway.

Al igual que los controladores de entrada más populares de Kubernetes, el controlador de entrada de Application Gateway proporciona varias características, por lo que se aprovecha el equilibrador de carga L7 nativo de Application Gateway de Azure. Por mencionar algunas:

• Enrutamiento de direcciones URL
• Afinidad basada en cookies
• Terminación de la Capa de sockets seguros (SSL)
• SSL de un extremo a otro
• Soporte para sitios web públicos, privados e híbridos
• Firewall de aplicaciones web integrado

La arquitectura del controlador de entrada de Application Gateway es diferente de la de un equilibrador de carga tradicional L7 en clúster. En este diagrama se muestran las diferencias arquitectónicas:

• Un equilibrador de carga en clúster realiza todas las operaciones de ruta de acceso de datos que aprovechando los recursos de proceso del clúster de Kubernetes. Compite por los recursos con las aplicaciones empresariales que presenta. Los controladores de entrada en clúster crean recursos de servicio de Kubernetes y aprovechan kubenet para el tráfico de red. En comparación con el controlador de entrada, el tráfico fluye a través de un salto adicional.
• El controlador de entrada aprovecha las redes avanzadas de AKS que asigna una dirección IP para cada pod de la subred compartida con Application Gateway. Application Gateway tiene acceso directo a todos los pods de Kubernetes. Esto elimina la necesidad de que los datos pasen a través de kubenet. Para más información sobre este tema, consulte nuestro artículo “Conceptos de redes de aplicaciones en Azure Kubernetes Service (AKS)” artículo, específicamente la sección “Comparación de modelos de red”.

Rendimiento de la solución

Como resultado de que Application Gateway tenga conectividad directa con los pods de Kubernetes, el controlador de entrada de Application Gateway puede alcanzar hasta el 50 % menos de latencia de red frente a los controladores de entrada en clúster. Application Gateway es un servicio administrado, respaldado por los conjuntos de escalado de máquinas virtuales de Azure. Por consiguiente, Application Gateway no utiliza recursos de proceso de AKS para el procesamiento de rutas de acceso de datos. No comparte los recursos asignados a la implementación de Kubernetes ni interfiere con dichos recursos. El escalado automático de Application Gateway en horas punta, a diferencia de la entrada en clúster, no impedirá la capacidad de escalar verticalmente los pods de las aplicaciones de forma rápida. Y, por supuesto, al cambiar de la entrada L7 en clúster a Application Gateway se reducirá inmediatamente la carga de proceso que AKS usa.

Hemos comparado el rendimiento de un controlador de entrada en clúster y el controlador de entrada de Application Gateway en un clúster de AKS de tres nodos con una sencilla aplicación web que ejecuta veintidós pods por nodo. Un total de sesenta y seis recursos compartidos de pods de aplicación web con tres entradas en clúster (una por nodo). Hemos configurado Application Gateway con dos instancias. Hemos usado Apache Bench para crear un total de 100 000 solicitudes con una simultaneidad establecida en 3000 solicitudes. Hemos lanzado Apache Bench dos veces: una vez dirigido a SLB frente al controlador de entrada en clúster y la segunda vez para conectar con la dirección IP pública de Application Gateway. En este clúster de AKS muy ocupado, se registró la latencia media en todas las solicitudes:

• Application Gateway: 480 ms por solicitud
• Entrada en clúster: 710 ms por solicitud

Tal y como han demostrado los datos recopilados anteriores, con mucha carga, el controlador de entrada en clúster tiene aproximadamente una latencia un 48 % mayor por solicitud en comparación con la entrada de Application Gateway. Al ejecutar la misma prueba comparativa en el mismo clúster pero con dos pods de aplicación web por nodo, un total de seis pods, observamos que el controlador de entrada en clúster consigue una latencia de aproximadamente el 17 % mayor que Application Gateway.

Pasos siguientes

El controlador de entrada de Application Gateway ahora es estable y está disponible para su uso en entornos de producción. El proyecto está madurando rápidamente y estamos trabajando activamente para agregar nuevas funcionalidades. Estamos trabajando para mejorar el producto con características que los clientes han solicitado, como el uso de certificados almacenados en Application Gateway, la autenticación TLS mutua, gRPC y HTTP/2. Le invitamos a probar el nuevo controlador de entrada de Application Gateway para AKS, seguir nuestro progreso y, lo más importante, darnos su opinión sobre GitHub.