国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

k8s集群應用基于Prometheus實現HPA

IT那活兒 / 594人閱讀
k8s集群應用基于Prometheus實現HPA

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！


01

在k8s集群中，我們希望當應用負載過大的時候，可以對應用進行自動擴容，提升pod的副本數來應對大量的流量，當負載小的時候可以對應用進行自動縮容，以避免資源浪費，這個時候就需要給應用做一個HPA。
但是并非所有系統應用都可以通過多帶帶依靠CPU/內存使用量度來滿足其SLA。有時候，我們希望除了CPU/內存指標外有更多的指標能用于實現HPA。這樣不僅能保證實現HPA指標的多樣性，還可以通過多指標對系統應用做HPA，以更好地處理突發事件并確保高可用性。 

02

HPA原理

對k8s比較熟悉的人，都知道k8s集群里的應用在調度和擴縮容的時候都有自己的一套算法，自動彈性伸縮的原理是怎樣的呢，下面舉一個實際例子進行闡述。
假設存在一個叫A的Deployment，包含3個Pod，每個副本的Request值是1核，當前3個Pod的CPU利用率分別是60%、70%與80%，此時我們設置HPA閾值為50%，最小副本為3，最大副本為10。
接下來我們將上述的數據帶入公式中：
  • 總的Pod的利用率是60%+70%+80% = 210%；
  • 當前的Target是3；
  • 算式的結果是70%，大于50%閾值，因此當前的Target 數目過小，需要進行擴容；
  • 重新設置 ，此時算式的結果為42%低于50%，判斷還需要擴容兩個容器；
  • 此時HPA設置Replicas為5，進行Pod的水平擴容。


03

影響HPA的細節

經過前面的推演，可以協助我們快速理解HPA最核心的原理，不過上面的推演結果和實際情況下是有所出入的，如果我們進一步試驗的話，會發現 Replicas最終的結果是6而不是5。這是由于 HPA 中一些細節的處理導致的，主要包含如下三個主要的方面：

3.1 噪聲處理

通過前面的公式可以發現，Target的數目很大程度上會影響最終的結果，而在Kubernetes中，無論是變更或者升級，都更傾向于使用Recreate而不是Restart的方式進行處理。
這就導致了在Deployment的生命周期中，可能會出現某一個時間，Target會由于計算了Starting或者 Stopping的Pod而變得很大。這就會給HPA的計算帶來非常大的噪聲，在HPA Controller的計算中，如果發現當前的對象存在Starting或者Stopping的Pod會直接跳過當前的計算周期，等待狀態都變為Running再進行計算。

3.2 冷卻周期

HPA控制器觀測資源使用率并作出決策是有周期的，執行是需要時間的，在執行自動伸縮過程中metrics不是靜止不變的，可能降低或者升高，如果執行太頻繁可能導致資源的使用快速抖動，因此控制器每次決策后的一段時間內不再進行新的決策。
在彈性伸縮中，冷卻周期是不能逃避的一個話題，很多時候我們期望快速彈出與快速回收，而另一方面，我們又不希望集群震蕩，所以一個彈性伸縮活動冷卻周期的具體數值是多少，一直被開發者所挑戰。在HPA中，默認的擴容冷卻周期是3min，縮容冷卻周期是5min。可以通過調整kube-controller-manager組件啟動參數設置冷卻時間：
--horizontal-pod-autoscaler-downscale-delay擴容冷卻
--horizontal-pod-autoscaler-upscale-delay縮容冷卻
針對不同的k8s版本，可以參考相應k8s版本kube-controller-manager組件關于HPA的啟動參數：

3.3 邊界值計算

我們回到剛才的計算公式，第一次我們算出需要彈出的容器數目是 5，此時擴容后整體的負載是42%，但是我們似乎忽略了一個問題：
一個全新的 Pod啟動會不會自己就占用了部分資源？
此外，8%的緩沖區是否就能夠緩解整體的負載情況？
要知道當一次彈性擴容完成后，下一次擴容要最少等待3分鐘才可以繼續擴容。為了解決這些問題，HPA引入了邊界值，目前在計算邊界條件時，會自動加入10%的緩沖，這也是為什么在剛才的例子中最終的計算結果為6的原因。 


