Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se proporcionan descripciones detalladas y los requisitos de los componentes de la puerta de enlace de aplicaciones para contenedores. Explica cómo Application Gateway for Containers acepta solicitudes entrantes y las enruta a un destino de back-end. Para obtener información general sobre la puerta de enlace de aplicaciones para contenedores, consulta Qué es la puerta de enlace de aplicaciones para contenedores.
Componentes principales
- Un recurso de la puerta de enlace de aplicaciones para contenedores es un recurso primario de Azure que implementa el plano de control.
- El plano de control organiza la configuración del proxy en función de la intención del cliente.
- Application Gateway for Containers tiene dos recursos secundarios: asociaciones y frontend.
- Los recursos secundarios pertenecen exclusivamente a su instancia principal de Application Gateway for Containers y no se pueden compartir con otros recursos de Application Gateway for Containers.
Front-ends de la puerta de enlace de aplicaciones para contenedores
- Un recurso frontend de la puerta de enlace de aplicaciones para contenedores es un recurso secundario de Azure del recurso primario de la puerta de enlace de aplicaciones para contenedores.
- Un front-end de Application Gateway for Containers define el punto de entrada que el tráfico de cliente utiliza para una instancia determinada de Application Gateway for Containers.
- No se puede asociar un frontend con más de una instancia de Application Gateway for Containers.
- Puede crear un registro CNAME mediante el FQDN único que proporciona cada front-end.
- Actualmente no se admiten direcciones IP privadas.
- Una sola instancia de Application Gateway for Containers puede admitir más de un front-end.
Asociaciones de la puerta de enlace de aplicaciones para contenedores
- Un recurso de asociación de la puerta de enlace de aplicaciones para contenedores es un recurso secundario de Azure del recurso primario de la puerta de enlace de aplicaciones para contenedores.
- Una asociación de la puerta de enlace de aplicaciones para contenedores define un punto de conexión en una red virtual. Una asociación es una asignación 1:1 de un recurso de asociación a una subred de Azure delegada.
- Application Gateway for Containers está diseñado para permitir múltiples asociaciones.
- En este momento, el número actual de asociaciones está limitado a 1.
- Durante la creación de una asociación, el plano de datos subyacente se aprovisiona y se conecta a una subred dentro de la subred de la red virtual definida.
- Cada asociación debe suponer que al menos 256 direcciones están disponibles en la subred en el momento del aprovisionamiento.
- Se requiere una máscara de subred mínima de /24 para cada implementación (suponiendo que no se hayan aprovisionado recursos previamente en la subred).
- Si tiene previsto implementar varios recursos de Application Gateway para contenedores que comparten la misma subred, calcule las direcciones necesarias como n×256, donde n es igual al número de recursos de Application Gateway para contenedores. Esto supone que cada uno contiene una asociación.
- Todos los recursos de asociación de la puerta de enlace de aplicaciones para contenedores deben coincidir con la misma región que su recurso primario.
- Se requiere una máscara de subred mínima de /24 para cada implementación (suponiendo que no se hayan aprovisionado recursos previamente en la subred).
Controlador ALB de puerta de enlace de aplicaciones para contenedores
- Un controlador ALB de puerta de enlace de aplicaciones para contenedores es una implementación de Kubernetes que organiza la configuración e implementación de puertas de enlace de aplicaciones para contenedores mediante la inspección tanto de los recursos personalizados de Kubernetes como de sus configuraciones de recursos, como, entre otros, entrada, puerta de enlace y ApplicationLoadBalancer. Usa las API de configuración de ARM y de Application Gateway para contenedores con el fin de propagar la configuración a la implementación de Azure del Application Gateway para contenedores.
- Implemente o instale el controlador ALB con Helm.
- El controlador ALB consta de dos pods en ejecución.
- alb-controller pod orquesta la intención del cliente en la configuración de equilibrio de carga de Application Gateway for Containers.
- El pod de alb-controller-bootstrap administra los CRD.
Directiva de seguridad de Application Gateway for Containers
- Una directiva de seguridad de Puerta de enlace de aplicaciones para contenedores define configuraciones de seguridad adicionales, como WAF, para que el controlador ALB consuma.
- Un único recurso de Application Gateway for Containers puede hacer referencia a más de una directiva de seguridad.
- En este momento, el único tipo de directiva de seguridad que se ofrece es
wafpara las funcionalidades de firewall de aplicaciones web. - La
wafpolítica de seguridad es un mapeo uno a uno entre el recurso de política de seguridad y una política de firewall de aplicaciones web.- Solo puede hacer referencia a una directiva de firewall de aplicaciones web en cualquier número de directivas de seguridad para un recurso de Application Gateway for Containers definido.
Conceptos generales o de Azure
Dirección IP privada
- Una dirección IP privada no se define explícitamente como un recurso de Azure Resource Manager. Una dirección IP privada hace referencia a una dirección de host específica dentro de la subred de una red virtual determinada.
Delegación de subred
- Microsoft.ServiceNetworking/trafficControllers es el espacio de nombres adoptado por Application Gateway for Containers y se puede delegar a la subred de una red virtual.
- Al delegar, no aprovisiona recursos de Application Gateway for Containers, ni existe una asignación exclusiva a un recurso de asociación de Application Gateway for Containers.
- Cualquier número de subredes puede tener una delegación de subred que sea la misma o diferente de la puerta de enlace de aplicaciones para contenedores. Una vez definido, no puede aprovisionar otros recursos en la subred a menos que se defina explícitamente mediante la implementación del servicio.
Identidad administrada asignada por el usuario
- Las identidades administradas para los recursos de Azure eliminan la necesidad de administrar las credenciales en el código.
- Necesita una identidad administrada asignada por el usuario para cada controlador de Azure Load Balancer para realizar cambios en Application Gateway for Containers.
- AppGw for Containers Configuration Manager es un rol RBAC integrado que permite al controlador ALB acceder y configurar el recurso de puerta de enlace de aplicaciones para contenedores.
Nota
El rol AppGw for Containers Configuration Manager tiene permisos de acción de datos que los roles Propietario y Colaborador no tienen. Es fundamental delegar los permisos adecuados para evitar problemas con el controlador ALB que realiza cambios en el servicio Application Gateway for Containers.
Cómo acepta solicitudes la puerta de enlace de aplicaciones para contenedores
Cada front-end de Application Gateway for Containers proporciona un nombre de dominio completo generado administrado por Azure. Puede usar el FQDN as-is o enmascararlo con un registro CNAME.
Antes de que un cliente envíe una solicitud a Application Gateway for Containers, el cliente resuelve un CNAME que apunta al FQDN del front-end o el cliente resuelve directamente el FQDN proporcionado por Application Gateway para contenedores mediante un servidor DNS.
La resolución DNS traduce el registro DNS a una dirección IP.
Cuando el cliente inicia la solicitud, el nombre DNS especificado se pasa como encabezado de host a la puerta de enlace de aplicaciones para contenedores en el front-end definido.
Un conjunto de reglas de enrutamiento evalúa cómo se debe iniciar la solicitud de ese nombre de host en un destino de back-end definido.
Cómo enruta solicitudes la puerta de enlace de aplicaciones para contenedores
Solicitudes HTTP/2
Application Gateway para contenedores admite protocolos HTTP/2 y HTTP/1.1 para la comunicación entre el cliente y el front-end. La configuración HTTP/2 siempre está habilitada y no se puede cambiar. Si los clientes prefieren usar HTTP/1.1 para su comunicación con el front-end de Application Gateway para contenedores, pueden seguir negociando en consecuencia.
La comunicación entre Application Gateway para contenedores y el destino de back-end siempre se realiza a través de HTTP/1.1, excepto gRPC, que usa HTTP/2.
Modificaciones a una solicitud
Application Gateway for Containers inserta tres encabezados adicionales en todas las solicitudes antes de iniciarlas hacia un destino de backend.
- x-forwarded-for
- x-forwarded-proto
- x-request-id
x-forwarded-for es la dirección IP del cliente del solicitante original. Si la solicitud llega a través de un proxy, el valor del encabezado anexa la dirección que recibe, delimitada por comas. Por ejemplo: 1.2.3.4,5.6.7.8; donde 1.2.3.4 es la dirección IP del cliente al proxy delante de Application Gateway for Containers y 5.6.7.8 es la dirección del tráfico de reenvío de proxy a Application Gateway for Containers.
x-forwarded-proto devuelve el protocolo Application Gateway for Containers que recibe del cliente. El valor es http o https.
x-request-id es un identificador único (GUID) que Application Gateway for Containers genera para cada solicitud de cliente y presenta en la solicitud reenviada al objetivo de backend. El identificador único global consta de 32 caracteres alfanuméricos, separados por guiones (por ejemplo: aaaa0000-bb11-2222-33cc-444444d). Puede usar este guid para correlacionar una solicitud que Application Gateway for Containers recibe e inicia en un destino de back-end tal como se define en los registros de acceso.
Solicitud de tiempos de expiración
Application Gateway for Containers aplica los siguientes tiempos de espera a medida que inicia y mantiene solicitudes entre el cliente, Application Gateway for Containers y el back-end.
| Tiempo de espera | Duración | Descripción |
|---|---|---|
| Tiempo de espera de solicitud | 60 segundos | Tiempo que Application Gateway for Containers espera la respuesta de destino de back-end. |
| Tiempo de espera de inactividad de HTTP | 5 minutos | Tiempo de espera de inactividad antes de cerrar una conexión HTTP. |
| Tiempo de espera de inactividad de flujo | 5 minutos | Tiempo de espera de inactividad antes de cerrar una secuencia individual llevada por una conexión HTTP. |
| Tiempo de espera de conexión ascendente | 5 segundos | Tiempo para establecer una conexión con el destino de back-end. |
Nota
El tiempo de espera de la solicitud se aplica estrictamente para garantizar que la solicitud se complete en el tiempo definido, independientemente de si los datos se transmiten activamente o si la solicitud está inactiva. Por ejemplo, si está atendiendo descargas de archivos grandes y espera que las transferencias tarden más de 60 segundos debido al tamaño o velocidades de transferencia lentas, considere la posibilidad de aumentar el valor de tiempo de espera de la solicitud o establecerlo en 0.