All Products
Search
Document Center

Container Service for Kubernetes:Expose an application with an auto-created load balancer

Last Updated:Oct 30, 2026

If you do not have an available load balancer, the cloud-controller-manager (CCM) component automatically creates and manages a load balancer instance for a service of type: LoadBalancer. This can be a Classic Load Balancer (CLB) or a Network Load Balancer (NLB). This topic describes how to expose an Nginx application by using a service that automatically creates a load balancer.

Usage notes

Considerations for CCM-managed SLB instances

  • CCM configures load balancing only for Type=LoadBalancer Services.

  • Important

    If a Type=LoadBalancer Service is changed to another type, CCM deletes the SLB configurations. The Service becomes inaccessible through the SLB instance.

  • CCM uses a declarative API and may refresh SLB configuration based on Service changes. Manual modifications in the SLB console may be overwritten.

  • Important

    Do not modify configurations of ACK-managed SLB instances in the SLB console. Your changes may be lost, and the Service may become inaccessible.

  • Do not delete or modify the service.k8s.alibaba/resources or service.k8s.alibaba/nlb finalizer. This may prevent CLB or NLB resources from being properly reclaimed.

  • For Cloud Controller Manager v2.5.0 or later, specifying a CLB instance when creating a Service requires whitelisting. Submit a request on Quota Center.

Server Load Balancer

Deploy an application

Deploy a stateless NGINX application as the LoadBalancer Service backend.

Use the ACK console

  1. Log on to the ACK console. In the left-side navigation pane, click Clusters.

  2. On the Clusters page, click your cluster name. In the left pane, choose Workloads > Deployments.

  3. On the Deployments page, click Create from Image and configure the Deployment:

    1. On the Basic Information page, set Name to my-nginx and click Next.

    2. On the Container page, configure the image and port:

      Parameter

      Value

      Image Name

      Click Select images. On the Artifact Center tab, search for nginx and select openanolis/nginx. Click Select Image Tag, set a tag, and click Confirm.

      Port

      Name: nginx, Container Port: 80

    3. On the Advanced page, keep the defaults and click Create.

Use kubectl

  1. Create a file named my-nginx.yaml with the following content:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx        # Deployment name
      labels:
        app: nginx
    spec:
      replicas: 2           # Number of pod replicas
      selector:
        matchLabels:
          app: nginx        # Must match the selector in the Service
      template:
        metadata:
          labels:
            app: nginx
        spec:
        #  nodeSelector:
        #    env: test-team
          containers:
          - name: nginx
            image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
            ports:
            - containerPort: 80
  2. Deploy the application:

    kubectl apply -f my-nginx.yaml
  3. Verify the Deployment is ready:

    kubectl get deployment my-nginx

    Expected output:

    NAME       READY   UP-TO-DATE   AVAILABLE   AGE
    my-nginx   2/2     2            2           50s

Step 2: Expose the application with an auto-created load balancer

You can create a service of type: LoadBalancer and expose your application by using either the ACK console or kubectl.

Starting from September 11, 2025, creating a Service of the Classic Load Balancer (CLB) type through the console requires whitelist access. Before you create a CLB-type Service in the console, submit a privilege quota application for “Console-based creation of a CLB-type Service” in the Quota Center (quota IDs: ack.white_list / ack.create_clb_service). You can create a CLB-type Service in the console only after the application is approved. For more information, see the product change announcement.