04

HPA 的API版本

目前HPA已經支持三大版本：autoscaling/v1、autoscaling/v2beta1和autuscaling/v2beta2 三個大版本。
  • API的v1版本，在當前穩定版本（autoscaling/v1）中只支持基于 CPU 指標的擴縮。
  • API的beta版本，autoscaling/v2beta1版和autuscaling/v2beta2版引入了基于內存和自定義指標的擴縮，在autoscaling/v2beta1中增加支持custom metrics，在 autoscaling/v2beta2 中增加支持 external metrics。


05

實現流程圖

關鍵組件介紹：
  • Prometheus：采集Pod的性能指標數據。
  • Custom Metrics server：從Prometheus中采集性能指標數據。它是資源指標數據的聚合器，實現了自定義指標API（Resource Metres API），通過Kubernetes的Custom Metrics server（Prometheus Adapter)層將自定義指標HPA注冊Maste API server中，以/apis/custom.metrics.k8s.io路徑提供指標數據。
  • HAI Controler：為APA控制器，通過自定義指標API從API Server中獲取指標數據，以決策擴縮容操作。


06


安裝

組件包括Prometheus，Metrics server，Custom Metrics server（prometheus-adapter），如果集群已經安裝了Prometheus，Metrics server，只需安裝Custom Metrics server即可。

6.1 安裝Custom Metrics server

測試環境當中已經安裝了Prometheus，Metrics server，這里只需安裝Custom Metrics server即可，下載prometheus-adapter的helm chart，使用helm一鍵部署。
編輯values.yaml添加平臺Prometheus.service地址，使用如下命令一鍵部署：
helm install  prometheus-adapter --namespace monitoring ../prometheus-adapter/ -f values.yaml

6.2 配置

我們可以將Prometheus中的任何一個指標都用于HPA，但是前提是我們能通過查詢語句將它拿到（包括指標名稱和其對應的值）。
Prometheus適配器在configmap里配置了如何從prometheus獲取數據，并與k8s的資源做對應，以及如何在api接口中展示的規則。


07

驗證

列出prometheus提供的自定義指標，發現所有Prometheus里能查看的監控指標在這里都被獲取到了。
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
獲取monitoring命名孔徑下所有Pod的FS使用率：
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/fs_usage_bytes" | jq .
從自定義metrics API中獲取每秒請求總數。
例如Prometheus監控的應用，暴露了名為http_requests_total的自定義指標。Prometheus適配器刪除_total后綴，并將度量標記為計數器度量(counter metric)。
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/http_requests" | jq .

{
"kind": "MetricValueList",
"apiVersion": "custom.metrics.k8s.io/v1beta1",
"metadata": {
"selfLink": "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/http_requests"
},
"items": [
{
"describedObject": {
"kind": "Pod",
"namespace": "default",
"name": "podinfo-6c994884cf-m6l6m",
"apiVersion": "/v1"
},
"metricName": "http_requests",
"timestamp": "2020-10-09T03:01:01Z",
"value": "1072m"
},
{
"describedObject": {
"kind": "Pod",
"namespace": "default",
"name": "podinfo-6c994884cf-pns2n",
"apiVersion": "/v1"
},
"metricName": "http_requests",
"timestamp": "2020-10-09T03:01:01Z",
"value": "1035m"
}
]
}
自定義API SERVER收到請求后會從Prometheus里面查詢http_requests_total的值，然后把這個值換算成一個以時間為單位的請求率。
m代表milli-units，例如1035m代表1035 milli-requests（就是大約1個請求），用十進制表示為 1.035。可能度量指標API將返回沒有后綴的整數，否則返回以千分單位的數量。
這意味著我們可能會看到你的度量指標在1和1035m（也就是在十進制記數法中的 1 和 1.035之間波動）。

