Kubernetes高級進階之彈性伸縮的困境與布局

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

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

2.1 傳統伸縮的困境
從傳統意義上，彈性伸縮主要解決的問題是容量規劃與實際負載的矛盾

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

傳統的理解，比如有幾臺web服務器，負載高了加機器，然后負載下去減機器

傳統的彈性伸縮和k8s的彈性伸縮有什么區別？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

現在一般來說都是一些成本的節省和可用之間的矛盾，既然業務已經多元化了，解決這個問題就可以將這些業務進行分類

2、彈性伸縮概念的延伸
不是所有的業務都存在峰值流量，越來越細分的業務形態帶來更多成本節省和可用性之間的跳轉。

1. 在線負載型：微服務、網站、API
2. 離線任務型：離線計算、機器學習
3. 定時任務型：定時批量計算
   不同類型的負載對于彈性伸縮的要求有所不同，在線負載對彈出時間敏感，離線任務對價格敏感，定時任務對調度敏感。

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

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

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

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

如果在云上建議 HPA 結合 cluster-autoscaler 的方式進行集群的彈性伸縮管理。

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