tencent cloud

masukan

Auto Scaling Based on Prometheus Custom Metrics

Terakhir diperbarui:2024-12-24 15:55:47

    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.
    
    
    Hubungi Kami

    Hubungi tim penjualan atau penasihat bisnis kami untuk membantu bisnis Anda.

    Dukungan Teknis

    Buka tiket jika Anda mencari bantuan lebih lanjut. Tiket kami tersedia 7x24.

    Dukungan Telepon 7x24