容器化後資源與成本優化實踐

語言: CN / TW / HK

時間 2022-03-24 21:48:04 好未來技術

導讀：本文描述了好未來在容器資源優化方面進行的探索和實踐，包括業務彈性動態擴縮容來減少時間維度上的資源佔用，通過超賣和在離線服務混合部署來優化CPU資源利用率，最後也講述了公有云上容器計算資源型別選擇的一些參考和賬單優化的常規建議。

現狀概述

截止目前，集團大部分業務線已經完成了容器化。容器化相對於虛擬機器，在資源管理上更加靈活。我們可以按照業務需求，以更細粒度的方式來高效分配和管理計算資源。同時，容器秒級啟動的特性，也讓我們更容易在業務中利用彈性擴縮容來節省資源。集團核心業務在容器化後，雖然叢集資源利用率有所提升，但叢集整體利用率仍然比較低。我們在分析當前叢集資源利用整體情況時，發現叢集（IDC和公有云叢集）的記憶體一般都比較充足，業務服務更多的是在爭搶CPU資源。CPU資源在大量的申請後處於閒置狀態。一方面叢集整體CPU利用率不高（天均值小於10%），另一方面業務卻因為分配不到CPU資源出現pending狀態。圖1展示了一個IDC k8s叢集CPU利用率。

圖1：某個k8s叢集CPU利用率

儘管圖1中叢集CPU利用率很低，但是實際上該叢集已經的CPU已經分配完了，再需要較大CPU申請量時，k8s已經比較難分配出來，即該叢集的資源大量空閒，且碎片化比較嚴重。業務服務在申請CPU用量時，一般傾向於申請遠遠大於實際用量的資源，同時會傾向於屯一部分資源(業務在閒時也開啟過多副本)，導致叢集CPU利用率非常低。

適配業務流量的週期特徵動態擴縮容

網際網路業務流量一般有明顯的週期特徵。在一天、一週表現出非常規律的流量波峰和波谷。下圖展示了某個業務的流量監控。

圖 2 某業務流量波峰/波谷週期特徵

從圖2可以看到，基本上每天晚上7點以後會有一波較短時間的流量高峰。然後在一天其他時間流量處於很低的水平。我們查看了其他的一些業務，流量基本上也是這種規律。這跟當前業務形態是一致的，即在政策允許的時間段，線上服務會有流量。而其他時間段，線上服務流量較少。這些業務已經容器化，非常適合利用容器的極速彈效能力實現資源和成本的優化。尤其是在公有云上的服務，及時的向公有云申請和釋放資源，節約的成本直接反應在賬單上。我們利用率阿里雲提供的定時水平擴充套件(CrohHPA)，並結合彈性節點池，實現動態擴縮容。如下圖 3所示。在資源不夠時，利用k8s cluster api向阿里雲申請資源，並將新加的節點按照初始化模版加入到k8s叢集提供算力。在流量高峰過去後，pod數量大幅減少，叢集資源空閒較多，此時將富餘的計算節點歸還給阿里雲。

圖 3 彈性節點池

我們分析了某個在阿里雲上的業務的服務，按照一週的平均量來看，該服務所在的k8s叢集大概使用1/2的固定節點資源，另外1/2使用彈性擴縮容形式動態申請和釋放，每天只用幾個小時。通過計算，大約能節省23%的資源成本。當然這裡面還可以進行優化，該叢集還執行其他的業務，並沒有開啟彈性，整體開彈性的比例不高。如果整體開啟彈性動態擴縮容，我們估算能節省30%以上的資源。

優化資源利用率

應用申請資源超賣

彈性擴縮容是從時間緯度上優化資源用量。在容器現狀分析裡面看到，容器叢集整體CPU利用率極低，天級別平均不到10%。另一方面，k8s叢集上經常出現資源無法分配導致pending的狀態。我們分析了叢集的應用，應用申請的CPU都會比實際用量大。對多個叢集近千個應用進行統計分析表明，應用申請的CPU大約是實際使用量峰值的3+倍。k8s在排程時，採用request設定的值靜態排程。應用設定超過需要實際的用量，導致多餘的資源被分配，但實際處理閒置狀態。k8s還可以設定limit值，在執行時限制實際使用的資源。根據request和limit不同，k8s對Pod有以下服務等級。

Guaranteed：Pod 中的每個容器，包含初始化容器，必須指定記憶體和CPU的requests和limits，且兩者值相等。
Burstable：Pod 不符合 Guaranteed QoS 類的標準；Pod 中至少一個容器具有記憶體或 CPU requests。
BestEffort：Pod 中的容器必須沒有設定記憶體和 CPU的requests或limits。

在業務實際使用中，大部分業務服務設定了request和limit，同時limit是request的2倍以上。limit比request大，實際是對物理資源的一種超賣。我們對應用進行分析，reqeust大概是最大使用值的2～3倍，而limit大概是最大使用值的5～6倍，參考如下示意圖4。

圖4 叢集資源利用現狀

通過資源進行一定程度的超賣，增加了pod的部署密度，能提升叢集整體的利用率。但直接讓使用者自行設定超賣值，會造成超賣的標準非常不統一。我們發現有些業務超賣16+倍以上，而有的按照2+倍來設定。這裡造成的問題是，節點CPU利用率極其不均衡。如下圖5所示，叢集節點CPU利用率波動較大，如圖5所示。超賣嚴重不均衡，實際欺騙了k8s的靜態排程器，造成節點CPU利用率極其不均衡。更嚴重的情形下，會造成部分節點負載進入異常狀態，從而影響業務的穩定性。容器團隊正在開發相應的排程相關外掛，優化此種情況。

