Kubernetes Autoscaling是如何工作的？

09-01

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 hpaNAME 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或啟用APIaggregation。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