Kubernetes Autoscaling是如何工作的？

好雨雲幫發表於2019-03-02

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

所以本文將從Kubernetes Autoscaling功能的工作原理以及縮放叢集時可以提供的優勢等方面進行解釋。

什麼是Autoscaling

想象用水龍頭向2個水桶裡裝水，我們要確保水在裝滿第一個水桶的80%時，開始注入第二個水桶。解決方法很簡單，只要在適當的位置在兩個水桶間裝置管道連線即可。而當我們想要擴大裝水量，我們只需要用這種辦法增加水桶即可。

Kubernetes Autoscaling是如何工作的？

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

  • 水桶 – 縮放單位 – 解釋我們縮放什麼的問題
  • 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

相關文章