7.1 創建HPA

基于pod/svc/CPU/memory創建HPA：
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: podinfo-hpa-f
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: podinfo
minReplicas: 1
maxReplicas: 5
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 80
- type: Resource
resource:
name: memory
target:
type: AverageValue
averageValue: 200Mi
- type: Pods
pods:
metric:
name: http_requests
target:
type: AverageValue
averageValue: 50
- type: Object
object:
metric:
name: http_requests
describedObject:
apiVersion: v1
kind: service
name: podinfo
target:
type: Value
value: 50
一個HPA中可以定義多種指標，如果定義多個指標將針對每種類型指標都計算Pod副本數量，取最大的進行擴縮容。
換句話說，系統會根據CPU和pod的自定義指標計算，在每個調度周期（默認為30s）都會計算出一個縮放的推薦值并記錄下來，在每次計算縮放值時都會查看歷史的推薦值，從最近的一段歷史推薦值中挑選最大的，任何一個達到了都進行擴容。
上面HPA相關配置如下：
1）scaleTargetRef：自動擴容縮容的對象，可以是Deployment或者ReplicaSet，這里寫具體的Deployment的名稱。
2）metrics：這里是指標的目標值。在type中定義類型；通過target來定義指標的閾值，系統將在指標達到閾值的時候出發擴縮容操作。
3）可以指定資源度量指標使用絕對數值或者百分比，需要將 target 類型 AverageUtilization（百分比）替換成AverageValue（絕對數值），同時將target.averageUtilization替換成target.averageValue并設定相應的值。百分比適用于cpu/內存指標。
4）metrics中的type有如下類型：
  • Resource：基于資源的指標，可以是CPU或者是內存，如果基于這個類型的指標來做只需要部署Metric-server即可，不需要部署自定義APISERVER。
  • Pods：基于Pod的指標，系統將對Deployment中的全部Pod副本指標進行平均值計算，如果是Pod則該指標必須來源于Pod本身。
  • Object：基于Ingress或者其他自定義指標，比如ServiceMonitor。它的target類型可以是Value或者AverageValue（根據Pod副本數計算平均值）。

7.2 壓測服務并驗證HPA

以每秒200個請求的速度為podinfo服務加壓，
[root@ysgz-33 home]# ./bin/hey -n 10000 –q 2 -c 100 http://10.3.37.189:9898
一段時間后發現podinfo服務的pod數量增加了，撤掉加壓，過一會兒pod數量發生了縮減。
可以通過kubectl describe hpa 命令查看當前影響HPA的各種狀態條件信息。
使用 autoscaling/v2beta2 格式的 HorizontalPodAutoscale時，可以看到Kubernetes為 HPA設置的狀態條件（Status Conditions）。
這些狀態條件可以顯示當前HPA是否能夠執行擴縮以及是否受到一定的限制。status.conditions字段展示了這些狀態條件：
  • AbleToScale表明HPA是否可以獲取和更新擴縮信息，以及是否存在阻止擴縮的各種回退條件。
  • ScalingActive表明HPA是否被啟用（即目標的副本數量不為零）以及是否能夠完成擴縮計算。當這一狀態為False時，通常表明獲取度量指標存在問題。
  • ScalingLimitted 表明所需擴縮的值被HPA所定義的最大或者最小值所限制。（即已經達到最大或者最小擴縮值）


08

擴展

本次測試使用的壓測工具安裝。
hey壓測工具安裝：
yum install golang -y
export GOROOT=/usr/lib/golang
export GOPATH=/home
# 生效配置：
source /etc/profile

cd /home
go get -u github.com/rakyll/hey
go install github.com/rakyll/hey
./bin/hey -n 10000 -q 10 -c 50 http://地址
使用域名時，注意添加本地域名解析：

-n 請求次數

-q 請求速度

-c 請求并發數

09

總結

