今天就跟大家聊聊有關Kubernetes Autoscaling是怎么工作的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

創新互聯基于成都重慶香港及美國等地區分布式IDC機房數據中心構建的電信大帶寬，聯通大帶寬，移動大帶寬，多線BGP大帶寬租用,是為眾多客戶提供專業BGP機房服務器托管報價，主機托管價格性價比高，為金融證券行業服務器托管，ai人工智能服務器托管提供bgp線路100M獨享，G口帶寬及機柜租用的專業成都idc公司。

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。

Horizontal 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的使用門檻。

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

看完上述內容，你們對Kubernetes Autoscaling是怎么工作的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注創新互聯行業資訊頻道，感謝大家的支持。

新聞標題：KubernetesAutoscaling是怎么工作的
文章來源：http://vcdvsql.cn/article44/pehjee.html

成都網站建設公司_創新互聯，為您提供營銷型網站建設、品牌網站制作、App開發、手機網站建設、網站維護、靜態網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