kubernetes 降本增效標准指南｜理解彈性，應用彈性

彈性伸縮在雲計算領域的簡述

彈性伸縮又稱自動伸縮，是雲計算場景下一種常見的方法，彈性伸縮可以根據服務器上的負載、按一定的規則、進行彈性的擴縮容服務器。
彈性伸縮在不同場景下的含義：

• 對於服務運行在自建機房的公司，彈性伸縮通常意味着允許一些服務器在低負載時進入睡眠狀態，從而節省電費（以及用於冷卻機器的水費和水費）。
• 對於使用在托管在雲上的機房的公司而言，自動擴展可能意味着更低的費用，因為大多數雲提供商都基於總使用量而不是最大容量進行收費。
• 即使對於不能在任何給定時間減少運行或支付的總計算能力的公司，它們也可以在低流量時降低服務器的負載。
• 彈性伸縮解決方案還可以用來替換異常狀態的實例，從而在一定程度上防止硬件，網絡和應用程序故障。
• 在生產工作負載經常變化且不可預測的情況下，彈性伸縮可以提供更長的正常運行時間和更高的可用性。

引用自：https://zh.wikipedia.org/wiki/%E5%BC%B9%E6%80%A7%E4%BC%B8%E7%BC%A9

彈性伸縮的三大關鍵要素

1. 基於什么特征和屬性

彈性伸縮，顧名思義某種機制能夠讓某些對象進行彈性的擴容和縮容。在雲計算和容器相關領域也有較多的關於彈性伸縮的能力，有基於系統負載進行彈性擴縮容的，有基於業務日志進行彈性擴縮容的，也有基於資源預申請進行彈性擴縮容的。最常用的主要有以下記錄：

1. 基於系統負載指標擴縮容對象

• 使用場景：當您的應用程序承擔更多負載時，往往需要更多的 CPU 和內存資源，這時您可以設置一個 CPU 和內存利用率的指標，系統會自動設置副本數以動態承擔不同的負載情況，防止資源利用率過低的資源浪費或負載過高時應用程序無法承擔。

• 限制：有時應用的負載變高但 CPU 和內存的利用率並沒有很高，這時基於系統負載指標擴縮容是無效的。並且具體使用哪一種系統負載指標，以及利用率的閾值設定都是比較需要經驗的。

2. 基於業務日志擴縮容對象

• 使用場景：業務的日志有專門記錄和存儲，並且可以通過日志分析得到當前應用的實際負載情況，這時可以根據業務的日志自動擴縮容。

• 限制：需要擁有日志存儲和分析工具；日志信息量普遍很大，基於日志的彈性擴縮容易誤判、漏判。

3. 基於資源請求擴縮容對象

• 使用場景：當有些應用不適合水平擴縮容時，此時可以通過調整對資源的請求量來實現擴縮容。相較方式1是擴容副本數實現水平擴縮容，此時擴容的是容器對資源的請求量，屬於垂直擴縮容。

• 限制：當前這種方式需要重建容器，可能會引發服務的中斷；並且垂直擴容依賴當前容器運行的節點容量大小，如果節點本身沒有剩余資源，也無法實現垂直擴容。

4. 基於事件擴縮容對象

• 使用場景：例如當您的業務需要處理 Kafka 消息隊列中的任務時，Kafka 中每多一條 topic，需要生成一個新的副本來處理這個 topic；或者數據庫每多一條任務數據，會自動生成一個新的副本來承載這個任務。

• 限制：完全依賴事件的觸發，但事件本身處理時長有長有段，負載程度有高有低，完全相同的副本無法靈活應對。
  當然還可以用其他的特征和屬性進行擴縮容對象，這里也未全部枚舉，具體業務使用彈性伸縮，按需選擇不同的特征和屬性，特征和屬性則是彈性伸縮的基礎。

2. 根據什么策略

基於上述的特征和屬性獲得了數據之后，那么就需要一定的策略和判斷規則。 總結來說就是：

1. 上述的特征和屬性在什么情況和邊界下或進行擴容、擴多少、擴什么對象、怎么個擴法？
2. 上述的特征和屬性在什么情況和邊界下或進行縮容、縮多少、縮什么對象、怎么個縮法？

舉個 kubernetes Cluster AutoScaler 的例子：
在騰訊雲容器服務里節點的縮容策略：

1. CA（Cluster Autoscaler）監測到利用率（取 CPU 利用率和 MEM 利用率的最大值）低於設定的節點。計算利用率時，可以設置 Daemonset 類型不計入 Pod 占用資源。

2. CA 判斷集群的狀態是否可以觸發縮容，需要滿足如下要求：

   • 節點空閑時長要求（默認10分鍾）。

   • 集群擴容緩沖時間要求（默認10分鍾）。

