1。前言

近年，雲原生技術得到了快速發展和廣泛應用，興盛優選雲原生團隊及時擁抱變化，基於雲原生實現了多雲平臺（簡稱：星斗雲），做了很多業務場景落地的實踐，並幫助公司實現了非常不錯的降本增效，本文將重點將星斗雲遇到的大大小小問題與挑戰，及對應優雅解決方案一併呈現給大家。

2。背景

隨著業務方容器化改造越來越深入，星斗雲將多套叢集做了合併管理，叢集的規模變得非常大，遇到的問題也越來越棘手，其中我們以降本增效為導向，聚焦收斂後，整理了一些代表性問題，如下：

圖示說明：

1。殘退複用：公司運轉多年，存在不少老舊機器、待退役機器或三無組裝機，如何透過“法力無邊”的雲原生技術納管複用？

2。穩定保障：星斗雲除了支援無狀態業務部署外，還為業務提供了非常多的有狀態元件（如：ceph、kafka、es、hbase、rocketmq、redis等）部署管理，因上面提到的老舊殘退機器時不時會出現故障，引起響應的有狀態服務大受影響，故亟需做好穩定性保障？

3。耗用管控：業務做容器化改造期間，暫未限制預算與使用，業務服務部署時，資源耗用鮮少評估，也無限制，造成大手大腳，如何管控？

4。資源挖掘：資源利用再利用，公司總希望每一分成本都花在刀刃上，採購一臺機器幾十萬，如何儘可能深入挖掘，高效利用？

5。閒置回收：業務每天開發、測試發版成千上萬次，每天生成很多增量映象，需對映象倉庫老舊映象清理；另外，部分業務或元件縮容後，PV/PVC許久未用，怎麼回收？如何自動智慧，一勞永逸？

針對上述各類問題，我們做了深刻地思考和實踐性的解決方案，且聽娓娓道來。

3。實踐

3.1 node超賣

node資源超賣是當前業界通用的資源挖掘方式，透過超賣技術，實現每個node儘可能多的執行服務，提高資源利用率，最大限度的挖掘機器的效能，目前星斗雲基於160核1T配置的Dell物理母機，實現了800%的超賣率，為實現降本做出了非常大的共享。

3。1。1 超賣方案

流程說明：

1。kubelet透過apiserver上報node資源資訊。

2。上報請求達到apiserver後，對上報請求做認證和鑑權。

3。認證鑑權通過後，將透過validating 和 mutating驗證，在mutating階段將會呼叫我們webhook server，做資源資訊改寫。

4。資源改寫後，經apiserver落入etcd，實現超賣管理。

核心原理主要是實現一個webhook server，透過mutating webhook劫持node上報的資源資訊，然後按指定的係數改寫後落入etcd，供後續scheduler排程使用。

3。1。2 超賣方式

針對不同場景，我們實現了兩種超賣方式：固定比例和指定係數。

固定比例：記憶體不超賣，將cpu按mem/cpu的設定比例超賣，如：母機原配置mem 1T記憶體、cpu 160核，預設比例為6，若我們設定超賣比例為4，則node可用排程資源調整為1T、250核，反之，若設定超賣比例為8，低於實際母機配置，則不超賣。

指定係數：cpu和mem設定指定的係數進行超賣，預設係數均為1即不超賣，且低於1的設定無效，如：母機原配置mem 1T記憶體、cpu 160核，設定cpu超賣係數為2。0，mem超賣係數為1。2，則超賣出的cpu為320核，mem為1。2T記憶體。

3.2 自定義HPA

3。2。1 原生HPA

原生的HPA已經比較強大了，能實現多指標、冷卻視窗等能力，但在具體業務場景實踐中還是稍有欠缺，具體問題如下：

無用耗時：每15秒的計算週期，無法滿足超大突發場景下秒級甚至ms級響應需求。

缺少併發：從佇列裡獲取多個HPA物件，處理完一個再輪到下一個，若同一時刻，業務請求導致微服務呼叫鏈上下游均高負載，缺少併發處理能力，無法滿足場景需求。

指標滯後：透過獲取metrics，prometheus週期性抓取、聚合再做計算，每一個流程都是耗時，時效已經偏低，無法做到實時響應，對於電商突發性高負載，太滯後。

