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

創(chuàng)新互聯(lián)基于成都重慶香港及美國(guó)等地區(qū)分布式IDC機(jī)房數(shù)據(jù)中心構(gòu)建的電信大帶寬，聯(lián)通大帶寬，移動(dòng)大帶寬，多線BGP大帶寬租用,是為眾多客戶(hù)提供專(zhuān)業(yè)BGP機(jī)房服務(wù)器托管報(bào)價(jià)，主機(jī)托管價(jià)格性?xún)r(jià)比高，為金融證券行業(yè)服務(wù)器托管，ai人工智能服務(wù)器托管提供bgp線路100M獨(dú)享，G口帶寬及機(jī)柜租用的專(zhuān)業(yè)成都idc公司。

Kubernetes Autoscaling是如何工作的？這是最近我們經(jīng)常被問(wèn)到的一個(gè)問(wèn)題。

下面將從Kubernetes Autoscaling功能的工作原理以及縮放集群時(shí)可以提供的優(yōu)勢(shì)等方面進(jìn)行解釋。

什么是Autoscaling

想象用水龍頭向2個(gè)水桶里裝水，我們要確保水在裝滿第一個(gè)水桶的80%時(shí)，開(kāi)始注入第二個(gè)水桶。解決方法很簡(jiǎn)單，只要在適當(dāng)?shù)奈恢迷趦蓚€(gè)水桶間裝置管道連接即可。而當(dāng)我們想要擴(kuò)大裝水量，我們只需要用這種辦法增加水桶即可。

同樣的道理放在我們的應(yīng)用或者服務(wù)上，云計(jì)算的彈性伸縮功能可以讓我們從手動(dòng)調(diào)節(jié)物理服務(wù)器/虛擬機(jī)之中解放出來(lái)。那么把“水桶裝水”和“應(yīng)用消耗計(jì)算資源”相比較——

• 水桶 - 縮放單位 - 解釋我們縮放什么的問(wèn)題

• 80%標(biāo)記 - 縮放的度量和觸發(fā)器 - 解釋我們什么時(shí)候縮放的問(wèn)題

• 管道 - 實(shí)現(xiàn)縮放的操作 - 解釋我們?cè)鯓舆M(jìn)行縮放的問(wèn)題

我們縮放什么？

在Kubernetes集群環(huán)境中，作為用戶(hù)我們一般會(huì)縮放兩個(gè)東西：

Pods - 對(duì)于某個(gè)應(yīng)用，假設(shè)我們運(yùn)行X個(gè)副本（replica），當(dāng)請(qǐng)求超過(guò)X個(gè)Pods的處理量，我們就需要擴(kuò)展應(yīng)用。而為了使這一過(guò)程無(wú)縫工作，我們的Nodes應(yīng)該由足夠的可用資源，以便成功調(diào)度并執(zhí)行這些額外的Pads；

Nodes - 所有Nodes的總?cè)萘看砦覀兊募喝萘俊Ｈ绻ぷ髫?fù)載需求超過(guò)該容量，我們就需要為集群增加節(jié)點(diǎn)，以確保有效調(diào)度和執(zhí)行工作負(fù)載。如果Pods不斷擴(kuò)展，那么可能會(huì)出現(xiàn)節(jié)點(diǎn)可用資源即將耗盡的情況，我們不得不添加更多節(jié)點(diǎn)來(lái)增加集群級(jí)別可用的整體資源；

什么時(shí)候縮放？

一般情況下，我們會(huì)連續(xù)測(cè)量某個(gè)度量，當(dāng)度量超過(guò)閾值時(shí)，通過(guò)縮放某個(gè)資源來(lái)對(duì)其進(jìn)行操作。例如，我們可能需要測(cè)量Pod的平均CPU消耗，然后在CPU消耗超過(guò)80％時(shí)觸發(fā)縮放操作。

但是一個(gè)度量標(biāo)準(zhǔn)不適合所有用例，對(duì)于不同類(lèi)型的應(yīng)用程序，度量標(biāo)準(zhǔn)可能會(huì)有所不同——對(duì)于消息隊(duì)列，處于等待狀態(tài)的消息數(shù)量可能會(huì)被作為度量標(biāo)準(zhǔn)；對(duì)于內(nèi)存密集型應(yīng)用程序，內(nèi)存消耗作為指標(biāo)可能會(huì)更合適。如果我們有一個(gè)業(yè)務(wù)應(yīng)用，該應(yīng)用每秒可處理給定容量窗格約1000個(gè)事務(wù)，那么我們可能就會(huì)選用這個(gè)指標(biāo)，并在Pods達(dá)到850以上時(shí)進(jìn)行擴(kuò)展。

以上我們只考慮了擴(kuò)展部分，但是當(dāng)工作負(fù)載使用率下降時(shí)，應(yīng)該有一種方法可以適度縮減，而不會(huì)中斷正在處理的現(xiàn)有請(qǐng)求。

怎樣進(jìn)行縮放？

對(duì)于Pods，只需更改replication中副本的數(shù)量就可以了；而對(duì)于Nodes，我們需要有辦法調(diào)用云計(jì)算服務(wù)商的API，創(chuàng)建一個(gè)新實(shí)例并將其作為集群的一部分。

