title | description | services | author | ms.service | ms.topic | ms.date | ms.author |
---|---|---|---|---|---|---|---|
Networking architecture in Azure Container Apps |
Learn how to configure virtual networks in Azure Container Apps |
container-apps |
craigshoemaker |
container-apps |
conceptual |
05/06/2022 |
cshoe |
Azure Container Apps run in the context of an environment, which is supported by a virtual network (VNET). When you create an environment, you can provide a custom VNET, otherwise a VNET is automatically generated for you. Generated VNETs are inaccessible to you as they're created in Microsoft's tenant. To take full control over your VNET, provide an existing VNET to Container Apps as you create your environment.
The following articles feature step-by-step instructions for creating Container Apps environments with different accessibility levels.
Accessibility level | Description |
---|---|
External | Container Apps environments deployed as external resources are available for public requests. External environments are deployed with a virtual IP on an external, public facing IP address. |
Internal | When set to internal, the environment has no public endpoint. Internal environments are deployed with a virtual IP (VIP) mapped to an internal IP address. The internal endpoint is an Azure internal load balancer (ILB) and IP addresses are issued from the custom VNET's list of private IP addresses. |
As you create a custom VNET, keep in mind the following situations:
-
If you want your container app to restrict all outside access, create an internal Container Apps environment.
-
When you provide your own VNET, the network needs a single subnet.
-
Network addresses are assigned from a subnet range you define as the environment is created.
- You can define the subnet range used by the Container Apps environment.
- Once the environment is created, the subnet range is immutable.
- A single load balancer and single Kubernetes service are associated with each container apps environment.
- Each revision is assigned an IP address in the subnet.
- You can restrict inbound requests to the environment exclusively to the VNET by deploying the environment as internal.
As you begin to design the network around your container app, refer to Plan virtual networks for important concerns surrounding running virtual networks on Azure.
:::image type="content" source="media/networking/azure-container-apps-virtual-network.png" alt-text="Diagram of how Azure Container Apps environments use an existing V NET, or you can provide your own.":::
Azure Container Apps uses Envoy proxy as an edge HTTP proxy. TLS is terminated on the edge and requests are routed based on their traffic split rules and routes traffic to the correct application.
HTTP applications scale based on the number of HTTP requests and connections. Envoy routes internal traffic inside clusters. Downstream connections support HTTP1.1 and HTTP2 and Envoy automatically detects and upgrades the connection should the client connection be upgraded. Upstream connection is defined by setting the transport
property on the ingress object.
Under the ingress section, you can configure the following settings:
-
Accessibility level: You can set your container app as externally or internally accessible in the environment. An environment variable
CONTAINER_APP_ENV_DNS_SUFFIX
is used to automatically resolve the FQDN suffix for your environment. -
Traffic split rules: You can define traffic split rules between different revisions of your application.
The following scenarios describe configuration settings for common use cases.
In situations where you're frequently iterating development of your container app, you can set traffic rules to always shift all traffic to the latest deployed revision.
The following example routes all traffic to the latest deployed revision:
"ingress": {
"traffic": [
{
"latestRevision": true,
"weight": 100
}
]
}
Once you're satisfied with the latest revision, you can lock traffic to that revision by updating the ingress
settings to:
"ingress": {
"traffic": [
{
"latestRevision": false, // optional
"revisionName": "myapp--knowngoodrevision",
"weight": 100
}
]
}
Consider a situation where you have a known good revision that's serving 100% of your traffic, but you want to issue an update to your app. You can deploy and test new revisions using their direct endpoints without affecting the main revision serving the app.
Once you're satisfied with the updated revision, you can shift a portion of traffic to the new revision for testing and verification.
The following configuration demonstrates how to move 20% of traffic over to the updated revision:
"ingress": {
"traffic": [
{
"revisionName": "myapp--knowngoodrevision",
"weight": 80
},
{
"revisionName": "myapp--newerrevision",
"weight": 20
}
]
}
When building microservices, you may want to maintain production and staging endpoints for the same app. Use labels to ensure that traffic doesn't switch between different revisions.
The following example demonstrates how to apply labels to different revisions.
"ingress": {
"traffic": [
{
"revisionName": "myapp--knowngoodrevision",
"weight": 100
},
{
"revisionName": "myapp--98fdgt",
"weight": 0,
"label": "staging"
}
]
}
For every app in Azure Container Apps, there are two URLs.
The first URL is generated by Container Apps and is used to access your app. See the Application Url in the Overview window of your container app in the Azure portal for the fully qualified domain name (FQDN) of your container app.
The second URL grants access to the log streaming service and the console. If necessary, you may need to add https://azurecontainerapps.dev/
to the allowlist of your firewall or proxy.
The VNET associated with a Container Apps environment uses a single subnet with 255 addresses.
The following ports are exposed for inbound connections.
Use | Port(s) |
---|---|
HTTP/HTTPS | 80, 443 |
Container Apps reserves 60 IPs in your VNET, and the amount may grow as your container environment scales.
IP addresses are broken down into the following types:
Type | Description |
---|---|
Public inbound IP address | Used for app traffic in an external deployment, and management traffic in both internal and external deployments. |
Outbound public IP | Used as the "from" IP for outbound connections that leave the virtual network. These connections aren't routed down a VPN. |
Internal load balancer IP address | This address only exists in an internal deployment. |
App-assigned IP-based TLS/SSL addresses | These addresses are only possible with an external deployment, and when IP-based TLS/SSL binding is configured. |
Subnet address ranges can't overlap with the following reserved ranges:
- 169.254.0.0/16
- 172.30.0.0/16
- 172.31.0.0/16
- 192.0.2.0/24
As a Container Apps environment is created, you provide resource IDs for a single subnet.
If you're using the CLI, the parameter to define the subnet resource ID is infrastructure-subnet-resource-id
. The subnet hosts infrastructure components and user app containers.
If you're using the Azure CLI and the platformReservedCidr range is defined, both subnets must not overlap with the IP range defined in platformReservedCidr
.
There's no forced tunneling in Container Apps routes.
When you deploy an internal or an external environment into your own network, a new resource group prefixed with MC_
is created in the Azure subscription where your environment is hosted. This resource group contains infrastructure components managed by the Azure Container Apps platform, and shouldn't be modified. The resource group contains Public IP addresses used specifically for outbound connectivity from your environment and a load balancer. As the load balancer is created in your subscription, there are extra costs associated with deploying the service to a custom virtual network.