tencent cloud

Tencent Kubernetes Engine

DocumentaçãoTencent Kubernetes EngineUse CasesAuto ScalingKEDAAuto Scaling Based on Prometheus Custom Metrics

Auto Scaling Based on Prometheus Custom Metrics

PDF
Modo Foco
Tamanho da Fonte
Última atualização: 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.


Anterior: Multi-Level Service Synchronized Horizontal Scaling (Workload Triggers)Próximo: Cluster Auto Scaling Practices

Ajuda e Suporte

Esta página foi útil?

comentários