Kubernetes Autoscaling

基于以上理解，我們來(lái)看看Kubernetes Autoscaling的具體實(shí)現(xiàn)和技術(shù)——

Cluster Autoscaler

Cluster Autoscaler（集群自動(dòng)縮放器）用于動(dòng)態(tài)縮放集群（Nodes），它的作用是持續(xù)監(jiān)控Pods，一旦發(fā)現(xiàn)Pods無(wú)法被schedule，則基于PodConditoin進(jìn)行擴(kuò)展。這種方式比查看集群中即誒單的CPU百分比要有效很多。由于Nodes創(chuàng)建需要一分鐘或更長(zhǎng)時(shí)間（取決于云計(jì)算服務(wù)商等因素），因此Pods可能需要一些時(shí)間才能被Schedule。

在群集內(nèi)，我們可能有多個(gè)Nodes Pool，例如用于計(jì)費(fèi)應(yīng)用的Nodes Pool和用于機(jī)器學(xué)習(xí)工作負(fù)載的另一個(gè)Nodes Pool。Cluster Autoscaler提供各種標(biāo)記和方法來(lái)調(diào)整Nodes縮放行為，更多詳情請(qǐng)查看https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md。

對(duì)于縮?。⊿cale down），Cluster Autoscaler會(huì)查看Nodes的平均利用率并參考其他相關(guān)因素，例如如果Pods（Pod disruption Budget）運(yùn)行在無(wú)法重新調(diào)度的Node上，那么該Node無(wú)法從集群中移除。Custer Autoscaler提供了一種正常終止Nodes的方法，一般可以在10分鐘內(nèi)重新定位Pods。

Horizontal Pod Autoscaler（HPA）

HPA是一個(gè)控制循環(huán)，用于監(jiān)視和縮放部署中的Pods。這可以通過(guò)創(chuàng)建引用部署/reolication controller的HPA object來(lái)完成。 我們可以定義部署按比例調(diào)整的閾值及規(guī)模上下限。HPA最早版本GA（autoscaling/v1）僅支持CPU作為可監(jiān)控的度量標(biāo)準(zhǔn)。當(dāng)前版本HPA處于測(cè)試階段（autoscaling/v2beta1）支持內(nèi)存和其他自定義指標(biāo)。一旦創(chuàng)建了HPA object并且它能夠查詢(xún)?cè)摯案竦闹笜?biāo)，就可以看到它報(bào)告了詳細(xì)信息：

$ kubectl get hpa
NAME               REFERENCE                     TARGETS  MINPODS MAXPODS REPLICAS AGE
helloetst-ownay28d Deployment/helloetst-ownay28d 8% / 60% 1       4       1        23h

我們可以通過(guò)為Controller Manager添加Flags來(lái)對(duì)水平Pod Autoscaler進(jìn)行一些調(diào)整：

• 利用Flags-horizontal-pod-autoscaler-sync-period確定hPa對(duì)于Pods組指標(biāo)的監(jiān)控頻率。默認(rèn)的周期為30秒。

• 兩次擴(kuò)展操作之間的默認(rèn)間隔為3分鐘，可以Flags來(lái)控制-horizontal-pod-autoscaler-upscale-delay

• 兩個(gè)縮小操作之間的默認(rèn)間隔為5分鐘，同樣可以通過(guò)Flags來(lái)控制-horizontal-pod-autoscaler-downscale-delay

指標(biāo)和云提供商

為了衡量指標(biāo)，服務(wù)器應(yīng)該在啟用Kubernetes自定義指標(biāo)（https://github.com/kubernetes/metrics）的同時(shí)，啟用Heapster或啟用API aggregation。API metrics server是Kubernetes1.9版本以上的首選方法。對(duì)于配置Nodes，我們應(yīng)該在群集中啟用并配置適當(dāng)?shù)腸loud provider，更多詳情查看https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/。

一些插件

還有一些很不錯(cuò)的插件，比如——

• Vertical pod autoscaler https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

• addon-resizer https://github.com/kubernetes/autoscaler/tree/master/addon-resizer

總而言之，下次再遇到有人問(wèn)“Kubernetes Autoscaling是如何工作的”？希望這篇短文能對(duì)大家的解釋有所幫助。

Kubernetes提出的一系列概念抽象，非常符合理想的分布式調(diào)度系統(tǒng)。但大量高難度技術(shù)概念，同時(shí)也形成了一條陡峭的學(xué)習(xí)曲線，直接拉高了Kubernetes的使用門(mén)檻。

除此之外，Kubernetes本身是一個(gè)容器編排工具，并不提供管理流程，而Rainbond提供現(xiàn)成的管理流程，包括DevOps、自動(dòng)化運(yùn)維、微服務(wù)架構(gòu)和應(yīng)用市場(chǎng)等，可以開(kāi)箱即用。

看完上述內(nèi)容，你們對(duì)Kubernetes Autoscaling是怎么工作的有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

新聞標(biāo)題：KubernetesAutoscaling是怎么工作的
文章來(lái)源：http://www.yijiale78.com/article44/pehjee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營(yíng)銷(xiāo)型網(wǎng)站建設(shè)、品牌網(wǎng)站制作、App開(kāi)發(fā)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站維護(hù)、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)