本文詳述了Prometheus Adapter的部署與配置,透過三個實踐案例展示其在Kubernetes環境中的應用,幫助使用者實現基於自定義指標的自動擴充套件和跨叢集統一監控。
關注作者,分享AI全維度知識。作者擁有10+年網際網路服務架構、AI產品研發經驗、團隊管理經驗,同濟本復旦碩,復旦機器人智慧實驗室成員,阿里雲認證的資深架構師,專案管理專業人士,上億營收AI產品研發負責人
一、引言
Prometheus Adapter的背景與重要性
在現代的雲原生架構中,微服務和容器化技術得到了廣泛的應用。這些技術帶來了系統靈活性和擴充套件性的提升,但同時也增加了系統監控和管理的複雜度。Prometheus作為一款開源的監控系統,因其強大的指標收集和查詢能力,成為了許多企業和開發者的首選。然而,隨著應用場景的多樣化和規模的不斷擴大,單純依賴Prometheus內建的功能已經不能滿足所有需求。Prometheus Adapter應運而生,作為Prometheus生態系統的重要組成部分,提供了強大的自定義指標擴充套件和靈活的指標查詢能力。
Prometheus Adapter的核心功能是將Prometheus中的監控資料轉換為Kubernetes可識別的自定義指標,這對於實現基於自定義指標的自動擴充套件(Horizontal Pod Autoscaler,HPA)至關重要。在複雜的微服務架構和大規模叢集管理中,透過Prometheus Adapter,使用者可以自定義監控指標,進行精細化的資源管理和自動化運維,從而提升系統的可靠性和效能。
適用場景與應用需求
Prometheus Adapter主要應用於以下幾種場景:
-
自定義指標的自動擴充套件:
在Kubernetes中,HPA主要依賴於CPU和記憶體等基礎資源的使用情況進行自動擴充套件。但在實際應用中,使用者往往需要基於業務指標(如請求響應時間、佇列長度等)進行擴充套件。Prometheus Adapter允許使用者定義和使用自定義的Prometheus查詢,將這些業務指標轉化為HPA可識別的指標,從而實現更精細的擴充套件策略。 -
多叢集環境下的統一監控:
在多叢集環境中,管理和監控各個叢集的資源和應用是一項複雜的任務。透過Prometheus Adapter,使用者可以將不同叢集的Prometheus資料統一處理和展示,實現跨叢集的集中監控和管理,提高運維效率。 -
複雜業務場景下的靈活監控:
在一些複雜業務場景中,使用者需要對特定的應用或服務進行深入監控。例如,在電商網站中,使用者可能需要監控每秒訂單數、支付成功率等業務指標。透過Prometheus Adapter,使用者可以自定義監控這些特定業務指標,結合Prometheus強大的查詢功能,進行靈活多樣的監控和分析。
Prometheus Adapter的功能與優勢
Prometheus Adapter具備以下幾項關鍵功能和優勢:
-
靈活的自定義指標定義:
使用者可以透過簡單的配置檔案,定義複雜的Prometheus查詢,將結果轉化為Kubernetes自定義指標。這使得使用者可以根據具體的業務需求,靈活定義和使用各種自定義指標。 -
高效的資料查詢與轉換:
Prometheus Adapter透過高效的查詢和資料轉換機制,能夠快速處理大量監控資料,並將其轉換為Kubernetes可識別的格式。這對於大規模叢集和高併發場景尤為重要,能夠確保監控系統的實時性和可靠性。 -
與Kubernetes的無縫整合:
作為Prometheus生態系統的一部分,Prometheus Adapter與Kubernetes有著緊密的整合。使用者可以方便地在Kubernetes中部署和管理Prometheus Adapter,實現與現有監控系統的無縫對接,簡化運維操作。 -
社群支援與擴充套件性:
Prometheus Adapter作為一個開源專案,有著活躍的社群支援。使用者可以透過參與社群貢獻,獲取最新的功能更新和技術支援。此外,Prometheus Adapter還具備良好的擴充套件性,使用者可以根據自身需求進行二次開發和定製。
二、Prometheus Adapter的基本概念
什麼是Prometheus Adapter
Prometheus Adapter是一個開源工具,用於將Prometheus中的監控資料轉換為Kubernetes自定義指標。這一轉換過程使得Kubernetes可以基於這些自定義指標進行自動擴充套件(Horizontal Pod Autoscaler,HPA)和其他自定義操作。透過Prometheus Adapter,使用者可以將複雜的業務指標引入到Kubernetes的監控和管理體系中,從而實現更靈活、更細緻的資源管理。
Prometheus Adapter的出現源於對監控靈活性和擴充套件性的需求。在傳統的監控體系中,監控指標通常固定在CPU、記憶體等基礎資源上。然而,實際的業務需求往往更加複雜多樣。例如,在電商網站中,監控訂單處理時間、使用者請求數等業務指標往往比單純的資源指標更為重要。Prometheus Adapter透過將Prometheus的強大查詢功能與Kubernetes的自定義指標相結合,提供了一個解決這一需求的有效方案。
Prometheus Adapter的架構與工作原理
Prometheus Adapter的架構設計旨在高效、可靠地實現監控資料的轉換和傳輸。其核心元件包括配置解析器、資料查詢模組和指標轉發模組。以下是對這些元件的詳細解析:
-
配置解析器:
配置解析器負責讀取和解析使用者定義的配置檔案。這些配置檔案中定義了Prometheus查詢規則、自定義指標名稱和轉換邏輯。配置解析器將這些配置轉化為內部資料結構,供後續模組使用。 -
資料查詢模組:
資料查詢模組負責與Prometheus例項通訊,執行配置檔案中定義的查詢操作。透過使用Prometheus的HTTP API,資料查詢模組可以獲取實時的監控資料。資料查詢模組需要具備高效的資料處理能力,以應對大規模叢集和高併發環境下的查詢需求。 -
指標轉發模組:
指標轉發模組負責將查詢到的資料轉換為Kubernetes可識別的自定義指標格式,並將這些指標推送到Kubernetes API伺服器。透過與Kubernetes的Metric API整合,指標轉發模組確保這些自定義指標可以被Kubernetes中的其他元件(如HPA)識別和使用。
Prometheus Adapter與Prometheus的關係與區別
Prometheus Adapter與Prometheus之間存在緊密的關係,但兩者的功能定位和使用場景有所不同:
-
功能定位:
Prometheus是一個強大的監控系統,負責資料的採集、儲存和查詢。它透過抓取各類監控目標的資料,提供豐富的查詢和告警功能。Prometheus Adapter則是一個資料轉換工具,負責將Prometheus中的監控資料轉換為Kubernetes自定義指標。其核心功能是將Prometheus強大的查詢能力引入到Kubernetes的監控和管理體系中。 -
使用場景:
Prometheus主要用於各類系統和應用的監控,其使用場景包括基礎設施監控、應用效能監控和業務指標監控等。Prometheus Adapter則主要用於Kubernetes環境中,特別是在需要基於自定義指標進行自動擴充套件和其他自定義操作的場景中。透過Prometheus Adapter,使用者可以將複雜的業務指標引入到Kubernetes的自動化管理流程中。 -
技術實現:
Prometheus透過抓取各類監控目標的HTTP端點,收集和儲存時序資料。它的架構設計強調高效的資料採集和查詢能力。Prometheus Adapter則透過呼叫Prometheus的HTTP API,執行預定義的查詢操作,並將結果轉換為Kubernetes自定義指標。兩者在技術實現上有明顯的區別,但透過API介面實現了緊密的整合。
三、部署與安裝
環境要求
在部署Prometheus Adapter之前,需要確保以下環境和軟體元件已經正確安裝和配置:
-
Kubernetes叢集:
- 版本要求:Kubernetes 1.14及以上
- 叢集內應至少包含一個主節點和若干工作節點
- 已正確配置kubectl命令列工具,並能夠正常訪問叢集
-
Prometheus例項:
- 版本要求:Prometheus 2.0及以上
- Prometheus應已經部署並在叢集中執行,確保能夠採集和儲存監控資料
- 確保Prometheus的HTTP API可用,並且叢集內的元件能夠訪問該API
-
Helm(可選):
- 版本要求:Helm 3.0及以上
- Helm用於簡化Prometheus Adapter的安裝和管理,但也可以透過手動部署YAML檔案進行安裝
安裝步驟
Prometheus Adapter的安裝過程可以透過兩種方式完成:使用Helm Chart進行安裝或手動部署YAML檔案。以下將詳細介紹這兩種安裝方式。
使用Helm Chart進行安裝
-
新增Prometheus Adapter的Helm倉庫:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update
-
安裝Prometheus Adapter:
helm install prometheus-adapter prometheus-community/prometheus-adapter --namespace monitoring
-
驗證安裝:
安裝完成後,檢查Prometheus Adapter的Pod是否成功啟動:kubectl get pods -n monitoring -l app=prometheus-adapter
手動部署YAML檔案
-
下載Prometheus Adapter的部署檔案:
可以從Prometheus Adapter的GitHub倉庫獲取最新的部署檔案:git clone https://github.com/kubernetes-sigs/prometheus-adapter.git cd prometheus-adapter/deploy/manifests
-
部署Prometheus Adapter:
kubectl apply -f .
-
驗證安裝:
同樣,檢查Prometheus Adapter的Pod是否成功啟動:kubectl get pods -n custom-metrics
配置詳解
安裝完成後,需要對Prometheus Adapter進行詳細的配置,以確保其能夠正確地與Prometheus和Kubernetes整合。配置主要透過一個YAML檔案進行定義,其中包括Prometheus的地址、自定義查詢規則、以及Kubernetes API伺服器的相關設定。
配置檔案結構
Prometheus Adapter的配置檔案通常包含以下幾個部分:
-
MetricMappings:
定義Prometheus查詢規則和Kubernetes自定義指標的對映關係。 -
Rules:
定義自定義的Prometheus查詢規則,包括指標名稱、查詢語法等。 -
ResourceRules:
定義與Kubernetes資源相關的查詢規則,如節點、Pod等。 -
MetricsRelabelings:
定義如何從Prometheus查詢結果中提取和轉換指標。
以下是一個示例配置檔案:
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-metrics-config
namespace: custom-metrics
data:
config.yaml: |
rules:
default: false
seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
resources:
overrides:
namespace: {resource: "namespace"}
pod: {resource: "pod"}
name:
matches: "^(.*)_total"
as: "${1}_per_second"
metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
如何定義自定義的指標
在配置檔案中,可以透過rules
部分定義自定義的Prometheus查詢規則。以下是一個詳細的示例:
rules:
- seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
resources:
overrides:
namespace: {resource: "namespace"}
pod: {resource: "pod"}
name:
matches: "^(.*)_total"
as: "${1}_per_second"
metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
- seriesQuery:定義需要查詢的Prometheus指標。
- resources:定義如何將Prometheus指標中的標籤對映到Kubernetes資源。
- name:定義轉換後的自定義指標名稱。
- metricsQuery:定義具體的Prometheus查詢語法,用於計算自定義指標的值。
不同資料來源的適配
除了Prometheus,Prometheus Adapter還可以適配其他資料來源,如Thanos、VictoriaMetrics等。透過在配置檔案中定義不同的資料來源地址和查詢規則,可以實現多資料來源的靈活適配。例如:
prometheus:
url: http://thanos-query:9090/
path: /api/v1/query
常見問題與解決方案
在部署和配置Prometheus Adapter的過程中,可能會遇到一些常見問題。以下是幾種典型問題及其解決方案:
無法連線到Prometheus例項
解決方案:
- 檢查Prometheus的服務地址和埠,確保Prometheus Adapter的配置檔案中地址正確無誤。
- 使用curl或wget命令測試Prometheus API的可訪問性。
curl http://prometheus-server:9090/api/v1/query?query=up
自定義指標無法被Kubernetes識別
解決方案:
- 確保自定義查詢規則符合Prometheus Adapter的配置規範,並且Prometheus中確實存在相應的指標資料。
- 使用Prometheus的表示式瀏覽器(Expression Browser)驗證查詢語法,確保查詢結果正確。
查詢結果為空
解決方案:
- 檢查Prometheus中的原始資料,確保資料確實存在並且符合查詢條件。
- 調整查詢視窗或查詢條件,確保能夠匹配到預期的資料。
查詢語法錯誤
解決方案:
- 使用Prometheus的表示式瀏覽器驗證查詢語法,確保語法正確。
- 檢查配置檔案中的查詢規則,確保沒有語法錯誤或拼寫錯誤。
curl http://prometheus-server:9090/api/v1/query?query=sum(rate(http_requests_total[5m])) by (namespace, pod)
驗證配置
完成配置後,可以透過以下步驟驗證Prometheus Adapter的工作情況:
-
檢查Prometheus Adapter的日誌:
kubectl logs -n custom-metrics <prometheus-adapter-pod-name>
-
驗證自定義指標:
使用kubectl命令檢視自定義指標是否成功匯入Kubernetes API伺服器:kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
-
測試HPA配置:
建立一個基於自定義指標的HPA資源,驗證其是否能夠正常工作:apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: custom-metrics-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-deployment minReplicas: 1 maxReplicas: 10 metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: 100
透過以上步驟,可以驗證Prometheus Adapter的安裝和配置是否正確,以及自定義指標是否能夠被Kubernetes正常識別和使用。
四、Prometheus Adapter的配置
配置檔案詳解
Prometheus Adapter的配置檔案主要用於定義如何將Prometheus中的監控資料轉換為Kubernetes可識別的自定義指標。配置檔案通常使用YAML格式,包含多個部分,每一部分都負責特定的配置任務。
核心配置元件
-
metricsRelabelings:
- 用於重新標記和篩選Prometheus中的原始指標。
- 例子:
metricsRelabelings: - sourceLabels: [__name__] separator: ; regex: '(.*)' targetLabel: metric_name replacement: '${1}' action: replace
-
rules:
- 定義如何從Prometheus查詢中生成自定義指標。
- 例子:
rules: - seriesQuery: 'http_requests_total{namespace!="",pod!=""}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: matches: "^(.*)_total" as: "${1}_per_second" metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
-
resourceRules:
- 用於定義與Kubernetes資源相關的查詢規則,例如節點和Pod的指標。
- 例子:
resourceRules: cpu: name: matches: "^(.*)_cpu_usage" as: "custom_cpu_usage" metricsQuery: 'sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>}[1m])) by (<<.GroupBy>>)'
如何定義自定義的指標
自定義指標的定義過程涉及編寫Prometheus查詢,並將其轉換為Kubernetes自定義指標。以下是詳細步驟:
步驟1:編寫Prometheus查詢
首先,在Prometheus中編寫查詢以獲取所需的資料。例如,要獲取每秒HTTP請求數,可以使用以下查詢:
sum(rate(http_requests_total[5m])) by (namespace, pod)
步驟2:定義配置規則
在Prometheus Adapter的配置檔案中,定義對應的查詢規則和指標轉換邏輯。例如:
rules:
- seriesQuery: 'http_requests_total{namespace!="",pod!=""}'
resources:
overrides:
namespace: {resource: "namespace"}
pod: {resource: "pod"}
name:
matches: "^(.*)_total"
as: "${1}_per_second"
metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
上述配置中:
seriesQuery
:指定Prometheus中的原始指標。resources
:定義如何將Prometheus指標中的標籤對映到Kubernetes資源。name
:指定自定義指標的命名規則。metricsQuery
:定義Prometheus查詢語法,計算自定義指標的值。
步驟3:部署配置檔案
將配置檔案部署到Kubernetes中:
kubectl apply -f custom-metrics-config.yaml
不同資料來源的適配
Prometheus Adapter不僅可以與Prometheus整合,還可以適配其他資料來源,例如Thanos和VictoriaMetrics。配置方法類似,透過定義不同的資料來源地址和查詢規則,實現靈活的多資料來源適配。
適配Thanos
Thanos是一個用於Prometheus高可用性、長時間儲存和多叢集聚合的解決方案。可以透過以下配置適配Thanos:
prometheus:
url: http://thanos-query:9090/
path: /api/v1/query
在這種配置中,url
指向Thanos查詢服務的地址,path
指定查詢API路徑。
適配VictoriaMetrics
VictoriaMetrics是一個高效能的開源時間序列資料庫,相容Prometheus。適配VictoriaMetrics的配置示例如下:
prometheus:
url: http://victoriametrics:8428/
path: /api/v1/query
高階配置技巧
動態標籤處理
Prometheus Adapter支援動態標籤處理,透過metricsRelabelings
和rules
部分的配置,可以靈活處理Prometheus指標中的標籤。例如:
metricsRelabelings:
- sourceLabels: [__name__]
separator: ;
regex: '(.*)'
targetLabel: metric_name
replacement: '${1}'
action: replace
分片與聚合
在大規模叢集中,可以透過分片和聚合策略,提升查詢效能和資料處理效率。例如:
rules:
- seriesQuery: 'container_cpu_usage_seconds_total{namespace!="",pod!=""}'
resources:
overrides:
namespace: {resource: "namespace"}
pod: {resource: "pod"}
name:
matches: "^(.*)_cpu_usage_seconds_total"
as: "${1}_cpu_usage"
metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
上述配置透過sum(rate(...))
實現資料的聚合處理,適用於大規模資料場景。
常見問題與解決方案
在配置和使用Prometheus Adapter時,可能會遇到一些常見問題。以下是幾種典型問題及其解決方案:
自定義指標查詢失敗
問題描述:配置的自定義指標無法在Kubernetes中查詢到。
解決方案:
- 檢查Prometheus查詢語法,確保其在Prometheus表示式瀏覽器中能夠返回預期結果。
- 確認Prometheus Adapter配置檔案的語法和內容正確。
- 檢視Prometheus Adapter的日誌,排查錯誤資訊。
kubectl logs -n custom-metrics <prometheus-adapter-pod-name>
連線Prometheus失敗
問題描述:Prometheus Adapter無法連線到Prometheus例項。
解決方案:
- 確認Prometheus例項的地址和埠正確無誤。
- 檢查網路連線,確保Prometheus Adapter所在Pod能夠訪問Prometheus例項。
curl http://prometheus-server:9090/api/v1/query?query=up
指標名稱衝突
問題描述:配置的自定義指標名稱與現有指標名稱衝突。
解決方案:
- 在定義自定義指標時,使用獨特的命名規則,避免與現有指標名稱重複。
- 透過
name
配置部分,靈活調整自定義指標名稱。
name:
matches: "^(.*)_total"
as: "${1}_custom_per_second"
驗證配置
完成配置後,可以透過以下步驟驗證Prometheus Adapter的工作情況:
-
檢查Prometheus Adapter的日誌:
kubectl logs -n custom-metrics <prometheus-adapter-pod-name>
-
驗證自定義指標:
使用kubectl命令檢視自定義指標是否成功匯入Kubernetes API伺服器:kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
-
測試HPA配置:
建立一個基於自定義指標的HPA資源,驗證其是否能夠正常工作:apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: custom-metrics-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-deployment minReplicas: 1 maxReplicas: 10 metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: 100
透過以上步驟,可以驗證Prometheus Adapter的配置是否正確,自定義指標是否能夠被Kubernetes正常識別和使用。
五、Prometheus Adapter實踐案例
在這一部分,我們將透過實際案例展示Prometheus Adapter的應用,幫助使用者理解如何在不同場景中配置和使用Prometheus Adapter,以滿足複雜的監控需求。以下是三個詳細的實踐案例。
案例一:Kubernetes整合Prometheus Adapter
背景
在Kubernetes叢集中,水平自動擴充套件(HPA)主要依賴於CPU和記憶體的使用情況。然而,在實際應用中,許多業務場景需要基於其他指標(如請求數、響應時間等)進行擴充套件。透過Prometheus Adapter,可以將自定義的Prometheus指標引入到Kubernetes HPA中,實現更精細的擴充套件策略。
目標
透過Prometheus Adapter,將HTTP請求數這一業務指標引入到Kubernetes HPA中,實現基於請求數的自動擴充套件。
步驟
-
配置Prometheus Adapter
首先,編寫Prometheus Adapter的配置檔案,定義從Prometheus中獲取HTTP請求數的查詢規則。
apiVersion: v1 kind: ConfigMap metadata: name: custom-metrics-config namespace: custom-metrics data: config.yaml: | rules: - seriesQuery: 'http_requests_total{namespace!="",pod!=""}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: matches: "^(.*)_total" as: "${1}_per_second" metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
部署配置檔案:
kubectl apply -f custom-metrics-config.yaml
-
部署Prometheus Adapter
使用Helm或YAML檔案部署Prometheus Adapter。
helm install prometheus-adapter prometheus-community/prometheus-adapter --namespace custom-metrics
-
驗證自定義指標
確認Prometheus Adapter已經成功匯入自定義指標:
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
-
配置HPA
建立一個HPA資源,基於自定義的HTTP請求數指標進行擴充套件:
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: http-requests-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-deployment minReplicas: 1 maxReplicas: 10 metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: 100
部署HPA配置檔案:
kubectl apply -f http-requests-hpa.yaml
效果
透過上述步驟,Kubernetes叢集中的應用將基於HTTP請求數的變化進行自動擴充套件,從而確保在高負載時有足夠的資源來處理請求,同時在低負載時釋放資源,最佳化資源利用率。
案例二:結合自定義指標進行業務監控
背景
在實際業務場景中,某電商平臺需要監控每秒訂單數,以確保在高峰期能夠及時擴充套件資源,避免系統過載。
目標
透過Prometheus Adapter,將訂單數這一業務指標引入到Kubernetes HPA中,實現基於訂單數的自動擴充套件。
步驟
-
配置Prometheus Adapter
編寫Prometheus Adapter的配置檔案,定義從Prometheus中獲取訂單數的查詢規則。
apiVersion: v1 kind: ConfigMap metadata: name: order-metrics-config namespace: custom-metrics data: config.yaml: | rules: - seriesQuery: 'orders_total{namespace!="",pod!=""}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: matches: "^(.*)_total" as: "${1}_per_second" metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
部署配置檔案:
kubectl apply -f order-metrics-config.yaml
-
部署Prometheus Adapter
使用Helm或YAML檔案部署Prometheus Adapter。
helm install prometheus-adapter prometheus-community/prometheus-adapter --namespace custom-metrics
-
驗證自定義指標
確認Prometheus Adapter已經成功匯入自定義指標:
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
-
配置HPA
建立一個HPA資源,基於自定義的訂單數指標進行擴充套件:
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: orders-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 2 maxReplicas: 20 metrics: - type: Pods pods: metric: name: orders_per_second target: type: AverageValue averageValue: 50
部署HPA配置檔案:
kubectl apply -f orders-hpa.yaml
效果
透過上述步驟,電商平臺的訂單處理服務將基於每秒訂單數的變化進行自動擴充套件,確保在訂單高峰期能夠及時擴充套件資源,保證服務的可用性和響應速度。
案例三:多叢集環境下的Prometheus Adapter應用
背景
在多叢集環境中,需要統一監控和管理不同叢集的資源和應用。透過Prometheus Adapter,可以實現跨叢集的統一監控和管理。
目標
透過Prometheus Adapter,實現多個Kubernetes叢集的統一監控和管理。
步驟
-
配置多叢集環境
假設已有兩個Kubernetes叢集:Cluster A和Cluster B,分別部署了Prometheus例項。
-
在每個叢集中部署Prometheus Adapter
在Cluster A中:
helm install prometheus-adapter prometheus-community/prometheus-adapter --namespace custom-metrics
在Cluster B中:
helm install prometheus-adapter prometheus-community/prometheus-adapter --namespace custom-metrics
-
配置跨叢集Prometheus查詢
在每個叢集的Prometheus Adapter配置檔案中,分別定義從對方叢集獲取資料的查詢規則。例如,在Cluster A的配置檔案中:
prometheus: url: http://prometheus-cluster-b:9090/ path: /api/v1/query
在Cluster B的配置檔案中:
prometheus: url: http://prometheus-cluster-a:9090/ path: /api/v1/query
-
定義跨叢集自定義指標
在Cluster A的Prometheus Adapter配置檔案中,定義從Cluster B獲取的指標查詢規則:
rules: - seriesQuery: 'cluster_b_http_requests_total{namespace!="",pod!=""}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: matches: "^(.*)_total" as: "${1}_per_second" metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
在Cluster B的Prometheus Adapter配置檔案中,定義從Cluster A獲取的指標查詢規則:
rules: - seriesQuery: 'cluster_a_http_requests_total{namespace!="",pod!=""}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: matches: "^(.*)_total" as: "${1}_per_second" metricsQuery: 'sum(rate(<<.Series>>[5m])) by (<<.GroupBy>>)'
-
驗證配置
在兩個叢集中,分別驗證Prometheus Adapter是否成功匯入跨叢集自定義指標:
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
效果
透過上述配置,兩個叢集中的Prometheus Adapter能夠互相獲取對方的監控資料,實現跨叢集的統一監控和管理。在多叢集環境中,使用者可以透過自定義指標,實現對不同叢集資源的靈活管理和自動擴充套件,提高系統的整體監控效率和響應能力。
如有幫助,請多關注
TeahLead KrisChang,10+年的網際網路和人工智慧從業經驗,10年+技術和業務團隊管理經驗,同濟軟體工程本科,復旦工程管理碩士,阿里雲認證雲服務資深架構師,上億營收AI產品業務負責人。