Kubernetes高級(jí)進(jìn)階之彈性伸縮的困境與布局-創(chuàng)新互聯(lián)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 機(jī)器利用率不單純依靠宿主機(jī)計(jì)算

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(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í)需注明來源： 創(chuàng)新互聯(lián)