**Kubernetes彈性伸縮的困境與布局**

目錄：
 2.1 傳統(tǒng)彈性伸縮的困境
            1、kubernetes中彈性伸縮存在的問題
            2、彈性伸縮概念的延伸
  2.2 kubernetes 彈性伸縮布局

2.1 傳統(tǒng)伸縮的困境
從傳統(tǒng)意義上，彈性伸縮主要解決的問題是容量規(guī)劃與實際負(fù)載的矛盾

創(chuàng)新互聯(lián)服務(wù)項目包括潮南網(wǎng)站建設(shè)、潮南網(wǎng)站制作、潮南網(wǎng)頁制作以及潮南網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，潮南網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到潮南省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

藍(lán)色水位線表示集群資源容量隨著負(fù)載的增加不斷擴容，紅色曲線表示集群資源實際負(fù)載變化。
彈性伸縮就是要解決當(dāng)實際負(fù)載增加，而集群資源容量沒來得及反應(yīng)的問題。

傳統(tǒng)的理解，比如有幾臺web服務(wù)器，負(fù)載高了加機器，然后負(fù)載下去減機器

傳統(tǒng)的彈性伸縮和k8s的彈性伸縮有什么區(qū)別？

從傳統(tǒng)意義上來說，其實k8s的彈性伸縮也是大家比較關(guān)注的一個話題，但是考慮起k8s上的彈性伸縮就不得不從傳統(tǒng)的彈性伸縮談起，看看傳統(tǒng)伸縮和k8s的彈性伸縮有什么不同之處，從傳統(tǒng)來將解決的問題是容量規(guī)劃與實際負(fù)載的矛盾，為什么這么講，從上面這張圖可以看出藍(lán)色的是可用資源，紅色的是實際負(fù)載，藍(lán)色的是好比就是集群池，好比是一個web，這里有4臺服務(wù)器，容量都是4c8g,一共十16c,32g,這樣的一個容量，那么比如雙十一來了，那么你的負(fù)載高了，那么可能需要18c,36g這樣的一個負(fù)載，那么這個本身的這個資源池肯定是不夠用的了，超出了可用的范圍，這就是實際負(fù)載，這個時候我們就得擴容，考慮的是趕緊擴容機器，再擴容一臺，或者更多，來應(yīng)對實際的負(fù)載，其實彈性伸縮就是這么來的，當(dāng)出現(xiàn)資源利用率的觸發(fā)時，能夠快速的響應(yīng)快速的擴容，在傳統(tǒng)的這樣的一個方式下可能會有點慢，就是還沒來的及反應(yīng)呢，就已經(jīng)超出你的負(fù)載了，因為實際負(fù)載面對一些活動的時候，都是一些比較快的突發(fā)事件，你沒有做好任何準(zhǔn)備，或者一個惡意的***一下超過你的負(fù)載，說為什么矛盾，其實就是可用資源和實際負(fù)載之間，關(guān)鍵的挑戰(zhàn)其實就在這，能不能快速的彈出，快速的回收，就是這個資源池能不能快速的放大，能不能在低峰期收來降低成本，這是我們考慮的，但是這個做好的確還是很難的，所以從之前考慮的彈性伸縮，能不能快速的彈出，目前就是提前增加服務(wù)器，沒有一些好的辦法，所以就是解決這個矛盾，像一些快速的流量能不能響應(yīng)起來。

如果已知的活動，那么提前擴容這個服務(wù)器，基本都是這么來的，包括雙十一了，淘寶京東都是，像阿里，他們本身就有一個龐大的資源池，他們雙十一會將他們大量的業(yè)務(wù)，都會放在這個池子里，并且預(yù)留很多的資源，然后給這個集群去使用，像我們一般都是提前去加服務(wù)器，包括云上也是。

