前言

資源使用背景

當(dāng)前眾多金融企業(yè)開(kāi)始將業(yè)務(wù)應(yīng)用進(jìn)行容器化部署，以期實(shí)現(xiàn)業(yè)務(wù)應(yīng)用開(kāi)發(fā)的敏捷迭代、運(yùn)行環(huán)境的快速部署、業(yè)務(wù)負(fù)載的彈性伸縮、應(yīng)用系統(tǒng)的全生命周期管理等效果。助力企業(yè)金融科技創(chuàng)新和金融場(chǎng)景創(chuàng)新，拓寬金融業(yè)行業(yè)邊界，讓金融服務(wù)內(nèi)容更加多元，挖掘用戶更多潛在需求，提升用戶黏性和服務(wù)體驗(yàn)，全面增強(qiáng)企業(yè)競(jìng)爭(zhēng)力。

當(dāng)前上云用云作為G行數(shù)字化轉(zhuǎn)型的關(guān)鍵一步已走到?jīng)Q定性階段。從內(nèi)部來(lái)看，隨著上云由外圍系統(tǒng)過(guò)渡到核心系統(tǒng)，用云進(jìn)入深水區(qū)，目標(biāo)從如何上云用云，變成如何用好云。安全可靠、控制成本和優(yōu)化性能是目前G行云使用方案需要關(guān)注的三個(gè)重要維度。從外部來(lái)看，一方面全球經(jīng)濟(jì)下行處于下行期，另一方面近期一些互聯(lián)網(wǎng)頭部企業(yè)相繼發(fā)生系統(tǒng)崩潰事件，促使業(yè)界對(duì)云使用的資源優(yōu)化和安全運(yùn)行討論又一次達(dá)到高峰。

在云資源降本增效的過(guò)程中，我們目標(biāo)是要降本不降質(zhì)，不能以降低系統(tǒng)穩(wěn)定性、效率、安全運(yùn)營(yíng)等為代價(jià)。本文基于有效保障業(yè)務(wù)平穩(wěn)運(yùn)行的前提下，探索常見(jiàn)容器環(huán)境的資源優(yōu)化方法，對(duì)如何提升資源利用率，控制云成本做出思考和總結(jié)。

資源使用背景

為方便理解，我們將容器環(huán)境應(yīng)用架構(gòu)分為如圖1所示的應(yīng)用層、調(diào)度層、資源層。逐一闡述各層資源使用情況。

圖1 容器環(huán)境應(yīng)用基礎(chǔ)架構(gòu)

應(yīng)用層

Kubernetes 使用了Request（請(qǐng)求）和Limit（限額）來(lái)描述容器對(duì)CPU和內(nèi)存資源的需求。

Request：容器預(yù)留的資源量。即便容器沒(méi)有實(shí)際使用到這些資源，Kubernetes也會(huì)為容器預(yù)留好這些資源，其他容器無(wú)法在資源池內(nèi)申請(qǐng)這些資源。

Limit：限制容器使用的資源上限。容器在實(shí)際運(yùn)行的時(shí)候不能超過(guò)的資源閾值。如果容器使用的資源超過(guò)了這個(gè)值，就會(huì)觸發(fā)K8s后續(xù)對(duì)應(yīng)的操作。對(duì)于CPU來(lái)說(shuō)，由于CPU 是可壓縮資源，所以如果容器使用的CPU超過(guò)了 limit 設(shè)置的值，會(huì)導(dǎo)致CPU節(jié)流服務(wù)降級(jí)，影響應(yīng)用處理速度。但對(duì)于內(nèi)存這種不可壓縮資源，如果內(nèi)存的使用量超過(guò)了limit的值，則會(huì)觸發(fā)OOMKilled。

G行在業(yè)務(wù)的實(shí)際使用中，為大部分服務(wù)設(shè)置Request和Limit，同時(shí)Limit是Request的2倍以上（Limit比Request大，實(shí)際是對(duì)物理資源的一種超賣）。在圖2中，從G行某集群工作節(jié)點(diǎn)CPU使用線性圖可以看出，CPU限制率為209.14%，節(jié)點(diǎn)上的應(yīng)用超賣109.14%。通過(guò)應(yīng)用資源配置進(jìn)行一定程度的超賣，增加Pod的部署密度，可以有效提升集群整體的利用率。

圖2 集群工作節(jié)點(diǎn)應(yīng)用CPU超賣情況

調(diào)度層

