## 背景

作業幫的服務端技術體系正向著雲原生化發展，提升資源利用率是雲原生技術棧的核心目標之一，資源利用率的提升意味著以更少的計算節點用承載更多的應用例項，極大的降低資源開銷。而 Serverless 具有彈性伸縮、強隔離性、按量計費、運維自動化等特點，帶來了降低交付時間、降低風險、降低基礎設施成本、降低人力成本等核心優勢。Serverless 化一直是作業幫基礎架構探索的核心方向。Serverless 化長期來看有兩種方案，一種是函式計算，一種是 Kubernetes Serverless 虛擬節點。Kubernetes Serverless 虛擬節點對已經執行在 Kubernetes 上的服務無實際使用差異，使用者體驗較好，業務服務使用無感知，可以由基礎架構進行排程遷移，阿里雲 ECI 就是一種典型 Kubernetes 虛擬節點方案。

所以在 2020 年，我們就開始嘗試將部分密集計算排程到 Serverless 虛擬節點上，用 Serverless 虛擬節點底層伺服器的強隔離能力來規避服務間相互影響；2021 年，我們就將定時任務排程到 Serverless 虛擬節點，替代節點擴縮容，應對短期執行任務，提升資源利用率降低成本；2022 年，我們開始將核心線上業務排程到 Serverless 虛擬節點，而線上業務是最敏感、使用者易感知的。同時線上業務有著明顯的波峰和波谷，在高峰期彈性排程到 Serverless 虛擬節點將帶來巨大的成本收益，隨之而來的要求也越高，儘可能保證線上業務在效能、穩定性上和物理伺服器效果一致，業務觀測感知上一致，也就是讓上層業務服務感知不到 Serverless 虛擬節點和物理伺服器之間的差異。

### Kubernetes Serverless 虛擬節點

虛擬節點並不是真實的節點，而是一種排程能力，支援將標準 Kubernetes 叢集中的 pod 排程到叢集伺服器節點之外的資源中。部署在虛擬節點上的 pod 具備裸金屬伺服器一致的安全隔離性、網路隔離性、網路連通性，又具有無需預留資源，按量計費的特性。

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

### Kubernetes Serverless 虛擬節點 成本優勢

作業幫的大部分服務都已經完成容器化，線上業務有著典型的高峰期，且高峰期持續時間較短（4 個小時/每天），全部使用裸金屬伺服器，高峰期伺服器平均負載接近 60%，而低峰期負載只有 10% 左右。此場景就非常適合 Serverless 的彈性伸縮落地，可以做一個簡單的計算：假設全部使用自有伺服器每小時的成本為 C，平均每天高峰期的時間為 4 小時，使用 Serverless 的單位時間成本為 1.5C，那麼：

-   全部使用自有伺服器的總成本為 C * 24 = 24C\

-   保留 70% 的自有伺服器，高峰期增加 30% 的 Serverless 來應對，此時的總成為：C * 24 * 0.7 + 1.5C * 4 * 0.3 = 18.6C\

理論上高峰期波峰部分使用 Serverless 可降低的成本為：(24C - 18.6C) / 24C = 22.5%， 可見，將線上服務高峰期彈性排程到 Serverless 可以節省大量的資源成本。

## 問題和解決方案

雖然 Kubernetes Serverless 虛擬節點擁有諸多優點，但也仍存在一些問題，目前主要遇到以下一些問題：

### 排程和管控問題

排程層面主要解決兩個問題：一是擴容時建立 pod 基於何種排程策略排程到虛擬節點，二是縮容時應優先縮虛擬節點上的 pod。這兩種能力在我們當前使用的 Kubernetes 版本中能力是不足的。

#### 擴容/縮容排程策略

擴容排程策略應該由基礎架構和運維來統一把控，與業務關聯度不大，因為業務方不知道底層資源層還有多少伺服器計算資源可以被利用。我們理想情況下，是希望當本叢集池內，物理伺服器資源達到利用率瓶頸後，擴容到 Serverless 虛擬節點上。這樣就可以即沒有容量風險也可以獲得成本優勢。

業界使用虛擬節點的演進過程：

1.  虛擬節點和標準節點是完全分開的，只能排程到指定的池子。

2. 使用者不用指定 selector，當 pod 因固定節點資源不足排程 pending 的時候，會自動排程到虛擬節點上，該過程會有延遲。

3. 雲廠商比如（阿里雲 ACK Pro）的排程器會當資源不足時自動排程到虛擬節點上，這個過程自動且無延遲，相對比較理想。