Console

  1. Log on to the ACK console. In the left navigation pane, click Clusters.

  2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Network > Services.

  3. On the Services page, click Create. In the Create Service dialog box, set the parameters for the service.

    Parameter

    Description

    Example

    Name

    Enter a name for the service.

    my-nginx-svc

    service type

    Select a service type. A service supports the following network modes to handle access from different types and sources of clients:

    Cluster IP

    This type enables communication within a cluster. Service discovery among service instances is supported only when the service type is set to ClusterIP. By using a Headless Service, you can interact with other service discovery mechanisms without relying on the default ClusterIP-based service discovery and load balancing provided by Kubernetes.

    LoadBalancer

    By integrating with Alibaba Cloud Classic Load Balancer (CLB) and Network Load Balancer (NLB), you can expose applications within the cluster to external traffic. This method significantly improves application availability and performance compared to the NodePort method.

    Node Port

    This provides a convenient way for external users to access services in the cluster through the IP address and a specific port of a node. Users can connect to a NodePort service by accessing <NodeIP>:<NodePort>, but you must manually configure load balancing.

    1. Select Server Load Balancer as the service type.

    2. Select CLB as the load balancer type and select Create Resource.

    3. In the Create CLB Instance drop-down section, adjust the settings as needed. Set the Billing Method to Pay-by-specification.

    External Traffic Policy

    Set the Node Port or Server Load Balancer service type before you can configure the External Traffic Policy. For more information, see Manage services.

    • Local: Traffic goes only to pods on the same node.

    • Cluster: Traffic can be forwarded to pods on other nodes in the cluster.

    Local

    Backend

    Select the backend application to bind to the service. If you do not associate a deployment, the system does not create Endpoints objects. For more information, see services-without-selectors.

    • Name: app

    • Value: nginx

    Port Mapping

    Add a service port (corresponds to the port field in the Service YAML file) and a container port (corresponds to the targetPort field in the Service YAML file). The container port must match the port exposed by the backend pod.

    • Service Port: 80

    • Container Port: 80

    • Protocol: TCP

    annotations

    Add an annotation to the service to configure load balancer parameters. For more parameters, see Configure CLB using annotations and Configure NLB using annotations.

    Important

    Do not reuse the load balancer instance of the cluster's API Server. Otherwise, cluster access may be disrupted.

    In this example, the public network traffic for the service is billed on a pay-by-bandwidth basis, with a peak bandwidth of 2 Mbit/s to control traffic. The annotations are as follows:

    • service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: paybybandwidth

    • service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth: 2

    labels

    Add a label to identify the service.

    None

    Service Deletion Protection

    Enable deletion protection for services that support critical business or handle sensitive data. This prevents accidental deletions and reduces maintenance costs. After enabling deletion protection, you must manually disable it before deleting the resource.

    Note

    To use this feature, install the policy-template-controller and gatekeeper components from the Container Security Policy add-on. Click Install Now to deploy the components.

    Disabled

    After you configure the parameters, click OK.

  4. After the service is created, click its name to go to its details page. In the Basic Information section, click the service's External IP, such as 39.106.XX.XX:80, to access the sample application.

    image

Kubectl

  1. Create a file named my-nginx-svc.yaml with the following content for the sample service.

    Set the selector to the value of matchLabels in the my-nginx.yaml sample application file, which is app: nginx in this example. This associates the service with the backend application.

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: nginx
      name: my-nginx-svc
      namespace: default
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        app: nginx
      type: LoadBalancer
  2. Apply the Service:

    kubectl apply -f my-nginx-svc.yaml
  3. Confirm the Service has an external IP:

    kubectl get svc my-nginx-svc

    Expected output:

    NAME           TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
    my-nginx-svc   LoadBalancer   172.21.5.82   39.106.XX.XX     80:30471/TCP   5m
  4. Access the application:

    curl <YOUR-EXTERNAL-IP>    # Replace with the external IP from the previous step

    Expected output:

    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    ...
    </html>

Classic Load Balancer (CLB)

Create CLB Instance

When you create a Classic Load Balancer (CLB), follow the instructions for creating a CLB instance. For more information, see Create and manage CLB instances.

Name

Description

Name

Enter a custom name for the CLB.

Access Method

Select Public Access or Internal Access.

Billing Method

Select Pay-by-specification or Pay-as-you-go (Pay-by-CU). For more information, see CLB billing overview.

IP Version

Select IPv4 or IPv6.

Important

To use IPv6, ensure your ACK cluster region supports IPv6 CLB instances. For regions that support IPv6 CLB, see CLB supported regions.

Scheduling Algorithm

