前言
微服務架構的出現，拆分了龐大的單體應用，讓業務之間的開發與協作變得更加靈活。當面臨業務流量增加的場景時，往往需要對一些應用組件進行擴容。K8S在應用層面提供了HPA，圍繞HPA開源社區延伸出了KEDA這樣的彈性組件，爲微服務應用以業務指標執行彈性策略提供了實現的可能性。但HPA正常工作的一個大前提是需要保證集羣資源充足，爲此用戶必須提前對集羣擴容或時常保持集羣資源冗餘。
對於集羣資源彈性這一命題，K8S社區給出了Cluster Autoscaler（CA）和Virtual Kubelet（VK）兩種解決方案。本文圍繞着微服務應用的形態與特點，剖析了CA與VK各自適用的場景，並總結了微服務架構下應用該如何選擇集羣資源彈性。
微服務應用形態與特點
在微服務應用架構，微服務架構將一個龐大的應用系統拆分成了一個個離散的應用組件，這些組件通過RPC串在一起，對外提供完整的服務。每個組件是離散的，大部分組件可以通過水平擴縮從而調整服務容量。非核心鏈路上的組件，是允許延遲擴容或者不擴容，甚至是縮容讓出資源。
微服務架構下在彈性場景存在五大特徵點：
- 水平伸縮可以調整系統容量：在外部資源充足的情況下，微服務應用組件水平擴容可以提升業務系統的容量。
- 應用間存在依賴關係：單個微服務應用並不能提供完整的服務，擴容單個微服務組件，對系統容量的提升非常有限，往往需要和依賴的服務一起擴容纔能有效提升系統容量。
- 應用本身是無狀態的：若微服務應用本身有狀態，對於水平擴容是不利的，例如對磁盤有強依賴，在擴容場景下需要注意調度親和性以打散Pod，避免同類型應用在同一節點對磁盤IO搶佔，同時縮容時還需要考慮對於狀態數據的處理。因此需要儘量改造成無狀態應用。
- 啓動速度快且服務上下線流量無損：服務上下線流量無損對於自動擴縮容場景至關重要，尤其是在大流量高併發場景下擴容，冷啓動的新Pod很容易被大流量擊潰，並且在健康探針的作用下，擴容出的新Pod不斷被K8s重啓，最終實現的是無效擴容。
- 流量具有周期性：絕大多數微服務架構應用面向的是在線服務，因此可以用二八定律來描述它，即20%的時間處理了80%的流量。對於業務流量而言，最顯著的特徵是存在週期性的變化，且往往這個變化是快速的，所以微服務應用容量擴縮的響應速度對於業務系統的穩定起重要作用。
在微服務應用架構中配置應用彈性時，我們所需要考慮的是選擇合適的指標來衡量系統容量。在配置集羣資源彈性時，我們所需要考慮的是擴容出的計算資源是否能夠滿足應用所需。
K8S 集羣資源彈性技術方案
如前言中所提及，K8S社區給出了兩份“標準答案”的框架，具體的資源彈性實現還依賴雲廠商的技術形態與產品能力。
虛擬節點：VK
Virtual Kubelet是根據Kubelet定義提出的一個“虛擬節點”的概念，允許雲廠商將雲服務包裝成一個“虛擬節點”，加入到Kubernetes集羣中。虛擬節點的背後往往是雲廠商的大資源池，因此理論上我們可以認爲虛擬節點的資源是無限的，當然實際情況還要以雲廠商的規模和產品能力來做判斷。
節點伸縮：CA
Cluster Autoscaler是K8S社區給出的集羣節點伸縮方案。CA監聽集羣中所有Pod事件，當有Pod因爲資源不足而無法調度時，CA會根據伸縮組信息進行模擬擴容並調度計算，最後按照預設的節點擴張策略進行真實節點擴容。同時CA監聽集羣整體資源利用率，當利用率低於預設的縮容閾值時，CA進行模擬縮容調度計算，排除各種影響因素後，CA對可縮容節點執行打污點、排水、刪除這一系列操作。
各方案特點比對
以CA技術形態爲主的真實節點伸縮與以VK技術形態爲主的虛擬節點，這兩種主流技術手段有着各自特點，其中最主要的區別如下：
簡而言之，CA伸縮真實節點以提供完整K8S能力，但響應速度較慢；VK由雲廠商資源池驅動，提供了秒級、無限資源的彈性能力，但不存在真實節點，從而失去了部分K8S特性。
雲廠商解決方案
在VK和CA這兩種主要資源彈性技術方向上，各個雲廠商也紛紛推出了對應產品以提供相應的解決方案。
Serverless方向主要是Serverless Instance與Serverless Cluster。Serverless Instance產品有ECI、Fargate、ACI這類，以快速、無限資源爲顯著特點。Serverless Cluster產品有阿里雲的ASK、谷歌的GKE Autopilot，由雲廠商維護所有集羣資源，對用戶而言開箱即用免運維。
節點伸縮方向AWS還推出了開源組件Karpenter，它繞過了CA中伸縮組的概念，從而讓擴縮容時對於資源的選擇更加靈活。
資源彈性策略選擇與考量因素
對於資源彈性問題，我們首要考慮的是能力。即新的計算資源是否能夠滿足業務使用需求。以VK技術形態爲主的彈性方案，受限於架構設計、安全、性能等因素，天然地缺失了節點特性、容器特權等能力。對於有這部分訴求的業務應用應儘可能地進行改造，以移除相關依賴。
其次我們考慮的是成本與效率。對於企業應用而言，成本預算是不可避免的話題，定價規則以及計費模式不同，最終帶來的資源成本不同，勢必會影響我們對於某項技術的偏好。在當前的Serverless場景下，計算資源大體上採用的還是按量計費模式，對於一些長時運行的應用上，採用預付費模式的計算資源是否能達到更節省成本，還需要我們進一步去調研與嘗試。成本這一層面不僅包含資源成本，還包含運維成本、團隊技術學習成本以及依賴具體雲廠商所隱含的遷移成本等等，這些成本在當下可能對企業的收益影響有限，但從企業長遠發展角度來看，這一部分不可忽視。同時對於技術團隊而言，選擇相應技術方案在節約運維成本和降低團隊學習成本的同時，需要理性看待這部分成本節省與團隊成長所帶來的收益之間的關係。
效率是影響業務收益成本的重要因素之一，從流量來襲，到HPA根據指標做出響應，再到資源彈性做出動作，最後到應用啓動服務上線。這之中每一個環節都存在時間成本，通常情況下這個時間成本越小越好，但也存在一些業務對於時間成本不敏感。對於擴容的每個環節，都延伸出了相應的技術解決方案。如HPA被動式響應，阿里雲推出了AHPA帶指標預測的提前擴容能力。如JAVA應用啓動慢，GraalVM、Alibaba Dragonwell都在冷啓動上做出了一些努力。對於明確業務週期的應用，設置好定時彈性提前擴容，這些問題自然引刃而解。
最後還有一些場景問題需要考慮，對當前應用架構進行升級、遷移、重建時，我們需要把高彈性因素納入考慮範圍，進行合適的技術選型。
綜上所述，我們總結了一張資源彈性選擇策略圖，列舉了通用場景下對集羣彈性選型時需要考慮的因素點。
總結
在微服務架構中，我們需要從業務視角梳理與劃分應用組件。對於核心鏈路組件，要儘可能的保證這些組件的健壯性，並調整成一個高可用、高彈性的架構，從而讓核心業務長久運行。對於外圍鏈路組件，需要權衡成本與高可用、高彈性帶來的效益。
在K8S資源彈性問題上，現有技術手段中，我們需要考量兼容性、效率與成本，從而選擇合適於自身業務的集羣彈性策略。
阿里雲的微服務應用託管平臺 EDAS 在資源彈性場景下，不僅針對性的對於獨享資源型業務虛擬機 ECS 集羣，池化資源型業務 K8S 集羣，以及全託管免運維的阿里雲 Serverless 集羣均做了很好的支持；同時基於結合阿里雲容器服務和 ECI ，同時提供了針對池化資源 + Serverless Instance 的形態場景支撐，讓我們微服務的業務在可以充分利用雲技術所帶來的技術紅利。
本文爲阿里雲原創內容，未經允許不得轉載。