Componentes del Application Gateway para contenedores

En este artículo se proporcionan descripciones detalladas y los requisitos de los componentes de la puerta de enlace de aplicaciones para contenedores. Información sobre cómo la puerta de enlace de aplicaciones para contenedores 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 es responsable de orquestar la configuración del proxy en función de la intención del cliente.
• La puerta de enlace de aplicaciones para contenedores tiene dos recursos secundarios: asociaciones y frontend.
  • Los recursos secundarios son solo exclusivos de su instancia principal de la puerta de enlace de aplicaciones para contenedores y no pueden ser referenciados por otro recurso de la puerta de enlace de aplicaciones para contenedores adicionales.

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 frontend de puerta de enlace de aplicaciones para contenedores define el tráfico del cliente del punto de entrada que debe recibir una instancia determinada de la puerta de enlace de aplicaciones para contenedores.
  • Un front-end no se puede asociar a varias instancias de Application Gateway for Containers.
  • Cada frontend proporciona un FQDN único al que puede hacer referencia el registro CNAME de un cliente.
  • Actualmente no se admiten direcciones IP privadas.
• Una sola puerta de enlace de aplicaciones para contenedores puede admitir varios 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.
• La puerta de enlace de aplicaciones para contenedores está diseñada para permitir varias 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.
  • Máscara mínima de subred /24 para cada implementación (suponiendo que no se ha aprovisionado previamente ningún recurso en la subred).
    • Si se aprovisiona n número de puertas de enlace de aplicaciones para contenedores, con la suposición de que cada una de sus instancias contiene una asociación y la intención es compartir la misma subred, las direcciones necesarias disponibles deben ser n*256.
  • 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.

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/Puerta de enlace de aplicaciones para contenedores para propagar la configuración a la implementación de Azure de la puerta de enlace de aplicaciones para contenedores.
• El controlador ALB se implementa o instala a través de Helm.
• El controlador ALB consta de dos pods en ejecución.
  • El pod alb-controller es responsable de orquestar la intención del cliente en La puerta de enlace de aplicaciones para la configuración del equilibrio de carga de contenedores.
  • El pod alb-controller-bootstrap es responsable de la administración de CRD.

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 haría 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 la puerta de enlace de aplicaciones para contenedores y se puede delegar en la subred de una red virtual.
• Cuando se produce la delegación, no se produce el aprovisionamiento de los recursos de la puerta de enlace de aplicaciones para contenedores ni existe una asignación exclusiva a un recurso de asociación de puerta de enlace de aplicaciones para contenedores.
• 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, ningún otro recurso, aparte del servicio definido, se puede aprovisionar 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.
• Se requiere una identidad administrada de usuario para que cada controlador de Azure Load Balancer realice cambios en puerta de enlace de aplicaciones para contenedores.
• 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 de puerta de enlace de aplicaciones para contenedores.

Cómo acepta solicitudes la puerta de enlace de aplicaciones para contenedores

Cada front-end de puerta de enlace de aplicaciones para contenedores proporciona un nombre de dominio completo (FQDN) generado administrado por Azure. El FQDN se puede usar tal como está o los clientes pueden optar por enmascarar el FQDN con un registro CNAME.

Antes de que un cliente envíe una solicitud a la puerta de enlace de aplicaciones para contenedores, el cliente resuelve un CNAME que apunta al FQDN del front-end, o bien, el cliente puede resolver directamente el FQDN proporcionado por la puerta de enlace de aplicaciones 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

La Puerta de enlace de aplicaciones para contenedores es totalmente compatible con el protocolo HTTP/2 para la comunicación desde el cliente al front-end. La comunicación de Puerta de enlace de aplicaciones para contenedores al destino de back-end usa el protocolo HTTP/1.1. 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 Puerta de enlace de aplicaciones para contenedores, pueden seguir negociando en consecuencia.

Modificaciones a una solicitud

La puerta de enlace de aplicaciones para contenedores inserta tres encabezados extra en todas las solicitudes antes de que se inicien desde la puerta de enlace de aplicaciones para contenedores a 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 recibida y delimitada por comas. 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 la puerta de enlace de aplicaciones para contenedores y 5.6.7.8 es la dirección del tráfico de reenvío de proxy a la puerta de enlace de aplicaciones para contenedores.

x-forwarded-proto devuelve el protocolo recibido por la puerta de enlace de aplicaciones para contenedores desde el cliente. El valor es http o https.

x-request-id es un GUID único que genera la puerta de enlace de aplicaciones para contenedores para cada solicitud de cliente y que presenta en la solicitud reenviada al destino de back-end. El identificador único global consta de 32 caracteres alfanuméricos, separados por guiones (por ejemplo: aaaa0000-bb11-2222-33cc-444444d). Este GUID se puede usar para correlacionar una solicitud recibida por la puerta de enlace de aplicaciones para contenedores e iniciarse 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 se inician y mantienen las solicitudes entre el cliente, Puerta de enlace de aplicaciones para contenedores y el back-end.

Tiempo de espera	Duration	Descripción
Tiempo de espera de solicitud	60 segundos	hora en la que Puerta de enlace de aplicaciones para contenedores 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.