但我們的業務場景需要更精細化的資源管理策略，需要我們更緊密結合資源管理述求的排程策略，所以我們基於阿里雲 ACK 的能力之上研發了我們自己的方案：

擴容：基於線上服務的波峰波谷，進行預測推薦排程，預測高峰該服務能在叢集物理機上執行的副本數閾值，透過自研排程器將超過閾值的 pod 排程到虛擬節點上。該閾值資料即叢集物理機上執行副本的最優解，既能滿足物理機叢集的利用率也能滿足效能要求。閾值太低則物理機資源浪費，閾值太高則物理機部署密度太高，資源利用率過高，影響業務。

縮容：縮容時優先縮 Serverless 虛擬節點上的 pod 很好理解，因為常備的資源池是包年包月的單價更低，虛擬節點上的資源是按量計費的單價較高，優先縮虛擬節點上的 pod 來達到成本最優；我們透過自研排程器對虛擬節點上的 pod 注入自定義的註解，修改 kube-controller-manager 的縮容邏輯，將帶有虛擬節點自定義註解的 pod 置於縮容佇列的頂部，來完成優先縮容虛擬節點上的 pod。

在管控面 DevOps 平臺除了支援自動計算排程到虛擬節點的閾值，還支援手動設定以便於業務進行更精細的調控。排程到虛擬節點的能力可以結合 hpa、cron-hpa 同時使用，來滿足業務更靈活的需求。管控面還支援故障場景下一鍵封鎖虛擬節點，以及應對更極端情況（如機房整體故障）的多雲排程能力。

### 觀測性問題

我們的觀測服務都是自建，比如（日誌檢索、監控報警、分散式追蹤）。因為是虛擬節點，pod 裡跑的監控元件，日誌採集，是由雲廠商內建的。我們需要保證業務感知層面上，pod 執行在 Serverless 虛擬節點和物理伺服器上一致，所有就有一個轉化到我們自有觀測服務的一個過程。

監控：在監控方面，雲廠商虛擬節點完全相容 kubelet 監控介面，可以無縫接入 Prometheus。完成 pod 實時 CPU/記憶體/磁碟/網路流量等監控，做到了和普通節點上的 pod 一致。

日誌：在日誌採集方面，透過 CRD 配置日誌採集，將日誌傳送到統一的 Kafka。透過我們自研了日誌消費服務，消費各雲廠商和自有節點上的日誌。

分散式追蹤：在分散式追蹤方面，由於無法部署 daemonset 形式的 jeager agent，我們 jeager client 端做了改造，透過環境變數識別 pod 執行的環境，如果是在虛擬節點上則跳過 jeager agent，直接將分散式追蹤的資料推送到 jeager colletror。

### 效能、穩定性及其他問題

Serverless 虛擬節點底層效能差異：由於底層計算資源規格的不同以及虛擬化層帶來的開銷，效能可能和裸金屬伺服器有所差異，這就需要對時延非常敏感的業務，在上虛擬節點之前進行充分的測試和評估。

雲伺服器庫存風險：高峰期大量擴容，如果雲廠商某個規格的的資源池水位低，可能會擴不出來指定規格的資源。這裡我們是開啟自動升配，也就是申請 2c2G，理論上應該匹配 2c2G 的 ECI，如果沒有庫存，會匹配到 2c4G 的 ECI。以此類推。

問題定位排查：因為虛擬節點本質上使用的是雲廠商資源池，不在我們自身的管控範圍內，當業務出現異常時雖然可以自動摘流，但無法登陸到機器排查問題，比如像檢視系統日誌、取回 core dump 檔案等操作就比較困難。在我們的建議下，雲服務（阿里雲 ECI）已經支援將 core dump 自動上傳到 oss了。

## 規模和收益

目前方案已經成熟，高峰期已有近萬核規模的核心鏈路線上業務執行在基於阿里雲 ACK+ECI 的 Kubernetes Serverless 虛擬節點。隨著業務的放量，未來執行在 Serverless 虛擬節點上的服務規模會進一步擴大，將節省大量的資源成本。

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

點選[**此處**](https://help.aliyun.com/document_detail/212216.html)，快速瞭解阿里雲容器服務 ACK 彈性排程方案詳情！

*本篇轉載自「作業幫技術團隊」，更多相關技術實踐分享可前往該公眾號進行查閱。*

作業幫線上業務 Kubernetes Serverless 虛擬節點大規模應用實踐

相關文章