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.

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.

警告

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.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: scaler-eg-app
spec:
  components:
    - name: hello-world-scaler
      type: webservice
      properties:
        image: oamdev/hello-world
        ports:
         - port: 8000
           expose: true        
      traits:
        # This Trait used for initializing the replica
        - type: scaler
          properties:
            replicas: 1
        - type: keda-auto-scaler
          properties:
            triggers:
            - type: cron
              metadata:
                timezone: Asia/Hong_Kong  # The acceptable values would be a value from the IANA Time Zone Database.
                start: 00 * * * *       # Every hour on the 30th minute
                end: 10 * * * *         # Every hour on the 45th minute
                desiredReplicas: "3"
  policies:
    - name: apply-once
      type: apply-once
      properties:
        enable: true
        rules:
        - strategy:
            path: ["spec.replicas"]
          selector:
            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.

提示

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).

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: scaler-eg-app
spec:
  components:
    - name: frontend
      type: webservice
      properties:
        image: oamdev/testapp:v1
        cmd: ["node", "server.js"]
        cpu: "0.1"
        ports:
          - port: 8080
            expose: true
      traits:
        # This Trait used for initializing the replica
        - type: scaler
          properties:
            replicas: 1
        - type: gateway
          properties:
            class: traefik
            classInSpec: true
            domain: test.my.domain
            http:
              "/": 8080
        - type: keda-auto-scaler
          properties:
            minReplicaCount: 1
            maxReplicaCount: 10
            cooldownPeriod: 10
            pollingInterval: 10
            triggers:
            - type: cpu
              metricType: Utilization
              metadata:
                value: "80"
  policies:
    - name: apply-once
      type: apply-once
      properties:
        enable: true
        rules:
        - strategy:
            path: ["spec.replicas"]
          selector:
            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.

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

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

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

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

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.

Last updated on 2023年8月4日 by Daniel Higuero