在Kubernetes中，調(diào)度是指將Pod放置到合適的節(jié)點(diǎn)上，以便節(jié)點(diǎn)上的Kubelet能夠運(yùn)行這些Pod。原生Kubernetes調(diào)度器Kube-scheduler給一個(gè)Pod做調(diào)度選擇時(shí)包含兩個(gè)階段—預(yù)選和優(yōu)選。

預(yù)選階段會(huì)將所有滿足Pod調(diào)度需求的節(jié)點(diǎn)選出來(lái)。其中PodFitsResurces策略會(huì)檢查候選節(jié)點(diǎn)的可用資源是否滿足Pod的Request資源請(qǐng)求。

優(yōu)選階段會(huì)對(duì)每個(gè)通過(guò)預(yù)選的節(jié)點(diǎn)優(yōu)先級(jí)打分。其中LeastRequestedPriority策略會(huì)優(yōu)先從預(yù)選節(jié)點(diǎn)列表選擇資源占用最小的節(jié)點(diǎn)。BalancedResourceAllocation策略會(huì)優(yōu)先從預(yù)選節(jié)點(diǎn)選擇CPU和內(nèi)存占用率最均衡的節(jié)點(diǎn)。

從原生Kubernetes調(diào)度器的策略可以看出，Pod請(qǐng)求值Request配置的準(zhǔn)確性直接影響集群節(jié)點(diǎn)資源利用率和集群負(fù)載的均衡性。

資源層

Node節(jié)點(diǎn)資源并不能完全被Pod所使用，這就引入了一個(gè)問(wèn)題，Kubernetes如何劃分節(jié)點(diǎn)上的計(jì)算資源。Kubernetes將節(jié)點(diǎn)上的計(jì)算資源分為如圖3所示幾部分，其中：

• System Reserved：系統(tǒng)保留的計(jì)算資源，不能被Kubernetes調(diào)度和使用，比如 sshd 等等。
• Kubernetes Reserved：Kubernetes為Dockerd、Kubelet、Kube-proxy等保留的計(jì)算資源，這部分保證Kubernetes正常工作。
• Eviction Thread：當(dāng)節(jié)點(diǎn)內(nèi)存或磁盤(pán)資源緊張時(shí)達(dá)到閾值，kubelet會(huì)根據(jù)Pod 的 QoS優(yōu)先級(jí)回收Pod占用的資源。
• Fragments Resource：通常情況下，Node節(jié)點(diǎn)上會(huì)剩余一些資源碎片，這些資源無(wú)法滿足調(diào)度Pod的資源需求。
• Node Allocatable Capacity: 能夠被Kubernetes調(diào)度和使用的計(jì)算資源，它的計(jì)算方法為：[Node Allocatable Capacity] = [Node Capacity] - [System Reserved] - [Kubernetes Reserved] - [Eviction Thread] - [Fragments Resource]

圖3 Node節(jié)點(diǎn)維度的計(jì)算資源

資源未能充分使用原因

應(yīng)用層

• 采用傳統(tǒng)資源評(píng)估分配方法進(jìn)行云上資源分配

容器資源規(guī)格Resource Request和Limit的填寫(xiě)讓Kubernetes的使用者困惑，應(yīng)用管理員需要預(yù)留較多的冗余資源，來(lái)應(yīng)對(duì)流量的波動(dòng)，保障業(yè)務(wù)運(yùn)行的穩(wěn)定性，導(dǎo)致資源冗余性有余，利用率不足。在圖4中，某教學(xué)類系統(tǒng)CPU請(qǐng)求率為2%到5%（請(qǐng)求率=使用值/請(qǐng)求值），資源規(guī)格Request值設(shè)置有冗余，資源利用率有一定的提升空間。

圖4 教學(xué)類項(xiàng)目資源使用率

• 對(duì)容器的自動(dòng)彈性能力保持謹(jǐn)慎，按需自動(dòng)擴(kuò)縮容未能有效運(yùn)用

