Kubernetes彈性伸縮全場(chǎng)景中如何解析概念延伸與組件布局

Kubernetes彈性伸縮全場(chǎng)景中如何解析概念延伸與組件布局，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

傳統(tǒng)彈性伸縮的困境

彈性伸縮是 Kubernetes 中被大家關(guān)注的一大亮點(diǎn)，在討論相關(guān)的組件和實(shí)現(xiàn)方案之前。首先想先給大家擴(kuò)充下彈性伸縮的邊界與定義，傳統(tǒng)意義上來(lái)講，彈性伸縮主要解決的問(wèn)題是容量規(guī)劃與實(shí)際負(fù)載的矛盾。

如上圖所示，藍(lán)色的水位線表示集群的容量隨著負(fù)載的提高不斷的增長(zhǎng)，紅色的曲線表示集群的實(shí)際的負(fù)載真實(shí)的變化。而彈性伸縮要解決的就是當(dāng)實(shí)際負(fù)載出現(xiàn)激增，而容量規(guī)劃沒(méi)有來(lái)得及反應(yīng)的場(chǎng)景。

常規(guī)的彈性伸縮是基于閾值的，通過(guò)設(shè)置一個(gè)資源緩沖水位來(lái)保障資源的充盈，通常 15%-30% 左右的資源預(yù)留是比較常見(jiàn)的選擇。換言之就是通過(guò)一個(gè)具備緩沖能力的資源池用資源的冗余換取集群的可用。

這種方式表面上看是沒(méi)有什么問(wèn)題的，確實(shí)在很多的解決方案或者開(kāi)源組件中也是按照這種方式進(jìn)行實(shí)現(xiàn)的，但是當(dāng)我們深入的思考這種實(shí)現(xiàn)方案的時(shí)候會(huì)發(fā)現(xiàn)，這種方式存在如下三個(gè)經(jīng)典問(wèn)題。

1. 百分比碎片難題

在一個(gè) Kubernetes 集群中，通常不只包含一種規(guī)格的機(jī)器，針對(duì)不同的場(chǎng)景、不同的需求，機(jī)器的配置、容量可能會(huì)有非常大的差異，那么集群伸縮時(shí)的百分比就具備非常大的迷惑性。假設(shè)我們的集群中存在 4C8G 的機(jī)器與 16C32G 的機(jī)器兩種不同規(guī)格，對(duì)于 10% 的資源預(yù)留，這兩種規(guī)格是所代表的意義是完全不同的。

特別是在縮容的場(chǎng)景下，通常為了保證縮容后的集群不處在震蕩狀態(tài)，我們會(huì)一個(gè)節(jié)點(diǎn)一個(gè)節(jié)點(diǎn)或者二分法來(lái)縮容節(jié)點(diǎn)，那么如何根據(jù)百分比來(lái)判斷當(dāng)前節(jié)點(diǎn)是處在縮容狀態(tài)就尤為重要，此時(shí)如果大規(guī)格機(jī)器有較低的利用率被判斷縮容，那么很有可能會(huì)造成節(jié)點(diǎn)縮容后，容器重新調(diào)度后的爭(zhēng)搶饑餓。如果添加判斷條件，優(yōu)先縮容小配置的節(jié)點(diǎn)，則有可能造成縮容后資源的大量冗余，最終集群中可能會(huì)只剩下所有的巨石節(jié)點(diǎn)。

2. 容量的規(guī)劃炸彈

還記得在沒(méi)有使用容器前，是如何做容量規(guī)劃的嗎？一般會(huì)按照應(yīng)用來(lái)進(jìn)行機(jī)器的分配，例如，應(yīng)用 A 需要 2 臺(tái) 4C8G 的機(jī)器，應(yīng)用 B 需要 4 臺(tái) 8C16G 的機(jī)器，應(yīng)用 A 的機(jī)器與應(yīng)用 B 的機(jī)器是獨(dú)立的，相互不干擾。到了容器的場(chǎng)景中，大部分的開(kāi)發(fā)者無(wú)需關(guān)心底層的資源了，那么這個(gè)時(shí)候容量規(guī)劃哪里去了呢？

