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

語言: CN / TW / HK

背景

作業幫的服務端技術體系正向著雲原生化發展,提升資源利用率是雲原生技術棧的核心目標之一,資源利用率的提升意味著以更少的計算節點用承載更多的應用例項,極大的降低資源開銷。而 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

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

點選此處,快速瞭解阿里雲容器服務 ACK 彈性排程方案詳情!

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