Serverless 與容器決戰在即？有了彈性伸縮就不同了

做者 | 阿里雲容器技術專家 莫源  

本文整理自莫源於 8 月 31 日 K8s & cloudnative meetup 深圳場的演講內容。關注「阿里巴巴雲原生」公衆號，回覆關鍵詞「資料」， 便可得到 2019 整年 meetup 活動 PPT 合集及 K8s 最全知識圖譜。

導讀：Serverless 和 Autoscaling 是近些年來廣大開發者很是關心的內容。有人說 Serverless 是容器 2.0，終有一天容器會和 Serverless 進行一場決戰，分出勝負。實際上，容器和 Serverless 是能夠共存而且互補的，特別是在 Autoscaling 相關的場景下，Serverless 能夠與容器完美兼容，彌補容器場景在使用簡單、速度、成本的缺欠，在本文中將會爲你們介紹容器在彈性場景下的原理、方案與挑戰，以及 Serverless 是如何幫助容器解決這些問題的。

當咱們在談論"彈性伸縮"的時候

當咱們在談論"彈性伸縮"的時候，咱們在談論什麼？"彈性伸縮"對於團隊中不一樣的角色有不一樣的意義，而這正是彈性伸縮的魅力所在。

從一張資源曲線圖講起

這張圖是闡述彈性伸縮問題時常常引用的一張圖，表示的是集羣的實際資源容量和應用所需容量之間的關係。

• 其中紅色的曲線表示的是應用實際所需的容量，由於應用的資源申請量相比節點而言會小不少，所以曲線相對比較平滑；
• 而綠色的折線表示的是集羣的實際資源容量，折線的拐點代表此時進行了手動的容量調整，例如增長節點或者移除節點，由於單個節點的資源容量固定且相對較大，所以以折線爲主。

首先，咱們先看左側第一塊黃色柵格的區域，這個區域表示集羣的容量沒法知足業務的容量所需，在實際的場景中，一般會伴隨出現因爲資源不足而沒法調度的 Pod 等現象。

中間的柵格區域，集羣的容量遠高於實際資源所需的容量，此時會出現資源的浪費，實際的表現一般是節點的負載分配不均，部分節點上面無調度負載，而另一些節點的負載相對較高。

右側柵格區域表示的是激增的峯值容量，咱們能夠看到，到達峯值前的曲率是很是陡峭的，這種場景一般是因爲流量激增、大批量任務等很是規容量規劃內的場景，激增的峯值流量給運維同窗的反應時間很是短，一旦處理不當就有可能引起事故。

彈性伸縮對於不一樣角色的人員，有着不一樣的意義：

• 開發人員但願經過彈性伸縮使應用得到高可用的保障；
• 運維人員但願經過彈性伸縮下降基礎設施的管理成本；
• 架構師但願經過彈性伸縮獲得靈活彈性的架構應對突發的激增峯值。

彈性伸縮有多種不一樣的組件和方案，選擇適合本身業務需求的方案是落地執行前的第一步。

Kubernetes 彈性伸縮能力解讀

Kubernetes 彈性伸縮的相關組件

Kubernetes 彈性伸縮的組件能夠從兩個維度進行解讀：一個是伸縮方向，一個是伸縮對象。

從伸縮方向上，分爲橫向與縱向。從伸縮對象上，分爲節點與 Pod。那麼將這個象限進行展開，就變成以下 3 類組件：

1. cluster-autoscaler，節點水平伸縮；
2. HPA & cluster-proportional-autoscaler，Pod 水平伸縮；
3. vertical pod autoscaler&addon resizer，Pod 縱向伸縮。

其中 HPA 與 Cluster-Autoscaler 是開發者最常組合使用的彈性伸縮組件。HPA 負責容器的水平伸縮，Cluster-Autoscaler 負責節點的水平伸縮。不少的開發者會產生這樣的疑問：爲何彈性伸縮一個功能須要細化成這麼多組件分開處理，難道不能夠直接設置一個閾值，就實現集羣的自動水位管理嗎？

Kubernetes 的彈性伸縮挑戰

瞭解 Kubernetes 的調度方式能夠幫助開發者更好的理解 Kubernetes 彈性伸縮的設計哲學。在 Kubernetes 中，調度的最小單元是一個 Pod，Pod 會根據調度策略被調度到知足條件的節點上，這些策略包括資源的匹配關係、親和性與反親和性等等，其中資源的匹配關係的計算是調度中的核心要素。

一般和資源相關的有以下四個概念：

• Capacity 表示一個節點所能分配的容量總量；
• Limit 表示一個 Pod 可以使用的資源總量；
• Request 表示一個 Pod 在調度上佔用的資源空間；
• Used 表示一個 Pod 的真實資源使用。

在瞭解這四個基本概念和使用場景以後，咱們再來看下 Kubernetes 彈性伸縮的三大難題：

