新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

如何使用KEDA自動縮放GrafanaLokiQueries

如何使用 KEDA 自動縮放 Grafana Loki Queries

作者：祝祥 2022-11-03 08:02:06

云計算

云原生為了驗證我們的實現(xiàn)是否滿足我們在真實場景中的需求，我們在內部環(huán)境中部署了自動縮放器。到目前為止，我們已經在 k6 創(chuàng)建所有工作負載的隔離環(huán)境中進行了實驗。接下來，我們必須估計最大和最小副本數(shù)的適當值。

成都創(chuàng)新互聯(lián)公司是一家專業(yè)從事網(wǎng)站建設、成都網(wǎng)站建設、網(wǎng)頁設計的品牌網(wǎng)絡公司。如今是成都地區(qū)具影響力的網(wǎng)站設計公司,作為專業(yè)的成都網(wǎng)站建設公司,成都創(chuàng)新互聯(lián)公司依托強大的技術實力、以及多年的網(wǎng)站運營經驗,為您提供專業(yè)的成都網(wǎng)站建設、營銷型網(wǎng)站建設及網(wǎng)站設計開發(fā)服務！

介紹

Grafana Loki (https://grafana.com/oss/loki/?pg=blog&plcmt=body-txt) 是 Grafana Labs 的開源日志聚合系統(tǒng)，靈感來自 Prometheus(https://prometheus.io/) 。Loki 具有水平可擴展性、高可用性和多租戶特性。

Grafana Cloud 大規(guī)模運營 Grafana Cloud Logs，集群分布在不同的區(qū)域和云平臺，如 AWS、Microsoft Azure 和 Google Cloud。Grafana Cloud 每天還攝取數(shù)百 TB 的數(shù)據(jù)，并在數(shù)千個租戶中查詢數(shù) PB 的數(shù)據(jù)。最重要的是，每天數(shù)據(jù)查詢與處理過程中，資源消耗都會有很大的波動，這使得以對用戶響應且對 Grafana Cloud 來說具有成本效益的方式手動擴展集群變得非常困難。

在這篇博客中，我們將描述 Grafana Labs 的工程師如何使用基于 Kubernetes 的事件驅動自動縮放器 ( KEDA(https://keda.sh/) ) 來更好地處理后端的 Loki 查詢。

為什么我們需要 autoscaling

負責處理 Grafana Cloud Logs 查詢的 Loki 讀取路徑組件之一是 querier，它是將 LogQL(https://grafana.com/docs/loki/latest/logql/?pg=blog&plcmt=body-txt) 查詢與日志匹配的組件?？梢韵胂?，我們需要很多 querier 來實現(xiàn)如此高的吞吐量。但是，由于我們的集群全天工作負載發(fā)生重大變化，這種需求會發(fā)生波動。直到最近，我們還是根據(jù)工作負載手動擴展 querier，但這種方法存在三個主要問題。

1、它會適當?shù)財U展 querier 以響應工作量的增加。

2、我們可能會過度配置集群并使 querier 閑置一段時間。

3、這會導致操作繁瑣 (https://sre.google/sre-book/eliminating-toil/) ，因為我們必須手動上下擴展 querier。

為了克服這些問題，我們決定在 Kubernetes 中的 querier 部署中添加自動縮放功能。

為什么選擇 KEDA

Kubernetes 附帶了一個用于水平自動縮放 Pod 的內置解決方案：HorizontalPodAutoscaler ( HPA)。您可以使用 HPA 根據(jù)來自 Kubernetes metrics-server(https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 的指標為 StatefulSets 和 Deployments 等組件配置自動縮放。metrics-server 公開 pod 的 CPU 和內存使用情況，但如果需要，您可以為其提供更多指標。

CPU 和內存使用指標通常足以決定何時擴大或縮小規(guī)模，但可能還有其他指標或事件需要考慮。在我們的案例中，我們對基于一些 Prometheus 指標的擴展感興趣。從 Kubernetes 1.23 開始，HPA 已經支持外部指標(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#scaling-on-custom-metrics) ，所以我們可以選擇一個 Prometheus adapter 來根據(jù) Prometheus 指標進行擴展。然而，KEDA 使這變得更加容易。

KEDA 是最初由 Microsoft 和 Red Hat 開發(fā)的開源項目，我們已經在內部將它用于與Grafana Mimir(https://grafana.com/oss/mimir/?pg=blog&plcmt=body-txt) 類似的用例。除了熟悉之外，我們之所以選擇它，是因為它更成熟，而且它允許根據(jù)來自不同來源（例如 Prometheus）的事件和指標擴展任何 Pod。KEDA 構建在 HPA 之上，并公開了一個新的 Kubernetes 指標服務器，該服務器為 KEDA 創(chuàng)建的 HPA 提供新指標。

我們如何在 queriers 上使用 KEDA

Queriers 從查詢調度程序隊列中提取查詢并在所有 querier 上處理它們。因此，根據(jù)以下條件進行擴展是有意義的：

調度程序隊列大小
在 querier 中運行的查詢

最重要的是，我們希望避免因短期工作負載高峰而擴大規(guī)模。在這些情況下，查詢可能會比擴展所需的時間更快地處理工作負載。

考慮到這一點，我們根據(jù)排隊查詢的數(shù)量加上正在運行的查詢進行擴展。我們稱這些為 inflight requests。查詢調度程序組件將公開一個新指標，cortex_query_scheduler_inflight_requests 指標結果使用百分比(https://grafana.com/blog/2022/03/01/how-summary-metrics-work-in-prometheus/?pg=blog&plcmt=body-txt) 跟蹤正在進行的請求。通過使用百分比，我們可以避免在指標出現(xiàn)短期峰值時進行擴容。

使用結果度量，我們可以在查詢中使用分位數(shù) (Q) 和范圍 (R) 參數(shù)來微調我們的縮放。Q 越高，指標對短期尖峰越敏感。隨著 R 的增加，我們會隨著時間的推移減少度量變化。較高的 R 值有助于防止自動縮放器過于頻繁地修改副本數(shù)量。

sum(
max_over_time(
  cortex_query_scheduler_inflight_requests{namespace="%s", quantile=""}[]
)
)

然后我們需要設置一個閾值，以便我們可以根據(jù)度量值計算所需的副本數(shù)。Querier 程序處理來自隊列的查詢，每個 querier 配置為運行六個 worker。我們希望為高峰留出一些富余處理空間，因此我們的目標是使用這些 worker 中的 75%。因此，我們的門檻將是每個 querier 6 個 worker 的 75%，即 4 個 worker。

這個等式定義了當前副本中所需的副本數(shù)、度量值以及我們配置的閾值：

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / threshold )]

例如，如果我們有一個副本和 20 個正在進行的請求，并且我們的目標是使用每個 worker 可用的六個 worker 中的 75%（四個），那么新的所需副本數(shù)量將是五個。

desiredReplicas = ceil[1 * (20 / 4)] = 5

考慮到這一點，我們現(xiàn)在可以創(chuàng)建 KEDA ScaledObject 來控制查詢器的自動縮放。以下資源定義將 KEDA 配置為從 http://prometheus.default:9090/prometheus 提取指標。它還可以擴展到最大 50 個 querier，縮小到最小 10 個 querier，將 75% 用于 inflight requests 指標，并在兩分鐘內聚合其最大值。擴展閾值仍然是每個 querier 四個 worker。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: querier
namespace: 
spec:
maxReplicaCount: 50
minReplicaCount: 10
pollingInterval: 30
scaleTargetRef:
  kind: Deployment
  name: querier
triggers:
- metadata:
    metricName: querier_autoscaling_metric
    query: sum(max_over_time(cortex_query_scheduler_inflight_requests{namespace=~"REDACTED", quantile="0.75"}[2m]))
    serverAddress: http://prometheus.default:9090/prometheus
    threshold: "4"
  type: prometheus

使用 Grafana k6 Cloud 進行測試

在部署到我們的內部和生產環(huán)境之前，我們進行了多次實驗和基準測試來驗證。

Grafana k6 Cloud 是 Grafana k6 的完全托管版本，它是一個免費、開源、以開發(fā)人員為中心且可擴展的負載測試工具，可讓工程團隊輕松進行性能測試。

使用 k6 的 Grafana Loki 擴展(https://grafana.com/blog/2022/06/08/a-quick-guide-to-load-testing-grafana-loki-with-grafana-k6/?pg=blog&plcmt=body-txt) ，我們創(chuàng)建了一個 k6 測試 (https://gist.github.com/salvacorts/7f6fe8e53dcbdfc38606f3892918cfcc) ，該測試迭代地從多個虛擬用戶（VU；有效的運行線程）向 Loki 開發(fā)集群發(fā)送不同類型的查詢。我們嘗試使用以下序列模擬真實的可變流量：

1、在兩分鐘內，將 VU 從 5 個增加到 50 個。

2、用 50 個 VU 保持一分鐘。

3、在 30 秒內從 50 個 VU 增加到 100 個 VU，并在另外 30 秒內增加到 50 個，以創(chuàng)建工作負載峰值。

4、重復上一個尖峰。

5、最后，在兩分鐘內從 50 個 VU 變?yōu)榱恪?/p>

在下圖中，我們可以看到測試在 k6 Cloud 中的表現(xiàn)，以及在測試期間進行中的請求和查詢器副本的數(shù)量如何變化。首先，querier 會隨著工作負載的增加而擴大，最后，querier 會在測試完成幾分鐘后回退。

一個 Grafana k6 Cloud 測試，它迭代地將不同類型的查詢發(fā)送到 Grafana Loki 開發(fā)集群。

隨著 inflight request 數(shù)量的增加（頂部），querier 的數(shù)量增加（底部）。在工作負載減少后的某個時間，querier 的數(shù)量也會減少。

一旦我們確認我們的方法按預期工作，下一步就是在一些實際工作負載上進行嘗試。

部署和微調

為了驗證我們的實現(xiàn)是否滿足我們在真實場景中的需求，我們在內部環(huán)境中部署了自動縮放器。到目前為止，我們已經在 k6 創(chuàng)建所有工作負載的隔離環(huán)境中進行了實驗。接下來，我們必須估計最大和最小副本數(shù)的適當值。

對于最小副本數(shù)，我們在前 7 天 75% 的時間內檢查了平均 inflight request，目標是 querier 的利用率為 75%。

clamp_min(ceil(
  avg(
      avg_over_time(cortex_query_scheduler_inflight_requests{namespace=~"REDACTED", quantile="0.75"}[7d])
  ) / scalar(floor(vector(6 * 0.75)))
), 2)

對于最大副本數(shù)，我們將當前副本數(shù)與在前 7 天內處理 50% 的 inflight request 所需的查詢器數(shù)相結合。由于每個 querier 運行六個 worker，我們將 inflight 中的請求除以六。

clamp_min(ceil(
  (
      max(
          max_over_time(cortex_query_scheduler_inflight_requests{namespace=~"REDACTED", quantile="0.5"}[7d])
      ) / 6
      >
      max (kube_deployment_spec_replicas{namespace=~"REDACTED", deployment="querier"})
  )
  or
  max(
      kube_deployment_spec_replicas{namespace=~"REDACTED", deployment="querier"}
  )
), 20)

在估計了最小和最大副本的一些數(shù)字后，我們在內部環(huán)境中部署了自動縮放器。如下圖所示，我們實現(xiàn)了預期的結果：querier 隨著工作負載的增加而擴大，在工作負載減少后縮小。

隨著我們部署中 inflight request 數(shù)量的增加（頂部），querier 的數(shù)量增加（底部）。當 worker 減少時，querier 的數(shù)量也會減少。

您可能已經注意到由于縮放指標值的不斷變化，副本數(shù)量的頻繁波動（也稱為抖動）(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping) 。如果您在擴展大量 pod 后過早縮減它們，最終會消耗 Kubernetes 中的大量資源來調度 pod。此外，它可能會影響查詢延遲，因為我們需要經常啟動新的 querier 來處理這些查詢。幸運的是，HPA 提供了一種機制來配置穩(wěn)定窗口(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#stabilization-window) 以減輕這些頻繁的波動，正如您可能已經猜到的那樣，KEDA 也是如此。spec.advanced.horizontalPodAutoscalerConfig.behavior.scaleDown.stabilizationWindowSeconds參數(shù)允許您在 0 秒（立即縮放）和 3,600 秒（一小時）之間配置冷卻時間，默認值為 300 秒（五分鐘）。該算法很簡單：我們使用一個跨越配置時間的滑動窗口，并將副本數(shù)設置為該時間范圍內報告的最高數(shù)量。在我們的例子中，我們配置了一個 30 分鐘的穩(wěn)定窗口：

spec:
advanced:
  horizontalPodAutoscalerConfig:
    behavior:
      scaleDown:
        stabilizationWindowSeconds: 1800

下圖顯示了圖表的形狀現(xiàn)在在副本數(shù)量方面如何更加統(tǒng)一。在某些情況下，querier 在縮小后不久就會擴大規(guī)模，但總會有邊緣情況發(fā)生這種情況。我們仍然需要為這個參數(shù)找到一個適合我們工作負載形狀的好值，但總的來說，我們可以看到峰值更少。

配置穩(wěn)定窗口后，與上圖相似的工作負載相比，副本數(shù)量波動較小。

即使我們配置的最大副本數(shù)比手動擴展 Loki 時要高得多，但添加自動擴展程序后的平均副本數(shù)會更低。較低的平均副本數(shù)轉化為較低的查詢器部署的擁有成本。

啟用查詢器自動縮放器后，集群中運行的平均副本數(shù)減少了。

此外，我們可以看到自動縮放器沒有出現(xiàn)查詢延遲下降的問題。下圖顯示了 7 月 21 日 12:00 UTC 在啟用自動縮放之前和之后的查詢和范圍查詢的 p90 延遲（以秒為單位）。

啟用查詢器自動縮放器后，查詢延遲并沒有變差。

最后，我們需要一種方法來知道何時增加我們的最大副本數(shù)。為此，我們創(chuàng)建了一個警報，當自動縮放器長時間以配置的最大副本數(shù)運行時觸發(fā)。以下代碼片段包含此指標，如果它在至少三個小時內輸出為 true，則會觸發(fā)。

name: LokiAutoscalerMaxedOut
expr: kube_horizontalpodautoscaler_status_current_replicas{namespace=~"REDACTED"} == kube_horizontalpodautoscaler_spec_max_replicas{namespace=~"REDACTED"}
for: 3h
labels:
severity: warning
annotations:
description: HPA {{ $labels.namespace }}/{{ $labels.horizontalpodautoscaler }} has been running at max replicas for longer than 3h; this can indicate underprovisioning.
summary: HPA has been running at max replicas for an extended time

原文：https://grafana.com/blog/2022/10/20/how-to-autoscale-grafana-loki-queries-using-keda/

網(wǎng)站欄目：如何使用KEDA自動縮放GrafanaLokiQueries
本文URL：http://m.fisionsoft.com.cn/article/cccscpe.html