資訊專欄INFORMATION COLUMN
摘要：是如何工作的這是最近我們經(jīng)常被問到的一個問題。是一個控制循環(huán)，用于監(jiān)視和縮放部署中的。最早版本僅支持作為可監(jiān)控的度量標準。是版本以上的首選方法。
Kubernetes Autoscaling是如何工作的？這是最近我們經(jīng)常被問到的一個問題。
所以本文將從Kubernetes Autoscaling功能的工作原理以及縮放集群時可以提供的優(yōu)勢等方面進行解釋。
什么是Autoscaling想象用水龍頭向2個水桶里裝水，我們要確保水在裝滿第一個水桶的80%時，開始注入第二個水桶。解決方法很簡單，只要在適當?shù)奈恢迷趦蓚€水桶間裝置管道連接即可。而當我們想要擴大裝水量，我們只需要用這種辦法增加水桶即可。
同樣的道理放在我們的應用或者服務上，云計算的彈性伸縮功能可以讓我們從手動調(diào)節(jié)物理服務器/虛擬機之中解放出來。那么把“水桶裝水”和“應用消耗計算資源”相比較——
水桶 - 縮放單位 - 解釋我們縮放什么的問題
80%標記 - 縮放的度量和觸發(fā)器 - 解釋我們什么時候縮放的問題
管道 - 實現(xiàn)縮放的操作 - 解釋我們怎樣進行縮放的問題
我們縮放什么？在Kubernetes集群環(huán)境中，作為用戶我們一般會縮放兩個東西：
Pods - 對于某個應用，假設(shè)我們運行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基于以上理解，我們來看看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...。
對于縮?。⊿cale down），Cluster Autoscaler會查看Nodes的平均利用率并參考其他相關(guān)因素，例如如果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...）的同時，啟用Heapster或啟用API aggregation。API metrics server是Kubernetes1.9版本以上的首選方法。對于配置Nodes，我們應該在群集中啟用并配置適當?shù)腸loud provider，更多詳情查看https://kubernetes.io/docs/co...。
一些插件還有一些很不錯的插件，比如——
Vertical pod autoscaler https://github.com/kubernetes...
addon-resizer https://github.com/kubernetes...
總而言之，下次再遇到有人問“Kubernetes Autoscaling是如何工作的”？希望這篇短文能對大家的解釋有所幫助。
Kubernetes提出的一系列概念抽象，非常符合理想的分布式調(diào)度系統(tǒng)。但大量高難度技術(shù)概念，同時也形成了一條陡峭的學習曲線，直接拉高了Kubernetes的使用門檻。
好雨云開源PaaS Rainbond則將這些技術(shù)概念包裝成為“Production-Ready”的應用，可以作為一個Kubernetes面板，開發(fā)者不需要特殊學習即可使用。包括本文中的彈性伸縮，Rainbond支持用戶進行水平伸縮和垂直伸縮：）
除此之外，Kubernetes本身是一個容器編排工具，并不提供管理流程，而Rainbond提供現(xiàn)成的管理流程，包括DevOps、自動化運維、微服務架構(gòu)和應用市場等，可以開箱即用。
進一步了解：https://www.goodrain.com/scen...
Rainbond Github：https://github.com/goodrain/r...
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/32655.html
摘要：如版本之前版本到版本之間版本之后一各種的含義該軟件可能包含錯誤。啟用一個功能可能會導致隨時可能會丟棄對該功能的支持，恕不另行通知軟件經(jīng)過很好的測試。啟用功能被認為是安全的。 本篇文章來自Terraform與Kubernetes中關(guān)于Deployment apps/v1的吐槽 Kubernetes的官方文檔中并沒有對apiVersion的詳細解釋，而且因為K8S本身版本也在快速迭代，有些...
摘要：借助能夠?qū)崿F(xiàn)無人值守的上線部署。三自動化集群管理在同一個平臺上實現(xiàn)區(qū)域擴展。使集群中的很容易的發(fā)布到公網(wǎng)。支持自定義的的指標通過中的實現(xiàn)，支持自定義模板，目前為版，支持根據(jù)用戶自定義的閾值對應用進行自動伸縮。 Kubernetes 1.2版本剛剛發(fā)布就給docker生態(tài)圈帶來不小的震撼，1.2版本的新特點（相對于v1.1.1）： 一、集群規(guī)模顯著增加集群規(guī)模增加了400%達到了1，00...
摘要：標識是與操作對象間的紐帶。集群為每個對象維護三類信息對象元數(shù)據(jù)期望狀態(tài)與實際狀態(tài)元數(shù)據(jù)指對象的基本信息，比如命名標簽注釋等等，用于識別對象期望狀態(tài)一般由用戶配置來描述的實際狀態(tài)是由集群各個組件上報的集群實際的運行情況。 綜述 學習Kubernetes時，發(fā)現(xiàn)它的概念和術(shù)語還是比較多的，光靠啃官方文檔比較晦澀。所以邊學習邊整理，對主要的概念和術(shù)語做一下分類及簡要說明。感覺把重要概念都理解...
摘要：自定義指標由提供，由此可支持任意采集到的指標。文件清單的，收集級別的監(jiān)控數(shù)據(jù)監(jiān)控服務端，從拉數(shù)據(jù)并存儲為時序數(shù)據(jù)。本文為容器監(jiān)控實踐系列文章，完整內(nèi)容見 概述 上文metric-server提到，kubernetes的監(jiān)控指標分為兩種： Core metrics(核心指標)：從 Kubelet、cAdvisor 等獲取度量數(shù)據(jù)，再由metrics-server提供給 Dashboar...
摘要：自定義指標由提供，由此可支持任意采集到的指標。文件清單的，收集級別的監(jiān)控數(shù)據(jù)監(jiān)控服務端，從拉數(shù)據(jù)并存儲為時序數(shù)據(jù)。本文為容器監(jiān)控實踐系列文章，完整內(nèi)容見 概述 上文metric-server提到，kubernetes的監(jiān)控指標分為兩種： Core metrics(核心指標)：從 Kubelet、cAdvisor 等獲取度量數(shù)據(jù)，再由metrics-server提供給 Dashboar...
閱讀 637·2023-04-26 01:53
閱讀 2762·2021-11-17 17:00
閱讀 2897·2021-09-04 16:40
閱讀 1999·2021-09-02 15:41
閱讀 848·2019-08-26 11:34
閱讀 1236·2019-08-26 10:16
閱讀 1344·2019-08-23 17:51
閱讀 834·2019-08-23 16:50