1. 容量規劃炸彈 還記得在沒有使用容器前，是如何作容量規劃的嗎？通常會按照應用來進行機器的分配，例如，應用 A 須要 2 臺 4C8G 的機器，應用 B 須要 4 臺 8C16G 的機器，應用 A 的機器與應用 B 的機器是獨立的，相互不干擾。到了容器的場景中，大部分的開發者無需關心底層的資源了，那麼這個時候容量規劃哪裏去了呢？

在 Kubernetes 中是經過 Request 和 Limit 的方式進行設置，Request 表示資源的申請值，Limit 表示資源的限制值。既然 Request 和 Limit 纔是容量規劃的對等概念，那麼這就表明着資源的實際計算規則要根據 Request 和 Limit 才更加準確。而對於每一個節點預留資源閾值而言，頗有可能會形成小節點的預留沒法知足調度，大節點的預留又調度不完的場景。

2. 百分比碎片陷阱 在一個 Kubernetes 集羣中，一般不僅包含一種規格的機器。針對不一樣的場景、不一樣的需求，機器的配置、容量可能會有很是大的差別，那麼集羣伸縮時的百分比就具有很是大的迷惑性。

假設咱們的集羣中存在 4C8G 的機器與 16C32G 兩種不一樣規格的機器，對於 10% 的資源預留而言，這兩種規格是所表明的意義是徹底不一樣的。特別是在縮容的場景下，一般爲了保證縮容後的集羣不處在震盪狀態，咱們會一個節點一個節點來縮容節點，那麼如何根據百分比來判斷當前節點是處在縮容狀態就尤其重要。此時若是大規格機器有較低的利用率被判斷縮容，那麼頗有可能會形成節點縮容後，容器從新調度後的爭搶飢餓。若是添加判斷條件，優先縮容小配置的節點，則有可能形成縮容後資源的大量冗餘，最終集羣中可能會只剩下全部的巨石節點。

3. 資源利用率困境 集羣的資源利用率是否能夠真的表明當前的集羣狀態呢？當一個 Pod 的資源利用率很低的時候，不表明就能夠侵佔他所申請的資源。在大部分的生產集羣中，資源利用率都不會保持在一個很是高的水位，但從調度來說，資源的調度水位應該保持在一個比較高的水位。這樣才能既保證集羣的穩定可用，又不過於浪費資源。

若是沒有設置 Request 與 Limit，而集羣的總體資源利用率很高，這意味着什麼？這表示全部的 Pod 都在被以真實負載爲單元進行調度，相互之間存在很是嚴重的爭搶，並且簡單的加入節點也絲毫沒法解決問題，由於對於一個已調度的 Pod 而言，除了手動調度與驅逐，沒有任何方式能夠將這個 Pod 從高負載的節點中移走。那若是咱們設置了 Request 與 Limit 而節點的資源利用率又很是高的時候說明了什麼呢？很惋惜這在大部分的場景下都是不可能的，由於不一樣的應用不一樣的負載在不一樣的時刻資源的利用率也會有所差別，大機率的狀況是集羣尚未觸發設置的閾值就已經沒法調度 Pod 了。

在瞭解了 Kubernetes 彈性伸縮的三大問題後，咱們再來看下 Kubernetes 的解決辦法是什麼？

Kubernetes 的彈性伸縮設計哲學

Kubernetes 的設計理念是將彈性伸縮分紅調度層伸縮和資源層伸縮。調度層負責根據指標、閾值伸縮出調度單元，而資源層伸縮負責知足調度單元的資源需求。

在調度層一般是經過 HPA 的方式進行 Pod 的水平伸縮，HPA 的使用方式和咱們傳統意義上理解的彈性伸縮是很是接近和相似的，經過設置判斷的指標、判斷的閾值來進行水平伸縮。

在資源層目前主流的方案是經過 cluster-autoscaler 進行節點的水平伸縮。當出現 Pod 因爲資源不足形成沒法調度時，cluster-autoscaler 會嘗試從配置伸縮組中，選擇一個能夠知足調度需求的組，並自動向組內加入實例，當實例啓動後註冊到 Kubernetes 後，kube-scheduler 會從新觸發 Pod 的調度，將以前沒法調度的 Pod 調度到新生成的節點上，從而完成全鏈路的擴容。

一樣在縮容時，調度層會現根據資源的利用率與設置的閾值比較，實現 Pod 水平的縮容。當節點上 Pod 的調度資源下降到資源層縮容閾值的時候，此時 Cluster-Autoscaler 會進行低調度百分比的節點的排水，排水完成後會進行節點的縮容，完成整個鏈路的收縮。

Kubernetes 彈性伸縮方案的阿克琉斯之踵

經典的 Kubernetes 彈性伸縮的案例

