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

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

10年積累的成都做網(wǎng)站、網(wǎng)站設計經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有下冶免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

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

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

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

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

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

1. 百分比碎片難題

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

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

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

還記得在沒有使用容器前，是如何做容量規(guī)劃的嗎？一般會按照應用來進行機器的分配，例如，應用 A 需要 2 臺 4C8G 的機器，應用 B 需要 4 臺 8C16G 的機器，應用 A 的機器與應用 B 的機器是獨立的，相互不干擾。到了容器的場景中，大部分的開發(fā)者無需關心底層的資源了，那么這個時候容量規(guī)劃哪里去了呢？

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

3. 資源利用率困境

集群的資源利用率是否可以真的代表當前的集群狀態(tài)呢？當一個 Pod 的資源利用率很低的時候，不代表就可以侵占它所申請的資源。在大部分的生產集群中，資源利用率都不會保持在一個非常高的水位，但從調度來講，資源的調度水位應該保持在一個比較高的水位。這樣才能既保證集群的穩(wěn)定可用，又不過于浪費資源。

如果沒有設置 Request 與 Limit，而集群的整體資源利用率很高這意味著什么？這表示所有的 Pod 都在被以真實負載為單元進行調度，相互之間存在非常嚴重的爭搶，而且簡單的加入節(jié)點也絲毫無法解決問題，因為對于一個已調度的 Pod 而言，除了手動調度與驅逐之外沒有任何方式可以將這個 Pod 從高負載的節(jié)點中移走。那如果我們設置了 Request 與 Limit 而節(jié)點的資源利用率又非常高的時候說明了什么呢？很可惜這在大部分的場景下都是不可能的，因為不同的應用不同的負載在不同的時刻資源的利用率也會有所差異，大概率的情況是集群還沒有觸發(fā)設置的閾值就已經(jīng)無法調度 Pod 了。

彈性伸縮概念的延伸

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

1. 在線任務類型

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

2. 離線任務類型

例如大數(shù)據(jù)離線計算、邊緣計算等，這種應用的特點是對可靠性的要求較低，也沒有明確的時效性要求，更多的關注點是成本如何降低。

3. 定時任務類型

定時運行一些批量計算任務是這種應用的比較常見形態(tài)，成本節(jié)約與調度能力是重點關注的部分。

4. 特殊任務類型

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

單純的基于資源利用率的彈性伸縮大部分是用來解決第一種類型的應用而產生的，對于其他三種類型的應用并不是很合適，那么 Kubernetes 是如何解決這個問題的呢？

Kubernetes 的彈性伸縮布局

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

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

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

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

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

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

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

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

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

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

分享名稱：Kubernetes彈性伸縮全場景中如何解析概念延伸與組件布局
地址分享：http://muchs.cn/article12/pdpidc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、定制網(wǎng)站、做網(wǎng)站、企業(yè)建站、App設計、手機網(wǎng)站建設

廣告

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