在應(yīng)用層開(kāi)啟彈性能力賦能業(yè)務(wù)是我們需要重點(diǎn)考慮的問(wèn)題。容器秒級(jí)啟動(dòng)的特性，讓我們可以在業(yè)務(wù)中利用彈性擴(kuò)縮容按需分配資源。G行在研究探索過(guò)程中發(fā)現(xiàn)在線類交易業(yè)務(wù)流量存在波峰波谷現(xiàn)象，若此類業(yè)務(wù)開(kāi)啟彈性擴(kuò)縮容，會(huì)避免大量資源浪費(fèi)。圖5為某在線交易項(xiàng)目微服務(wù)模塊的CPU使用率情況，我們可以看到該業(yè)務(wù)每天會(huì)有突發(fā)性流量高峰，其他時(shí)間段流量處于較低的水平，有明顯的流量波峰和波谷的特征。非常適合利用容器的極速?gòu)椥阅芰?shí)現(xiàn)資源優(yōu)化。

圖5 在線交易項(xiàng)目微服務(wù)模塊CPU使用率

調(diào)度層

• 原生調(diào)度無(wú)法滿足實(shí)際使用場(chǎng)景

Kubernetes默認(rèn)使用原生調(diào)度器Kube-scheduler，它的主要職責(zé)是為一個(gè)新創(chuàng)建出來(lái)的 Pod，尋找一個(gè)最合適的 Node節(jié)點(diǎn)。G行在探索過(guò)程中發(fā)現(xiàn)由于原生 Kubernetes 調(diào)度器只能基于資源的 Resource Request 進(jìn)行調(diào)度，有些節(jié)點(diǎn) Pod 的真實(shí)資源使用率，往往與其所申請(qǐng)資源的Request差異很大，這直接導(dǎo)致集群負(fù)載不均的問(wèn)題和部分節(jié)點(diǎn)的資源使用不充分。Kubernetes 原生調(diào)度與資源綁定功能已經(jīng)無(wú)法滿足復(fù)雜的算力場(chǎng)景。圖6為某集群節(jié)點(diǎn)的CPU使用率，從中可以看到使用原生調(diào)度器的場(chǎng)景下每個(gè)節(jié)點(diǎn)的CPU使用率并不均勻并且存在個(gè)別節(jié)點(diǎn)資源使用不充分的情況。

圖6 集群節(jié)點(diǎn)CPU使用率

資源層

• 資源碎片使資源池?zé)o法充分利用

由于 Kubernetes 調(diào)度程序無(wú)法預(yù)測(cè)未來(lái)的 Pod 大小和節(jié)點(diǎn)添加，隨著時(shí)間的推移，最終會(huì)導(dǎo)致任何節(jié)點(diǎn)都無(wú)法滿足Pod的資源調(diào)度，即使節(jié)點(diǎn)上可能剩余很多資源。這樣就產(chǎn)生一個(gè)假的資源緊張現(xiàn)象。結(jié)合圖7和圖8展示的G行某集群節(jié)點(diǎn)CPU資源使用情況和Pod業(yè)務(wù)資源規(guī)格可以看出節(jié)點(diǎn)計(jì)算資源總量為16核，已請(qǐng)求13.15核，但業(yè)務(wù)的請(qǐng)求規(guī)格為4核，這直接導(dǎo)致節(jié)點(diǎn)有至少2核的資源碎片無(wú)法被其他Pod調(diào)度。

圖7 G行某集群節(jié)點(diǎn)CPU使用情況

資源優(yōu)化措施

通過(guò)分析上面影響資源利用率的原因做出以下相應(yīng)改進(jìn)措施。

應(yīng)用層

• 結(jié)合云的特性優(yōu)化資源評(píng)估方法，規(guī)范調(diào)配常駐資源

針對(duì)使用方普遍存在的過(guò)度申請(qǐng)冗余資源的情況。在資源申請(qǐng)方面，G行通過(guò)非功能測(cè)試評(píng)估業(yè)務(wù)部門(mén)未來(lái)一段時(shí)間的業(yè)務(wù)規(guī)劃，梳理出合規(guī)并有一定冗余量的資源規(guī)格；在資源優(yōu)化方面，通過(guò)持續(xù)收集容器的資源用量，進(jìn)行匯總分析，根據(jù)歷史數(shù)據(jù)和智能算法為每個(gè)容器生成資源規(guī)格的合理推薦值，沉淀形成資源評(píng)估分配規(guī)范標(biāo)準(zhǔn)；在資源運(yùn)營(yíng)方面，強(qiáng)化資源使用跟蹤，監(jiān)控資源運(yùn)行數(shù)據(jù)，按日發(fā)布資源利用率情況，按月發(fā)布項(xiàng)目運(yùn)營(yíng)分析報(bào)告及綜合效能評(píng)分，協(xié)助各項(xiàng)目組優(yōu)化資源部署，提升資源效能。