3. CA 判斷該節點是否符合縮容條件。您可以按需設置以下不縮容條件（滿足條件的節點不會被 CA 縮容）：

   • 含有本地存儲的節點。

   • 含有 Kube-system namespace 下非 DaemonSet 管理的 Pod 的節點。說明：

4. CA 驅逐節點上的 Pod 后釋放/關機節點（不會處理包年包月節點）。

   • 完全空閑節點可並發縮容（可設置最大並發縮容數）。

   • 非完全空閑節點逐個縮容。
     

上述就是 Kubernetes 對節點縮容的處理邏輯，也就是彈性伸縮三大關鍵要素的擴縮容策略部分。總結來說，策略是決定彈性伸縮相關的能力是否足夠匹配業務場景的最關鍵的部分。

3. 彈縮什么對象

彈性伸縮在雲服務商上的服務對象往往就是服務器的數量，還有更多彈性伸縮的對象如：雲服務器的資源配置（CPU/內存）、還可以是承載用戶業務的 Kubernetes 里的 Pod、還可以是其他企業所需要使用的雲產品，業務只要有按需使用雲資源的訴求，隨用隨取的資源皆可成為彈性伸縮的對象。 雲上彈性伸縮的本質和目的：就是對彈性伸縮對象的按需付費。

彈性跟雲計算成本的關系

彈性伸縮可以降低哪些成本

騰訊雲雲原生團隊后續計划推出雲原生白皮書， 其中將會介紹來着 1000+ 企業在成本方面的經驗總結， 整體分成了三個部分：理解成本->控制成本->優化成本。利用雲的彈性伸縮是企業優化成本的三大方法之一。

1、彈性伸縮可降低 IT 設備成本

通過《降本增效｜容器化計算資源利用率現象剖析》中的調研分析，充分利用彈性伸縮能力，是提高資源利用率，降低資源成本的關鍵點之一，對比未使用彈性伸縮的情況下整體資源利用率能夠提高20%、30%以上。
騰訊雲原生團隊提出了容器化資源利用率成熟度模型中的 level2 就是業務利用容器和雲的彈性伸縮能力，結合 Kubernetes 的 HPA、VPA、CA 等能力，高峰擴容、空閑縮容，極大提高資源利用率。

2、彈性伸縮可提供運維效率、降低人員投入成本

未使用彈性伸縮的情況下，運維人員可能會碰到以下場景：
● 業務突增或 CC 攻擊導致機器數量不足，以致您的服務無響應
● 按高峰訪問量預估資源，而平時訪問量很少達到高峰，造成投入資源浪費
● 人工守護及頻繁處理容量告警，需要多次手動變更

采用彈性伸縮，配置自動化后，既可以釋放人員對資源的手動變更的投入成本， 還可以讓業務的穩定性進一步提高。

引用自：https://cloud.tencent.com/document/product/377/3154

彈性伸縮影響成本關鍵點

1、彈性伸縮影響 IT 資源成本的關鍵點

1. 1 靈敏度

靈敏度可以用從觸發擴縮容到實際將對象擴縮容完成的時間來衡量，時間越短、靈敏度越高。
靈敏度的提升對業務來說不僅僅是影響時間差的 IT 資源成本，還可能對業務某些場景起到關鍵性的作用。
靈敏度可以從 HPA 擴容速度、CluterAutoscler 擴容速度、業務擴容方式多維度進行提升。
靈敏度是騰訊雲容器系列產品彈性伸縮功能的關鍵考核指標，從基礎層重點考量彈性伸縮的速度，以節點擴展效率為例，TKE 通過節點池擴節點的時間實際測試數據如下：

測試方案：

1. 創建一個 TKE 集群，分別擴展50、100、200節點

2. 記錄批量擴展從啟動到完成初始化的時間

3. 釋放新創建的節點

4. 重復測試5次，記錄每一次批量擴展時間

批量添加50節點：

-	第1次	第2次	第3次	第4次	第5次
耗時	3分 16秒	3分 33秒	3分 59秒	4分 5秒3	3分 13秒

批量添加100節點批量添加200節點：

-	第1次	第2次	第3次	第4次	第5次
耗時	4分 55秒	5分 07秒	5分 02秒	5分 11秒	5分 10秒

當然從業務實際需要觸發擴縮容到業務負載 Ready，在 Kubernetes 服務層面不僅僅是節點的擴容一個部分，還涉及 Pod 的 HPA、監控或日志指標的采集分析效率等，騰訊雲容器服務系列產品也將持續圍繞提高彈性伸縮靈敏度建設彈性伸縮產品能力。

1.2 精確度

