彈性伸縮在雲端計算領域的簡述
彈性伸縮又稱自動伸縮，是雲端計算場景下一種常見的方法，彈性伸縮可以根據伺服器上的負載、按一定的規則、進行彈性的擴縮容伺服器。
彈性伸縮在不同場景下的含義：
- 對於服務執行在自建機房的公司，彈性伸縮通常意味著允許一些伺服器在低負載時進入睡眠狀態，從而節省電費（以及用於冷卻機器的水費和水費）。
- 對於使用在託管在雲上的機房的公司而言，自動擴充套件可能意味著更低的費用，因為大多數雲提供商都基於總使用量而不是最大容量進行收費。
- 即使對於不能在任何給定時間減少執行或支付的總計算能力的公司，它們也可以在低流量時降低伺服器的負載。
- 彈性伸縮解決方案還可以用來替換異常狀態的例項，從而在一定程度上防止硬體，網路和應用程式故障。
- 在生產工作負載經常變化且不可預測的情況下，彈性伸縮可以提供更長的正常執行時間和更高的可用性。
引用自：https://zh.wikipedia.org/wiki/%E5%BC%B9%E6%80%A7%E4%BC%B8%E7%BC%A9
彈性伸縮的三大關鍵要素
1. 基於什麼特徵和屬性
彈性伸縮，顧名思義某種機制能夠讓某些物件進行彈性的擴容和縮容。在雲端計算和容器相關領域也有較多的關於彈性伸縮的能力，有基於系統負載進行彈性擴縮容的，有基於業務日誌進行彈性擴縮容的，也有基於資源預申請進行彈性擴縮容的。最常用的主要有以下記錄：
- 基於系統負載指標擴縮容物件
-
使用場景：當您的應用程式承擔更多負載時，往往需要更多的 CPU 和記憶體資源，這時您可以設定一個 CPU 和記憶體利用率的指標，系統會自動設定副本數以動態承擔不同的負載情況，防止資源利用率過低的資源浪費或負載過高時應用程式無法承擔。
-
限制：有時應用的負載變高但 CPU 和記憶體的利用率並沒有很高，這時基於系統負載指標擴縮容是無效的。並且具體使用哪一種系統負載指標，以及利用率的閾值設定都是比較需要經驗的。
- 基於業務日誌擴縮容物件
-
使用場景：業務的日誌有專門記錄和儲存，並且可以通過日誌分析得到當前應用的實際負載情況，這時可以根據業務的日誌自動擴縮容。
-
限制：需要擁有日誌儲存和分析工具；日誌資訊量普遍很大，基於日誌的彈性擴縮容易誤判、漏判。
- 基於資源請求擴縮容物件
-
使用場景：當有些應用不適合水平擴縮容時，此時可以通過調整對資源的請求量來實現擴縮容。相較方式1是擴容副本數實現水平擴縮容，此時擴容的是容器對資源的請求量，屬於垂直擴縮容。
-
限制：當前這種方式需要重建容器，可能會引發服務的中斷；並且垂直擴容依賴當前容器執行的節點容量大小，如果節點本身沒有剩餘資源，也無法實現垂直擴容。
- 基於事件擴縮容物件
-
使用場景：例如當您的業務需要處理 Kafka 訊息佇列中的任務時，Kafka 中每多一條 topic，需要生成一個新的副本來處理這個 topic；或者資料庫每多一條任務資料，會自動生成一個新的副本來承載這個任務。
-
限制：完全依賴事件的觸發，但事件本身處理時長有長有段，負載程度有高有低，完全相同的副本無法靈活應對。
當然還可以用其他的特徵和屬性進行擴縮容物件，這裡也未全部列舉，具體業務使用彈性伸縮，按需選擇不同的特徵和屬性，特徵和屬性則是彈性伸縮的基礎。
2. 根據什麼策略
基於上述的特徵和屬性獲得了資料之後，那麼就需要一定的策略和判斷規則。 總結來說就是：
- 上述的特徵和屬性在什麼情況和邊界下或進行擴容、擴多少、擴什麼物件、怎麼個擴法？
- 上述的特徵和屬性在什麼情況和邊界下或進行縮容、縮多少、縮什麼物件、怎麼個縮法？
舉個 kubernetes Cluster AutoScaler 的例子：
在騰訊雲容器服務裡節點的縮容策略：
-
CA（Cluster Autoscaler）監測到利用率（取 CPU 利用率和 MEM 利用率的最大值）低於設定的節點。計算利用率時，可以設定 Daemonset 型別不計入 Pod 佔用資源。
-
CA 判斷叢集的狀態是否可以觸發縮容，需要滿足如下要求：
-
節點空閒時長要求（預設10分鐘）。
-
叢集擴容緩衝時間要求（預設10分鐘）。
-
-
CA 判斷該節點是否符合縮容條件。您可以按需設定以下不縮容條件（滿足條件的節點不會被 CA 縮容）：
-
含有本地儲存的節點。
-
含有 Kube-system namespace 下非 DaemonSet 管理的 Pod 的節點。說明：
-
-
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 通過節點池擴節點的時間實際測試資料如下：
測試方案：
-
建立一個 TKE 叢集，分別擴充套件50、100、200節點
-
記錄批量擴充套件從啟動到完成初始化的時間
-
釋放新建立的節點
-
重複測試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 降本增效標準指南系列的上一篇文章《資源利用率提升工具大全》。
歡迎廣大讀者試用並且提出您寶貴的建議。