一、背景
業務程式非 CPU、memeory 敏感類業務,希望可以基於流量指標進行 HPA 彈性伸縮,但是大部分程式並沒有整合 Prometheus SDK 相關程式碼進行插樁。此時可以透過 cAdvisor 提供的容器網路流量指標實現業務峰谷期間的彈性擴縮容。
二、方案介紹
cAdvisor 負責節點上的容器和節點本身資源的統計,內建在 kubelet 中,並透過 kubelet 的 /metrics/cadvisor 介面對外提供 API。它可以採集容器網路累積接收資料總量和容器網路累積傳輸資料總量 , 即網路流入和流出指標。
參考指標:
container_network_receive_bytes_total 容器接受的網路流量,單位是位元組數
image.png
container_network_transmit_bytes_total 容器傳輸的網路流量,單位是位元組數
image.png
上面兩個指標都是 counter 計數器型別,對應的值只增不減。在配置自定義指標轉換規則時需要做下速率換算,將總量換算成每秒接受多少位元組數的流量指標。
三、實踐操作
3.1 安裝 Prometheus 相關外掛
建議使用華為雲 CCE 產品,外掛市場整合了 kube-prometheus-stack,同時該外掛也已經對接了 CCE 叢集節點實現了節點 cadvisor 的指標監控。
image.png
外掛安裝完成後,可以透過訪問 prometheus UI 檢視指標資訊:
image.png
3.2 配置 Prometheus-adapter 指標轉換規則
kubectl -n monitoring edit configmap user-adapter-config
image.png
seriesQuery: 'container_network_receive_bytes_total{namespace!="",pod!=""}'
seriesFilters: []
resources:
overrides:
namespace:
resource: namespace
pod:
resource: pod
name:
matches: container_(.*)_total
as: "pod_${1}_per_second"
metricsQuery: sum(rate(<<.Series>>{<<.LabelMatchers>>}[3m])) by (<<.GroupBy>>)/1000
seriesQuery: 'container_network_transmit_bytes_total{namespace!="",pod!=""}'
seriesFilters: []
resources:
overrides:
namespace:
resource: namespace
pod:
resource: pod
name:
matches: container_(.*)_total
as: "pod_${1}_per_second"
metricsQuery: sum(rate(<<.Series>>{<<.LabelMatchers>>}[3m])) by (<<.GroupBy>>)/1000
注意:修改後需要重啟 monitoring 名稱空間下的 custom-metrics-apiserver 負載例項。
其中 metricsQuery: sum(rate(<<.Series>>{<<.LabelMatchers>>}[3m])) by (<<.GroupBy>>)/1000 配置表示 最近 3min 內 pod 每秒接受的請求量,由於 container_network_receive_bytes_total 和 container_network_transmit_bytes_total 是 counter 型別的指標,指標數值會一直遞增,所以需要將指標做下速率換算。 除以 / 1000 則表示以 kb 為單位,預設單位是位元組數,查出來的值會很大,該處可以根據實際情況進行配置。
resources 處配置則是將 Prometheus 中查詢的指標和 K8s 叢集中的資源進行匹配對映。
name 處配置則是將 Prometheus 查詢出來的指標,進行重新命名處理,增強指標可讀性。
3.3 驗證自定義彈性指標是否可用
呼叫介面訪問自定義指標:
kubectl get --raw="/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/pod_network_receive_bytes_per_second" |jq
可以看到對應的指標和其返回的值。
也可以在 CCE 控制檯進行自定義指標的檢視,發現該指標已經可用:
3.4 測試 HPA 彈性功能
主要是觀測能否根據該指標,即容器每秒接受的網路流量指標進行動態闊縮容。
編寫 HPA yaml 檔案,建立 HPA 彈性伸縮策略
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: hpa-app07
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: app07
minReplicas: 1
maxReplicas: 10
metrics:
type: Pods
pods:
metric:
name: pod_network_receive_bytes_per_second
target:
type: AverageValue
averageValue: 10
然後透過執行命令 while true; do curl clusterIP:port;done 進行壓測,創造訪問流量。
觀測 HPA 實時動態 kubectl get hpa xxx -w
可以看到隨著流量指標數值的攀升,pod 例項逐步開始擴容。直到擴容到例項上限。
停止壓測觀察 HPA 縮容變化,直到最後只剩下一個 pod 在執行。
如何基於容器網路流量指標進行彈性伸縮
相關文章
- Serverless:基於個性化服務畫像的彈性伸縮實踐Server
- Knative Autoscaler 自定義彈性伸縮
- 彈性佈局(伸縮佈局)
- AutoScaling彈性伸縮配置重大升級
- 一個例子體會Kubernetes內容器的高可用性和彈性伸縮
- 如何使用 Kubernetes 實現應用程式的彈性伸縮
- EMQX Operator 如何快速建立彈性伸縮的 MQTT 叢集MQQT
- AutoScaling彈性伸縮附加與分離RDS例項
- AutoScaling 彈性伸縮附加與分離RDS例項
- Kubernetes彈性伸縮全場景解讀(五) - 定時伸縮元件釋出與開源元件
- Fluid 給資料彈性一雙隱形的翅膀 -- 自定義彈性伸縮UI
- 在騰訊雲容器服務 TKE 中利用 HPA 實現業務的彈性伸縮
- Effective HPA:預測未來的彈性伸縮產品
- 使用 tke-autoscaling-placeholder 實現秒級彈性伸縮
- 大型網站的可伸縮性架構如何設計?網站架構
- AutoScaling彈性伸縮附加與分離負載均衡例項負載
- SpringCloud 應用在 Kubernetes 上的最佳實踐 —— 高可用(彈性伸縮)SpringGCCloud
- 阿里云云計算ACP認證重點梳理3—彈性伸縮阿里
- TKE基於彈性網路卡直連Pod的網路負載均衡負載
- 彈性伸縮:高可用架構利器(架構+演算法+思維)架構演算法
- 雲端乾貨|降本必備—彈性伸縮的基本原理
- 容器網路流量轉發分析
- 基於容器特點和傳統網路安全能力進行容器雲安全規劃設計
- Node.js的可伸縮性Node.js
- Knativa 基於流量的灰度釋出和自動彈性實踐
- RDS for MySQL Serverless公測上線:彈性伸縮,最高可降成本超80%MySqlServer
- KubeVela + KEDA:為應用帶來“與生俱來”的彈性伸縮能力
- K8S Canal基於Prometheus進行實時指標監控K8SPrometheus指標
- 美團是如何進行指標管理的?指標
- 雲原生的彈性 AI 訓練系列之三:藉助彈性伸縮的 Jupyter Notebook,大幅提高 GPU 利用率AIGPU
- 如何進行網路抓取?
- AutoScaling目標追蹤伸縮規則概述
- 透過HPA+CronHPA組合應對業務複雜彈性伸縮場景
- 我們總結了彈性伸縮的五個條件與六個教訓
- Flex彈性盒子與容器屬性Flex
- 網際網路行業“潛規則”:彈性工作制,BAT的加班狀況簡直令人髮指!行業BAT
- 常見網際網路分析指標指標
- 免運維、彈性伸縮、按需付費...Serverless還有多少驚喜是我不知道的?運維Server