This topic describes how to install the ack-kubernetes-elastic-workload add-on in a Container Service for Kubernetes cluster and run elastic workloads.
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.