精確度在彈性伸縮領域主要意味着：在准確的時間進行擴縮容、擴縮數量准確、擴縮的對象屬性精確（如雲服務器的機型），精確度越高同樣意味着越貼合業務，擴容不會擴得過大而導致成本的浪費，也不會擴的過小導致沒有解決業務問題，同樣縮容不縮的過多導致業務故障、不會縮的過下而造成資源浪費。
精確度跟擴縮容的策略和算法息息相關。
在 Kubenretes 服務上的精確度同靈敏度一樣，也分散在各個彈性擴縮容的組件上，以 HPA 來舉例，精確度主要的還是其默認的擴縮容算法作代表，詳情可參閱 Kubernetes 官網：
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

默認的 HPA 擴容策略，能夠滿足絕大數場景，但業務的場景更多，因此也出現了匹配業務熟悉具備更高精確度的對 Pod 進行擴縮容的組件如：
● 業務屬性跟時間相關，通過 CronHPA (騰訊容器服務為 HPC 功能) 來控制更精確的擴縮容時間。
● 基於事件的自動擴縮容 KEDA ，通過替換指標的數據源來匹配業務的訴求如離線計算的場景。
● ......
相信社區后續在 Pod 級別的擴縮容上也還會出現越來越豐富的組件，以適配業務的多樣的場景來提高彈性伸縮的精確度。

2、彈性伸縮影響運維成本的關鍵點

2.1 自動化程度

自動化的程度如果要通過一個可衡量的數值來參考，可以考慮選擇運維或開發在IT資源管理上投入的時間，時間越少，自動化程度越高， 投入的時間越少，也意外着投入的人力成本越低。這里的時間還可以繼續拆分到投入擴縮容 IT 資源的時間和對 IT 資源資源維護的時間如故障替換等。
想要提高彈性伸縮的自動化程度，理解彈性的基本工作原理是最基礎的要求。下文也會詳細展開 Kubenetes 服務下的幾個基本的彈性伸縮組件的工作原理。
在理解彈性伸縮工作原理的基礎上，企業往往會結合自身的運維平台，將彈性伸縮集成進去，成為運維系統的一部分，以結合業務的訴求。因此自動化也要求雲服務商對彈性伸縮的可配置性、API 的易用性也有較高的要求，如若各位讀者有使用騰訊雲容器服務相關的彈性伸縮 API，歡迎各位給產品提供優質的建議。

2. 2 可觀測性

之所以將彈性伸縮的可觀測性單獨作為一個影響運維成本的關鍵點，是因為當前 Kubernetes 的彈性伸縮的自動化還不能達到完全脫離運維人員的狀態，良好的可觀測性能讓負責 IT 管理的人員減少心智負擔，讓業務的運行更加透明。同時也讓自動化無法處理的工作能夠有更快人員介入處理。
可觀測性包含對彈性伸縮對象的盤點和管理、彈性伸縮對象基本的系統指標、運行狀態的監控、以及故障告警等等。
雲廠商的產品包括騰訊雲容器系列的產品都會提供一些基本的可觀測性的產品能力，也可以采用社區的 Grafana 等儀表盤工具構建企業自己的可觀測性平台。

是否所有業務都適用彈性伸縮

業務的擴容相對來講是一件低風險的事情，最大的影響是支出可能會增多，但對業務本身來說是一件安全的事情。但是彈性伸縮不僅有擴容，也有縮容。業務被縮容之后，針對下次的突發流量是否能快速擴容？特別是如果剩余資源被別的業務搶占，或雲上的資源售罄的情況下，臨時再擴容是一件風險比較大的事情。
業務的應用之間存在依賴關系時，一個應用擴縮容后，另一個應用是否也該擴縮容？是否會有連鎖反應？這些都是可能導致系統故障的風險點。
上面提到的彈性伸縮基於的特征和屬性、策略、對象都有很多種，任何一種方式都可以彈性伸縮，到底哪一個才是最好最適合的擴容方式？往往需要非常強的技術積累和經驗，很難自動化。
使用彈性不當，導致賬單爆漲的案例比比皆是。要理解彈性伸縮工作的原理、才能更准確的使用彈性伸縮，降低業務成本，提高業務穩定性。建議使用 Kubernetes 彈性伸縮能力之前先詳細閱讀 Kubernetes 彈性伸縮相關官方文檔或 Git 文檔。

· ClusterAutoScaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

· HPA: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

· VPA：https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

Kubernetes 彈性領域仍存在的問題

靈敏度存在的問題

彈性伸縮需要監控到“變化”（這個變化指的是上面提到的彈性伸縮的特征和屬性），才能根據提前制定的“策略”，對要操作的“對象”進行彈性伸縮。但是從實際業務流量的變高，到負載量“變化”，再到監控組件監控到負載量變化，到最后引發彈性擴縮容發生往往需要較長的時間。