事件驅動：原生HPA都是事後的處理，即流量突發已成事實，缺少對事前預警性的場景滿足，需要類似於KEDA一樣的被動感知或事件驅動。

零副本：原生HPA暫未支援零副本能力，對於離線計算業務，場景需求明確。

3。2。2 SophonHPA

經過長期需求對接和充分的業界方案調研發現，目前暫無符合我們應用場景的開源HPA方案，故我們重新設計了SophonHPA，方案架構圖如下：

圖示架構說明：

SophonHPA為Operator，支援自定義CRD以controller方式實現HPA邏輯，同時相容原生能力。

SophonHPA將HPA拆分為控制面（controller）和執行體（executor），相互獨立執行，以保持架構的穩定性及容災能力，即使其中某個掛掉，HPA功能繼續運作，不會造成大面積癱瘓。

controller多副本，支援選舉，主要實現針對CRD的Reconcile邏輯，作為控制管理，一旦發現新增CR，建立一個robot實現針對指定workload的HPA專屬護航。

robot即executor主要負責每個CR指定workload的HPA實現，以獨立pod方式執行，即1個CR會生成1個executor pod，該executor透過直接呼叫度量系統API獲取實時指標或透過apiserver的api service方式獲取快取指標，來判斷觸發HPA邏輯，過程和原生類似，支援冷卻視窗，支援多指標綜合等能力。

為儘可能保證實時性，指標獲取方式拓展支援實時拉取prometheus或其他自定義監控系統指標，以抽象介面方式實現，executor透過不斷迴圈拉取的方式，保證指標的實時更新，實現彈性伸縮的實時感知與觸發。

圖示流程說明：

1。使用者設定customize-HPA即SophonHPA，生成CR並下發。

2。CR透過apiserver寫入etcd。

3。operator監聽到CR新增事件，觸發Reconcile邏輯。

4。使用者每新增部署一個CR，新建一個robot即executor，以pod方式執行，跟隨使用者CR指定workload，一對一保障其HPA能力。

5。executor以聚合指標介面的方式，從不同的後端獲取指標。

6。executor內的Calculator透過獲取的指標，根據指定的策略，決策是否做彈性伸縮。

7。executor內的Calculator計算達到觸發條件，觸發彈性伸縮。

8。executor內的scaler執行對指定workload的彈性伸縮，並透過實現冷卻視窗和控制擴縮步伐，保證擴縮節奏。

9。executor內的scaler執行完擴縮後，將狀態同步記錄到CR中。

3.3 優先順序管理

業務有重點、非重點之分，有線上、離線之別，我們對於業務做了細分差異處理，即分級管理。

3。3。1 業務分級

業務按重要程度從高到低依次分為P0-P5共6個等級：

P0：絕對核心業務、公司級平臺服務，如：電商、物流等核心業務，ceph儲存，閘道器等

P1：核心支撐系統，如：能效平臺、星斗雲元件等

P2：重要業務、叢集核心元件，如：prometheus，日誌平臺、映象倉庫等

P3：測試通用通用中介軟體，非核心通用業務，如：redis、kafka、hbase等

P4：開發測試業務

P5：離線計算業務

3。3。2 QOS策略

我們針對不同級別的業務，會做不同級別的QOS策略保障及資源管控，其中不同的級別對應不同的QOS策略即（Guaranteed、Burstable、BestEffort）：

1。P0：絕對核心業務，QOS為Guarranteed模式，即request和limits的cpu、memory都一樣，示例：

a。pod需求評估是4核8G，實際部署時，request和limits都設定成4核8G，即：

2。P1：memory不允許彈性，cpu彈性範圍為實際cpu需求的1/2~2倍，QOS為Burstable模式，即request和limits下mem一樣，limits的cpu為requests的1-16倍，示例如下：

a。pod需求評估是4核8G，實際部署時，request的cpu、memory設定成2核8G，limits設定為8核8G，即：

3。P2：memory不允許彈性，cpu彈性範圍為實際cpu需求的1/4~4倍，QOS為Burstable模式，即request和limits下mem一樣，limits的cpu為requests的1-16倍，示例如下：

a。pod需求評估是4核8G，實際部署時，request的cpu、memory設定成1核8G，limits設定為16核8G，即：

4。P3：memory不允許彈性，cpu彈性範圍為實際cpu需求的1/4~8倍，QOS為Burstable模式，示例如下：

