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+ 企業在成本方面的經驗總結， 總體分紅了三個部分：理解成本->控制成本->優化成本。利用雲的彈性伸縮是企業優化成本的三大方法之一。

一、彈性伸縮可下降 IT 設備成本

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

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

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

採用彈性伸縮，配置自動化後，既能夠釋放人員對資源的手動變動的投入成本， 還可讓業務的穩定性進一步提升。

引用自：https://cloud.tencent.com/doc...

彈性伸縮影響成本關鍵點

一、彈性伸縮影響 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.1 自動化程度

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

2. 2 可觀測性

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

是否全部業務都適用彈性伸縮

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

· ClusterAutoScaler: https://github.com/kubernetes...

· HPA: https://kubernetes.io/docs/ta...

· VPA：https://github.com/kubernetes...

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 還提供了使用自定義指標進行彈性伸縮的方法。這麼多的指標該如何選擇？那種指標纔是最合適本身業務的指標？指標的數值設置成多少合適？副本數的變化範圍該如何設置？這裏都是影響彈性伸縮的關鍵因素。

可觀測性的問題

什麼時間由於什麼事情形成了什麼樣的彈性擴縮容結果，這對現有的監控系統來講，還須要作較多努力。由於現有的監控系統一般都是監控某一項指標，它能夠監控副本數的變化，能夠監控彈性伸縮對象的變化，也能夠監控資源使用率的狀況，甚至能夠監控事件/日誌等信息，可是把它們有機的結合在一塊兒，互聯互通倒是一件相對來說較爲困難的事情，當前彈性伸縮的可觀測性方面還須要人工聚合和分析多方面的監控數據，須要高度定製化，對運維人員來講依舊是一件比較繁瑣的事情。

其它問題

一、彈性維度

當前 HPA 監控的是 Pod 的指標，可是有些 Pod 裏存在多個容器，主業務容器高負載的狀況下，若是此時 sidecar 容器低負載，而且此 Pod 下全部容器的平均資源利用率低於引起擴容的閾值時，也沒法引起擴容，配置的彈性伸縮無效。維度方面還有一個高維度的問題：一樣以 HPA 爲例，做用對象是 Pod 級別，但產品一般是以應用爲中心，HPA 的彈性伸縮缺乏「聯動效應」，例如一個 Pod 的擴縮容是否能夠自動引起同一個應用下其它 Pod 的擴縮容？

二、驅逐選擇

一個 Pod 資源利用率很低，若它的資源被彈性收縮後，資源被別的負載侵佔，此時若是這個 Pod 負載忽然變高，但節點又沒有剩餘可用資源，是該驅逐該 Pod 仍是驅逐別的 Pod？

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

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

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