今天就跟大家聊聊有關Kubernetes Autoscaling是怎么工作的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
創(chuàng)新互聯(lián)基于成都重慶香港及美國等地區(qū)分布式IDC機房數(shù)據(jù)中心構(gòu)建的電信大帶寬，聯(lián)通大帶寬，移動大帶寬，多線BGP大帶寬租用,是為眾多客戶提供專業(yè)BGP機房服務器托管報價，主機托管價格性價比高，為金融證券行業(yè)服務器托管，ai人工智能服務器托管提供bgp線路100M獨享，G口帶寬及機柜租用的專業(yè)成都idc公司。
Kubernetes Autoscaling是如何工作的？這是最近我們經(jīng)常被問到的一個問題。
下面將從Kubernetes Autoscaling功能的工作原理以及縮放集群時可以提供的優(yōu)勢等方面進行解釋。
想象用水龍頭向2個水桶里裝水，我們要確保水在裝滿第一個水桶的80%時，開始注入第二個水桶。解決方法很簡單，只要在適當?shù)奈恢迷趦蓚€水桶間裝置管道連接即可。而當我們想要擴大裝水量，我們只需要用這種辦法增加水桶即可。
同樣的道理放在我們的應用或者服務上，云計算的彈性伸縮功能可以讓我們從手動調(diào)節(jié)物理服務器/虛擬機之中解放出來。那么把“水桶裝水”和“應用消耗計算資源”相比較——
水桶 - 縮放單位 - 解釋我們縮放什么的問題
80%標記 - 縮放的度量和觸發(fā)器 - 解釋我們什么時候縮放的問題
管道 - 實現(xiàn)縮放的操作 - 解釋我們怎樣進行縮放的問題
在Kubernetes集群環(huán)境中，作為用戶我們一般會縮放兩個東西：
Pods - 對于某個應用，假設我們運行X個副本（replica），當請求超過X個Pods的處理量，我們就需要擴展應用。而為了使這一過程無縫工作，我們的Nodes應該由足夠的可用資源，以便成功調(diào)度并執(zhí)行這些額外的Pads；
Nodes - 所有Nodes的總?cè)萘看砦覀兊募喝萘?。如果工作負載需求超過該容量，我們就需要為集群增加節(jié)點，以確保有效調(diào)度和執(zhí)行工作負載。如果Pods不斷擴展，那么可能會出現(xiàn)節(jié)點可用資源即將耗盡的情況，我們不得不添加更多節(jié)點來增加集群級別可用的整體資源；
一般情況下，我們會連續(xù)測量某個度量，當度量超過閾值時，通過縮放某個資源來對其進行操作。例如，我們可能需要測量Pod的平均CPU消耗，然后在CPU消耗超過80％時觸發(fā)縮放操作。
但是一個度量標準不適合所有用例，對于不同類型的應用程序，度量標準可能會有所不同——對于消息隊列，處于等待狀態(tài)的消息數(shù)量可能會被作為度量標準；對于內(nèi)存密集型應用程序，內(nèi)存消耗作為指標可能會更合適。如果我們有一個業(yè)務應用，該應用每秒可處理給定容量窗格約1000個事務，那么我們可能就會選用這個指標，并在Pods達到850以上時進行擴展。
以上我們只考慮了擴展部分，但是當工作負載使用率下降時，應該有一種方法可以適度縮減，而不會中斷正在處理的現(xiàn)有請求。
對于Pods，只需更改replication中副本的數(shù)量就可以了；而對于Nodes，我們需要有辦法調(diào)用云計算服務商的API，創(chuàng)建一個新實例并將其作為集群的一部分。
基于以上理解，我們來看看Kubernetes Autoscaling的具體實現(xiàn)和技術(shù)——
Cluster Autoscaler（集群自動縮放器）用于動態(tài)縮放集群（Nodes），它的作用是持續(xù)監(jiān)控Pods，一旦發(fā)現(xiàn)Pods無法被schedule，則基于PodConditoin進行擴展。這種方式比查看集群中即誒單的CPU百分比要有效很多。由于Nodes創(chuàng)建需要一分鐘或更長時間（取決于云計算服務商等因素），因此Pods可能需要一些時間才能被Schedule。
在群集內(nèi)，我們可能有多個Nodes Pool，例如用于計費應用的Nodes Pool和用于機器學習工作負載的另一個Nodes Pool。Cluster Autoscaler提供各種標記和方法來調(diào)整Nodes縮放行為，更多詳情請查看https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md。
對于縮小（Scale down），Cluster Autoscaler會查看Nodes的平均利用率并參考其他相關因素，例如如果Pods（Pod disruption Budget）運行在無法重新調(diào)度的Node上，那么該Node無法從集群中移除。Custer Autoscaler提供了一種正常終止Nodes的方法，一般可以在10分鐘內(nèi)重新定位Pods。
HPA是一個控制循環(huán)，用于監(jiān)視和縮放部署中的Pods。這可以通過創(chuàng)建引用部署/reolication controller的HPA object來完成。 我們可以定義部署按比例調(diào)整的閾值及規(guī)模上下限。HPA最早版本GA（autoscaling/v1）僅支持CPU作為可監(jiān)控的度量標準。當前版本HPA處于測試階段（autoscaling/v2beta1）支持內(nèi)存和其他自定義指標。一旦創(chuàng)建了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進行一些調(diào)整：
利用Flags-horizontal-pod-autoscaler-sync-period確定hPa對于Pods組指標的監(jiān)控頻率。默認的周期為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，我們應該在群集中啟用并配置適當?shù)腸loud 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提出的一系列概念抽象，非常符合理想的分布式調(diào)度系統(tǒng)。但大量高難度技術(shù)概念，同時也形成了一條陡峭的學習曲線，直接拉高了Kubernetes的使用門檻。
除此之外，Kubernetes本身是一個容器編排工具，并不提供管理流程，而Rainbond提供現(xiàn)成的管理流程，包括DevOps、自動化運維、微服務架構(gòu)和應用市場等，可以開箱即用。
看完上述內(nèi)容，你們對Kubernetes Autoscaling是怎么工作的有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
重慶分公司
重慶分公司