Supported algorithms are round robin (RR) and weighted round robin (WRR). RR (default): Distribute external requests to backend servers in sequence. WRR: Backend servers with higher weights receive more requests.

Access Control

Provide listener-level access control. For more information, see Access control.

Health Check

Supports TCP and HTTP protocols. After enabling health checks, use them to determine backend server availability. For more information, see CLB health check.

Others

Configure CLB using annotations. For more information, see Configure CLB using annotations.

Use Existing Resource

Select an existing Classic Load Balancer (CLB) instance from the drop-down list. You can also select the option to forcibly overwrite existing listeners. For more information, see Use existing load balancer and force overwrite existing listeners.

Important

Reusing CLB instances is subject to certain limitations and considerations. For more information, see Which Server Load Balancers can be reused?.

Configure Resources

Name

Description

Scheduling Algorithm

Supports two policies: round-robin (RR) and weighted round-robin (WRR). RR is the default. With RR, Server Load Balancer distributes external requests to backend servers in sequence. With WRR, backend servers with higher weights receive more requests.

Access Control

Provides listener-level access control. For more information, see Access control.

Health Check

Supports TCP and HTTP protocols. After you enable health checks, Server Load Balancer uses them to assess the availability of your backend servers. For how health checks work, see How Server Load Balancer health checks work.

Others

You can also configure a Classic Load Balancer using annotations. For more information, see Configure a Classic Load Balancer using annotations.

Network Load Balancer (NLB)

Create NLB Instance

You can create a Network Load Balancer (NLB) resource. For more information, see Create and manage NLB instances.

Name

Description

Name

Enter a custom name for the NLB instance. This parameter is required only when you create a new NLB instance.

Access Method

Select Public Access or Internal Access as needed.

Billing Method

Pay-as-you-go. For more information, see NLB billing.

IP Version

Select IPv4 or DualStack as needed.

Scheduling Algorithm

Select a scheduling algorithm.

  • Round Robin: Distributes requests to backend servers in sequence.

  • Weighted Round-robin (Default): Distributes requests to backend servers based on their weights. Backend servers with higher weights receive more requests.

  • Source IP Hashing: Uses consistent hashing based on source IP addresses. Requests from the same source IP address are routed to the same backend server.

  • Four-element Hashing: Uses consistent hashing based on four-tuples (source IP, destination IP, source port, and destination port). Packets from the same stream are routed to the same backend server.

  • QUIC ID Hashing: Uses consistent hashing based on QUIC connection IDs. Requests with the same QUIC ID are routed to the same backend server.

    You can select QUIC ID hashing only when the backend protocol is UDP.
    The QUIC protocol is evolving rapidly. This algorithm is implemented based on draft-ietf-quic-transport-10. Compatibility with all QUIC versions is not guaranteed. We recommend that you perform sufficient tests before you use this algorithm in a production environment.
  • Weighted Least Connections: This algorithm considers the actual load (number of connections) of backend servers in addition to the weight of each server. If backend servers have the same weight, the server with the fewest active connections is polled more frequently.

Health Check

Enable or disable health checks.

  • TCP (Default): Sends SYN handshake messages to check whether the server port is active.

    • Response Timeout Period: Enter the period to wait for a response from a health check. If a backend server does not respond correctly within the specified period, the health check fails.

    • Health Check Interval: Enter the interval for health checks.

    • Healthy Threshold: The number of consecutive successful health checks required to change the health check status of a backend server from failed to successful.

    • Unhealthy Threshold: The number of consecutive failed health checks required to change the health check status of a backend server from successful to failed.

  • Http : Sends HEAD or GET requests to simulate browser access and check the health of the server application.

    • Domain Name: Enter the domain name for the health check.

      • Backend Server Internal IP (Default): Uses the private IP address of the backend server as the domain name for the health check.

      • Custom Domain Name: Enter a domain name.

    • Health Check Path: Enter the URL of the health check page.

    • Health Check Status Codes: Select http_2xx (Default), http_3xx, http_4xx, or http_5xx.

Others

You can also configure the NLB instance using annotations. For more information, see Configure an NLB instance using annotations.

