All Products
Search
Document Center

Alibaba Cloud Service Mesh:Associate an NLB instance with an ingress gateway

Last Updated:Mar 11, 2026

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

  1. Log on to the ASM console.

  2. In the left-side navigation pane, choose Service Mesh > Mesh Management.

  3. On the Mesh Management page, click the name of your ASM instance.

  4. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.

  5. On the Ingress Gateway page, click Create.

  6. Configure the NLB-specific parameters described in the following table. For all other parameters, see Create an ingress gateway.

    ParameterDescription
    NLBAppears when Service Type is set to LoadBalancer. Select an access type: Internet Access (public) or VPC Access (internal).
    Create SLB InstanceSelected by default. Select vSwitches in at least two zones under Select Zones for NLB Instance.
    Use Existing SLB InstanceSelect 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

  1. Log on to the ASM console.

  2. In the left-side navigation pane, choose Service Mesh > Mesh Management.

  3. On the Mesh Management page, click the name of your ASM instance.

  4. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.

  5. On the Ingress Gateway page, click Use a YAML template.

  6. Set the gateway name to ingressgateway-nlb-test and select istio-system for Namespace.

  7. 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.

Expand to view YAML

apiVersion: istio.alibabacloud.com/v1
kind: IstioGateway
metadata:
  name: ingressgateway-nlb-test
  namespace: istio-system
spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: istio
              operator: In
              values:
              - ingressgateway
          topologyKey: kubernetes.io/hostname
        weight: 1
  autoCreateGatewayYaml: false
  clusterIds:
  - <your-cluster-id>                    # ID of the cluster added to the mesh
  disableContainerPortExposed: true
  dnsPolicy: ClusterFirst
  externalTrafficPolicy: Local
  gatewayType: ingress
  hostNetwork: false
  ports:
  - name: http-0
    port: 80
    protocol: HTTP
    targetPort: 80
  - name: https-1
    port: 443
    protocol: HTTPS
    targetPort: 443
  replicaCount: 2
  resources:
    limits:
      cpu: "2"
      memory: 4G
    requests:
      cpu: 200m
      memory: 256Mi
  rollingMaxSurge: 25%
  rollingMaxUnavailable: 25%
  runAsRoot: true
  serviceAnnotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain: "on"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout: "10"
    service.beta.kubernetes.io/alicloud-loadbalancer-address-type: internet
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-zone-maps: "<zone-id-1>:<vswitch-id-1>,<zone-id-2>:<vswitch-id-2>"
  serviceType: LoadBalancer
  loadBalancerClass: alibabacloud.com/nlb    # Required: switches from CLB to NLB

Replace the following placeholders with your actual values:

PlaceholderDescriptionExample
<your-cluster-id>ID of the Kubernetes cluster added to the meshcd1a4f4f7e2d4419aba****
<zone-id-1>First availability zone IDcn-hangzhou-g
<vswitch-id-1>vSwitch ID in the first zonevsw-bp1xxxxxxxxxx
<zone-id-2>Second availability zone IDcn-hangzhou-j
<vswitch-id-2>vSwitch ID in the second zonevsw-bp1yyyyyyyyyy
Note

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 keyDescriptionRequired
alibaba-cloud-loadbalancer-zone-mapsMaps availability zones to vSwitch IDs. Specify at least two zones. Format: <zone-id>:<vswitch-id>,<zone-id>:<vswitch-id>Yes
alicloud-loadbalancer-address-typeAccess type. Set to internet for public access or intranet for VPC-only access.Yes
alibaba-cloud-loadbalancer-connection-drainEnables connection draining during backend removal. Set to on or off.No (recommended)
alibaba-cloud-loadbalancer-connection-drain-timeoutTimeout 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:

  1. 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.

    nlb.png

  2. (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.

Related topics