K8s中HPA的原理及分析是怎樣的

今天就跟大家聊聊有關K8s中HPA的原理及分析是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

一、介紹

HPA的全稱為（Horizontal Pod Autoscaling）它可以根據當前pod資源的使用率（如CPU、磁盤、內存等），進行副本數的動態的擴容與縮容，以便減輕各個pod的壓力。
當pod負載達到一定的閾值后，會根據擴縮容的策略生成更多新的pod來分擔壓力，當pod的使用比較空閑時，在穩定空閑一段時間后，還會自動減少pod的副本數量。

二、HPA的工作原理

k8s中的某個Metrics Server（Heapster或自定義Metrics Server）持續采集所有Pod副本的指標數據。

HPA控制器通過Metrics Server的API（Heapster的API或聚合API）獲取這些數據，基于用戶定義的擴縮容規則進行計算，得到目標Pod副本數量。

當目標Pod副本數量與當前副本數量不同時，HPA控制器就訪問Pod的副本控制器（Deployment 、RC或者ReplicaSet）發起scale操作，調整Pod的副本數量，完成擴縮容操作。

三、指標的類型

       Master的kube-controller-manager服務持續監測目標Pod的某種性能指標，以計算是否需要調整副本數量。目前k8s支持的指標類型如下。

◎　Pod資源使用率：Pod級別的性能指標，通常是一個比率值，例如CPU使用率。
◎　Pod自定義指標：Pod級別的性能指標，通常是一個數值，例如接收的請求數量。
◎　Object自定義指標或外部自定義指標：通常是一個數值，需要容器應用以某種方式提供，例如通過HTTP URL“/metrics”提供，或者使用外部服務提供的指標采集URL。

       k8s從1.11版本開始，棄用基于Heapster組件完成Pod的CPU使用率采集的機制，全面轉向基于Metrics Server完成數據采集。Metrics Server將采集到的Pod性能指標數據通過聚合API（Aggregated API）如metrics.k8s.io、custom.metrics.k8s.io和external.metrics.k8s.io提供給HPA控制器進行查詢。關于聚合API和聚合器（API Aggregator）的概念我們后面詳細講解。

四、擴縮容策略

通過伸縮系數判斷是否要進行擴容或縮容。

HPA會根據獲得的指標數值，應用相應的算法算出一個伸縮系數，此系數是指標的期望值與目前值的比值，如果大于1表示擴容，小于1表示縮容。

容忍度

--horizontal-pod-autoscaler-tolerance：容忍度

它允許一定范圍內的使用量的不穩定，現在默認為0.1，這也是出于維護系統穩定性的考慮。

例如，設定HPA調度策略為cpu使用率高于50%觸發擴容，那么只有當使用率大于55%或者小于45%才會觸發伸縮活動，HPA會盡力把Pod的使用率控制在這個范圍之間。

算法

具體的每次擴容或者縮容的多少Pod的算法為: 期望副本數 = ceil[當前副本數 * ( 當前指標 / 期望指標 )]

舉個栗子

• 當前metric值是200m，期望值是100m，那么pod副本數將會翻一倍，因為 比率為 200.0 / 100.0 = 2.0；

• 如果當前值是50m，我們會將pod副本數減半，因為50.0 / 100.0 == 0.5

• 如果比率接近1.0，如0.9或1.1（即容忍度是0.1），將不會進行縮放（取決于內置的全局參數容忍度，–horizontal-pod-autoscaler-tolerance，默認值為0.1）。

此外，存在幾種Pod異常的情況，如下所述。

◎  Pod正在被刪除（設置了刪除時間戳）：將不會計入目標Pod副本數量。

◎ Pod的當前指標值無法獲得：本次探測不會將這個Pod納入目標Pod副本數量，后續的探測會被重新納入計算范圍。

◎ 如果指標類型是CPU使用率，則對于正在啟動但是還未達到Ready狀態的Pod，也暫時不會納入目標副本數量范圍。可以通過kube-controller-manager服務的啟動參數--horizontal-pod-autoscaler-initial-readiness-delay設置首次探測Pod是否Ready的延時時間，默認值為30s。另一個啟動參數--horizontal-pod-autoscaler-cpuinitialization-period設置首次采集Pod的CPU使用率的延時時間。

注意：

• 每次最大擴容pod數量不會超過當前副本數量的2倍

• 如果某些pod的容器沒有需要的的資源metrics，自動伸縮將不會根據這些metrics進行伸縮。

• 如果指定了targetAverageValue 或者 targetAverageUtilization，currentMetricValue是所有目標pod的metric取均值。在檢查容忍度和確定最終值之前，會結合參考pod是否就緒、是否丟失metrics。

• 設置了刪除時間戳的所有Pod（即處于關閉狀態的Pod）和所有失敗的Pod將被丟棄。

冷卻和延遲機制

使用HPA管理一組副本時，有可能因為metrics動態變化而導致副本數頻繁波動，這種現象叫做 “顛簸”。

想象一種場景：

當pod所需要的CPU負荷過大，從而在創建一個新pod的過程中，系統的CPU使用量可能會同樣在有一個攀升的過程。所以，在每一次作出決策后的一段時間內，將不再進行擴展決策。對于擴容而言，這個時間段為3分鐘，縮容為5分鐘

• --horizontal-pod-autoscaler-downscale-delay：這個參數用于告訴autoscaler做完縮容操作后需要等多久才能進行下一次縮容，默認值是5分鐘。

• --horizontal-pod-autoscaler-upscale-delay：這個參數用于告訴autoscaler做完擴容操作后需要等多久才能進行下一次擴容，默認值是3分鐘。

注意：使用者需要知道調整這個參數可能造成的影響。設置得太長，HPA對負載變化的響應也會變長；太短又會導致自動伸縮“顛簸”。

Pod延遲探測機制

如果指標類型是CPU使用率，則對于正在啟動但是還未達到Ready狀態的Pod，也暫時不會納入目標副本數量范圍。

• 可以通過kube-controller-manager服務的啟動參數--horizontal-pod-autoscaler-initial-readiness-delay設置首次探測Pod是否Ready的延時時間，默認值為30s。

• 另一個啟動參數--horizontal-pod-autoscaler-cpuinitialization-period設置首次采集Pod的CPU使用率的延時時間。

五、HPA獲取自定義指標（Custom Metrics）的底層實現（基于Prometheus）

Kubernetes是借助Agrregator APIServer擴展機制來實現Custom Metrics。Custom Metrics APIServer是一個提供查詢Metrics指標的API服務（Prometheus的一個適配器），這個服務啟動后，kubernetes會暴露一個叫custom.metrics.k8s.io的API，當請求這個URL時，請求通過Custom Metics APIServer去Prometheus里面去查詢對應的指標，然后將查詢結果按照特定格式返回。

看完上述內容，你們對K8s中HPA的原理及分析是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。