基于Heapster的HPA

luxixing 發布于2019-06-28 16:56 / 2785人閱讀

摘要：基于的概述，簡稱，是中實現水平自動伸縮的功能。它可以根據使用率或應用自定義自動擴展數量支持和節點擴縮容層面，集群的持續監控，一旦發現無法被，則基于進行擴展，即節點的自動擴縮容，具體內容在后續文章中介紹。

基于Heapster的HPA 概述

Horizontal Pod Autoscaling，簡稱HPA，是Kubernetes中實現POD水平自動伸縮的功能。自動擴展主要分為兩種:

水平擴展(scale out)，針對于實例數目的增減

垂直擴展(scal up)，即單個實例可以使用的資源的增減, 比如增加cpu和增大內存

HPA屬于前者。它可以根據CPU使用率或應用自定義metrics自動擴展Pod數量(支持 replication controller、deployment 和 replica set)

節點擴縮容層面，k8s集群的Cluster Autoscaler持續監控Pods，一旦發現Pods無法被schedule，則基于PodConditoin進行擴展，即node節點的自動擴縮容，具體內容在后續文章中介紹。

監控數據獲取

Heapster: heapster收集Node節點上的cAdvisor數據，并按照kubernetes的資源類型來集合資源。但是在v1.11中已經被廢棄（heapster監控數據可用，但HPA不再從heapster拿數據）

metric-server: 在v1.8版本中引入，官方將其作為heapster的替代者。metric-server依賴于kube-aggregator，因此需要在apiserver中開啟相關參數。v1.11中HPA從metric-server獲取監控數據

工作流程

1.創建HPA資源，設定目標CPU使用率限額，以及最大、最小實例數, 一定要設置Pod的資源限制參數: request, 否則HPA不會工作。

2.控制管理器每隔30s(可以通過–horizontal-pod-autoscaler-sync-period修改)查詢metrics的資源使用情況

3.然后與創建時設定的值和指標做對比(平均值之和/限額)，求出目標調整的實例個數

4.目標調整的實例數不能超過1中設定的最大、最小實例數，如果沒有超過，則擴容；超過，則擴容至最大的實例個數

如何部署：

1.6-1.8版本默認使用heapster

1.11版本及以上默認使用metric-server（需多帶帶安裝，并開啟參數）

1.部署和運行php-apache并將其暴露成為服務

2.創建HPA

如果為1.8及以下的k8s集群，指標正常，如果為1.11集群，需要執行如下操作。

4.向php-apache服務增加負載，驗證自動擴縮容

啟動一個容器，并通過一個循環向php-apache服務器發送無限的查詢請求（請在另一個終端中運行以下命令）

5.觀察HPA是否生效

用yaml創建HPA的方式為：

實現細節

HPA由一個控制循環實現，循環周期由--horizontal-pod-autoscaler-sync-period 標志指定，默認是30秒，每個周期內，controller-manager會查詢HPA中定義的metric的資源利用率。

如上例子，pod的request定義為200M，而HPA定義的target為50%，即HPA將通過增加或者減少Pod副本的數量（通過Deployment）以保持所有Pod的平均CPU利用率在50%以內(即200*0.5=100M以內），循環周期到達時，獲取pod的1分鐘內的平均cpu利用率（從heaspter),發現超過了100M，為332M，于是通過下面的公式，決定最終的pod數量

TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) / Target)

即 332/50 =6.xxx ceil為向上取整，得到7。如果得到的結果大于10，則為10

因為每次HPA生效都會創建或者刪除pod，而這些操作其實會影響到metric監控值，如創建pod會暫時性的升高cpu，因此每次擴容都要間隔3分鐘，縮容需要間隔5分鐘。且需要滿足：avg（CurrentPodsConsumption）/ Target下降9%，進行縮容，增加至10%才進行擴容

這樣做好處是：
1、判斷的精度高，不會頻繁的擴縮pod，造成集群壓力大。
2、避免頻繁的擴縮pod，防止應用訪問不穩定

實現hpa的條件：
1、hpa不能autoscale daemonset類型control
2、要實現autoscale，pod必須設置request

參考：https://github.com/kubernetes...

本文為容器監控實踐系列文章，完整內容見：container-monitor-book

GPU云服務器云服務器 HPA heapster 基于云計算的基于linux的

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

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

基于Heapster的HPA

摘要：基于的概述，簡稱，是中實現水平自動伸縮的功能。它可以根據使用率或應用自定義自動擴展數量支持和節點擴縮容層面，集群的持續監控，一旦發現無法被，則基于進行擴展，即節點的自動擴縮容，具體內容在后續文章中介紹。基于Heapster的HPA 概述 Horizontal Pod Autoscaling，簡稱HPA，是Kubernetes中實現POD水平自動伸縮的功能。自動擴展主要分為兩種: 水...

Forelax 2019-07-01 16:59 評論0 收藏0
容器監控實踐—Heapster

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

DDreach 2019-06-28 16:56 評論0 收藏0
容器監控實踐—Heapster

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

寵來也 2019-07-01 16:59 評論0 收藏0
容器監控實踐—Metrics Server

摘要：出現后，新的監控架構將變成上圖的樣子核心流程黑色部分這是正常工作所需要的核心度量，從等獲取度量數據，再由提供給控制器等使用。本文為容器監控實踐系列文章，完整內容見概述從 v1.8 開始，資源使用情況的監控可以通過 Metrics API的形式獲取，具體的組件為Metrics Server，用來替換之前的heapster，heapster從1.11開始逐漸被廢棄。 Metrics-S...

libxd 2019-06-28 16:57 評論0 收藏0
容器監控實踐—Metrics Server

摘要：出現后，新的監控架構將變成上圖的樣子核心流程黑色部分這是正常工作所需要的核心度量，從等獲取度量數據，再由提供給控制器等使用。本文為容器監控實踐系列文章，完整內容見概述從 v1.8 開始，資源使用情況的監控可以通過 Metrics API的形式獲取，具體的組件為Metrics Server，用來替換之前的heapster，heapster從1.11開始逐漸被廢棄。 Metrics-S...

lmxdawn 2019-07-01 17:01 評論0 收藏0