All Products
Search
Document Center

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

Last Updated:May 28, 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 Services of Type=LoadBalancer. It does not configure load balancing for Services of other types.

  • Important

    If a Service of Type=LoadBalancer is changed to a type other than LoadBalancer, CCM deletes the configurations that were added to the SLB instance. As a result, the Service becomes inaccessible through the SLB instance.

  • CCM uses a declarative API and automatically refreshes the SLB configuration based on the Service configuration under certain conditions. Any configurations that you modify in the Server Load Balancer console are at risk of being overwritten.

  • Important

    Do not manually modify any configurations of SLB instances created and maintained by ACK in the Server Load Balancer console. Otherwise, your configurations may be lost, and the Service may become inaccessible.

  • Do not manually delete or modify the service.k8s.alibaba/resources or service.k8s.alibaba/nlb finalizer on a Service. Manually modifying the finalizer may prevent CLB or NLB resources from being properly reclaimed.

  • If the Cloud Controller Manager version is v2.5.0 or later, the option to specify a CLB instance when you create a Service in the console is a whitelisted feature. To use this feature, you must submit a request on the Quota Center platform.

Server Load Balancer

  • CCM creates an SLB instance for each Service of Type=LoadBalancer. By default, you can have up to 60 CLB instances and 60 NLB instances. To increase this quota, log on to the Quota Center console and submit an application.

  • CCM attaches ECS instances or Elastic Network Interfaces (ENIs) to the backend server group of the SLB instance based on the Service configuration. It also creates a separate server group for each different targetPort in the Service. Note the following quota limits:

    • Number of backend servers: By default, you can attach up to 200 backend servers to a CLB instance and up to 400 ECS, ENI, or IP-based backend servers to an NLB instance. The required quota is calculated as follows: Number of backend servers × Number of targetPorts. To increase the quota, log on to the Quota Center console and submit an application in advance.

    • Number of times an instance can be attached to server groups: By default, the same ECS instance or ENI can be attached to a maximum of 50 different backend server groups of a CLB instance and 200 different backend server groups of an NLB instance. To attach it to more server groups, log on to the Quota Center console and submit an application.

    • Extra quota usage during rolling updates: During a rolling update, new pods are created before old pods are destroyed. This consumes extra quota. The actual consumption may exceed your expectations. Reserve enough quota in advance.

  • CCM creates listeners based on the ports defined in the Service. By default, you can add up to 50 listeners to a CLB or NLB instance. To add more listeners, log on to the Quota Center console and submit an application.

  • For more information about SLB limits, see CLB limits and NLB limits.

    To query SLB quotas, see Server Load Balancer quota management.

Step 1: Deploy a sample application

This topic shows how to use a LoadBalancer Service to expose a stateless Nginx application in an ACK cluster.

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

  3. On the Deployments page, click Create from Image and configure the basic information, container settings, and advanced settings for the application.

    1. On the Basic Information tab, set Name to my-nginx, accept the defaults for the other parameters, and then click Next.

    2. On the Container tab, set the container image name and port, accept the defaults for the other parameters, and then click Next.

      Parameter

      Value

      Image name

      Click Select images. In the dialog box that appears, click the Artifact Center tab, search fornginx and select the image repository named openanolis/nginx. Then, click Select Image Tag, set the image version, and then click Confirm.

      Port

      • Name: nginx.

      • Container Port: 80.

    3. On the Advanced Settings tab, keep the default settings and click Launch.

kubectl

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

    apiVersion: apps/v1 # for versions before 1.8.0 use apps/v1beta1
    kind: Deployment
    metadata:
      name: my-nginx    # The name of the sample application.
      labels:
        app: nginx
    spec:
      replicas: 2       # The number of replicas.
      selector:
        matchLabels:
          app: nginx     # Must match the selector in the Service to be exposed by 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                                # This port must be exposed in the Service.
  2. Run the following command to deploy the sample application my-nginx:

    kubectl apply -f my-nginx.yaml
  3. Run the following command to verify that the sample application is running as expected:

    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.

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 Load Balancing 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. Run the following command to create a Service named my-nginx-svc and use the Service to expose the application:

    kubectl apply -f my-nginx-svc.yaml
  3. Run the following command to make sure that the LoadBalancer Service is created:

    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. Run the following command to access the sample application:

    curl <YOUR-External-IP> # Replace <YOUR-External-IP> with the external IP address that you obtained.

    Expected output:

    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
        body {
            width: 35em;
            margin: 0 auto;
            font-family: Tahoma, Verdana, Arial, sans-serif;
        }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
    
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </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): 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 scheduled 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 scheduled to the same backend server.

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

    Important

    QUIC is implemented based on draft-ietf-quic-transport-10 and iterates rapidly. Compatibility is not guaranteed for all QUIC versions. Test this mode before applying it to 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): 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 scheduled 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 scheduled to the same backend server.

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

    Important

    QUIC is implemented based on draft-ietf-quic-transport-10 and iterates rapidly. Compatibility is not guaranteed for all QUIC versions. Test this mode before applying it to 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