Pod彈性伸縮常見問題解析

【背景】

安裝華為云mertic-server插件，并配置HPA策略后；可根據實時監控，動態擴縮容Pod實例數。此文檔主要分析HPA的彈性算法，文檔結構如下：

1) HPA原理

2) 案例分析

3) 使用擴展

【HPA原理】

名詞講解：

HPA：Pod 水平自動擴縮（Horizontal Pod Autoscaler），用戶設置擴縮容規則（cpu和內存使用率），利用mertric-server插件能力，實現pod根據業務量彈性變動

工作原理：

Pod 水平自動擴縮特性由 Kubernetes API 資源和控制器實現，控制器會周期性的調整副本控制器或 Deployment 中的副本數量，以使得 Pod 的平均 CPU 利用率與用戶所設定的目標值匹配。Pod 水平自動擴縮器的實現是一個控制回路，由控制器管理器構成。每個周期內（默認是15s），控制器管理器根據每個 HorizontalPodAutoscaler 定義中指定的指標查詢資源利用率，然后控制器管理器從資源度量指標 API（按 Pod 統計的資源用量）和自定義度量指標 API（其他指標）獲取度量值，根據伸縮算法，實現動態水平擴縮容。

HPA擴縮容按照Pod 水平自動擴縮算法如下：

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

期望副本數 = ceil[當前副本數 * (當前指標 / 期望指標)]

【案例分析】

用戶反饋設置CPU和內存的HPA閾值為80%，但是某些POD在并未達到80%時發生了擴容,并且長時間未縮容，截圖如下：

問題分析：

從用戶的截圖看到記錄如上：

ScalingActive?? True? validMetricFound the HPA was able to successfully calculate ……………

ScalingLimited??False??DesireWithinRange the desire count is within the acceptable range

看到最后一條信息副本數變化為False,期望的副本數在可接受范圍內，不工作了

定位思路：

未縮容策略中對應的服務指標如下：

當前指標：52%，期望指標：80%，當前副本數：2

伸縮目標： （52% / 80% * 2）=1.3向上取整為2，即當前值為2，伸縮最終副本數目標還是2，所以未觸發擴縮容，也印證了日志報錯：ScalingLimited? False? DesireWithinRange the desire count is within the acceptable range

用戶擴縮容成功的實例：

當前指標：53%，期望指標：80%，當前副本數：3

縮容目標： （53% / 80% * 3）=1.9 向上取整為2所以縮容了

【使用擴展】

HorizontalPodAutoscaler 指定的是targetAverageValue 或 targetAverageUtilization， 那么將會把指定 Pod 度量值的平均值做為 currentMetricValue，此時無法將如下類型的指標 Pod 統計進去：

1：所有被標記了刪除時間戳（Pod 正在關閉過程中）的 Pod 和 失敗的 Pod 都會被忽略，即在界面或者命令行看到狀態為terminating或者error的pod，這種不會被統計到，hpa不會采集；

2：如果某個 Pod 缺失度量值，它將會被擱置，只在最終確定擴縮數量時再考慮，即如果這個pod未設置limit和request，這種不會被統計到，hpa不會采集；

3：當使用 CPU 指標來擴縮時，任何還未就緒（例如還在初始化）狀態的Pod或最近的指標 度量值采集于就緒狀態前的 Pod，該 Pod 也會被擱置。即pod如果應為其他原因未就緒，一直處于containercreating或者pending，這種不會被統計到，hpa不會采集；

4：Pod 水平擴縮控制器無法準確的知道 Pod 什么時候就緒， 也就無法決定是否暫時擱置該 Pod。 --horizontal-pod-autoscaler-initial-readiness-delay 參數（默認為 30s）用于設置 Pod 準備時間， 在此時間內的 Pod 統統被認為未就緒。 --horizontal-pod-autoscaler-cpu-initialization-period 參數（默認為5分鐘） 用于設置 Pod 的初始化時間， 在此時間內的 Pod，CPU 資源度量值將不會被采納。在排除掉被擱置的 Pod 后，擴縮比例就會根據currentMetricValue/desiredMetricValue 計算出來；

5：直接操控副本控制器執行滾動升級時，HPA 不能工作， 也就是說你不能將 HPA 綁定到某個 RC 再執行滾動升級 （例如使用 kubectl rolling-update 命令）。HPA 不能工作的原因是它無法綁定到滾動更新時所新創建的副本控制器，因此建議服務自身滾動升級過程中，停掉HPA的擴容策略，待服務更新升級完，在重新配置。

綜合而言，hpa計算采集的pod，必須是處于running狀態的pod，在服務升級過程中，建議關閉hpa。

彈性伸縮 AS Kubernetes

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。