此外，為了保證 Pod 高的 QoS，防止重要 Pod 被 Kubernetes 的調度器驅逐，用戶會將容器設置相同的 Request 和 Limit，此時用戶實際的資源使用率最多只有 100%。假設用戶使用 HPA，且閾值設置為 90%，則每次擴容，副本數最多只能擴容到現在的 1/0.9=1.11 倍。倘若此時流量突然增大到必須使用現在兩倍的資源量，即兩倍的副本數，則需要擴容 8 次才能承載兩倍的流量：（1（1.18）= 2.14），很明顯這個擴容步驟過多，周期過長。

時間窗口的設置，當前 HPA 控制器中針對擴容和縮容分別有一個時間窗口，即在該窗口內會盡量保證 HPA 擴縮容的目標副本數處於穩定的狀態，其中擴容是3分鍾，而縮容是5分鍾。若時間窗口設置得較小，則副本數可能頻繁變化導致集群狀態不穩定；若時間窗口設置得較大，則擴縮容反應時間太慢，無法有效應對突發流量。

影響精確度的問題

擴容是有可能失敗的，這對流量突發場景可能是致命的，例如：雲上的資源是有可能售罄的，此時無法擴容。

當前 Cluster Autoscaler 的節點擴縮容主要依賴 Pod 的 Pending 情況，數據過於單一，精度有待提高。並且 Pod 的 Pending 只查看已分配的資源請求和限制，而不是實際的資源使用情況，對業務方來說，過度配置 Pod 是常見的做法，這些都影響着彈性伸縮的精度。

一個集群中存在多個規格的 CVM，擴容和縮容應優先處理哪種規格的 CVM，例如：縮容大規格節點容易引發容器重新調度后的爭搶飢餓，縮容小規格節點有可能導致集群最后僅剩下大規格節點。

自動化程度的問題

當前的彈性伸縮的各種方法還不夠自動化，雖然最后能實現自動的彈性擴縮容，但是它還是建立在前期大量的手工配置上面，這些配置需要很強的業務經驗和積累，以及對 Kubernetes 各種彈性伸縮的深刻理解。

以 HPA 為例，目前 TKE 已經支持了五大類共 30 個不同的指標，了解更多詳細內容請參見 TKE 自動伸縮指標說明，此外，TKE 還提供了使用自定義指標進行彈性伸縮的方法。這么多的指標該如何選擇？那種指標才是最合適自己業務的指標？指標的數值設置成多少合適？副本數的變化范圍該如何設置？這里都是影響彈性伸縮的關鍵因素。

可觀測性的問題

什么時間因為什么事情造成了什么樣的彈性擴縮容結果，這對現有的監控系統來說，還需要做較多努力。因為現有的監控系統通常都是監控某一項指標，它可以監控副本數的變化，可以監控彈性伸縮對象的變化，也可以監控資源使用率的情況，甚至可以監控事件/日志等信息，但是把它們有機的結合在一起，互聯互通卻是一件相對來講較為困難的事情，當前彈性伸縮的可觀測性方面還需要人工聚合和分析多方面的監控數據，需要高度定制化，對運維人員來說依舊是一件比較繁瑣的事情。

其它問題

1、彈性維度

當前 HPA 監控的是 Pod 的指標，但是有些 Pod 里存在多個容器，主業務容器高負載的情況下，如果此時 sidecar 容器低負載，並且此 Pod 下所有容器的平均資源利用率低於引發擴容的閾值時，也無法引發擴容，配置的彈性伸縮無效。維度方面還有一個高維度的問題：同樣以 HPA 為例，作用對象是 Pod 級別，但產品通常是以應用為中心，HPA 的彈性伸縮缺少“聯動效應”，例如一個 Pod 的擴縮容是否可以自動引發同一個應用下其它 Pod 的擴縮容？

2、驅逐選擇

一個 Pod 資源利用率很低，若它的資源被彈性收縮后，資源被別的負載侵占，此時如果這個 Pod 負載突然變高，但節點又沒有剩余可用資源，是該驅逐該 Pod 還是驅逐別的 Pod？

騰訊雲容器服務彈性伸縮願景介紹

我們致力於依托騰訊雲原生團隊提供的各種彈性伸縮服務，幫助客戶實現自動化的資源管理，減少人力維護成本以及資源浪費，提升彈性伸縮靈敏度、精確度、自動化、可觀測性。具體可參照的 Kubernetes 降本增效標准指南系列的上一篇文章《資源利用率提升工具大全》。

歡迎廣大讀者試用並且提出您寶貴的建議。