在 Kubernetes 中是通過(guò) Request 和 Limit 的方式進(jìn)行設(shè)置，Request 表示資源的申請(qǐng)值，Limit 表示資源的限制值。既然 Request 和 Limit 才是容量規(guī)劃的對(duì)等概念，那么這就代表著資源的實(shí)際計(jì)算規(guī)則要根據(jù) Request 和 Limit 才更加準(zhǔn)確。而對(duì)于每個(gè)節(jié)點(diǎn)預(yù)留資源閾值而言，很有可能會(huì)造成小節(jié)點(diǎn)的預(yù)留無(wú)法滿足調(diào)度，大節(jié)點(diǎn)的預(yù)留又調(diào)度不完的場(chǎng)景。

3. 資源利用率困境

集群的資源利用率是否可以真的代表當(dāng)前的集群狀態(tài)呢？當(dāng)一個(gè) Pod 的資源利用率很低的時(shí)候，不代表就可以侵占它所申請(qǐng)的資源。在大部分的生產(chǎn)集群中，資源利用率都不會(huì)保持在一個(gè)非常高的水位，但從調(diào)度來(lái)講，資源的調(diào)度水位應(yīng)該保持在一個(gè)比較高的水位。這樣才能既保證集群的穩(wěn)定可用，又不過(guò)于浪費(fèi)資源。

如果沒(méi)有設(shè)置 Request 與 Limit，而集群的整體資源利用率很高這意味著什么？這表示所有的 Pod 都在被以真實(shí)負(fù)載為單元進(jìn)行調(diào)度，相互之間存在非常嚴(yán)重的爭(zhēng)搶，而且簡(jiǎn)單的加入節(jié)點(diǎn)也絲毫無(wú)法解決問(wèn)題，因?yàn)閷?duì)于一個(gè)已調(diào)度的 Pod 而言，除了手動(dòng)調(diào)度與驅(qū)逐之外沒(méi)有任何方式可以將這個(gè) Pod 從高負(fù)載的節(jié)點(diǎn)中移走。那如果我們?cè)O(shè)置了 Request 與 Limit 而節(jié)點(diǎn)的資源利用率又非常高的時(shí)候說(shuō)明了什么呢？很可惜這在大部分的場(chǎng)景下都是不可能的，因?yàn)椴煌膽?yīng)用不同的負(fù)載在不同的時(shí)刻資源的利用率也會(huì)有所差異，大概率的情況是集群還沒(méi)有觸發(fā)設(shè)置的閾值就已經(jīng)無(wú)法調(diào)度 Pod 了。

彈性伸縮概念的延伸

既然基于資源利用率的彈性伸縮有上述已知的三個(gè)問(wèn)題，有什么辦法可以來(lái)解決呢？隨著應(yīng)用類型的多樣性發(fā)展，不同類型的應(yīng)用的資源要求也存在越來(lái)越大的差異。彈性伸縮的概念和意義也在變化，傳統(tǒng)理解上彈性伸縮是為了解決容量規(guī)劃和在線負(fù)載的矛盾，而現(xiàn)在是資源成本與可用性之間的博弈。如果將常見(jiàn)的應(yīng)用進(jìn)行規(guī)約分類，可以分為如下四種不同類型：

1. 在線任務(wù)類型

比較常見(jiàn)的是網(wǎng)站、API 服務(wù)、微服務(wù)等常見(jiàn)的互聯(lián)網(wǎng)業(yè)務(wù)型應(yīng)用，這種應(yīng)用的特點(diǎn)是對(duì)常規(guī)資源消耗較高，比如 CPU、內(nèi)存、網(wǎng)絡(luò) IO、磁盤 IO 等，對(duì)于業(yè)務(wù)中斷容忍性差。

2. 離線任務(wù)類型

例如大數(shù)據(jù)離線計(jì)算、邊緣計(jì)算等，這種應(yīng)用的特點(diǎn)是對(duì)可靠性的要求較低，也沒(méi)有明確的時(shí)效性要求，更多的關(guān)注點(diǎn)是成本如何降低。

3. 定時(shí)任務(wù)類型

定時(shí)運(yùn)行一些批量計(jì)算任務(wù)是這種應(yīng)用的比較常見(jiàn)形態(tài)，成本節(jié)約與調(diào)度能力是重點(diǎn)關(guān)注的部分。

4. 特殊任務(wù)類型

例如閑時(shí)計(jì)算的場(chǎng)景、IOT 類業(yè)務(wù)、網(wǎng)格計(jì)算、超算等，這類場(chǎng)景對(duì)于資源利用率都有比較高的要求。

