When you set Service Type to LoadBalancer for an ASM ingress gateway, a Classic Load Balancer (CLB) instance is associated by default. To handle higher throughput at Layer 4 with automatic scaling, associate a Network Load Balancer (NLB) instance instead by setting loadBalancerClass to alibabacloud.com/nlb.
This topic describes how to create an NLB-backed ingress gateway through the ASM console or a YAML template.
Prerequisites
Before you begin, make sure you have:
A Kubernetes cluster added to your ASM instance that meets the following requirements:
Kubernetes cluster version V1.24 or later
Cloud controller manager (CCM) version V2.5.0 or later
ASM instance version V1.18 or later
vSwitches in at least two zones within the VPC where the ACK cluster resides
Create an NLB-backed ingress gateway
Create the gateway through the ASM console or by applying a YAML template.
Option 1: Use the ASM console
Log on to the ASM console.
In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of your ASM instance.
In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.
On the Ingress Gateway page, click Create.
Configure the NLB-specific parameters described in the following table. For all other parameters, see Create an ingress gateway.
Parameter Description NLB Appears when Service Type is set to LoadBalancer. Select an access type: Internet Access (public) or VPC Access (internal). Create SLB Instance Selected by default. Select vSwitches in at least two zones under Select Zones for NLB Instance. Use Existing SLB Instance Select an existing NLB instance from the Select An Existing Load Balancer dropdown. Review Risks of reusing a load balancer before choosing this option.
Option 2: Use a YAML template
Log on to the ASM console.
In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of your ASM instance.
In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.
On the Ingress Gateway page, click Use a YAML template.
Set the gateway name to ingressgateway-nlb-test and select istio-system for Namespace.
Paste the following YAML and replace the placeholder values. You do not need to specify specifications for the NLB instance, but you must specify at least two zones.
Replace the following placeholders with your actual values:
| Placeholder | Description | Example |
|---|---|---|
<your-cluster-id> | ID of the Kubernetes cluster added to the mesh | cd1a4f4f7e2d4419aba**** |
<zone-id-1> | First availability zone ID | cn-hangzhou-g |
<vswitch-id-1> | vSwitch ID in the first zone | vsw-bp1xxxxxxxxxx |
<zone-id-2> | Second availability zone ID | cn-hangzhou-j |
<vswitch-id-2> | vSwitch ID in the second zone | vsw-bp1yyyyyyyyyy |
To create an internal (VPC-only) NLB, change the alicloud-loadbalancer-address-type annotation from internet to intranet.
Key service annotations
The following annotations control NLB behavior. All annotations use the service.beta.kubernetes.io/ prefix.
| Annotation key | Description | Required |
|---|---|---|
alibaba-cloud-loadbalancer-zone-maps | Maps availability zones to vSwitch IDs. Specify at least two zones. Format: <zone-id>:<vswitch-id>,<zone-id>:<vswitch-id> | Yes |
alicloud-loadbalancer-address-type | Access type. Set to internet for public access or intranet for VPC-only access. | Yes |
alibaba-cloud-loadbalancer-connection-drain | Enables connection draining during backend removal. Set to on or off. | No (recommended) |
alibaba-cloud-loadbalancer-connection-drain-timeout | Timeout in seconds for connection draining. | No |
For the full list of NLB annotations, see Configure NLB instances by using annotations.
Verify the NLB association
After the gateway is created, confirm that the NLB instance is associated:
On the Ingress Gateway page, confirm that the new gateway appears. NLB-backed gateways display a domain name as the Service Address, while CLB-backed gateways display an IP address. If you specified two zones, two IP addresses are bound to the domain name.

(Optional) Log on to the NLB console to view the NLB instance status and configuration.
Risks of reusing a load balancer
Assign a dedicated load balancer to each Kubernetes Service whenever possible. Reusing an existing NLB instance introduces the following risks:
Listener overwrite: Existing listeners are overwritten when the Service is created, which can make your other applications inaccessible.
Reuse restrictions: Only NLB instances created manually in the console or through OpenAPI can be reused. Instances created automatically by Kubernetes through a Service cannot be reused.
Port conflicts: Multiple Services sharing the same NLB cannot use the same frontend listener port.
Identifier dependency: Kubernetes uses listener and vServer group names as unique identifiers. Do not rename them.
No cross-cluster or cross-region reuse: Load balancer sharing across clusters or regions is not supported.