Container Compute Service:Expose an application with an existing load balancer

Considerations

SLB reuse limits

• The SLB instance that you want to reuse must meet the following requirements:

  • You can reuse only SLB instances that you create manually in the SLB console. You cannot reuse instances automatically created by the cloud controller manager (CCM) or used by the cluster API server.

  • To reuse an intranet SLB instance in an ACS cluster, the SLB instance and the ACS cluster must be in the same virtual private cloud (VPC).

  • The address type of the SLB instance must match the access type of the Service:

    • If the Service provides Public Access (specified by the annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"), the Address Type of the SLB instance must be Public Network.

    • If the Service provides internal access (specified by the annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"), the Address Type of the SLB instance must be Internal Network.

  • Multiple Services cannot use the same listener port on the same SLB instance.

  • When you reuse an SLB instance across clusters, make sure that the combination of the namespace and Service name is unique in each cluster.

• The CCM configures an SLB instance only for a type: LoadBalancer Service.

  Important

  If you change a type: LoadBalancer Service to another type, the CCM deletes the configurations that were added to the SLB instance. As a result, the Service becomes inaccessible through the SLB instance.

• The CCM uses a declarative API and automatically reconciles the SLB configuration based on the Service configuration under specific conditions. If the service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true" annotation is set, any configurations that you manually modify in the SLB console may be overwritten.

  Important

  Do not manually modify any configurations of an SLB instance managed by ACS in the SLB console. Otherwise, the configurations may be lost and the Service may become inaccessible.

• You cannot change the SLB instance for an existing LoadBalancer service. If you want to change the SLB instance, you must create a new Service.

SLB quota limits

• 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

The following steps show how to deploy the application by using kubectl.

1. Use kubectl on Cloud Shell to connect to your cluster.

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

   View YAML content

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-nginx                 # The name of the sample application.
     labels:
       app: nginx
   spec:
     replicas: 3                    # The number of replicas.
     selector:
       matchLabels:
         app: nginx                 # This value must match the selector in the Service manifest to expose the application.
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginx:latest
           ports:
           - containerPort: 80        # This port must be exposed in the Service.

3. Run the following command to deploy the my-nginx sample application.

   kubectl apply -f my-nginx.yaml

4. Run the following command to verify that the application is running.

   kubectl get deployment my-nginx

   Expected output:

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

Step 2: Expose the application with a Service

You can create a LoadBalancer service to expose the application by using either the console or kubectl.