摘要:是如何工作的這是最近我們經常被問到的一個問題。是一個控制循環,用于監視和縮放部署中的。最早版本僅支持作為可監控的度量標準。是版本以上的首選方法。
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(集群自動縮放器)用于動態縮放集群(Nodes),它的作用是持續監控Pods,一旦發現Pods無法被schedule,則基于PodConditoin進行擴展。這種方式比查看集群中即誒單的CPU百分比要有效很多。由于Nodes創建需要一分鐘或更長時間(取決于云計算服務商等因素),因此Pods可能需要一些時間才能被Schedule。
在群集內,我們可能有多個Nodes Pool,例如用于計費應用的Nodes Pool和用于機器學習工作負載的另一個Nodes Pool。Cluster Autoscaler提供各種標記和方法來調整Nodes縮放行為,更多詳情請查看https://github.com/kubernetes...。
對于縮小(Scale down),Cluster Autoscaler會查看Nodes的平均利用率并參考其他相關因素,例如如果Pods(Pod disruption Budget)運行在無法重新調度的Node上,那么該Node無法從集群中移除。Custer Autoscaler提供了一種正常終止Nodes的方法,一般可以在10分鐘內重新定位Pods。
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...)的同時,啟用Heapster或啟用API aggregation。API metrics server是Kubernetes1.9版本以上的首選方法。對于配置Nodes,我們應該在群集中啟用并配置適當的cloud provider,更多詳情查看https://kubernetes.io/docs/co...。
一些插件還有一些很不錯的插件,比如——
Vertical pod autoscaler https://github.com/kubernetes...
addon-resizer https://github.com/kubernetes...
總而言之,下次再遇到有人問“Kubernetes Autoscaling是如何工作的”?希望這篇短文能對大家的解釋有所幫助。
Kubernetes提出的一系列概念抽象,非常符合理想的分布式調度系統。但大量高難度技術概念,同時也形成了一條陡峭的學習曲線,直接拉高了Kubernetes的使用門檻。
好雨云開源PaaS Rainbond則將這些技術概念包裝成為“Production-Ready”的應用,可以作為一個Kubernetes面板,開發者不需要特殊學習即可使用。包括本文中的彈性伸縮,Rainbond支持用戶進行水平伸縮和垂直伸縮:)
除此之外,Kubernetes本身是一個容器編排工具,并不提供管理流程,而Rainbond提供現成的管理流程,包括DevOps、自動化運維、微服務架構和應用市場等,可以開箱即用。
進一步了解:https://www.goodrain.com/scen...
Rainbond Github:https://github.com/goodrain/r...
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/32655.html
摘要:如版本之前版本到版本之間版本之后一各種的含義該軟件可能包含錯誤。啟用一個功能可能會導致隨時可能會丟棄對該功能的支持,恕不另行通知軟件經過很好的測試。啟用功能被認為是安全的。 本篇文章來自Terraform與Kubernetes中關于Deployment apps/v1的吐槽 Kubernetes的官方文檔中并沒有對apiVersion的詳細解釋,而且因為K8S本身版本也在快速迭代,有些...
摘要:借助能夠實現無人值守的上線部署。三自動化集群管理在同一個平臺上實現區域擴展。使集群中的很容易的發布到公網。支持自定義的的指標通過中的實現,支持自定義模板,目前為版,支持根據用戶自定義的閾值對應用進行自動伸縮。 Kubernetes 1.2版本剛剛發布就給docker生態圈帶來不小的震撼,1.2版本的新特點(相對于v1.1.1): 一、集群規模顯著增加集群規模增加了400%達到了1,00...
摘要:標識是與操作對象間的紐帶。集群為每個對象維護三類信息對象元數據期望狀態與實際狀態元數據指對象的基本信息,比如命名標簽注釋等等,用于識別對象期望狀態一般由用戶配置來描述的實際狀態是由集群各個組件上報的集群實際的運行情況。 綜述 學習Kubernetes時,發現它的概念和術語還是比較多的,光靠啃官方文檔比較晦澀。所以邊學習邊整理,對主要的概念和術語做一下分類及簡要說明。感覺把重要概念都理解...
摘要:自定義指標由提供,由此可支持任意采集到的指標。文件清單的,收集級別的監控數據監控服務端,從拉數據并存儲為時序數據。本文為容器監控實踐系列文章,完整內容見 概述 上文metric-server提到,kubernetes的監控指標分為兩種: Core metrics(核心指標):從 Kubelet、cAdvisor 等獲取度量數據,再由metrics-server提供給 Dashboar...
摘要:自定義指標由提供,由此可支持任意采集到的指標。文件清單的,收集級別的監控數據監控服務端,從拉數據并存儲為時序數據。本文為容器監控實踐系列文章,完整內容見 概述 上文metric-server提到,kubernetes的監控指標分為兩種: Core metrics(核心指標):從 Kubelet、cAdvisor 等獲取度量數據,再由metrics-server提供給 Dashboar...
閱讀 623·2023-04-26 01:53
閱讀 2749·2021-11-17 17:00
閱讀 2880·2021-09-04 16:40
閱讀 1983·2021-09-02 15:41
閱讀 830·2019-08-26 11:34
閱讀 1222·2019-08-26 10:16
閱讀 1335·2019-08-23 17:51
閱讀 815·2019-08-23 16:50