單純的基于資源利用率的彈性伸縮大部分是用來(lái)解決第一種類型的應(yīng)用而產(chǎn)生的，對(duì)于其他三種類型的應(yīng)用并不是很合適，那么 Kubernetes 是如何解決這個(gè)問(wèn)題的呢？

Kubernetes 的彈性伸縮布局

Kubernetes 將彈性伸縮的本質(zhì)進(jìn)行了抽象，如果拋開(kāi)實(shí)現(xiàn)的方式，對(duì)于不同應(yīng)用的彈性伸縮而言，該如何統(tǒng)一模型呢？ Kubernetes 的設(shè)計(jì)思路是將彈性伸縮劃分為保障應(yīng)用負(fù)載處在容量規(guī)劃之內(nèi)與保障資源池大小滿足整體容量規(guī)劃兩個(gè)層面。簡(jiǎn)單理解，當(dāng)需要彈性伸縮時(shí)，優(yōu)先變化的應(yīng)該是負(fù)載的容量規(guī)劃，當(dāng)集群的資源池?zé)o法滿足負(fù)載的容量規(guī)劃時(shí)，再調(diào)整資源池的水位保證可用性。而兩者相結(jié)合的方式是無(wú)法調(diào)度的 Pod 來(lái)實(shí)現(xiàn)的，這樣開(kāi)發(fā)者就可以在集群資源水位較低的時(shí)候使用 HPA、VPA 等處理容量規(guī)劃的組件實(shí)現(xiàn)實(shí)時(shí)極致的彈性，資源不足的時(shí)候通過(guò) Cluster-Autoscaler 進(jìn)行集群資源水位的調(diào)整，重新調(diào)度，實(shí)現(xiàn)伸縮的補(bǔ)償。兩者相互解耦又相互結(jié)合，實(shí)現(xiàn)極致的彈性。

在 Kubernetes 的生態(tài)中，在多個(gè)維度、多個(gè)層次提供了不同的組件來(lái)滿足不同的伸縮場(chǎng)景。如果我們從伸縮對(duì)象與伸縮方向兩個(gè)方面來(lái)解讀 Kubernetes 的彈性伸縮的話，可以得到如下的彈性伸縮矩陣。

• cluster-autoscaler： kubernetes 社區(qū)中負(fù)責(zé)節(jié)點(diǎn)水平伸縮的組件，目前處在 GA 階段 （General Availability， 即正式發(fā)布的版本）。

• HPA： kubernetes 社區(qū)中負(fù)責(zé) Pod 水平伸縮的組件，是所有伸縮組件中歷史最悠久的，目前支持 autoscaling/v1、 autoscaling/v2beta1 與 autoscaling/v2beta2， 其中 autoscaling/v1 只支持 CPU 一種伸縮指標(biāo)，在 autoscaling/v2beta1 中增加支持 custom metrics，在 autoscaling/v2beta2 中增加支持 external metrics。

• cluster-proportional-autoscaler： 根據(jù)集群的節(jié)點(diǎn)數(shù)目，水平調(diào)整 Pod 數(shù)目的組件，目前處在 GA 階段。

• vetical-pod-autoscaler： 根據(jù) Pod 的資源利用率、歷史數(shù)據(jù)、異常事件，來(lái)動(dòng)態(tài)調(diào)整負(fù)載的 Request 值的組件，主要關(guān)注在有狀態(tài)服務(wù)、單體應(yīng)用的資源伸縮場(chǎng)景，目前處在 beta 階段。

• addon-resizer： 根據(jù)集群中節(jié)點(diǎn)的數(shù)目，縱向調(diào)整負(fù)載的 Request 的組件，目前處在 beta 階段。

在這五個(gè)組件中， cluster-autoscaler、 HPA、 cluster-proportional-autoscaler 是目前比較穩(wěn)定的組件，建議有相關(guān)需求的開(kāi)發(fā)者進(jìn)行選用。

對(duì)于百分之八十以上的場(chǎng)景，我們建議客戶通過(guò) HPA 結(jié)合 cluster-autoscaler 的方式進(jìn)行集群的彈性伸縮管理， HPA 負(fù)責(zé)負(fù)載的容量規(guī)劃管理而 cluster-autoscaler 負(fù)責(zé)資源池的擴(kuò)容與縮容。

看完上述內(nèi)容，你們掌握Kubernetes彈性伸縮全場(chǎng)景中如何解析概念延伸與組件布局的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！