VPC

The region and ID of the default VPC for the cluster.

vSwitch

Select a virtual switch for a supported zone in the default VPC of the cluster. You can also click Create vSwitch to create a new one.

Use Existing Resource

Select an existing NLB instance from the drop-down list. You can also select the option to forcibly overwrite the existing listener. For more information, see Use an existing Server Load Balancer instance.

Important

Reusing an NLB instance is subject to certain limitations. For more information, see Which Server Load Balancer instances can be reused?

Configure Resources

Name

Description

Scheduling Algorithm

Select a scheduling algorithm.

  • Round Robin: Distributes requests to backend servers in sequence.

  • Weighted Round-robin (Default): Distributes requests to backend servers based on their weights. Backend servers with higher weights receive more requests.

  • Source IP Hashing: Uses consistent hashing based on source IP addresses. Requests from the same source IP address are routed to the same backend server.

  • Four-element Hashing: Uses consistent hashing based on four-tuples (source IP, destination IP, source port, and destination port). Packets from the same stream are routed to the same backend server.

  • QUIC ID Hashing: Uses consistent hashing based on QUIC connection IDs. Requests with the same QUIC ID are routed to the same backend server.

    You can select QUIC ID hashing only when the backend protocol is UDP.
    The QUIC protocol is evolving rapidly. This algorithm is implemented based on draft-ietf-quic-transport-10. Compatibility with all QUIC versions is not guaranteed. We recommend that you perform sufficient tests before you use this algorithm in a production environment.
  • Weighted Least Connections: This algorithm considers the actual load (number of connections) of backend servers in addition to the weight of each server. If backend servers have the same weight, the server with the fewest active connections is polled more frequently.

Health Check

Enable or disable health checks.

  • TCP (Default): Sends SYN handshake messages to check whether the server port is active.

    • Response Timeout Period: Enter the period to wait for a response from a health check. If a backend server does not respond correctly within the specified period, the health check fails.

    • Health Check Interval: Enter the interval for health checks.

    • Healthy Threshold: The number of consecutive successful health checks required to change the health check status of a backend server from failed to successful.

    • Unhealthy Threshold: The number of consecutive failed health checks required to change the health check status of a backend server from successful to failed.

  • Http : Sends HEAD or GET requests to simulate browser access and check the health of the server application.

    • Domain Name: Enter the domain name for the health check.

      • Backend Server Internal IP (Default): Uses the private IP address of the backend server as the domain name for the health check.

      • Custom Domain Name: Enter a domain name.

    • Health Check Path: Enter the URL of the health check page.

    • Health Check Status Codes: Select http_2xx (Default), http_3xx, http_4xx, or http_5xx.

Others

You can also configure the NLB instance using annotations. For more information, see Configure an NLB instance using annotations.

VPC

The region and ID of the default VPC for the cluster.

vSwitch

Select a virtual switch for a supported zone in the default VPC of the cluster. You can also click Create vSwitch to create a new one.

Next steps

If you need to view, update, or delete a service, or enable service deletion protection, you can perform the following operations. For example, you can modify the public-facing load balancer that is associated with the service.

Important

When you delete a Service or change its type from LoadBalancer to another type, the automatically created load balancer instance is automatically released.

Console

  1. Log on to the ACK console. In the left navigation pane, click Clusters.

  2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Network > Services.

  3. On the Services page, find the target service, and then click Update in the Actions column or click the image icon to update, Delete, or Enable Deletion Protection for the service.

Kubectl

Update a service

  • Method 1: Run the following command to update the service.

    kubectl edit service my-nginx-svc
  • Method 2: Modify the YAML file and apply the changes.

    kubectl apply -f my-nginx-svc.yaml

View a service

Run the following command to view the service.

kubectl get service my-nginx-svc

Expected output:

NAME           TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
my-nginx-svc   LoadBalancer   172.21.XX.XX   192.168.XX.XX     80:31599/TCP   5m

Delete a service

Run the following command to delete the service.

kubectl delete service my-nginx-svc