Kubernetes彈性伸縮全場景解讀（二） - HPA的原理與演進

前言

在上一篇文章中，咱們介紹了在Kubernetes在處理彈性伸縮時的設計理念以及相關組件的佈局，在今天這篇文章中，會爲你們介紹在Kubernetes中彈性伸縮最經常使用的組件HPA（Horizontal Pod Autoscaler）。HPA是經過計算Pod的實際工做負載進行從新容量規劃的組件，在資源池符合知足條件的前提下，HPA能夠很好的實現彈性伸縮的模型。HPA到目前爲止，已經演進了三個大的版本，在本文中會爲你們詳細解析HPA底層的原理以及在Kubernetes中彈性伸縮概念的演變歷程。

HPA基本原理

HPA是根據實際工做負載水平伸縮容器數目的組件，從中能夠提煉出兩個很是重要的關鍵字：負載和數目。咱們能夠用一個很是簡單的數學公式進行概括：

下面舉一個實際例子進行上述公式的闡述，假設存在一個叫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數目太小，須要進行擴容。
• 從新設置Target值爲5，此時算式的結果爲42%低於50%，判斷還須要擴容兩個容器。
• 此時HPA設置Replicas爲5，進行Pod的水平擴容。

通過上面的推演，能夠協助開發者快速理解HPA最核心的原理，不過上面的推演結果和實際狀況下是有所出入的，若是開發者進行試驗的話，會發現Replicas最終的結果是6而不是5。這是因爲HPA中一些細節的處理致使的，主要包含以下三個主要的方面：

1. 噪聲處理

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