這張圖是一個很是經典的彈性伸縮的案例，能夠表明大多數的在線業務的場景。應用的初始架構是一個 Deployment，下面有兩個 Pod，這個應用的接入層是通 過Ingress Controller 的方式進行對外暴露的，咱們設置應用的伸縮策略爲：單個 Pod 的 QPS 到達 100，則進行擴容，最小爲 2 個 Pod，最大爲 10 個 Pod。

HPA controller 會不斷輪訓 alibaba-cloud-metrics-adapter，來獲取 Ingress Gateway 當前路由的 QPS 指標。當 Ingress Gateway 的流量到達 QPS 閾值時，HPA controller 會觸發 Deployment 的 Pod 數目變化；當 Pod 的申請容量超過集羣的總量後，cluster-autoscaler 會選擇合適的伸縮組，彈出相應的 Node，承載以前未調度的 Pod。

這樣一個經典的彈性伸縮案例就解析完畢了，那麼在實際的開發過程當中，會遇到哪些問題呢？

經典的 Kubernetes 彈性伸縮的缺點與解法

首先是擴容時延的問題，社區標準模式是經過建立、釋放 ECS 的方式，擴容的時延在 2min-2.5min 左右，而阿里雲獨立的極速模式是經過建立、停機、啓動的方式進行實現，停機時只收取存儲的費用，不收取計算的費用。能夠經過很是低廉的價格得到 50% 以上的彈性效率。

此外複雜度也是 cluster-autoscaler 繞不過的問題，想要用好 cluster-autoscaler，須要深刻的瞭解 cluster-autoscaler 的一些內部機制，不然極有可能形成沒法彈出或者沒法縮容的場景。

對於大多數的開發者而言，cluster-autoscaler 的工做原理是黑盒的，並且 cluster-autoscaler 目前最好的問題排查方式依然是查看日誌。一旦 cluster-autoscaler 出現運行異常後者因爲開發者配置錯誤致使沒法如預期的伸縮，那麼 80% 以上的開發者是很難本身進行糾錯的。

阿里雲容器服務團隊開發了一款 kubectl plugin，能夠提供 cluster-autoscaler 更深層次的可觀測性，能夠查看當前 cluster-autoscaler 所在的伸縮階段以及自動彈性伸縮糾錯等能力。

雖然目前遇到的幾個核心的問題，都不是壓死駱駝的最後一棵稻草。可是咱們一直在思考，是否有其餘的方式可讓彈性伸縮使用起來更簡單、更高效？

阿克琉斯的馬丁靴 - Serverless Autoscaling

資源層伸縮的核心問題在於學習成本較高、排錯困難、時效性差。當回過頭來看 Serverless 的時候，咱們能夠發現這些問題剛好是 Serverless 的特色與優點，那麼是否有辦法讓 Serverless 成爲 Kubernetes 資源層的彈性方案呢？

Serverless Autoscaling 組件 - virtual-kubelet-autoscaler

阿里雲容器服務團隊開發了 virtual-kubelet-autoscaler，一個在 Kubernetes 中實現 serverless autoscaling 的組件。

當出現了沒法調度的 Pod 的時候，virtual-kubelet 負責承載真實的負載，能夠理解爲一個虛擬節點，擁有無限大的 capacity。當 Pod 調度到 virtual-kubelet 上時，會將 Pod 經過輕量級實例 ECI 進行啓動。目前 ECI 的啓動時間在 30s 以內，程序從調度開始到運行通常會在 1 分鐘內拉起。

與 cluster-autoscaler 相似，virtual-kubelet-autoscaler 也須要使用模擬調度的機制來判斷 Pod 是否能夠被真實處理和承載，可是相比 cluster-autoscaler 而言，存在以下差別：

1. virtual-kubelet-autoscaler 模擬調度的對象是增長了調度策略的 Pod Template 並不是 Node Template。
2. virtual-kubelet-autoscaler 的核心是選擇 virtual-kubelet 來承載負載，一旦 Pod 模擬調度成功綁定到 virtual-kubelet 上後，Pod 的生命週期管理、問題的排查等就與傳統的 Pod 沒有差別，再也不是黑盒排查問題。

virtual-kubelet-autoscaler 不是"銀彈"

virtual-kubelet-autoscaler 並非用來替代 cluster-autoscaler 的，virtual-kubelet-autoscaler 的優點在於使用簡單、高彈性高併發，按量按需計費。可是與此同時也犧牲了部分的兼容性，目前對 cluster-pi、coredns 等機制支持的還並不完善，只需少量的配置 virtual-kubelet-autoscaler 是能夠和 cluster-autoscaler 兼容的。virtual-kubelet-autoscaler 特別適合的場景是大數據離線任務、CI/CD 做業、突發型在線負載等。

最後

serverless autoscaling 已經逐漸成爲 Kubernetes 彈性伸縮的重要組成部分，當 serverless autoscaling 兼容性基本補齊的時候，serverless 使用簡單、無需運維、成本節約的特性會與 Kubernetes 造成完美互補，實現 Kubernetes 彈性伸縮的新飛躍。