a。pod需求評估是4核8G，實際部署時，request的cpu、memory設定成1核8G，limits設定為32核8G，即：

5。P4：cpu、memory均允許彈性，memory彈性範圍為實際的1/2~2倍，cpu彈性範圍為實際cpu的1/4~8倍，QOS為Burstable模式，即request和limits下mem一樣，limits的cpu為requests的1-16倍，示例如下：

a。pod需求評估是4核8G，實際部署時，request的cpu、memory設定成1核8G，limits設定為16核16G，即：

6。P5：cpu、memory均不設定，預設BestEffort模式，隨時可以銷燬回收同node超賣實現機制一樣，透過mutating webhook server劫持使用者部署的workload，改寫resource配置，從而實現不同等級的QOS管控，並做到了較大程度的資源複用，提高了整體負載彈性。

3.4 重點加固

伺服器有好、壞之異，業務有絕對核心，要求不可中斷，作為平臺方，務必重點保障核心業務穩定性，同時儘可能做到容災高可用，降低風險：

3。4。1 Taint & Toleration

對重點母機打Taint方式，只允許帶對應Toleration的pod排程到該機器，保障該母機容量同時，避免其他非核心服務的過度佔用，以致相互干擾。

3。4。2 親和性

對於重點業務服務，我們會透過設定Node Selector和Node Affinity，設定到指定node的排程親和性，使其能排程到效能更佳、配置更好的母機上去，保證其穩定可靠執行。

3。4。3 打散

核心元件都會做分散式打散部署，常用如：Redis、Kafka、RocketMq、Hbase等，當然還有很多核心業務，也會根據需求做同樣的配置管理，打散主要透過反親和性的方式實現。

3。4。4 搶佔

業務做了分級管理，高優先順序的業務，必須高優先順序保障，透過設定搶佔策略，可以對pod部署排程過程做出絕對保障，當資源緊張或某些機器異常時，可以優先保證高優先順序的業務服務執行。

3.5 在離線混布

計算資源的深度挖掘，除了超賣以外，就是混布，超賣有其場景限制，超賣容易導致母機整體負載過高，影響業務服務的穩定性，在、離線則不一樣，在利用率波谷期，可以完美搭配線上業務體系，實現業務空窗期資源利用填谷的效果，業界共識當然，方向有了，實踐效果就取決於管理系統的優劣了，好的離線業務排程管理系統，可以高效的實現離線計算服務高峰下線、低谷執行的目標，基於此我們從以下三個點做了思考、設計及實踐。

3。5。1 分級管理

在已有的分級策略中，離線計算業務預設按最低等級P6部署，即Best Effort模式，隨時可以中斷，在常規場景中，離線計算業務作為最低優先順序的服務，混布過程中，即使影響到現網業務，遇到異常情況也會最先被處理，比如：記憶體佔用過多，該型別服務會先觸發oom，資源搶佔情況下，最先驅逐的也是該類服務，所以分級QOS策略能幫我們實現影響收斂。

3。5。2 CronHPA

有了業務分級QOS管理體系後，我們再透過構建CronHPA的能力，實現定期排程部署任務能力，興盛業務有明顯的高峰、低谷期，週期性很強，夜間電商業務成交凍結，資源都浪費了，我們的離線作業系統，完全可以透過CronHPA的方式，定時擴縮容，如：晚上11：00開始拉起離線作業任務，早上7：00停掉。

3。5。3 排程系統

CronHPA的效果還是相對太大佬粗，一點也不柔和，對過程中的異常處理也不及時，無法根據實時情況，做出響應策略，比如：某臺母機突發異常，負載過高，影響線上業務服務響應，就需要有對應的管理系統感知，並停掉對應node上的離線計算服務，此時，一套更全面的離線業務排程管理系統即應運而生。

圖示說明：

離線計算作業排程系統共分兩套核心流程，圖中分別用橙色和藍色流程給出。

圖示橙色流程為支援作業的排程釋出及狀態同步管理，負責離線計算業務的定時或實時排程、部署、回收等管理，以及執行過程中的作業狀態管理。

圖示藍色流程為動態調諧流程，負責服務執行中感知周邊系統狀態，如：node負載、業務預警、叢集巡檢異常通知等資訊，透過感知這些資訊，動態調整執行中的作業，將作業pod做遷移、伸縮，或規避指定node等操作，保障現網業務穩定。

3.6 智慧清理

儲存資源的回收管理，透過自動化、智慧化的方式實現，達成成本管控目標前提下，做到非人工參與。

3。6。1 映象倉庫

業務每天釋出幾千次，各種映象資料，如果缺少合理的清理策略，時間久了多大的空間都會被打滿，容易導致映象上傳失敗或下載效率低harbor映象倉庫支援設定清理策略，並自動執行，但實踐中，無論我們怎麼設定，如：保留每個映象最近20個版本、保留最近1個月的映象，都無法滿足需求，經常會出現策略不合理，使得現網在執行服務映象被清理，導致該服務pod異常重建或擴容時失敗，引起事故，所以我們花了很大精力思考如何做到精準清理，實現一勞永逸，最終經過多番探討和論證，提出瞭如下方案：

3。6。2 持久儲存

業務經常會擴縮容，部分業務會使用持久儲存，經常縮容後殘留很多pv未清理，基於此我們會考慮如何做好清理，並且關鍵是不能把業務在用或待用的清理掉，以免導致資料丟失，引起業務故障，清理很簡單，但要做到顧全周到，就有很多細節需要把控。

3.7 配額管理

業務總是覺得自己的服務很重要，需要足夠資源保證使用，所以經常會分配過多的資源，導致佔用膨脹以致浪費，我們會對其使用的計算資源做合理管控，管控策略即限額和彈性，流程包括實時統計、限額預警和彈性借調。

3。7。1 實時統計

叢集中會執行一套Controller用於計算實時資源消耗情況，並按小時為週期做流水記錄和統計，統計單位為CPU“核小時”或記憶體“G小時”，配額也是同樣的單位，比如：A業務部署了多個例項，累計共10核20G配置使用，每隔1小時，會計算生成20核*小時的消耗流水記錄，並落入到資料庫。

3。7。2 限額預警

實時流水生成後，星斗雲會根據流水記錄做統計計算，並與業務配額做比對，按指定條件觸發預警，如：當業務資源使用達配額60%時，傳送郵件預警，當達到80%時企業微信告警，當達到90%時簡訊告警，超過100%時電話告警。

圖示說明：

1。Report Generater從資料庫獲取資料統計，並計算是否達到預警限額。

2。Report Generater將觸發指定的預警傳送到訊息佇列。

3。Report Pusher從訊息佇列消費，按指定等級推送預警資訊。

3。7。3 彈性借調

顧名思義，彈性借調即根據業務的使用情況動態調整其預算額度，部分業務因持續增長，會導致配額吃緊，相反，部分業務可能因預算評估過高，導致配額冗餘，或不同業務波峰波谷錯開，可以配額互惠，具體實踐則是對指定業務打標，然後按業務樹，由下往上借調，如：

1。業務樹結構為A->B->C，A是一級業務，B為二級業務，C是三級業務。

2。將C標記為核心業務，可做配額借調，若C的配額耗盡，則會從C上層業務B的範圍做借調，即二級業務B下屬的可用額度，借調到C業務上。

3。若二級業務B範圍內額度不夠，則繼續往上借調。

4。若A範圍內也不夠，則告警通知增加配額。

4。展望

透過以上述技術實踐，我們沉澱了很多經驗和能力，在往後的降本增效路上，還會有更多的雲原生技術方向延伸，比如：透過ebpf、NUMA排程等機器效能挖掘技術，及大資料、AI等雲原生技術結合方向探索，實現更好地降本增效技術落地，幫助業務更快發展受限於業務形態及發展規模，當前我們在離線混布、大資料、人工智慧等雲原生技術結合方向尚淺，後續隨著業務的持續發展，我們將會投入更多相關實踐，期望在高效能計算方向沉澱出更多技術結晶。

5。總結

興盛優選當前業務穩健發展，為了迎接未來可能會大規模業務增長，我們做了很多技術實踐和探索，為未來即將到來的挑戰做好準備，希望藉助雲原生技術的東風，助力業務更好的發展，本文著重將過程中以降本增效為方向的沉澱做了整理歸納，其中涉及超賣、排程、彈性、管控等多方面技術點，希望可以透過此次分享，幫助業界夥伴們提供一些思路和方法參考。