Kubernetes HPA Controller的工作原理

本篇內容介紹了“Kubernetes HPA Controller的工作原理”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

HPA Controller 工作原理

• K8s通過HPA，基于獲取到的metrics(CPU utilization, custom metrics) value，對rc, deployment管理的pods進行自動伸縮。

截止到Kubernetes 1.6，Release特性中僅支持CPU utilization這一resource metrics，對custom metrics的支持目前仍在alpha階段，請知曉。

• HPA Controller周期性(默認每30s一次，可通過kube-controller-manager的flag--horizontal-pod-autoscaler-sync-period進行設置)的調整對應的rc, deployment中的replicas數量，使得指定的metrics value能匹配用戶指定的target utilization value。

• 在每個HPA Controller的處理周期中，kube-controller-manager都去查詢HPA中定義的metrics的utilization。查詢方式根據metric類型不同而不同：

• 如果metric type是resource metrics，則通過resource metrics API查詢。

• 如果metric type屬于custom metrics，則通過custom metrics API查詢。

• 計算伸縮比例算法：

• 對于resource metrics，比如CPU，HPA Controller獲取HPA中指定的metrics，如果HPA中設定了target utilization，則HPA Controller會將獲取到的metrics除于對應的容器的resource request值作為監測到的當前pod的resource utilization。如此計算完所有HPA對應的pods后，對該resource utilization values取平均值。最后將平均值除于定義的target utilization，得到伸縮的比例。

  注意：如果HPA對應的某些pods中的容器沒有定義對應的resource request，則HPA不會對這些pods進行scale。

• 對于custome metrics，HPA Controller的伸縮算法幾乎與resource metrics一樣，不同的是：此時是根據custome metrics API查詢到的metrics value對比target metics value計算得到的，而不是通過utilization計算得到的。

• HPA與rc, deployment, pod的關系如下圖所示。

• HPA通過Scale sub-resource接口，對RC和Deployment的replicas進行控制。

• HPA最終對Pod副本數的控制終歸還是通過RC和Deployment控制器。

HPA Controller有兩種方式獲取metrics：

• direct Heapster access: 用于對resource metrics的監控，需要提前在kube-system namespace中部署Heapster。

• REST client access: 用于對custom metrics的監控，需要設置kube-controller-manager的--horizontal-pod-autoscaler-use-rest-clients flag為true。

“Kubernetes HPA Controller的工作原理”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！