Redes en el entorno de Azure Container Apps
Azure Container Apps se ejecuta en el contexto de un entorno, con su propia red virtual (VNet).
De forma predeterminada, el entorno de Container Apps se crea con una red virtual que se genera automáticamente. Para que haya un control más exhaustivo de la red, puede usar una red virtual existente al crear un entorno. Una vez creado el entorno con una red virtual generada o existente, no es posible cambiar el tipo de red.
Las redes virtuales generadas adoptan las siguientes características.
Son las siguientes:
- inaccesible para usted a medida que se crean en el inquilino de Microsoft
- accesible públicamente a través de Internet
- solo se puede acceder a los puntos de conexión accesibles a Internet
Además, solo admiten un subconjunto limitado de funcionalidades de red, como restricciones de IP de entrada y controles de entrada de nivel de aplicación de contenedor.
Use una red virtual existente si necesita más características de red de Azure, como:
- Integración con Application Gateway
- Grupos de seguridad de red
- Comunicación con recursos detrás de puntos de conexión privados en la red virtual
Las características de red virtual disponibles dependen de la selección del entorno.
Selección de entorno
Container Apps tiene dos tipos de entorno de diferentes, que comparten muchas de las mismas características de red con algunas diferencias clave.
Tipo de entorno | Tipos de plan admitidos | Descripción |
---|---|---|
Perfiles de carga de trabajo | Consumo, dedicado | Admite rutas definidas por el usuario (UDR), salida a través de NAT Gateway y creación de puntos de conexión privados en el entorno de la aplicación contenedora. El tamaño mínimo necesario de subred es /27 . |
Solo consumo | Consumo | No admite rutas definidas por el usuario (UDR), salida a través de NAT Gateway, emparejamiento a través de una puerta de enlace remota u otra salida personalizada. El tamaño mínimo necesario de subred es /23 . |
IP virtual
En función de la configuración de IP virtual, puede controlar si el entorno de la aplicación de contenedor permite la entrada pública o la entrada solo desde dentro de la red virtual en el nivel de entorno. Esta configuración no se puede cambiar después de crear el entorno.
Nivel de accesibilidad | Descripción |
---|---|
Externo | Permite que la aplicación de contenedor acepte solicitudes públicas. Los entornos externos se implementan con una dirección IP virtual en una dirección IP externa accesible desde Internet. |
Interno | Los entornos internos no tienen puntos de conexión públicos y se implementan con una dirección IP virtual (VIP) asignada a una dirección IP interna. El punto de conexión interno es un equilibrador de carga interno (ILB) de Azure y las direcciones IP se emiten desde la lista de direcciones IP privadas de la red virtual personalizada. |
Configuración de red virtual personalizada
A medida que cree una red virtual personalizada, tenga en cuenta las siguientes situaciones:
Si quiere que la aplicación de contenedor restrinja todo el acceso externo, cree un entorno interno de Container Apps.
Si usa su propia red virtual, debe proporcionar una subred dedicada exclusivamente al entorno de aplicación de contenedor que implemente. Esta subred no está disponible para otros servicios.
Las direcciones de red se asignan desde un intervalo de subred que se define a medida que se crea el entorno.
Puede definir el intervalo de subred que usa el entorno de Container Apps.
Puede restringir las solicitudes entrantes al entorno exclusivamente a la red virtual implementando el entorno como interno.
Nota:
Al proporcionar su propia red virtual, se crean recursos administrados adicionales. Estos recursos incurren en costos a sus tarifas asociadas.
A medida que empiece a diseñar la red en torno a la aplicación de contenedor, consulte Planear redes virtuales.
Nota:
No se permite mover redes virtuales entre diferentes grupos de recursos o suscripciones si la red virtual está en uso por un entorno de Container Apps.
Comportamiento del proxy perimetral HTTP
Azure Container Apps usa el Envoy proxy como proxy HTTP perimetral. La seguridad de la capa de transporte (TLS) se finaliza en el perímetro y las solicitudes se enrutan en función de sus reglas de división de tráfico y enrutan el tráfico a la aplicación correcta.
Las aplicaciones HTTP se escalan en función del número de solicitudes y conexiones HTTP. Envoy enruta el tráfico interno dentro de clústeres.
Las conexiones descendentes admiten HTTP1.1 y HTTP2 y Envoy detecta y actualiza automáticamente las conexiones si la conexión de cliente requiere una actualización.
Las conexiones ascendentes se definen al establecer la propiedad transport
en el objeto de entrada.
Configuración de entrada
En la sección entrada, puede configurar las siguientes opciones:
Nivel de accesibilidad: puede establecer la aplicación de contenedor como accesible externa o internamente en el entorno. Se usa una variable de entorno
CONTAINER_APP_ENV_DNS_SUFFIX
para resolver automáticamente el sufijo de nombre de dominio completo (FQDN) de su entorno. Al comunicarse entre aplicaciones de contenedor dentro del mismo entorno, también puede usar el nombre de la aplicación. Para más información sobre cómo acceder a las aplicaciones, consulte Entrada en Azure Container Apps.Reglas de división de tráfico: puede definir reglas de división de tráfico entre diferentes revisiones de la aplicación. Para más información, consulte División del tráfico.
Para más información sobre los distintos escenarios de red, consulte Entrada en Azure Container Apps.
Dependencias del portal
Por cada aplicación en Azure Container Apps, hay dos direcciones URL.
El entorno de ejecución de Container Apps genera inicialmente un nombre de dominio completo (FQDN) que se usa para acceder a la aplicación. Consulte la dirección URL de la aplicación en la ventana Información general de la aplicación de contenedor en Azure Portal del FQDN de la aplicación de contenedor.
También se genera una segunda dirección URL automáticamente. Esta ubicación concede acceso al servicio de streaming de registros y a la consola. Si es necesario, es posible que tenga que agregar https://azurecontainerapps.dev/
a la lista de permitidos del firewall o proxy.
Direcciones IP y puertos
Los puertos siguientes se exponen para las conexiones entrantes.
Protocolo | Puertos |
---|---|
HTTP/HTTPS | 80, 443 |
Las direcciones IP se dividen en los siguientes tipos:
Tipo | Descripción |
---|---|
Dirección IP pública de entrada | Se usa para el tráfico de la aplicación en una implementación externa y para el tráfico de administración tanto en implementaciones externas como internas. |
Dirección IP pública de salida | Se usa como dirección IP de procedencia para las conexiones de salida que salen de la red virtual. Estas conexiones no se enrutan a una VPN. Las direcciones IP salientes pueden cambiar con el tiempo. El uso de una puerta de enlace NAT u otro proxy para el tráfico saliente desde un entorno de Container Apps solo se admite en un entorno de perfiles de carga de trabajo. |
Dirección IP del equilibrador de carga interno | Esta dirección solo existe en un entorno interno. |
Subnet
La integración de red virtual depende de una subred dedicada. La forma en que se asignan las direcciones IP en una subred y qué tamaños de subred se admiten depende del plan que esté usando en Azure Container Apps.
Seleccione cuidadosamente el tamaño de la subred. Los tamaños de subred no se pueden modificar después de crear un entorno de Container Apps.
Los distintos tipos de entorno tienen requisitos de subred diferentes:
/27
es el tamaño mínimo de subred necesario para la integración de red virtual.La subred deberá estar delegada a
Microsoft.App/environments
.Cuando se usa un entorno externo con entrada externa, el tráfico entrante se enruta a través de la dirección IP pública de la infraestructura en lugar de a través de la subred.
Container Apps reserva automáticamente 12 direcciones IP para la integración con la subred. El número de direcciones IP necesarias para la integración de la infraestructura no varía en función de las demandas de escala del entorno. Las direcciones IP adicionales se asignan según las siguientes reglas dependiendo del tipo de perfil de carga de trabajo que esté utilizando se asignan más direcciones IP dependiendo del perfil de carga de trabajo de su entorno:
Perfil de carga de trabajo dedicado: a medida que la aplicación de contenedor se escala horizontalmente, cada nodo tiene asignada una dirección IP.
Perfil de carga de trabajo de consumo: cada dirección IP puede compartirse entre varias réplicas. Al planear el número de direcciones IP necesarias para la aplicación, planee 1 dirección IP por cada 10 réplicas.
Cuando se realiza un cambio a una revisión en modo de revisión única, el espacio de direcciones necesario se duplica durante un breve período de tiempo para admitir implementaciones de tiempo de inactividad cero. Esto afecta a las réplicas o nodos admitidos reales y disponibles para un tamaño de subred determinado. En la tabla siguiente se muestran las direcciones máximas disponibles por bloque CIDR y el impacto en la escala horizontal.
Tamaño de la subred Direcciones IP disponibles1 Número máximo de nodos (perfil de carga de trabajo dedicado)2 Número máximo de réplicas (perfil de carga de trabajo de consumo)2 /23 500 250 2,500 /24 244 122 1220 /25 116 58 580 /26 52 26 260 /27 20 10 100 1 Las direcciones IP disponibles son el tamaño de la subred menos las 12 direcciones IP necesarias para la infraestructura de Azure Container Apps.
2 Esto tiene en cuenta las aplicaciones en modo de revisión única.
Restricciones del intervalo de direcciones de subred
Los intervalos de direcciones de subred no se pueden superponer con los siguientes intervalos reservados por Azure Kubernetes Services:
- 169.254.0.0/16
- 172.30.0.0/16
- 172.31.0.0/16
- 192.0.2.0/24
Además, un entorno de perfiles de carga de trabajo reserva las siguientes direcciones:
- 100.100.0.0/17
- 100.100.128.0/19
- 100.100.160.0/19
- 100.100.192.0/19
Configuración de subred con la CLI
A medida que se crea un entorno de Container Apps, se proporcionan id. de recursos para una única subred.
Si usa la CLI, el parámetro para definir el identificador de recurso de subred es infrastructure-subnet-resource-id
. La subred hospeda componentes de infraestructura y contenedores de aplicaciones de usuario.
Si usa la CLI de Azure con un entorno de solo consumo y se define el intervalo platformReservedCidr, las subredes no deben superponerse con el intervalo IP definido en platformReservedCidr
.
Rutas
Rutas definidas por el usuario (UDR)
Las rutas definidas por el usuario (UDR) y la salida controlada a través de NAT Gateway se admiten en el entorno de perfiles de carga de trabajo. En el entorno de solo consumo, estas características no se admiten.
Nota:
Al usar UDR con Azure Firewall en Azure Container Apps, debe agregar determinadas etiquetas de servicio y FQDN a la lista de permitidos para el firewall. Para más información, consulte Configuración de UDR con Azure Firewall.
Puede utilizar una UDR con entornos de perfiles de carga de trabajo para restringir el tráfico saliente de la aplicación de contenedor a través de Azure Firewall o de otros dispositivos de red.
La configuración de UDR se realiza fuera del ámbito del entorno de Container Apps.
Azure crea una tabla de rutas predeterminada para las redes virtuales al crearla. Al implementar una tabla de rutas definida por el usuario, puede controlar cómo se enruta el tráfico dentro de la red virtual. Por ejemplo, puede crear una UDR que enrute todo el tráfico al firewall.
Configuración de UDR con Azure Firewall
Las rutas definidas por el usuario solo se admiten en un entorno de perfiles de carga de trabajo. Las siguientes reglas de red y aplicación deben agregarse a la lista de permitidos del firewall en función de los recursos que use.
Nota:
Para obtener una guía sobre cómo configurar UDR con Container Apps para restringir el tráfico saliente con Azure Firewall, visite la Guía de instrucciones para Container Apps y Azure Firewall.
Reglas de aplicación
Las reglas de aplicación permiten o deniegan el tráfico en función del nivel de aplicación. Las siguientes reglas de aplicación de firewall de salida son necesarias en función del escenario.
Escenarios | FQDNs | Descripción |
---|---|---|
Todas las situaciones | mcr.microsoft.com , *.data.mcr.microsoft.com |
Azure Container Apps usa estos FQDN para Microsoft Container Registry (MCR) y estas reglas de aplicación o las reglas de red para MCR deben agregarse a la lista de permitidos al usar Azure Container Apps con Azure Firewall. |
Azure Container Registry (ACR) | Your-ACR-address, *.blob.core.windows.net , login.microsoft.com |
Estos FQDN son necesarios al usar Azure Container Apps con ACR y Azure Firewall. |
Azure Key Vault | Your-Azure-Key-Vault-address, login.microsoft.com |
Estos FQDN son necesarios además de la etiqueta de servicio necesaria para la regla de red para Azure Key Vault. |
Identidad administrada | *.identity.azure.net , login.microsoftonline.com , *.login.microsoftonline.com , *.login.microsoft.com |
Estos FQDN son necesarios cuando se usa la identidad administrada con Azure Firewall en Azure Container Apps. |
Registro de Docker Hub | hub.docker.com , registry-1.docker.io , production.cloudflare.docker.com |
Si usa el registro de Docker Hub y quiere acceder a él a través del firewall, debe agregar estos FQDN al firewall. |
Reglas de red
Las reglas de red permiten o deniegan el tráfico en función de la capa de red y transporte. Las siguientes reglas de red de firewall de salida son necesarias en función del escenario.
Escenarios | Etiqueta de servicio | Descripción |
---|---|---|
Todas las situaciones | MicrosoftContainerRegistry , AzureFrontDoorFirstParty |
Azure Container Apps usa estas etiquetas de servicio para Microsoft Container Registry (MCR) y estas reglas de red o las reglas de aplicación para MCR deben agregarse a la lista de permitidos al usar Azure Container Apps con Azure Firewall. |
Azure Container Registry (ACR) | AzureContainerRegistry , AzureActiveDirectory |
Al usar ACR con Azure Container Apps, debe configurar estas reglas de aplicación usadas por Azure Container Registry. |
Azure Key Vault | AzureKeyVault , AzureActiveDirectory |
Estas etiquetas de servicio son necesarias además del FQDN para la regla de aplicación para Azure Key Vault. |
Identidad administrada | AzureActiveDirectory |
Al usar la identidad administrada con Azure Container Apps, deberá configurar estas reglas de aplicación usadas por la identidad administrada. |
Nota:
Para los recursos de Azure que usa con Azure Firewall no aparece en este artículo, consulte la documentación de etiquetas de servicio.
Integración de NAT Gateway
Puede usar NAT Gateway para simplificar la conectividad saliente para el tráfico saliente de Internet en la red virtual en un entorno de perfiles de carga de trabajo.
Al configurar una NAT Gateway en la subred, proporciona una dirección IP pública estática para su entorno. Todo el tráfico saliente de la aplicación de contenedor se enruta a través de la dirección IP pública estática de la NAT Gateway.
Acceso a la red pública (versión preliminar)
La configuración de acceso a la red pública determina si tu entorno de aplicaciones de contenedor es accesible desde la Internet pública. Si puede cambiar esta configuración después de crear el entorno depende de la configuración de IP virtual del entorno. En la tabla siguiente se muestran valores válidos para el acceso a la red pública, en función de la configuración de IP virtual del entorno.
IP virtual | Acceso de red pública admitido | Descripción |
---|---|---|
Externo | Enabled , Disabled |
El entorno de aplicaciones de contenedor se creó con un punto de conexión accesible a Internet. La configuración de acceso a la red pública determina si el tráfico se acepta a través del punto de conexión público o solo a través de puntos de conexión privados, y la configuración de acceso a la red pública se puede cambiar después de crear el entorno. |
Interno | Disabled |
El entorno de aplicaciones de contenedor se creó sin un punto de conexión accesible a Internet. No se puede cambiar la configuración de acceso a la red pública para aceptar el tráfico de Internet. |
Para crear puntos de conexión privados en el entorno de Azure Container App, el acceso a la red pública debe establecerse enDisabled
.
Las directivas de red de Azure se admiten con la marca de acceso de red pública.
Punto de conexión privado (versión preliminar)
Nota:
Esta característica es compatible con todas las regiones públicas. No se admiten las regiones gubernamentales y chinas.
El punto de conexión privado de Azure permite a los clientes ubicados en la red privada conectarse de forma segura al entorno de Azure Container Apps a través de Azure Private Link. Una conexión de vínculo privado elimina la exposición a la red pública de Internet. Los puntos de conexión privados usan una dirección IP privada en el espacio de direcciones de la red virtual de Azure.
Esta característica es compatible con los planes de consumo y dedicados en entornos de perfil de carga de trabajo.
Tutoriales
- Para más información sobre cómo configurar puntos de conexión privados en Azure Container Apps, consulte el tutorial Uso de un punto de conexión privado con un entorno de Azure Container Apps.
- La conectividad de Private Link con Azure Front Door es compatible con Azure Container Apps. Consulte Creación de un vínculo privado con Azure Front Door para más información.
Consideraciones
- Los puntos de conexión privados en Azure Container Apps solo admiten el tráfico HTTP entrante. No se admite el tráfico TCP.
- Para usar un punto de conexión privado con un dominio personalizado y un dominio de Apex como tipo de registro nombre de host, debe configurar una zona DNS privada con el mismo nombre que el DNS público. En el conjunto de registros, configure la dirección IP privada del punto de conexión privado en lugar de la dirección IP del entorno de la aplicación contenedora. Al configurar el dominio personalizado con CNAME, el programa de instalación no cambia. Para más información, consulte Configuración de un dominio personalizado con un certificado existente.
- La red virtual del punto de conexión privado puede ser independiente de la red virtual integrada con la aplicación de contenedor.
- Puede agregar un punto de conexión privado a entornos de perfil de carga de trabajo nuevos y existentes.
Para conectarse a las aplicaciones de contenedor a través de un punto de conexión privado, debe configurar una zona DNS privada.
Service | subrecurso | Nombre de zona de DNS privado |
---|---|---|
Azure Container Apps (Microsoft.App/ManagedEnvironments) | managedEnvironment | privatelink.{regionName}.azurecontainerapps.io |
Seguridad del entorno
Nota:
Para controlar el tráfico de entrada, también puede usar puntos de conexión privados con una conexión privada a Azure Front Door en lugar de Application Gateway. Esta característica se encuentra en versión preliminar.
Puede proteger completamente el entorno de perfiles de carga de trabajo de tráfico de red de entrada y salida mediante las siguientes acciones:
Cree el entorno de aplicación de contenedor interno en un entorno de perfiles de carga de trabajo. Para conocer los pasos, consulte Administración de perfiles de carga de trabajo con la CLI de Azure.
Integre las aplicaciones de contenedor con una Application Gateway.
Configure UDR para enrutar todo el tráfico a través de Azure Firewall.
Cifrado punto a punto en el entorno de Azure Container Apps
Azure Container Apps admite el cifrado TLS punto a punto dentro del entorno. Al habilitar esta característica, se cifra todo el tráfico de red dentro del entorno con un certificado privado válido dentro del ámbito del entorno de Azure Container Apps. Azure Container Apps administra automáticamente estos certificados.
Nota:
De forma predeterminada, el cifrado punto a punto está deshabilitado. La habilitación del cifrado punto a punto para las aplicaciones puede aumentar la latencia de respuesta y reducir el rendimiento máximo en escenarios de alta carga.
En el ejemplo siguiente se muestra un entorno con cifrado punto a punto habilitado.
1 El tráfico TLS entrante finaliza en el proxy de entrada en el perímetro del entorno.
2 El tráfico hacia y desde el proxy de entrada dentro del entorno es TLS cifrado con un certificado privado y descifrado por el receptor.
3 Las llamadas realizadas desde la aplicación A al FQDN de la aplicación B se envían primero al proxy de entrada perimetral y se cifran con TLS.
4 Las llamadas realizadas desde la aplicación A a la aplicación B mediante el nombre de la aplicación B se envían directamente a la aplicación B y se cifran CON TLS.
Las aplicaciones dentro de un entorno de Container Apps se autentican automáticamente. Sin embargo, el entorno de ejecución de Container Apps no admite la autorización para el control de acceso entre aplicaciones mediante el cifrado punto a punto integrado.
Cuando las aplicaciones se comunican con un cliente fuera del entorno, se admite la autenticación bidireccional con mTLS. Para más información, consulte Configurar certificados de cliente.
Puede habilitar el cifrado punto a punto mediante los siguientes comandos.
Al crear:
az containerapp env create \
--name <environment-name> \
--resource-group <resource-group> \
--location <location> \
--enable-peer-to-peer-encryption
Para una aplicación contenedora existente:
az containerapp env update \
--name <environment-name> \
--resource-group <resource-group> \
--enable-peer-to-peer-encryption
DNS
DNS personalizado: si la red virtual usa un servidor DNS personalizado en lugar del servidor DNS predeterminado que proporciona Azure, configure el servidor DNS para reenviar consultas de DNS sin resolver a
168.63.129.16
. Los solucionadores recursivos de Azure usan esta dirección IP para resolver solicitudes. Al configurar el grupo de seguridad de red o el firewall, no bloquee la dirección168.63.129.16
; de lo contrario, el entorno de Container Apps no funcionará correctamente.Entrada de ámbito de red virtual: si tiene previsto usar la entrada de ámbito de red virtual en un entorno interno, configure los dominios de una de las siguientes maneras:
Dominios no personalizados: si no tiene previsto usar un dominio personalizado, cree una zona DNS privada que resuelva el dominio predeterminado del entorno de Container Apps en la dirección IP estática del entorno de Container Apps. Puede usar DNS privado de Azure o su propio servidor DNS. Si usa DNS privado de Azure, cree una zona DNS privada denominada como dominio predeterminado del entorno de aplicación de contenedor (
<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io
), con un registroA
. El registroA
contiene el nombre*<DNS Suffix>
y la dirección IP estática del entorno de Container Apps.Dominios personalizados: si tiene previsto usar dominios personalizados y usa un entorno externo de Container Apps, use un dominio que se pueda resolver públicamente para agregar un dominio personalizado y un certificado a la aplicación contenedora. Si usa un entorno interno de Container Apps, no habrá ninguna validación para la vinculación del DNS, ya que solo se puede acceder al clúster desde dentro de la red virtual. Además, cree una zona de DNS privado que resuelva el dominio apex en la dirección IP estática del entorno de Container Apps. Puede usar DNS privado de Azure o su propio servidor DNS. Si usa DNS privado de Azure, cree una zona DNS privada con el nombre del dominio apex, con un registro
A
que apunte a la dirección IP estática del entorno de Container Apps.
La dirección IP estática del entorno de Container Apps está disponible en Azure Portal en sufijo DNS personalizado de la página de la aplicación de contenedor o mediante el comando az containerapp env list
de la CLI de Azure.
Recursos administrados
Al implementar un entorno interno o externo en su propia red, se crea un grupo de recursos en la suscripción de Azure donde se hospeda el entorno. Este grupo de recursos contiene componentes de infraestructura administrados por la plataforma Azure Container Apps. No modifique los servicios de este grupo ni el propio grupo de recursos.
Entorno de perfiles de carga de trabajo
El nombre del grupo de recursos creado en la suscripción de Azure donde se hospeda el entorno tiene el prefijo ME_
de forma predeterminada y el nombre del grupo de recursos se puede personalizar a medida que crea el entorno de la aplicación de contenedor.
Para entornos externos, el grupo de recursos contiene una dirección IP pública que se usa específicamente para la conectividad entrante con el entorno externo y un equilibrador de carga. En el caso de los entornos internos, el grupo de recursos solo contiene un equilibrador de carga.
Además de la facturación de Azure Container Apps estándar, se le facturará por lo siguiente:
Una IP pública estática estándar para la salida si se usa un entorno interno o externo, además de una IP pública estática estándar para la entrada si se usa un entorno externo. Si necesita más direcciones IP públicas para la salida debido a problemas de SNAT, abra una incidencia de soporte técnico para solicitar una invalidación.
Un equilibrador de carga estándar.
El coste de los datos procesados (en GB) incluyen tanto la entrada como la salida para las operaciones de administración.
Entorno de solo consumo
El nombre del grupo de recursos creado en la suscripción de Azure donde se hospeda el entorno tiene el prefijo MC_
de forma predeterminada y el nombre del grupo de recursos no se puede personalizar al crear el entorno de una aplicación de contenedor. El grupo de recursos contiene direcciones IP públicas que se usan específicamente para la conectividad saliente desde el entorno, así como un equilibrador de carga.
Además de la facturación de Azure Container Apps estándar, se le facturará por lo siguiente:
Una IP pública estática estándar para la salida. Si necesita más direcciones IP para la salida debido a problemas de traducción de direcciones de red de origen (SNAT), abra una incidencia de soporte técnico para solicitar una invalidación.
Dos equilibradores de carga estándar si usa un entorno interno o un equilibrador de carga estándar si se usa un entorno externo. Cada equilibrador de carga tiene menos de seis reglas. El coste de los datos procesados (en GB) incluyen tanto la entrada como la salida para las operaciones de administración.