Simplify Kubernetes Autoscaling with KEDA and Alibaba Cloud EDAS

Scaling Kubernetes

When managing a Kubernetes cluster you must monitor both cluster capacity and workload demand, ensuring enough resources for pods and that applications can keep up with queued work.

Cluster capacity – do we have enough resources to run the workloads?

Application workload – does the app have sufficient resources and can it process pending tasks (e.g., queue depth)?

To automate scaling, you typically set alerts and use autoscalers. The Cluster Autoscaler component watches the cluster, detects unschedulable pods caused by resource shortage, and adds or removes nodes accordingly.

Because the Cluster Autoscaler only triggers when pods cannot be scheduled, there may be a short period where workloads remain pending.

Virtual Kubelet, a CNCF sandbox project, adds a “virtual node” to a cluster, allowing pods to be scheduled onto it.

Platform providers such as Alibaba, Azure, and HashiCorp can overflow pending pods to these virtual nodes until sufficient capacity is available.

Application Autoscaling

Kubernetes also supports scaling applications directly:

Horizontal Pod Autoscaler (HPA) adds or removes pod replicas based on CPU, memory, or custom metrics.

Vertical Pod Autoscaler (VPA) adjusts CPU and memory requests of existing pods.

Limitations of HPA

While HPA is a solid starting point, it only considers pod‑level metrics (CPU, memory) and cannot natively use external metrics, scale to zero, or schedule based on custom business indicators without an external metrics server.

External metric adapters (e.g., Prometheus + Promitor) can provide such metrics, but they require substantial plumbing.

What is KEDA?

Kubernetes Event‑Driven Autoscaling (KEDA) is a single‑purpose, event‑driven scaler that plugs into Kubernetes, making application autoscaling simple and cost‑effective by supporting scale‑to‑zero.

Users create a ScaledObject or ScaledJob that defines the target and trigger; KEDA handles the rest.

KEDA builds on top of HPA, using external metric adapters to feed custom metrics, and supports over 30 external systems.

KEDA does not reinvent the wheel; it leverages HPA while providing its own external metric adapters.

Alibaba Cloud EDAS and KEDA

EDAS, Alibaba Cloud’s enterprise PaaS, integrates ARMS monitoring and contributed an ARMS scaler to KEDA, along with several fixes:

When multiple triggers fire, their values are summed.

HPA names are limited to 63 characters to avoid DNS issues.

Triggers cannot be disabled, preventing production problems.

The EDAS team is upstreaming these patches, many of which have already landed in KEDA v2.

Why EDAS Standardized on KEDA

EDAS needed fine‑grained custom metrics, scale‑to‑zero, and scheduled scaling—capabilities missing in upstream HPA. KEDA provides these out of the box, integrates cleanly with OAM/KubeVela, and fits EDAS’s architectural goals.

Future Outlook

Alibaba is driving AI‑ops‑enabled KEDA features that will make autoscaling decisions smarter by leveraging expert systems and historical data, including new QoS and database metric triggers.

References

KEDA: https://keda.sh/

Alibaba Cloud EDAS: https://cn.aliyun.com/product/edas

Cluster Autoscaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

Virtual Kubelet: https://virtual-kubelet.io/

HPA: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

VPA: https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

External Metrics Support: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-external-metrics.md

KubeVela: https://kubevela.io/