Customize cluster egress with outbound types in Azure Kubernetes Service (AKS)
Article
You can customize egress for an AKS cluster to fit specific scenarios. By default, AKS creates a Standard Load Balancer to be set up and used for egress. However, the default setup may not meet the requirements of all scenarios if public IPs are disallowed or extra hops are required for egress.
This article covers the various types of outbound connectivity that are available in AKS clusters.
Note
You can now update the outboundType after cluster creation.
Important
In nonprivate clusters, API server cluster traffic is routed and processed through the clusters outbound type. To prevent API server traffic from being processed as public traffic, consider using a private cluster, or check out the API Server VNet Integration feature.
Limitations
Setting outboundType requires AKS clusters with a vm-set-type of VirtualMachineScaleSets and load-balancer-sku of Standard.
Outbound types in AKS
You can configure an AKS cluster using the following outbound types: load balancer, NAT gateway, or user-defined routing. The outbound type impacts only the egress traffic of your cluster. For more information, see setting up ingress controllers.
Outbound type of loadBalancer
The load balancer is used for egress through an AKS-assigned public IP. An outbound type of loadBalancer supports Kubernetes services of type loadBalancer, which expect egress out of the load balancer created by the AKS resource provider.
If loadBalancer is set, AKS automatically completes the following configuration:
A public IP address is created for cluster egress.
The public IP address is assigned to the load balancer resource.
Backend pools for the load balancer are set up for agent nodes in the cluster.
Outbound type of managedNatGateway or userAssignedNatGateway
If managedNatGateway or userAssignedNatGateway are selected for outboundType, AKS relies on Azure Networking NAT gateway for cluster egress.
Select managedNatGateway when using managed virtual networks. AKS provisions a NAT gateway and attach it to the cluster subnet.
Select userAssignedNatGateway when using bring-your-own virtual networking. This option requires that you have a NAT gateway created before cluster creation.
The userDefinedRouting outbound type is an advanced networking scenario and requires proper network configuration.
If userDefinedRouting is set, AKS doesn't automatically configure egress paths. The egress setup is completed by you.
You must deploy the AKS cluster into an existing virtual network with a subnet that is configured. Since you're not using a standard load balancer (SLB) architecture, you must establish explicit egress. This architecture requires explicitly sending egress traffic to an appliance like a firewall, gateway, proxy or to allow NAT to be done by a public IP assigned to the standard load balancer or appliance.
The none outbound type is only available with Network Isolated Cluster and requires careful planning to ensure the cluster operates as expected without unintended dependencies on external services. For fully isolated clusters, see isolated cluster considerations.
If none is set, AKS won't automatically configure egress paths. This option is similar to userDefinedRouting but does not require a default route as part of validation.
The none outbound type is supported in both bring-your-own (BYO) virtual network scenarios and managed VNet scenarios. However, you must ensure that the AKS cluster is deployed into a network environment where explicit egress paths are defined if needed. For BYO VNet scenarios, the cluster must be deployed into an existing virtual network with a subnet that is already configured. Since AKS doesn't create a standard load balancer or any egress infrastructure, you must establish explicit egress paths if needed. Egress options can include routing traffic to a firewall, proxy, gateway, or other custom network configurations.
If block is set, AKS configures network rules to actively block all egress traffic from the cluster. This option is useful for highly secure environments where outbound connectivity must be restricted.
When using block:
AKS ensures that no public internet traffic can leave the cluster through network security group (NSG) rules. VNet traffic isn't affected.
You must explicitly allow any required egress traffic through extra network configurations.
The block option provides another level of network isolation but requires careful planning to avoid breaking workloads or dependencies.
Updating outboundType after cluster creation
Changing the outbound type after cluster creation deploys or removes resources as required to put the cluster into the new egress configuration.
The following tables show the supported migration paths between outbound types for managed and BYO virtual networks.
Supported Migration Paths for Managed VNet
Each row shows whether the outbound type can be migrated to the types listed across the top. "Supported" means migration is possible, while "Not Supported" or "N/A" means it isn’t.
From|To
loadBalancer
managedNATGateway
userAssignedNATGateway
userDefinedRouting
none
block
loadBalancer
N/A
Supported
Not Supported
Not Supported
Supported
Supported
managedNATGateway
Supported
N/A
Not Supported
Not Supported
Supported
Supported
userAssignedNATGateway
Not Supported
Not Supported
N/A
Not Supported
Not Supported
Not Supported
none
Supported
Supported
Not Supported
Not Supported
N/A
Supported
block
Supported
Supported
Not Supported
Not Supported
Supported
N/A
Supported Migration Paths for BYO VNet
From|To
loadBalancer
managedNATGateway
userAssignedNATGateway
userDefinedRouting
none
block
loadBalancer
N/A
Not Supported
Supported
Supported
Supported
Not Supported
managedNATGateway
Not Supported
N/A
Not Supported
Not Supported
Not Supported
Not Supported
userAssignedNATGateway
Supported
Not Supported
N/A
Supported
Supported
Not Supported
userDefinedRouting
Supported
Not Supported
Supported
N/A
Supported
Not Supported
none
Supported
Not Supported
Supported
Supported
N/A
Not Supported
Migration is only supported between loadBalancer, managedNATGateway (if using a managed virtual network), userAssignedNATGateway and userDefinedRouting (if using a custom virtual network).
Warning
Migrating the outbound type to user managed types (userAssignedNATGateway or userDefinedRouting) will change the outbound public IP addresses of the cluster.
if Authorized IP ranges is enabled, ensure new outbound IP range is appended to authorized IP range.
Warning
Changing the outbound type on a cluster is disruptive to network connectivity and results in a change of the cluster's egress IP address. If any firewall rules are configured to restrict traffic from the cluster, you need to update them to match the new egress IP address.
Update cluster to use a new outbound type
Note
You must use a version >= 2.56 of Azure CLI to migrate outbound type. Use az upgrade to update to the latest version of Azure CLI.
Update the outbound configuration of your cluster using the az aks update command.
Update cluster from loadbalancer to managedNATGateway
az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type managedNATGateway --nat-gateway-managed-outbound-ip-count <number of managed outbound ip>
Update cluster from managedNATGateway to loadbalancer
az aks update --resource-group <resourceGroup> --name <clusterName> \
--outbound-type loadBalancer \
<--load-balancer-managed-outbound-ip-count <number of managed outbound ip>| --load-balancer-outbound-ips <outbound ip ids> | --load-balancer-outbound-ip-prefixes <outbound ip prefix ids> >
Warning
Don't reuse an IP address that is already in use in prior outbound configurations.
Update cluster from managedNATGateway to userDefinedRouting
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
Azure Kubernetes Service feedback
Azure Kubernetes Service is an open source project. Select a link to provide feedback: