鄭韓

貨拉拉  技術中心  核心基礎設施部

架構師

• 在貨拉拉主導了Kubernetes從0到1落地全過程，致力于探索符合貨拉拉特點的云原生之道。

今天的分享主要包含以下五個方面的內容：

一、貨拉拉的基本情況介紹

二、基于K8S的成本優化手段

三、符合貨拉拉特點的成本優化路線

四、競價實例成本優化實踐

五、定時擴縮容成本優化實踐

一、貨拉拉的基本情況介紹

在探討成 本優化 之前 ，我們 先來 看看 貨拉拉 的基 本情 況，讓 大家 對貨拉拉有一個初步的認識。

• 貨拉拉的生產環境是100%跑在公有云上的，所以我們的成本優化也是針對公有云。
• 貨拉拉是一間全球化的互聯網公司，我們的業務遍布世界各地，在新加坡、印度、拉美和國內都有集群，所以我們必定會有多個集群跑在不同的云廠商上，這就決定了我們的所有方案都必須是通用的，不綁定任何云廠商的。
• 貨拉拉的流量比較規律，高峰低谷也比較明顯，貨運行業一般沒有什么突發事件導致流量突增，不像微博這種服務，某個明星突然丟出一個瓜就引來一大波吃瓜群眾，導致流量突增。同時，同城貨運是個日出而作、日落而息的行業，所以白天高峰期比較穩定，晚上低峰期流量也會降到很低，這樣的流量特點可以使我們通過簡單的預測算法就達到較好的預測效果，同時低峰期的成本優化也將會是我們的優化重點。
• 貨拉拉也會有大量的大數據離線任務，大數據的離線任務占了我們公司大概一半的計算資源，并且高峰期正好是業務的低峰期，所以如何通過離在線的混合部署提高整體資源利用率也是我們的優化方向之一。

二、基于K8S的成本優化手段

講完貨拉拉的基本情況，我們再來看一下云原生時代下，一般有哪些成本優化手段，我把主流的成本優化手段分成四類：

• 私有云的服務器成本優化
• 公有云的服務器成本優化
• 服務器利用率優化
• 服務性能優化

由于貨拉拉是100%跑在公有云上，所以我們本次不討論私有云方面的優化。而服務性能優化是非常個性化的優化，所以也不在我們這次討論范圍內，我們這次主要討論公有云的服務器成本優化和服務器利用率優化。

1、公有云的服務器成本優化

所謂公有云的服務器成本優化，其實就是研究如何在保證滿足公司實際需求的前提下，以盡可能低的價格買到服務器實例。

公有云的服務器，一般有三種優惠模式：

• 包年包月： 按固定周期購買一臺服務器，這種模式穩定性高，價格實惠，但是彈性不足，特別是晚上想縮容根本縮不動。
• 節省計劃： 這種模式其實就是通過承諾每小時最低消費換取折扣，穩定性有保障，服務器也可以隨意伸縮變換，但是每小時的總消費不能低于承諾消費，一般來講公司都會按最低需求購買。
• 競價實例： 競價實例就是云廠商將閑置的實例通過固定折扣或競價的方式出售，折扣一般能到一折或兩折，競價實例有最便宜的價格以及不輸按需實例的靈活性，但是不穩定，隨時有被回收的風險，使用這種實例對公司的技術能力和服務質量都有較高要求。

2、服務器利用率優化

下面我們再來看看提升服務器利用率的一些常用優化手段。

1）合理request/limit

如何科學合理地配置request/limit是每個公司使用k8s都會遇到的問題，request調整太大節點利用率低，調整太小服務容易OOM或者被驅逐。一般來講優化方式分兩步，第一步是根據應用畫像和過往負載設置一個初始值，第二步是建立巡檢機制定期巡檢，根據實際負載和策略動態調整request/limit配置。

2）HPA 

水平POD自動擴縮容，提前配置好指標和閾值，當指定指標超過閾值時自動擴容，低于閾值時自動縮容，比如CPU高于35%就擴容。HPA在應對突發流量時很不錯，但是HPA的擴容有一定的滯后性，如果負載增長過快，可能會出現來不及擴容的情況，導致短時間內故障或雪崩。

3）CronHPA 

定時水平擴縮容，這種很容易理解，設置時間點和副本數，到擴容時間點就擴容，到縮容時間點就縮容，適用于可預期或計劃內的場景。

4）智能調度 

智能調度是指根據公司實際需求增強調度器。k8s默認的調度器比較簡單，但一般不能完全符合公司需求，并且有較大的優化空間，例如實際負載感知、權重計算增加更多維度、磁盤GPU、優化堆疊策略等，通過優化更符合公司實際情況的調度算法，可以有效地提升節點資源利用率。

5）在離線混合部署 

離在線混合部署是利用離線任務可以中斷以及高峰期與在線服務相反的特點，充分利用服務器算力的一種方式。由于離線任務一般是在晚上運行，如果將離線任務和在線服務整合進一個k8s集群，那剛好可以彌補在線服務低峰期時的資源浪費，同時，如果離線任務可以支持隨時中斷，那通過自動避讓以及資源隔離等手段，還可以實現在高峰期利用空閑資源運行離線任務，榨干服務器最后一滴性能，但是這項能力在大幅度提升服務器利用率的情況下，也帶來了巨大的技術挑戰。

三、符合貨拉拉特點的成本優化路線

通過結合上面說的業界最佳實踐和貨拉拉的實際情況，我們探索出了以下這條貨拉拉成本優化演進路線。

首先我們通過節省計劃以相對優惠的價格保證了貨拉拉的基礎算力和穩定性，然后使用價格低廉且伸縮靈活的競價實例來提供彈性伸縮的算力，當然我們也做好了準備面對競價實例帶來的穩定性挑戰，到此基本上解決了服務器價格的優化問題。

接下來我們就需要解決服務器利用率的問題。

首先我們需要解決低峰期資源浪費的問題。剛剛講過貨拉拉的流量是很有規律的，所以我們通過自研CronHPA實現可預測和計劃內的彈性伸縮，同時通過HPA實現流量突增時的緊急擴容。這是我們已經做完的內容。

我們目前正在做的是智能request，通過應用畫像和過去的指標計算出合理的request和limit，期望通過這個功能提高高峰期的節點資源利用率。

當我們完成前面這幾項后，我相信我們已經極大的提高了節點的資源利用率，剩下的就是走完最后一公里，通過智能調度和在離線混合部署榨干服務器的最后一滴性能，我們計劃在2023年完成這些功能，之后再整體不斷優化。

接下來我將重點介紹下我們已經做完的兩點優化， 競價實例 和 定時擴縮容。

四、競價實例

1、什么是競價實例

我們都知道云廠商提供的服務器實例都是他們的物理機房虛擬化出來的，那既然是物理機房，服務器就是相對固定的，能夠提供的算力也是固定的，但是我們購買的實例數卻是浮動的，所以云廠商總有些算力是閑置的，而閑置的服務器產生的經濟價值就是0，所以云廠商就將這些閑置的算力拿出來打折或競價銷售，這些打折或競價銷售的實例就是競價實例。

競價實例的由來所有云廠都是一樣的，但是各個云廠商對競價實例的價格計算方式卻存在差異，主要有兩種方式：一種是 固定折扣 ，基本上都是打兩折，這個很好理解；另外一種是 競價 ，競價比較難理解。下面我介紹一下競價的基本過程。

2、競價方式介紹

我們購買競價實例時，會填寫一個可接受的最高價格，然后云廠商會根據所有人的報價和庫存情況計算出一個價格，出價高于或等于這個價格的人就能以這個價格買到實例，低于價格則購買失敗。上圖有個細節不知道大家有沒有發現，整幅圖只有定價這里我是用了黑色，那是因為這個價格到底是怎么計算出來的完全是個黑盒，其中的算法只有云廠商自己知道，我們只能知道他最后得出來一個價格，這個價格最低可以低到1折，最高可以等于沒打折。

3、競價實例原理

下面我講講使用競價實例的基本原理。

首先我們帶著機器型號和一個能接受的最高價向云廠商提出購買申請，云廠商如果判斷指定型號有庫存并且價格在我們的報價之下，則給我們分配實例，購買完成，這時我們就可以正常使用了。

在我們正常使用該競價實例的過程中，云廠商會一直監控庫存和價格變化，當發現價格實時價格高于我們的報價或庫存不足時，將向我們發送中斷信號，收到信號后我們需要做一些措施保證該實例被回收不影響業務，在我們收到中斷信號的幾分鐘后，實例就會被回收。

不同云廠商在回收機制上有些不同。aws會有預測算法，在預測到庫存不足時提前通知你，讓你有更多反應時間；阿里云有一小時保護機制，競價實例運行的第一個小時能保證不被回收。但是都不會等我們做完我們想做的事再回收，無一例外。比如我們想再買臺機器將服務遷移過去，但是可能還沒遷移就被回收了，所以我們應對突然中斷的手段一定要足夠快，才能避免對業務產生影響。

4、競價實例特點

介紹完競價實例的基本原理，我們再總結一下競價實例的特點：

• 性價比高。 和按需實例對比，競價實例通常僅是其價格的10-20％。和預留實例對比，競價實例通常僅是其價格的30-60％。
• 競價實例是將閑置資源打折出售。 當沒有閑置資源時，也就無法購買了，不是你什么時候想買云廠商都有貨。
• 隨時中斷。 云廠商會動態檢測當前的市場價格和庫存，一旦庫存不足，或者你的出價小于市場價格，云供應商可以在任何時候回收這些實例。

性價比高是我們使用競價實例的目標，庫存沒保障和隨時中斷是我們需要解決的問題。

5、競價實例結合K8S 落地

下面我將介紹競價實例如何結合K8S落地，以及如何解決競價實例帶來的穩定性問題。

首先從圖中我們可以看到，我將k8s的節點分成了多個節點組，然后通過cluster autoscaler進行彈性伸縮。節點組中有按需實例的節點組，也有競價實例的節點組，這是因為并不是所有服務都適合部署在競價實例上，我們需要一些更穩定性的節點部署跑不適合跑在競價實例上的服務，同時我們也需要在競價實例庫存不足時有按需實例的節點組提供足夠的算力支持業務正常運行。

然后我們再來看中斷回收部分。當競價實例需要中斷時，云廠商會發送一個中斷信號，如果是托管集群，云廠商會自己處理這個中斷信號，幫我們起一個新的節點并回收舊節點，但如果是自建集群，我們則需要自己實現一個中斷信號處理服務，在該服務中處理中斷問題。

在貨拉拉雖然我們是托管集群，但是我們還是自己開發了一個notify handler，該服務主要是為了收集中斷信號，用于監控中斷頻率以便后續用于告警和觸發應急預案。

整體架構還是比較簡單的，但是我們在實際使用過程中還是發現有不少地方需要優化，下面我就介紹下幾個主要的優化點。

6、競價實例優化點

1）增加競價實例的型號

上面我們講過競價實例的庫存沒有保障，所以我們能做的就是擴大這個池子，池子越多，庫存不足的概率就越低，所以我們創建的節點組需要覆蓋更多的可用區和更多的實例型號。但是需要注意的是，受到cluster autoscaler的限制，同一個節點組里的節點cpu和內存必須一致。

2）設置節點組優先級

目前我們的集群中有按需實例節點組和競價實例節點組，我們希望資源不足時優先彈出競價實例，只有當競價實例無法彈出時才彈出按需實例，這樣可以確保最大化的利用競價實例，同時又能確保競價實例庫存不足時及時彈出按需實例保證業務穩定運行。

這里用到的是cluster autoscaler的優先級配置，我們在cluster autoscaler的一個configmap中配置節點組的優先級，將競價實例的優先級設置成20，其他節點組是10，這樣ca就會優先彈出競價實例，彈不出競價實例時彈出按需實例。

3）設置pod親和性

由于競價實例隨時可能被中斷，且一旦中斷很有可能是同一個型號的節點同時被中斷，所以我們要避免把雞蛋放在一個籃子里，盡量把同一個服務的pod分散在不同實例、不同型號甚至是不同的可用區中，避免某一個服務所有的pod被同時驅逐，造成服務不可用。

這里用到的就是pod的親和性配置。從配置上我們可以看到，我們給了可用區最大的權重，其次是實例型號，最后是實例名，這樣k8s會盡量將同一個app的pod分散到不同的可用區，如果沒有合適的節點則分散到不同的實例類型，依然沒有合適的再分散到不同的實例，這樣可以最大化地打散同一個服務的pod，避免由于競價實例中斷導致服務不可用。

4）配置PDB

盡管我們之前已經做了很多措施，避免同一個服務的pod在同一時間由于實例中斷被驅逐，但是沒有哪一項是能100%避免這種情況的，所以我們需要再上一層保險，這層保險就是PDB，通過PDB我們可以設置同一個服務的pod必須保證同一時間有多少副本是可用的。像下面這張圖的配置里面就保證了服務70%的副本是正常的，這樣就算遇到需要同時驅逐的情況，k8s也會在強制保證至少有70%的副本可用的情況下滾動驅逐，確保整個過程服務都是可用的狀態。

但是需要注意的是，這個配置會導致本來可以并發的驅逐變成串行，這會影響到排空節點的時間，所以這個需要服務的啟動速度足夠快，在節點被真正回收前執行完整個遷移過程。

5）利用低優先級的pause pod給集群預留空間

上面我們講過，競價實例從收到中斷信號到真的被回收就那么兩三分鐘時間，時間一到不管我們是什么情況實例都會被回收，所以我們必須保證在實例被回收前完成整個遷移動作，那這兩三分鐘的每一秒是很珍貴的，我們必須想方設法提高遷移的效率，但是創建一個新的節點少則幾十秒，多則一兩分鐘，等新節點準備好其實已經浪費了很多時間，所以我們需要想辦法在收到中斷信號的時候就直接將舊節點排空，但是要排空節點就需要保證集群隨時有足夠的空間運行被驅逐的pod。而保證有足夠空間的做法就是我們現在講的這個利用低優先級的pause pod給集群預留空間。

k8s里面的pod有一個優先級的概念，高優先級的pod可以在資源不足時搶占低優先級的pod。從下面這張圖我們可以看到，我們在Node1和Node2都放置了一些低優先級的Pod，當Node1被中斷回收后，高優先級的pod會直接搶占低優先級的pod從而實現快速啟動，而不需要等新的節點準備就緒，而低優先級的pod則會全部變成pending狀態觸發擴容或等待新的節點ready后啟動，從而重新創建了一塊預留空間。

下面是具體的yaml，這里面優先級不必非得是-1，只要保證比正常pod的優先級小即可，低優先級pod主要是要把PriorityClassName填對，然后根據實際情況設置副本數和request即可。

7、不適宜部署在競價實例的服務

• 單副本服務。 這個不用解釋大家都明白。
• 啟動時間過長的服務。 因為需要保證服務能在實例被回收之前啟動完成，所以服務的啟動時間不能太長。
• 無法容忍任何非優雅停止的服務。 我們需要認識到不管我們做了多少措施，都不能完全杜絕實例在沒有排空之前就被回收，所以對于不能優雅停止無法容忍的服務也不適合部署在競價實例上。
• 有狀態的服務。 有狀態的服務遷移起來遠沒有無狀態的服務靈活，為避免出現各種各樣的問題，也不建議有狀態的服務部署在競價實例上。

五、定時擴縮容

1、背景

彈性伸縮的本質是為了提高服務器的利用率，那我們來看看貨拉拉一個沒有任何優化的集群的CPU利用率是怎么樣的。

從這個圖我們可以看到，這個集群在白天最高峰時的CPU利用率是35%，半夜低峰期的CPU利用率卻只有2.5%，2點的時候還有一個小高峰，是因為我們在這個時候有大量定時任務在執行，可以先不用考慮。目前這個利用率如果是放在虛擬機時代，還算是一個比較能接受的利用率，但是放在云原生時代，我們還是有很多手段可以提升這個利用率。

我們的優化目標是希望把高峰期節點CPU平均利用率達到50%，低峰期節點CPU平均利用率達到30%。

2、默認HPA的不足

按照正常做法，我們把HPA套上去應該就可以解決這些問題，隨著流量上升自動擴容，流量下降后自動縮容，事實上我們也這樣做過，但是很快就發現了問題。

第一個問題是 擴容有一定滯后。 HPA需要等負載上來觸發閾值后才開始擴容，而負載升得太快可能會導致擴容不及時，我們每天早上9點和下午2點都有一波很迅速的流量上升，這時HPA會大量擴容，但是大量擴容就需要先大量擴節點，導致這兩個時間點擴容總是太慢，每天這兩個時間點都會有些報錯，然后觸發告警。

第二個問題是 擴容閾值受到限制 。為了白天流量上升時擴容盡量穩定，我們不能把最小副本數設置得太低，這就導致我們晚上的CPU利用率上不去。而為了擴容及時，我們也不能把CPU的閾值設置得太高，因為越高就意味擴容時反應約遲鈍，而設置得太低又導致高峰期CPU利用率上不去，例如我們在HPA把CPU的閾值設置為35%,那我們的pod的CPU使用率基本上都不能超過35%，因為超過就會擴容，然后把CPU利用率拉下來。

第三個問題是 擴縮容時機無法控制。 HPA是完全根據配置的指標和閾值來擴容，無法根據企業特點定制策略，例如貨拉拉的流量白天還是比較穩定的，我們在白天高峰期時就算浪費點資源也不希望出現過多擴縮容影響穩定性，但是HPA并沒有提供這樣的配置。

3、CronHPA+HPA

結合我們對HPA的實踐經驗和貨拉拉的業務特點，我們總結探索出了符合貨拉拉特點的水平彈性伸縮方式，那就是自研的CronHPA+HPA組合。

CronHPA是根據設定好的時間調整對應HPA 的最小副本數，實現可預期或計劃內的彈性伸縮。

考慮到貨拉拉流量規律的特點，我們在自研的CronHPA中通過定時+過往指標分析+簡單預測算法可以做到比較高質量的預擴容以及定時縮容。例如早上9點流量開始快速上升，我們可以在7點到8點就提前把集群擴容到高峰期的水平，晚上10點后流量已經下降了很多，我們可以放心地縮容，并且有了預擴容打底，我們晚上可以把副本數縮到一個極低的水平而不用擔心白天來不及擴容。

CronHPA沒有直接操作deployment的副本數，而是操作HPA的最低副本數，是因為盡管CronHPA可以覆蓋我們99%的擴縮容需求，但是仍然需要HPA的自動擴縮容來解決1%偶發流量突增的問題，盡管我們很少遇到流量突增的情況，但是有了HPA可以讓我們在縮容或者設置高峰期副本數時不必為偶發的流量突增添加額外的buff，從而提升整體的資源利用率。

4、架構

講完定時擴縮容的原理，我們再來講講定時擴縮容的架構。

我們在K8S部署了一個自研的hll-cronhpa-controller，并且添加了一個CronHPA的CRD，用戶主要是設置CronHPA的CRD來設置彈性伸縮，并不直接設置HPA和deployment副本數，hll-cronhpa-controller會監聽CronHPA CRD對象的變化，當發現有新增或者更新時，就會同步修改HPA對象，其中除了最小副本數其他都是直接透傳，CronHPA的所有業務邏輯最終都會體現在HPA最小副本數的變化上。

而CronHPA的業務邏輯主要是hll-cronhpa-controller根據cronHPA對象的配置，從Prometheus拉取過往指標分析，同時結合從應用管理平臺拉取的應用畫像以及從配置中心拉取的擴縮容策略綜合分析后在合適的時間點為對應的HPA對象設置一個合適的最小副本數，這么說可能有點抽象。

舉個例子，假設我目前有個服務設置了晚上需要縮容，我們通過分析該服務過往夜間資源利用率得出晚上可以縮到剩下2個副本，同時我們從應用畫像中查到該服務是核心服務，而配置中心的擴縮容策略是核心服務最低不能少于5個副本，那綜合分析我們夜間需要給他設置的副本數就是5。

5、實現路徑

下面講一下我們的實現路徑。我們最開始自研的時候就確定了cronHPA+HPA的架構。

第一階段是純手工配置的，我們通過分析流量設置了一個全局縮容時間點和全局擴容時間點，然后各個服務根據經驗人工估算出一個縮容比例。這個階段由于全局是在同一個時間點同時擴縮容，在擴容瞬間對基礎設施的壓力比較大，同時人工估算出來的縮容比例還是過于保守。

第二階段是根據過往指標分析自動設置擴縮容的時機，這樣可以有效分散擴縮容壓力，同時讓擴縮容時機更為合理。例如有些服務可能晚上6點就沒流量了，階段一還需要等到晚上10點才縮容。

第三階段是根據appid自動計算縮容比例。人工估算縮容比例還是過于保守，例如高峰期100個pod，晚上其實可能只需要10個，但是一般人工評估只會縮到50個，但是通過算法自動計算就會相對科學很多，同時自動計算還可以通過分析過往指標不斷修正，例如某個pod經過計算晚上縮容到2個pod，但是通過分析過往指標發現過去7天晚上都會通過HPA擴容到3個pod，那第八天就把縮容副本數自動調整到3個。

第四階段是自動識別低峰期。原來手工設置低峰期時間段，程序在從這個時間段里選擇擴縮容時機，到了這一階段，我們可以自動識別每個服務自己的業務低峰期，做到個性化縮容。

第五階段是自動分階段擴縮容，前幾個階段都是確定一個擴縮容時間點，直接把副本數擴縮到目標副本數，但流量其實是逐漸變化的，通過這個階段我們可以實現服務在高峰期來臨前隨著流量上升逐步把副本數提上去，而在低峰期，隨時流量降低逐步降低副本數，這個階段與HPA最大的不同在于，HPA是基于指標和閾值，而cronHPA是基于預測。

6、未來規劃

最后講一下我們對于彈性伸縮的未來規劃，我們希望未來彈性伸縮可以形成這樣一個機制，服務初始化時可以通過應用畫像自動設置reqeust/limit和副本數，然后自動在高低峰通過過往指標分析和算法實現預擴容和及時縮容。

如果遇到突發流量可以通過原地升配實現快速縱向擴容，原地升配對比VPA最大的區別在于不用重啟pod，所以可以做到秒級擴容。如果所在節點資源不足則通過HPA橫向擴容，同時根據指標分析不斷修正服務的reqeust/limit和副本數，實現全自動的彈性伸縮閉環。