Kubernetes Autoscaling是如何工做的？

Kubernetes Autoscaling是如何工做的？這是最近咱們常常被問到的一個問題。

因此本文將從Kubernetes Autoscaling功能的工做原理以及縮放集羣時能夠提供的優點等方面進行解釋。

什麼是Autoscaling

想象用水龍頭向2個水桶裏裝水，咱們要確保水在裝滿第一個水桶的80%時，開始注入第二個水桶。解決方法很簡單，只要在適當的位置在兩個水桶間裝置管道鏈接便可。而當咱們想要擴大裝水量，咱們只須要用這種辦法增長水桶便可。

一樣的道理放在咱們的應用或者服務上，雲計算的彈性伸縮功能可讓咱們從手動調節物理服務器/虛擬機之中解放出來。那麼把「水桶裝水」和「應用消耗計算資源」相比較——

• 水桶 - 縮放單位 - 解釋咱們縮放什麼的問題
• 80%標記 - 縮放的度量和觸發器 - 解釋咱們何時縮放的問題
• 管道 - 實現縮放的操做 - 解釋咱們怎樣進行縮放的問題

咱們縮放什麼？

在Kubernetes集羣環境中，做爲用戶咱們通常會縮放兩個東西：

Pods - 對於某個應用，假設咱們運行X個副本（replica），當請求超過X個Pods的處理量，咱們就須要擴展應用。而爲了使這一過程無縫工做，咱們的Nodes應該由足夠的可用資源，以便成功調度並執行這些額外的Pads；

Nodes - 全部Nodes的總容量表明咱們的集羣容量。若是工做負載需求超過該容量，咱們就須要爲集羣增長節點，以確保有效調度和執行工做負載。若是Pods不斷擴展，那麼可能會出現節點可用資源即將耗盡的狀況，咱們不得不添加更多節點來增長集羣級別可用的總體資源；

何時縮放？

通常狀況下，咱們會連續測量某個度量，當度量超過閾值時，經過縮放某個資源來對其進行操做。例如，咱們可能須要測量Pod的平均CPU消耗，而後在CPU消耗超過80％時觸發縮放操做。

可是一個度量標準不適合全部用例，對於不一樣類型的應用程序，度量標準可能會有所不一樣——對於消息隊列，處於等待狀態的消息數量可能會被做爲度量標準；對於內存密集型應用程序，內存消耗做爲指標可能會更合適。若是咱們有一個業務應用，該應用每秒可處理給定容量窗格約1000個事務，那麼咱們可能就會選用這個指標，並在Pods達到850以上時進行擴展。

以上咱們只考慮了擴展部分，可是當工做負載使用率降低時，應該有一種方法能夠適度縮減，而不會中斷正在處理的現有請求。

怎樣進行縮放？

對於Pods，只需更改replication中副本的數量就能夠了；而對於Nodes，咱們須要有辦法調用雲計算服務商的API，建立一個新實例並將其做爲集羣的一部分。

Kubernetes Autoscaling

基於以上理解，咱們來看看Kubernetes Autoscaling的具體實現和技術——

Cluster Autoscaler

Cluster Autoscaler（集羣自動縮放器）用於動態縮放集羣（Nodes），它的做用是持續監控Pods，一旦發現Pods沒法被schedule，則基於PodConditoin進行擴展。這種方式比查看集羣中即誒單的CPU百分比要有效不少。因爲Nodes建立須要一分鐘或更長時間（取決於雲計算服務商等因素），所以Pods可能須要一些時間才能被Schedule。

在羣集內，咱們可能有多個Nodes Pool，例如用於計費應用的Nodes Pool和用於機器學習工做負載的另外一個Nodes Pool。Cluster Autoscaler提供各類標記和方法來調整Nodes縮放行爲，更多詳情請查看https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md。

對於縮小（Scale down），Cluster Autoscaler會查看Nodes的平均利用率並參考其餘相關因素，例如若是Pods（Pod disruption Budget）運行在沒法從新調度的Node上，那麼該Node沒法從集羣中移除。Custer Autoscaler提供了一種正常終止Nodes的方法，通常能夠在10分鐘內從新定位Pods。

Horizo​​ntal Pod Autoscaler（HPA）

HPA是一個控制循環，用於監視和縮放部署中的Pods。這能夠經過建立引用部署/reolication controller的HPA object來完成。 咱們能夠定義部署按比例調整的閾值及規模上下限。HPA最先版本GA（autoscaling/v1）僅支持CPU做爲可監控的度量標準。當前版本HPA處於測試階段（autoscaling/v2beta1）支持內存和其餘自定義指標。一旦建立了HPA object而且它可以查詢該窗格的指標，就能夠看到它報告了詳細信息：

$ kubectl get hpa
NAME               REFERENCE                     TARGETS  MINPODS MAXPODS REPLICAS AGE
helloetst-ownay28d Deployment/helloetst-ownay28d 8% / 60% 1       4       1        23h

咱們能夠經過爲Controller Manager添加Flags來對水平Pod Autoscaler進行一些調整：

• 利用Flags-horizontal-pod-autoscaler-sync-period肯定hPa對於Pods組指標的監控頻率。默認的週期爲30秒。
• 兩次擴展操做之間的默認間隔爲3分鐘，能夠Flags來控制-horizontal-pod-autoscaler-upscale-delay
• 兩個縮小操做之間的默認間隔爲5分鐘，一樣能夠經過Flags來控制-horizontal-pod-autoscaler-downscale-delay

指標和雲提供商

爲了衡量指標，服務器應該在啓用Kubernetes自定義指標（https://github.com/kubernetes/metrics）的同時，啓用Heapster或啓用API aggregation。API metrics server是Kubernetes1.9版本以上的首選方法。對於配置Nodes，咱們應該在羣集中啓用並配置適當的cloud provider，更多詳情查看https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/。

一些插件

還有一些很不錯的插件，好比——

• Vertical pod autoscaler https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
• addon-resizer https://github.com/kubernetes/autoscaler/tree/master/addon-resizer

總而言之，下次再遇到有人問「Kubernetes Autoscaling是如何工做的」？但願這篇短文能對你們的解釋有所幫助。

又到了廣告時間

Kubernetes提出的一系列概念抽象，很是符合理想的分佈式調度系統。但大量高難度技術概念，同時也造成了一條陡峭的學習曲線，直接拉高了Kubernetes的使用門檻。

好雨雲開源PaaS Rainbond則將這些技術概念包裝成爲「Production-Ready」的應用，能夠做爲一個Kubernetes面板，開發者不須要特殊學習便可使用。包括本文中的彈性伸縮，Rainbond支持用戶進行水平伸縮和垂直伸縮：）

除此以外，Kubernetes自己是一個容器編排工具，並不提供管理流程，而Rainbond提供現成的管理流程，包括DevOps、自動化運維、微服務架構和應用市場等，能夠開箱即用。

進一步瞭解：https://www.goodrain.com/scene/k8s-docker

Rainbond Github：https://github.com/goodrain/rainbond