圖5 節點CPU利用率不均衡

根據目前結果來看，如果放開使用者設定超賣倍率，對叢集的穩定性帶來較大的隱患。同時我們也分析了跟業務服務使用方式比較相近阿里雲ASK型別容器(ECI)。在這種型別k8s叢集上，會按照某種規則控制超賣比例，不讓使用者直接設定，我們猜測可能跟硬體資源庫存有關係。同樣，容器團隊也在開發相應的功能，引導使用者設定合理的request值，並根據規則設定limit值。

節點超賣

如果大家關注容器叢集CPU資源利用率優化，很多公司分享的經驗裡會提到對節點進行超賣，即通過k8s的webhook，更改CPU的容量值，給k8s排程器更多的可分配CPU資源。當然，這種超賣會提高pod的部署密度，因而會提高CPU利用率。我們在某個測試叢集上的資料如圖6所示。超賣的一組節點比未超賣節點組CPU利用率高約10個百分點。

圖6 超賣/未超賣兩組節點池CPU利用率

當然，這裡超賣跟應用超賣的效果是一樣的，在提升利用率的同時，會對叢集的和應用帶來極大的穩定性風險，為此，容器團隊在這種情形下，專門針對穩定性進行優化，期望在超賣和穩定性之間找到平衡點。

在離線服務混部

在離線服務混合部署，是提高叢集利用率的一大利器，各個大廠分享的實踐經驗比較多。其實原理也很簡單，即在容器叢集的計算資源在線上和離線服務之間進行動態拆借。我們目前已經完成了在離線服務混部的demo測試，整個方案比較簡單，直接將線上和離線的服務劃分兩個資源池，每一時刻只能由線上服務或者離線服務使用。當然有些公司實現了更復雜的方案，在同一臺機器上，同時執行線上服務和離線服務，通過排程器優化避免線上服務被離線服務影響。為避免一開始方案過於複雜，難於實現和落地，我們採用不混用的形式實現線上和離線計算資源的拆借，具體細節可以參考大資料團隊ttc文章《Yarn混合部署方案在好未來的實現》。

公有云資源與成本優化

目前在好未來，大量使用公有云計算資源部署服務，在公有云上優化資源利用能直接反應在賬單上。在彈性擴縮容例子中，我們看到開啟彈性伸縮，大概能節省20+%的計算資源。在公有云上除了上文提到的CPU利用率優化外，還需要考慮公有云上的各個不同產品之間的差異，以及計費策略等等，為業務尋找合適的計算資源。在自建的IDC叢集中，即使資源處於空閒狀態，機器/機櫃等開銷仍然存在，這部分屬於沉沒成本。然而在公有云上，我們及時的將資源返還給雲廠商，能立即節省費用。針對容器彈性計算資源的需求，阿里雲提供serverless形態的k8s叢集ASK(ECI)，提供極高的彈性，而且基本不需要運維。在好未來剛開始選擇公有云上的容器產品時，大量的使用了ASK，但對於常駐記憶體的後臺服務，ASK成本通常比較差，通過測算，使用ASK型別產品比使用裸金屬機器搭建的ACK叢集，成本高40%以上。目前正在廢棄對這種資源型別的使用。

在裸金屬機器和虛擬機器之間如何選擇呢？我們會優先使用裸金屬機器，在IDC採用物理機器搭建並運維了較多的k8s叢集，而且我們的運維團隊具備運維大規模物理k8s叢集的經驗，而且一些在k8s叢集上實現基礎擴充套件功能能繼續使用。另一方面，裸金屬機器成本比虛

擬機更有優勢。對於虛擬機器和裸金屬機器選型問題，可以繼續參考這篇文章《裸金屬與虛擬機器如何選擇》。另外，公有云提供的AMD機型，通常在同等算力下，單位成本更低。而且，公有云提供較多的計費策略可供選擇，例如包年包月、彈性資源、競價型資源等。價格差異也比較大，需要根據實際業務型別進行仔細評估並進行選擇，這裡需要根據實際需要針對公有云計費策略進行測試，細節不再贅述。

與業務研發一起優化資源和成本

容器資源和成本優化，並不都是對業務無感知的，甚至一些改動需要業務研發老師一起進行，例如進行定時彈性伸縮、應用申請的資源調整等。而業務研發傾向於保持穩定，減少底層干擾對業務穩定性的影響。為此，我們開發了容器的賬單服務，提供給業務參考。同時，我們也正在開發業務申請資源的有效利用率，通過榜單的形式，推動業務優化申請的成本。

另外，我們在做資源利用率優化時，容器團隊也會做穩定性的保障工作，在資源優化和穩定性上相互兼顧平衡。我們也會跟業務研發講明白如何保障業務穩定性、如何保障資源分配的及時性、優化資源方式的合理性，讓業務研發老師能在使用我們提供的優化資源建議時，少一些後顧之憂。

容器資源和成本優化，涉及到多個方面，既有技術上的重構和優化，也有不同團隊的合作，需要自上而下的推進，基礎部門和業務研發密切配合。在保證業務穩定性的前提下，優化叢集資源，降低成本。

掃描下方二維碼新增 「好未來技術」 微信官方賬號

進入好未來技術官方交流群與作者實時互動~

(若掃碼無效，可通過微訊號 TAL-111111 直接新增)