9.1 在集群中做了這樣一個配置后，集群可支持一個HPA中定義多種指標（cpu/內存，訪問量及其他Prometheus能獲取的指標）實現HPA；
9.2 如果定義了多種指標，系統會根據CPU和pod的自定義指標計算，在每個調度周期（默認為30s）都會計算出一個縮放的推薦值并記錄下來，在每次計算縮放值時都會查看歷史的推薦值，從最近的一段歷史推薦值中挑選最大的，任何一個達到了都進行擴容。 

 

 

END



本文作者：符 海

本文來源：IT那活兒（上海新炬王翦團隊）

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129487.html

相關文章

  • k8s與HPA--通過 Prometheus adaptor 來自定義監控指標

    摘要：與通過來自定義監控指標自動擴展是一種根據資源使用情況自動擴展或縮小工作負載的方法。適配器刪除后綴并將度量標記為計數器度量標準。負載測試完成后，會將部署縮到其初始副本您可能已經注意到自動縮放器不會立即對使用峰值做出反應。 k8s與HPA--通過 Prometheus adaptor 來自定義監控指標 自動擴展是一種根據資源使用情況自動擴展或縮小工作負載的方法。 Kubernetes中的自...

    孫吉亮 評論0 收藏0

  • k8s與HPA--通過 Prometheus adaptor 來自定義監控指標

    摘要：與通過來自定義監控指標自動擴展是一種根據資源使用情況自動擴展或縮小工作負載的方法。適配器刪除后綴并將度量標記為計數器度量標準。負載測試完成后，會將部署縮到其初始副本您可能已經注意到自動縮放器不會立即對使用峰值做出反應。 k8s與HPA--通過 Prometheus adaptor 來自定義監控指標 自動擴展是一種根據資源使用情況自動擴展或縮小工作負載的方法。 Kubernetes中的自...

    HollisChuang 評論0 收藏0

  • k8s與HPA--通過 Prometheus adaptor 來自定義監控指標

    摘要：與通過來自定義監控指標自動擴展是一種根據資源使用情況自動擴展或縮小工作負載的方法。適配器刪除后綴并將度量標記為計數器度量標準。負載測試完成后，會將部署縮到其初始副本您可能已經注意到自動縮放器不會立即對使用峰值做出反應。 k8s與HPA--通過 Prometheus adaptor 來自定義監控指標 自動擴展是一種根據資源使用情況自動擴展或縮小工作負載的方法。 Kubernetes中的自...

    ityouknow 評論0 收藏0

  • 容器監控實踐—Custom Metrics

    摘要：自定義指標由提供，由此可支持任意采集到的指標。文件清單的，收集級別的監控數據監控服務端，從拉數據并存儲為時序數據。本文為容器監控實踐系列文章，完整內容見 概述 上文metric-server提到，kubernetes的監控指標分為兩種： Core metrics(核心指標)：從 Kubelet、cAdvisor 等獲取度量數據，再由metrics-server提供給 Dashboar...

    laznrbfe 評論0 收藏0

  • 容器監控實踐—Custom Metrics

    摘要：自定義指標由提供，由此可支持任意采集到的指標。文件清單的，收集級別的監控數據監控服務端，從拉數據并存儲為時序數據。本文為容器監控實踐系列文章，完整內容見 概述 上文metric-server提到，kubernetes的監控指標分為兩種： Core metrics(核心指標)：從 Kubelet、cAdvisor 等獲取度量數據，再由metrics-server提供給 Dashboar...

    DangoSky 評論0 收藏0

  • 容器監控實踐—Heapster

    摘要：還可以把數據導入到第三方工具展示或使用場景共同組成了一個流行的監控解決方案原生的監控圖表信息來自在中也用到了，將作為，向其獲取，作為水平擴縮容的監控依據監控指標流程首先從獲取集群中所有的信息。 概述 該項目將被廢棄（RETIRED） Heapster是Kubernetes旗下的一個項目，Heapster是一個收集者，并不是采集 1.Heapster可以收集Node節點上的cAdvis...

    DDreach 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<