從圖9展示的資源利用率變化趨勢(shì)圖可以看出，針對(duì)某電子化項(xiàng)目資源利用率低的問(wèn)題做出整改措施后，利用率有明顯的上升變化。

圖9 某電子化項(xiàng)目資源使用優(yōu)化趨勢(shì)圖

• 在充分測(cè)試后，有效推進(jìn)彈性技術(shù)賦能業(yè)務(wù)

在線類業(yè)務(wù)的使用量會(huì)根據(jù)負(fù)載情況出現(xiàn)波動(dòng)，所以在設(shè)置資源規(guī)格時(shí)應(yīng)該充分考慮周期性特點(diǎn)使用彈性資源，以便業(yè)務(wù)在流量谷底可以降低資源使用，而在高峰之前又能及時(shí)提升能力。Kubernetes提供了自動(dòng)擴(kuò)展功能，如基于指標(biāo)的自動(dòng)水平彈性擴(kuò)縮容HPA，可以根據(jù)工作負(fù)載的 CPU 或內(nèi)存使用率自動(dòng)擴(kuò)縮 Pod 副本數(shù)，通過(guò)使用彈性能力實(shí)現(xiàn)資源按需分配。

從圖10和圖11可以看到某業(yè)務(wù)在CPU負(fù)載超過(guò)目標(biāo)閾值45秒后，Pod自動(dòng)擴(kuò)容到3副本。彈性擴(kuò)縮容幫助業(yè)務(wù)減少冗余資源的設(shè)置、規(guī)避容量風(fēng)險(xiǎn)。

圖10 擴(kuò)容CPU平均使用率

圖11 擴(kuò)容Pod副本數(shù)

調(diào)度層

• 調(diào)度感知實(shí)際資源負(fù)載

由于原生Kubernetes調(diào)度器依賴于Request 靜態(tài)配置，而不是基于實(shí)際節(jié)點(diǎn)的負(fù)載情況調(diào)度Pod，因此會(huì)出現(xiàn)集群各個(gè)節(jié)點(diǎn)負(fù)載不均衡的現(xiàn)象。我們期望動(dòng)態(tài)獲取當(dāng)前節(jié)點(diǎn)  的實(shí)時(shí)資源水位，據(jù)此打分從而干預(yù)調(diào)度結(jié)果，平衡各個(gè)計(jì)算節(jié)點(diǎn)的資源使用，充分發(fā)揮資源池的資源供給。

資源層

• 資源碎片再平衡

原生Kubernetes調(diào)度器會(huì)根據(jù)當(dāng)時(shí)集群的資源描述做出最佳的調(diào)度決定，但基于靜態(tài)數(shù)據(jù)的調(diào)度有時(shí)并不能適應(yīng)之后資源的動(dòng)態(tài)變化，我們期望通過(guò)識(shí)別和遷移節(jié)點(diǎn)間的特定 Pod 來(lái)實(shí)現(xiàn)可用資源片段的整合，解決資源池的資源碎片，更充分利用好現(xiàn)有資源，節(jié)省不必要的開(kāi)支。

總結(jié)

本文首先介紹容器環(huán)境各層使用資源的背景，通過(guò)生產(chǎn)環(huán)境的資源使用實(shí)踐，分析造成資源使用率低于預(yù)期的原因，最后提出相應(yīng)解決方案。

云上資源優(yōu)化并不是盲目追求低成本，而是在業(yè)務(wù)價(jià)值得到保障前提下有效提高投入產(chǎn)出比。優(yōu)化需要統(tǒng)籌多方指標(biāo)達(dá)到最優(yōu)解，任何時(shí)候都不能忽視系統(tǒng)安全性、穩(wěn)定性、可擴(kuò)展性和性能，這樣才能取得最優(yōu)效果。總之，上云用云是個(gè)循序漸進(jìn)的過(guò)程，云上資源優(yōu)化也是反復(fù)迭代過(guò)程，需要覆蓋業(yè)務(wù)上云全周期形成閉環(huán)、持續(xù)跟蹤、持續(xù)分析、持續(xù)優(yōu)化最終達(dá)到最佳效果。

本文是介紹G行全棧云容器環(huán)境降本增效之路的入門(mén)文章，之后會(huì)不定期更新系列文章介紹G行容器云資源優(yōu)化實(shí)踐和效益，助力充分發(fā)揮云效能，服務(wù)好廣大客戶。