All Products
Document Center

Run elastic workloads in a Container Service for Kubernetes cluster

Last Updated: Mar 03, 2021

This topic describes how to install the ack-kubernetes-elastic-workload add-on in a Container Service for Kubernetes cluster and run elastic workloads.


Install the ack-kubernetes-elastic-workload add-on

1. Log on to the Container Service console.

2. In the left-side navigation pane, choose Cluster > Cluster. On the Clusters page, find the cluster in which you want to install the ack-kubernetes-elastic-workload add-on and take note of the name of the cluster.

3. In the left-side navigation pane, choose Marketplace > App Catalog. On the App Catalog page, search for ack-kubernetes-elastic-workload and click the card of the add-on that is found.

4. In the Deploy pane on the right, select the cluster in which you want to install the ack-kubernetes-elastic-workload add-on and click Create.

5. In the left-side navigation pane, choose Applications > Deployments. On the Deployments page, select the cluster where the add-on is installed and the kube-system namespace from the drop-down lists. Verify that the deployment named ack-kubernetes-elastic-workload-controller-manager appears in the list.

Run an elastic workload

Kubernetes schedules each workload and manages the lifecycle of workloads. To run an elastic workload, Kubernetes must be able to perform the following operations:

1. Change the scheduling policy when the number of replicas reaches a certain value.

2. Preferentially destroy certain pods during lifecycle management.

This section demonstrates how to define and run an elastic workload and explains how Kubernetes schedules the replicas of the elastic workload.

Create a deployment by using the following template:

apiVersion: apps/v1 # for versions before 1.8.0 use apps/v1beta1
kind: Deployment
  name: nginx-deployment-basic
    app: nginx
  replicas: 2
      app: nginx
        app: nginx
    #  nodeSelector:
    #    env: test-team
      - name: nginx
        image: nginx:1.7.9 # replace it with your exactly <image_name:tags>
        - containerPort: 80

Create an elastic workload by using the following template:

# Define an elastic workload.
kind: ElasticWorkload
  name: elasticworkload-sample
    name: nginx-deployment-basic
    kind: Deployment
    apiVersion: apps/v1
    min: 2
    max: 4
  replicas: 6
  - name: virtual-kubelet
      virtual-kubelet: "true"
      virtual-kubelet: "true"
      type: "virtual-kubelet"
    - key: ""
      operator: "Exists"
    # min: the minimum number of replicas that must be scheduled to the elastic unit. You can specify the minimum number and maximum number of replicas for each elastic unit.
    # max: 10

The method of using an elastic workload is similar to that of using Horizontal Pod Autoscaler (HPA). An elastic workload scales out pods on the virtual node connected to your cluster, which has no impact on existing workloads.

Typically, the definition of an elastic workload consists of the following information:

1. SourceTarget: defines the type of the source workload and the allowed number of replicas.

2. elasticUnit: defines the scheduling policies for elastic units in an array. If you need to specify multiple elastic units, define the parameters of each elastic unit in the same order as that in the template.

Based on the preceding definition, the source deployment can have two to four replicas. When the number of replicas does not exceed four, the replicas are scheduled in the source deployment. When more than four replicas are required, certain replicas are scheduled to the elastic unit virtual-kubelet. The elastic unit virtual-kubelet has its own scheduling policy, including the labels, annotations, nodeSelector, affinity, and tolerations.

Kubernetes monitors the source deployment and generates cloned replicas on the elastic unit based on the scheduling policy configured for the elastic unit. When the number of replicas of the elastic workload changes, Kubernetes dynamically schedules replicas to the source deployment and elastic unit.

After you run the elastic workload template, you can run a command to view the status of the elastic workload. The Desired Replicas parameter for each unit in the Status section indicates the number of replicas scheduled to the unit.

kubectl describe ew elasticworkload-sample   # same as kubectl get elasticworkload
Name:         elasticworkload-sample
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:
Kind:         ElasticWorkload
  Creation Timestamp:  2020-05-06T03:43:41Z
  Generation:          27
  Resource Version:    20635284
  Self Link:           /apis/
  UID:                 0e9205ff-38b8-43b7-9076-ffa130f26ef4
  Elastic Unit:
      Virtual - Kubelet:  true
      Virtual - Kubelet:  true
    Name:                 demo
    Node Selector:
      Type:  virtual-kubelet
      Operator:  Exists
  Replicas:      6
  Source Target:
    API Version:  apps/v1
    Kind:         Deployment
    Max:          2
    Min:          0
    Name:         nginx-deployment-basic
  Elastic Units Status:
    Desired Replicas:  4
    Name:              nginx-deployment-basic-unit-virtual-kubelet
    Update Timestamp:  2020-05-07T12:38:27Z
  Replicas:            6
  Selector:            app=nginx
  Source Target:
    API Version:       apps/v1
    Desired Replicas:  2
    Kind:              Deployment
    Name:              nginx-deployment-basic
    Update Timestamp:  2020-05-07T12:38:27Z
Events:                <none>

After the elastic workload template is run, you can run a command to view the status of pods. Based on the command output, the source deployment is cloned to generate new deployments and pods. The number of pods for each deployment is allocated based on the definition of the elastic workload.

kubectl get pod -o wide
 NAME                                               READY   STATUS    RESTARTS   AGE    IP             NODE                     NOMINATED NODE   READINESS GATES
nginx-deployment-basic-7ff9955f89-djxwv            1/1     Running   0          138m   cn-hangzhou.   <none>           <none>
nginx-deployment-basic-7ff9955f89-hrw2z            1/1     Running   0          138m    cn-hangzhou.   <none>           <none>
nginx-deployment-basic-unit-demo-8bb586568-4f8xt   1/1     Running   0          138m     virtual-node-eci-1       <none>           <none>
nginx-deployment-basic-unit-demo-8bb586568-bl5pd   1/1     Running   0          138m     virtual-node-eci-0       <none>           <none>
nginx-deployment-basic-unit-demo-8bb586568-ndbp8   1/1     Running   0          138m     virtual-node-eci-0       <none>           <none>
nginx-deployment-basic-unit-demo-8bb586568-vx9jx   1/1     Running   0          138m     virtual-node-eci-2       <none>           <none>

In addition, you can use the elastic workload with HPA, as shown in the following configuration file. HPA scales replicas of the elastic workload based on the metric of CPU usage, and dynamically adjusts the number of replicas on each unit. For example, if the number of replicas needs to be reduced from six to four, HPA preferentially destroys replicas on the elastic unit.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
  name: elastic-workload-demo
  namespace: default
    kind: ElasticWorkload
    name: elasticworkload-sample
  minReplicas: 2
  maxReplicas: 10
  - type: Resource
      name: cpu
        type: Utilization
        averageUtilization: 50


In conclusion, Kubernetes generates multiple deployments for an elastic workload by cloning the source deployment and overriding the scheduling policy of the source deployment. In this way, Kubernetes can change the scheduling policy when the number of replicas reaches a certain value. Based on the number of replicas required, Kubernetes can dynamically adjust the number of replicas in the source deployment and on the elastic unit. This allows Kubernetes to preferentially destroy certain pods during a scale-in.