其實放在k8s中也不是解決這個矛盾，彈性伸縮就是解決容量規(guī)劃與實際負(fù)載的矛盾，但真正的沒有快速的彈出快速的回收，但是彈性伸縮還是停留在至此，但是有了k8s之后，在k8s與這種傳統(tǒng)的又有一種區(qū)別了，沒有特別好的方案去解決，現(xiàn)在呢在k8s也能按原來的思路去走，具有有兩方面的考慮，之前的彈性伸縮是基于什么樣的方式去擴展呢？如果放我們傳統(tǒng)的資源池已經(jīng)超出我們原本的容量，怎么判斷要自動的加機器呢，即使彈出的時間比較慢，也得做這個事，不可能說有效的去響應(yīng)這個資源池，那就不去彈出，那么還是有個策略，這個策略是怎么做的，根據(jù)怎么樣的預(yù)值去做，一般就是根據(jù)cpu和內(nèi)存，一般都是根據(jù)這些去做云主機的彈性伸縮，除了這些也沒有什么好方法，像公有云aws,像阿里云也都是這種形式，就是你設(shè)置一個預(yù)值，如果整體的資源超出了這個預(yù)值，就加機器，但是一般服務(wù)器都有一定的預(yù)留，一般也不會一下都把它打滿了，除非有一些異常的***，大多數(shù)情況下這個集群池都有一些預(yù)留，根據(jù)之前訪問的一個趨勢，做一個20%和30%的預(yù)留，給你一個緩沖的時間，一下來個20%的訪問量就打垮了，這樣也不太行，所以增加這些預(yù)留，要保證集群的可用性。

在k8s中去這種傳統(tǒng)的部署就是基于cpu利用率的百分比來講，可能就不太現(xiàn)實。

1、Kubernetes中彈性伸縮存在的問題

常規(guī)的做法是給集群資源預(yù)留保障集群可用，通常20%左右。這種方式看似沒什么問題，但放到Kubernetes中，就會發(fā)現(xiàn)如下2個問題。

1. 機器規(guī)格不統(tǒng)一造成機器利用率百分比碎片化
   在一個Kubernetes集群中，通常不只包含一種規(guī)格的機器，假設(shè)集群中存在4C8G與16C32G兩種規(guī)格的機器，對于10%的資源預(yù)留，這兩種規(guī)格代表的意義是完全不同的。
   
   像一些傳統(tǒng)的web,服務(wù)器的規(guī)格基本都是一樣的，一般使用輪詢，很少去用最小連接數(shù)，輪訓(xùn)的話，要是規(guī)格不一樣，服務(wù)器就是浪費，有一臺是4核8g,有一臺是16核32g,要是輪詢的大的那一個就是在浪費錢，基本在權(quán)重值都一樣。

要是上云的話，基本上配置都是統(tǒng)一的，擴容也是，像idc可能會有一些規(guī)格不一樣的，為了把這些資源都利用上，但是在k8s中，加的這些機器沒必要統(tǒng)一，甚至拿一些高配的服務(wù)器堆起來一個k8s機器，因為k8s本身就是給你拿一個大的資源池來用了，也就是邏輯上將他們作為一個資源池來用了，k8s統(tǒng)一的去調(diào)度，他會判斷這個資源能不能去調(diào)度，根據(jù)你這個實際的利用率，而不是根據(jù)輪詢來了，這樣的話，就會保證你每個節(jié)點，你的利用率都是比較高的，所以這就是一個大的資源池，所以不同規(guī)格的機器來說，都沒有太大的影響，但是對于彈性伸縮來說，它就有影響。

比如有三臺服務(wù)器，一個4c 8g , 一個16c 64g.,一個8c 16g,要是你還是基于之前的cpu,內(nèi)存的方式去彈性伸縮，說白了就是擴容，縮容，
比如都是利用率都是80%,這肯定是不一樣的，因為規(guī)格的不同，它的百分比也不同，要是按這種的node的擴容，這顯然也是不行的，
行是可以，按照縮容來說，有三臺機器，負(fù)載下來了，所以說要評估出哪個節(jié)點，再找空閑的節(jié)點去縮容，正好這三臺機器都空閑一點，判斷的肯定是以cpu和內(nèi)存，如果都是80%,縮小的是配置低的，那么縮容沒有太多的意義了，但是你縮容大規(guī)格的，那可能會導(dǎo)致，我一下很縮容很大，整體的集群利用率就會下降很多，所以就面對這些問題，也主要是縮容面對的問題。

特別是在縮容的場景下，為了保證縮容后集群穩(wěn)定性，我們一般會一個節(jié)點一個節(jié)點從集群中摘除，那么如何判斷節(jié)點是否可以摘除其利用率百分比就是重要的指標(biāo)。此時如果大規(guī)則機器有較低的利用率被判斷縮容，那么很有可能會造成節(jié)點縮容后，容器重新調(diào)度后的爭搶。如果優(yōu)先縮容小規(guī)則機器，則可能造成縮容后資源的大量冗余。

