This topic describes how to install the ack-kubernetes-elastic-workload add-on in a Container Service for Kubernetes cluster and run elastic workloads.
Prerequisites
A Container Service for Kubernetes cluster is created. For more information, see Create a managed Kubernetes cluster.
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
metadata:
name: nginx-deployment-basic
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
# nodeSelector:
# env: test-team
containers:
- name: nginx
image: nginx:1.7.9 # replace it with your exactly <image_name:tags>
ports:
- containerPort: 80
Create an elastic workload by using the following template:
# Define an elastic workload.
apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: ElasticWorkload
metadata:
name: elasticworkload-sample
spec:
sourceTarget:
name: nginx-deployment-basic
kind: Deployment
apiVersion: apps/v1
min: 2
max: 4
replicas: 6
elasticUnit:
- name: virtual-kubelet
labels:
virtual-kubelet: "true"
annotations:
virtual-kubelet: "true"
nodeSelector:
type: "virtual-kubelet"
tolerations:
- key: "virtual-kubelet.io/provider"
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: autoscaling.alibabacloud.com/v1beta1
Kind: ElasticWorkload
Metadata:
Creation Timestamp: 2020-05-06T03:43:41Z
Generation: 27
Resource Version: 20635284
Self Link: /apis/autoscaling.alibabacloud.com/v1beta1/namespaces/default/elasticworkloads/elasticworkload-sample
UID: 0e9205ff-38b8-43b7-9076-ffa130f26ef4
Spec:
Elastic Unit:
Annotations:
Virtual - Kubelet: true
Labels:
Virtual - Kubelet: true
Name: demo
Node Selector:
Type: virtual-kubelet
Tolerations:
Key: virtual-kubelet.io/provider
Operator: Exists
Replicas: 6
Source Target:
API Version: apps/v1
Kind: Deployment
Max: 2
Min: 0
Name: nginx-deployment-basic
Status:
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 172.20.1.151 cn-hangzhou.10.0.5.212 <none> <none>
nginx-deployment-basic-7ff9955f89-hrw2z 1/1 Running 0 138m 172.20.1.27 cn-hangzhou.10.0.5.208 <none> <none>
nginx-deployment-basic-unit-demo-8bb586568-4f8xt 1/1 Running 0 138m 10.1.76.63 virtual-node-eci-1 <none> <none>
nginx-deployment-basic-unit-demo-8bb586568-bl5pd 1/1 Running 0 138m 10.1.76.65 virtual-node-eci-0 <none> <none>
nginx-deployment-basic-unit-demo-8bb586568-ndbp8 1/1 Running 0 138m 10.1.76.64 virtual-node-eci-0 <none> <none>
nginx-deployment-basic-unit-demo-8bb586568-vx9jx 1/1 Running 0 138m 10.1.76.62 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
metadata:
name: elastic-workload-demo
namespace: default
spec:
scaleTargetRef:
apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: ElasticWorkload
name: elasticworkload-sample
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
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.