tencent cloud

All product documents
Tencent Kubernetes Engine
DocumentationTencent Kubernetes EnginePractical TutorialAuto ScalingKEDAAuto Scaling Based on Prometheus Custom Metrics
Auto Scaling Based on Prometheus Custom Metrics
Download PDF
Last updated: 2024-12-24 15:55:47
Auto Scaling Based on Prometheus Custom Metrics
Last updated: 2024-12-24 15:55:47
Download PDF

Prometheus Triggers

Kubernetes-based Event-Driven Autoscaler (KEDA) supports prometheus triggers, enabling scaling based on Prometheus metric data queried by custom PromQL. For full configuration parameters, please refer to KEDA Scalers: Prometheus. This document will provide use cases.

Case: istio-based QPS Scaling

If you use istio and the business Pod is injected with a sidecar, some Layer 7 monitoring metrics will be automatically exposed. The most common one is istio_requests_total, which can be used to calculate QPS.
Suppose the scenario is that Service A needs to scale based on the QPS processed by Service B. An example of the configuration is as follows:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: b-scaledobject
  namespace: prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: a # Scale for service A
  pollingInterval: 15
  minReplicaCount: 1
  maxReplicaCount: 100
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://monitoring-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090 # Replacing the Prometheus Address
        query: | # Calculate the PromQL of QPS of service B 
          sum(irate(istio_requests_total{reporter=~"destination",destination_workload_namespace=~"prod",destination_workload=~"b"}[1m]))
        threshold: "100" # Number of service A replicas = ceil(Service B QPS/100)

Advantages over Prometheus-adapter

prometheus-adapter also supports the same ability, which means that it can achieve scaling based on the monitoring metric data from Prometheus, but it has the following disadvantages compared to the KEDA solution:
Every time a new custom metric is added, the prometheus-adapter configuration needs to be changed, and the configuration is centrally managed, not supporting management through CRD. This makes configuration maintenance more cumbersome. In contrast, the KEDA solution only needs to configure ScaledObject or ScaledJob CRDs, allowing various businesses to use different YAML files for maintenance, which is beneficial for configuration maintenance.
The configuration syntax of prometheus-adapter is obscure and hard to understand. It does not allow direct writing of PromQL, requiring learning the prometheus-adapter's configuration syntax, thereby increasing the learning cost. However, KEDA's prometheus configuration is very simple, as the metrics can directly use the syntax queried by PromQL, making it straightforward.
prometheus-adapter only supports scaling based on Prometheus monitoring data, whereas for KEDA, Prometheus is just one of many triggers.


Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No

Feedback

Contact Us

Contact our sales team or business advisors to help your business.

Contact Us
Technical Support

Open a ticket if you're looking for further assistance. Our Ticket is 7x24 available.

Submit a Ticket
7x24 Phone Support
Hong Kong, China
+852 800 906 020 (Toll Free)
United States
+1 844 606 0804 (Toll Free)
United Kingdom
+44 808 196 4551 (Toll Free)
Canada
+1 888 605 7930 (Toll Free)
Australia
+61 1300 986 386 (Toll Free)
EdgeOne hotline
+852 300 80699
More local hotlines coming soon