Use LoadBalancer Services to expose applications

Expose on-cloud, edge, or hybrid pods with CLB or NLB and choose the right external traffic policy.

LoadBalancer Service configuration options:

How it works

The following diagrams show how traffic flows in each scenario.

On-cloud pods (ECS + CLB)

Pods run on Elastic Compute Service (ECS) instances inside a Virtual Private Cloud (VPC). The on-cloud control plane manages Classic Load Balancer (CLB) listeners and backend servers, distributing requests across backend pods.

Edge pods (ENS + ECS forwarding)

Pods run on edge servers in an Edge Node Service (ENS) node pool. On-cloud ECS instances forward requests over Express Connect to edge pods.

Hybrid pods (NLB — recommended)

Pods run in on-cloud and on-premises data centers. NLB distributes traffic across node pools, with pods registered directly as IP-type backend servers.

Prerequisites

Ensure you have:

An ACK Edge cluster
The network plug-in for your scenario (Terway Edge or Flannel VXLAN)

For the ENS scenario only:

An Express Connect circuit between the on-cloud VPC and edge data center
externalTrafficPolicy set to Cluster on the LoadBalancer Service (ECS forwarding does not support Local)

Important

Without ECS network forwarding, traffic cannot reach edge pods. Because this approach relies on ECS forwarding, if an ECS instance fails, load balancing is unavailable.

For the NLB scenario only:

An Express Connect circuit between on-cloud and edge node pools
Terway Edge as the network plug-in

Expose on-cloud pods with CLB

For pods on ECS instances in a VPC, create a standard LoadBalancer Service. The control plane provisions a CLB instance and syncs its listeners and backend servers with pod lifecycle events—no extra annotations needed for basic load balancing.

Expose edge pods via ECS forwarding

For pods in an ENS node pool, traffic enters a CLB listener on an on-cloud ECS instance and is forwarded over Express Connect to edge pods. Set externalTrafficPolicy: Cluster so all cluster nodes are eligible backends—traffic forwards even when a node has no local pod.

Expose hybrid pods with NLB (recommended)

For pods spanning on-cloud and edge node pools, use NLB to reach pods directly by IP. Add these annotations to the Service manifest:

Annotation	Purpose
`service.beta.kubernetes.io/backend-type: "eni"`	Add pods to NLB instances as backend servers
`service.beta.kubernetes.io/alibaba-cloud-loadbalancer-server-group-type: "Ip"`	Set the backend server group type to IP

Choose an external traffic policy

Set externalTrafficPolicy on a LoadBalancer or NodePort Service to control how external traffic reaches backend pods. Applies to both Terway Edge and Flannel VXLAN plug-ins.

	Local	Cluster
Backend servers	Only nodes running a backend pod are added to the Server Load Balancer (SLB) instance	All cluster nodes are added to the SLB instance
SLB resource quota	Low — fewer backend entries	High — every node is a backend entry. See Quotas
SLB IP access	Only nodes with a local backend pod	All nodes
Pod-level load balancing	Disabled by default. Enable with `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` for weighted round-robin (WRR) scheduling	Enabled by default
Source IP preservation	Supported	Not supported
Session persistence	Supported	Not supported
When to use	Apps that must log or act on client IP addresses	High-availability apps that do not need client IP preservation, such as large web clusters

Next steps

Use ELB instances to expose Services in multiple regions