2. 機器利用率不單純依靠宿主機計算

在大部分生產(chǎn)環(huán)境中，資源利用率都不會保持一個高的水位，但從調(diào)度來講，調(diào)度應(yīng)該保持一個比較高的水位，這樣才能保障集群穩(wěn)定性，又不過多浪費資源。
像k8s申請規(guī)格的話，一般就根據(jù)兩點，第一個就是request,項目參考的預(yù)值，第二個就是limit的大資源的限制，一般縮容擴容會根據(jù)request去考慮，比如申請的規(guī)格是2c2g,那么縮容肯定要考慮pod的，申請多少的規(guī)格就要預(yù)留這些規(guī)格，并不是我申請了2c2g,但是我沒考慮什么負(fù)載，那么不可能說我縮容的時候把這個考慮在內(nèi)，我就按實際的負(fù)載來算，肯定不行，我要算這個集群中2c2g來算，集群資源部單純靠宿主機來算，一共兩個維度，一個pod，一個request，就好比之前單純看節(jié)點增加了一個維度，所以做這個彈性伸縮就要把這個考慮進(jìn)去，并不是說我申請了request2c2g,用不到2c2g，去伸縮的時候，你要把它按實際的負(fù)載用，那到時候你縮容之后，萬一你申請的request的資源利用率上來了，那么你剩余的節(jié)點上是不是不夠了，到時候會造成pod的爭搶，再爭搶你增加節(jié)點的時候會受一定影響，所以這就是第二個存在的問題

怎么解決這些問題？
第一個就是機器規(guī)格不統(tǒng)一利用率的百分比，其實最好的形式就是，就從概念去看，把配置做成一樣，但是這種情況不太現(xiàn)實，，因為公司采購的服務(wù)器，包括遺留的這些機器，都是為了合理利用上，來做這個集群池，但是你拿一些新的機器可以將這些都搞成一樣的，但是規(guī)格不一樣就不太行了。

第二個就是機器部單純依靠宿主機計算，這一塊考慮縮容，即使要參考node的利用率，還要參考整個集群中pod請求的request,必須把request這個規(guī)格實際的負(fù)載計算進(jìn)去，不能按實際的負(fù)載，這些呢都是一些手段了。

現(xiàn)在一般來說都是一些成本的節(jié)省和可用之間的矛盾，既然業(yè)務(wù)已經(jīng)多元化了，解決這個問題就可以將這些業(yè)務(wù)進(jìn)行分類

2、彈性伸縮概念的延伸
不是所有的業(yè)務(wù)都存在峰值流量，越來越細(xì)分的業(yè)務(wù)形態(tài)帶來更多成本節(jié)省和可用性之間的跳轉(zhuǎn)。

1. 在線負(fù)載型：微服務(wù)、網(wǎng)站、API
2. 離線任務(wù)型：離線計算、機器學(xué)習(xí)
3. 定時任務(wù)型：定時批量計算
   不同類型的負(fù)載對于彈性伸縮的要求有所不同，在線負(fù)載對彈出時間敏感，離線任務(wù)對價格敏感，定時任務(wù)對調(diào)度敏感。

像傳統(tǒng)的負(fù)載型的就可以使用這個在線負(fù)載型的，然后就是離線型的，離線計算，機器學(xué)習(xí)，這些都是周期性的，可能定時性的并不是實時在線的，這一類比較關(guān)心的是，比較敏感，這一類的就是當(dāng)我工作的時候消耗是比較多的，比在線負(fù)載型的消耗真的很多，比如大數(shù)據(jù)的處理，機器的學(xué)習(xí)，這一塊呢就是某一刻的時間比較高，所以要考慮這個成本，所以不能說，它都是離線任務(wù)，偶爾大，然后機器又是峰值的配值規(guī)格，那種價格規(guī)格會高很多，第三種就是這種定時任務(wù)型的，定時批量計算，比如調(diào)度了，定時的去做一些事了，然后備份了這一塊了，這一塊可能對調(diào)度比較敏感一些，然后任務(wù)比較多的時候，會有一個全局調(diào)度系統(tǒng)，然后調(diào)度的去分配，所以它對調(diào)度比較敏感一些，所以彈性伸縮的概念延伸到了業(yè)務(wù)去合理的區(qū)分，比如在線負(fù)載型的考慮的是還是按之前的那種方式，考慮彈出時間的，就是擴容的敏感，像微服務(wù)，網(wǎng)站，API，如果負(fù)載比較到的話，能不能增加機器，離線任務(wù)就是對某一刻時間段的敏感，能不能用的時候提供足夠的資源，不用的時候能不能回收掉，讓其他的資源去用，這樣的話，就可以去省一些開銷，定時任務(wù)的也是。

