*頭：潘俊峰*

## 前言

微服務架構的出現，拆分了龐大的單體應用，讓業務之間的開發與協作變得更加靈活。當面臨業務流量增加的場景時，往往需要對一些應用元件進行擴容。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 叢集中。虛擬節點的背後往往是雲廠商的大資源池，因此理論上我們可以認為虛擬節點的資源是無限的，當然實際情況還要以雲廠商的規模和產品能力來做判斷。

![1.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0b187c0346dd4e4498629eb07467868e~tplv-k3u1fbpfcp-zoom-1.image "1.jpeg")

### 節點伸縮：CA

Cluster Autoscaler 是 K8s 社群給出的叢集節點伸縮方案。CA 監聽叢集中所有 Pod 事件，當有 Pod 因為資源不足而無法排程時，CA 會根據伸縮組資訊進行模擬擴容並排程計算，最後按照預設的節點擴張策略進行真實節點擴容。同時 CA 監聽叢集整體資源利用率，當利用率低於預設的縮容閾值時，CA 進行模擬縮容排程計算，排除各種影響因素後，CA 對可縮容節點執行打汙點、排水、刪除這一系列操作。

![2.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ded0ffe72d584c18bb69b524d4ed7ba6~tplv-k3u1fbpfcp-zoom-1.image "2.jpeg")

### 各方案特點比對

以 CA 技術形態為主的真實節點伸縮與以 VK 技術形態為主的虛擬節點，這兩種主流技術手段有著各自特點，其中最主要的區別如下：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5958705b6a724ae3a6fc1b2d6b655ef7~tplv-k3u1fbpfcp-zoom-1.image "3.png")

簡而言之，CA 伸縮真實節點以提供完整 K8s 能力，但響應速度較慢；VK 由雲廠商資源池驅動，提供了秒級、無限資源的彈效能力，但不存在真實節點，從而失去了部分 K8s 特性。

### 雲廠商解決方案

在 VK 和 CA 這兩種主要資源彈性技術方向上，各個雲廠商也紛紛推出了對應產品以提供相應的解決方案。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6557ac6922914febb465a7aef65d724d~tplv-k3u1fbpfcp-zoom-1.image "4.png")

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 都在冷啟動上做出了一些努力。對於明確業務週期的應用，設定好定時彈性提前擴容，這些問題自然引刃而解。

最後還有一些場景問題需要考慮，對當前應用架構進行升級、遷移、重建時，我們需要把高彈性因素納入考慮範圍，進行合適的技術選型。

綜上所述，我們總結了一張資源彈性選擇策略圖，列舉了通用場景下對叢集彈性選型時需要考慮的因素點。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/287ab3b970084d71ae2b3466193428b1~tplv-k3u1fbpfcp-zoom-1.image "5.png")

## 總結

在微服務架構中，我們需要從業務視角梳理與劃分應用元件。對於核心鏈路元件，要儘可能的保證這些元件的健壯性，並調整成一個高可用、高彈性的架構，從而讓核心業務長久執行。對於外圍鏈路元件，需要權衡成本與高可用、高彈性帶來的效益。

在 K8s 資源彈性問題上，現有技術手段中，我們需要考量相容性、效率與成本，從而選擇合適於自身業務的叢集彈性策略。

> 阿里雲的微服務應用託管平臺 EDAS 在資源彈性場景下，不僅針對性的對於獨享資源型業務虛擬機器 ECS 叢集，池化資源型業務 K8s 叢集，以及全託管免運維的阿里雲 Serverless 叢集均做了很好的支援；同時基於結合阿里雲容器服務和 ECI ，同時提供了針對池化資源 + Serverless Instance 的形態場景支撐，讓我們微服務的業務在可以充分利用雲技術所帶來的技術紅利。

微服務應用視角解讀如何選擇 K8s 的彈性策略

相關文章