tencent cloud

PrevNext

Feedback

search by keyword

Recent Pages

Documentation
Tencent Kubernetes Engine
    Documentation
    Download PDF

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

      Submit a Ticket
      7x24 Phone Support
      Copyright © 2013-2024 Tencent Cloud. All Rights Reserved.
      Privacy PolicyLegalCookie Policy