Auto Scaling

KubeVela supports integrate any auto-scaling ways in Kubernetes world. In this doc, we’ll use KEDA for auto-scaling. KEDA is a Kubernetes-based Event Driven Autoscaling component, it provides event driven scale for any container running in Kubernetes.

  1. vela addon enable keda

After installed, you’ll get the keda-auto-scaler trait, you can learn the specification below.

Keda supports lots of triggers such as cron, cpu, etc, let’s check some examples to learn how it works in KubeVela.

Auto Scaling - 图1caution

When you’re using HPA, you must specify the apply-once policy to let the HPA control the replica field.

Here’re several examples about how autoscaling work in KubeVela application.

We can use cron hpa with the keda cron trigger.

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: scaler-eg-app
  5. spec:
  6. components:
  7. - name: hello-world-scaler
  8. type: webservice
  9. properties:
  10. image: oamdev/hello-world
  11. ports:
  12. - port: 8000
  13. expose: true
  14. traits:
  15. # This Trait used for initializing the replica
  16. - type: scaler
  17. properties:
  18. replicas: 1
  19. - type: keda-auto-scaler
  20. properties:
  21. triggers:
  22. - type: cron
  23. metadata:
  24. timezone: Asia/Hong_Kong # The acceptable values would be a value from the IANA Time Zone Database.
  25. start: 00 * * * * # Every hour on the 30th minute
  26. end: 10 * * * * # Every hour on the 45th minute
  27. desiredReplicas: "3"
  28. policies:
  29. - name: apply-once
  30. type: apply-once
  31. properties:
  32. enable: true
  33. rules:
  34. - strategy:
  35. path: ["spec.replicas"]
  36. selector:
  37. resourceTypes: ["Deployment"]

In this example, it will scale up to 3 replicas from 0-10 in every hour. After that, it will scale back to the initial replica 1.

We can use CPU based hpa with the keda cpu trigger.

Auto Scaling - 图2tip

You must follow the prerequisite of this keda trigger:

KEDA uses standard cpu and memory metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the resources section of the relevant Kubernetes Pods must include limits (at a minimum).

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: scaler-eg-app
  5. spec:
  6. components:
  7. - name: frontend
  8. type: webservice
  9. properties:
  10. image: oamdev/testapp:v1
  11. cmd: ["node", "server.js"]
  12. cpu: "0.1"
  13. ports:
  14. - port: 8080
  15. expose: true
  16. traits:
  17. # This Trait used for initializing the replica
  18. - type: scaler
  19. properties:
  20. replicas: 1
  21. - type: gateway
  22. properties:
  23. class: traefik
  24. classInSpec: true
  25. domain: test.my.domain
  26. http:
  27. "/": 8080
  28. - type: keda-auto-scaler
  29. properties:
  30. minReplicaCount: 1
  31. maxReplicaCount: 10
  32. cooldownPeriod: 10
  33. pollingInterval: 10
  34. triggers:
  35. - type: cpu
  36. metricType: Utilization
  37. metadata:
  38. value: "80"
  39. policies:
  40. - name: apply-once
  41. type: apply-once
  42. properties:
  43. enable: true
  44. rules:
  45. - strategy:
  46. path: ["spec.replicas"]
  47. selector:
  48. resourceTypes: ["Deployment"]

In this example, we also exposed the service entrypoint by using the gateway trait, make sure you have the traefik ingress controller if you’re not using velad.

We can get the endpoint by the following command.

  1. $ vela status scaler-eg-app --endpoint
  2. Please access scaler-eg-app from the following endpoints:
  3. +---------+-----------+--------------------------+------------------------------+-------+
  4. | CLUSTER | COMPONENT | REF(KIND/NAMESPACE/NAME) | ENDPOINT | INNER |
  5. +---------+-----------+--------------------------+------------------------------+-------+
  6. | local | frontend | Service/default/frontend | http://frontend.default:8080 | true |
  7. | local | frontend | Ingress/default/frontend | http://test.my.domain | false |
  8. +---------+-----------+--------------------------+------------------------------+-------+

Please configure the /etc/hosts for visit the service:

  1. echo "<IP of your service> test.my.domain" >> /etc/hosts

Then we can add CPU pressure by using the ab tool.

  1. ab -n 300000 -c 200 http://test.my.domain/

We can use vela top to check the replica changing during the ab test.

All of the triggers are supported and the trigger part spec in KubeVela keda-auto-scaler trait are all aligned with KEDA trigger, you can refer to the docs of keda to learn details.

If your component is webservice which actually using Kubernetes Deployment as the underlying workload, you don’t need to specify the workload type.

If you’re using helm or customized component types, you should specify the scaleTargetRef field to tell the trait which workload it should work with.

KEDA supports Deployment, StatefulSet and Custom Resource, the only constraint is that the target Custom Resource must define /scale subresource.

NameDescriptionTypeRequiredDefault
triggers[]triggerstrue
scaleTargetRefscaleTargetReftrue
pollingIntervalspecify the polling interval of metrics, Default: 30 seconds.intfalse30
cooldownPeriodSpecify the cool down period that prevents the scaler from scaling down after each trigger activation. Default: 60 seconds.intfalse60
idleReplicaCountSpecify the idle period that the scaler to scale to zero. Default: ignored, must be less than minReplicaCount.intfalse0
minReplicaCountSpecify the minimal replica count. Default: 0.intfalse1
maxReplicaCountSpecify the maximal replica count. Default: 100.intfalse100
fallbackSpecify the fallback value when the metrics server is not available.fallbacktrue
NameDescriptionTypeRequiredDefault
typespecify the type of trigger, the rest spec here aligns with KEDA spec.stringtrue
metadataspecify the metadata of trigger, the spec aligns with the spec of KEDA https://keda.sh/docs/2.8/scalers/.map[string]_true
NameDescriptionTypeRequiredDefault
apiVersionSpecify apiVersion for target workload.stringfalseapps/v1
kindSpecify kind for target workload.stringfalseDeployment
envSourceContainerNameSpecify containerName, default to find this path “.spec.template.spec.containers[0]”.stringfalseempty
nameSpecify the instance name for target workload.stringtrue
NameDescriptionTypeRequiredDefault
failureThresholdSpecify the failure threshold of the scaler. Default: 3.intfalse3
replicasSpecify the replica when failed to get metrics. Default to minReplicaCount.intfalse1

Last updated on Feb 9, 2023 by dependabot[bot]