接下來就是怎么在k8s中去布局，這就是我們?nèi)タ紤]的了，不能按照宿主機的利用率了，多了一個維度，所以在k8s的生態(tài)中，針對上面不同形態(tài)的業(yè)務(wù)，彈性伸縮的形式也有很多的組件，以及各種各樣的場景
大致分為了三種彈性伸縮

2.2 kubernetes 彈性伸縮布局
在 Kubernetes 的生態(tài)中，在多個維度、多個層次提供了不同的組件來滿足不同的伸縮場景。
有三種彈性伸縮：

?   CA（Cluster Autoscaler）：Node級別自動擴/縮容
cluster-autoscaler組件
?   HPA（Horizontal Pod Autoscaler）：Pod個數(shù)自動擴/縮容
?   VPA（Vertical Pod Autoscaler）：橫向擴容，Pod配置自動擴/縮容，主要是CPU、內(nèi)存
addon-resizer組件

如果在云上建議 HPA 結(jié)合 cluster-autoscaler 的方式進(jìn)行集群的彈性伸縮管理。

就像創(chuàng)建新的pod,一個等待狀態(tài)，就不會去給你調(diào)度了，資源沒給你調(diào)度，pod如果超出request的規(guī)格，而且我的資源池，是不是穩(wěn)定，就像在線負(fù)載型的，就是能允許等待時間增加新的節(jié)點，所以request在限制的情況下，如果request都打滿，但是這個集群已經(jīng)不能分配新的pod了，這個集群還是穩(wěn)定狀態(tài)，因為它還有一個大的限制limit如果超出這個限制的話這個集群就會出現(xiàn)不穩(wěn)定的狀態(tài)，那么就需要去擴容node節(jié)點了，所以node就提供了這種自動的擴容，提供了這個組件，CA （cluster autoscaler）來實現(xiàn)node級別的自動擴縮容，這個組件目前主要對接的是公有云，比如阿里云，微軟云,aws之類的他們的組件，你可以實現(xiàn)，調(diào)度他們的云主機，來實現(xiàn)自己的擴容縮容，當(dāng)然也可以自己去研究類似得組件，來實現(xiàn)自動的擴容縮容，第二種就是基于這個pod的，其實它主要是針對你現(xiàn)有的資源池的，如果你現(xiàn)有的資源池是比較充裕的，那么我再調(diào)度新的pod，是沒問題的，也能去調(diào)度出來，也就是本身你的應(yīng)用10個副本，即使request跑滿，10個并發(fā)是1萬，現(xiàn)在的負(fù)載不夠了，現(xiàn)在要擴容副本，擴容20個副本那么我的并發(fā)就是2萬了，但我集群池的資源夠，所以就能應(yīng)對我現(xiàn)在的業(yè)務(wù)的負(fù)載，所以在針對k8s的擴容的時候，一般將就針對兩個維度進(jìn)行擴容縮容，一個就是node,一個就是pod,然后第三個維度，這個不經(jīng)常用，上面兩個都是按水平進(jìn)行考量的，第三個是pod的橫向擴展，橫向是指limit這個規(guī)格，幫你加這個配額，目前這個還比較少，目前就是node和pod的這個用的比較多，如果在云上建議 HPA 結(jié)合 cluster-autoscaler 的方式進(jìn)行集群的彈性伸縮管理。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前文章：Kubernetes高級進(jìn)階之彈性伸縮的困境與布局-創(chuàng)新互聯(lián)
轉(zhuǎn)載注明：http://jinyejixie.com/article34/ceshpe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、軟件開發(fā)、品牌網(wǎng)站設(shè)計、標(biāo)簽優(yōu)化、小程序開發(fā)、App設(shè)計

廣告

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