建站
咨詢
售后
建站咨詢
新聞中心
前言
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：空間域名、網(wǎng)頁空間、營銷軟件、網(wǎng)站建設(shè)、碌曲網(wǎng)站維護、網(wǎng)站推廣。
資源使用背景
當(dāng)前眾多金融企業(yè)開始將業(yè)務(wù)應(yīng)用進行容器化部署，以期實現(xiàn)業(yè)務(wù)應(yīng)用開發(fā)的敏捷迭代、運行環(huán)境的快速部署、業(yè)務(wù)負(fù)載的彈性伸縮、應(yīng)用系統(tǒng)的全生命周期管理等效果。助力企業(yè)金融科技創(chuàng)新和金融場景創(chuàng)新，拓寬金融業(yè)行業(yè)邊界，讓金融服務(wù)內(nèi)容更加多元，挖掘用戶更多潛在需求，提升用戶黏性和服務(wù)體驗，全面增強企業(yè)競爭力。
當(dāng)前上云用云作為G行數(shù)字化轉(zhuǎn)型的關(guān)鍵一步已走到?jīng)Q定性階段。從內(nèi)部來看，隨著上云由外圍系統(tǒng)過渡到核心系統(tǒng)，用云進入深水區(qū)，目標(biāo)從如何上云用云，變成如何用好云。安全可靠、控制成本和優(yōu)化性能是目前G行云使用方案需要關(guān)注的三個重要維度。從外部來看，一方面全球經(jīng)濟下行處于下行期，另一方面近期一些互聯(lián)網(wǎng)頭部企業(yè)相繼發(fā)生系統(tǒng)崩潰事件，促使業(yè)界對云使用的資源優(yōu)化和安全運行討論又一次達到高峰。
在云資源降本增效的過程中，我們目標(biāo)是要降本不降質(zhì)，不能以降低系統(tǒng)穩(wěn)定性、效率、安全運營等為代價。本文基于有效保障業(yè)務(wù)平穩(wěn)運行的前提下，探索常見容器環(huán)境的資源優(yōu)化方法，對如何提升資源利用率，控制云成本做出思考和總結(jié)。
資源使用背景
為方便理解，我們將容器環(huán)境應(yīng)用架構(gòu)分為如圖1所示的應(yīng)用層、調(diào)度層、資源層。逐一闡述各層資源使用情況。
圖1 容器環(huán)境應(yīng)用基礎(chǔ)架構(gòu)
應(yīng)用層
Kubernetes 使用了Request（請求）和Limit（限額）來描述容器對CPU和內(nèi)存資源的需求。
Request：容器預(yù)留的資源量。即便容器沒有實際使用到這些資源，Kubernetes也會為容器預(yù)留好這些資源，其他容器無法在資源池內(nèi)申請這些資源。
Limit：限制容器使用的資源上限。容器在實際運行的時候不能超過的資源閾值。如果容器使用的資源超過了這個值，就會觸發(fā)K8s后續(xù)對應(yīng)的操作。對于CPU來說，由于CPU 是可壓縮資源，所以如果容器使用的CPU超過了 limit 設(shè)置的值，會導(dǎo)致CPU節(jié)流服務(wù)降級，影響應(yīng)用處理速度。但對于內(nèi)存這種不可壓縮資源，如果內(nèi)存的使用量超過了limit的值，則會觸發(fā)OOMKilled。
G行在業(yè)務(wù)的實際使用中，為大部分服務(wù)設(shè)置Request和Limit，同時Limit是Request的2倍以上（Limit比Request大，實際是對物理資源的一種超賣）。在圖2中，從G行某集群工作節(jié)點CPU使用線性圖可以看出，CPU限制率為209.14%，節(jié)點上的應(yīng)用超賣109.14%。通過應(yīng)用資源配置進行一定程度的超賣，增加Pod的部署密度，可以有效提升集群整體的利用率。
圖2 集群工作節(jié)點應(yīng)用CPU超賣情況
調(diào)度層
在Kubernetes中，調(diào)度是指將Pod放置到合適的節(jié)點上，以便節(jié)點上的Kubelet能夠運行這些Pod。原生Kubernetes調(diào)度器Kube-scheduler給一個Pod做調(diào)度選擇時包含兩個階段—預(yù)選和優(yōu)選。
預(yù)選階段會將所有滿足Pod調(diào)度需求的節(jié)點選出來。其中PodFitsResurces策略會檢查候選節(jié)點的可用資源是否滿足Pod的Request資源請求。
優(yōu)選階段會對每個通過預(yù)選的節(jié)點優(yōu)先級打分。其中LeastRequestedPriority策略會優(yōu)先從預(yù)選節(jié)點列表選擇資源占用最小的節(jié)點。BalancedResourceAllocation策略會優(yōu)先從預(yù)選節(jié)點選擇CPU和內(nèi)存占用率最均衡的節(jié)點。
從原生Kubernetes調(diào)度器的策略可以看出，Pod請求值Request配置的準(zhǔn)確性直接影響集群節(jié)點資源利用率和集群負(fù)載的均衡性。
資源層
Node節(jié)點資源并不能完全被Pod所使用，這就引入了一個問題，Kubernetes如何劃分節(jié)點上的計算資源。Kubernetes將節(jié)點上的計算資源分為如圖3所示幾部分，其中：
- System Reserved：系統(tǒng)保留的計算資源，不能被Kubernetes調(diào)度和使用，比如 sshd 等等。
- Kubernetes Reserved：Kubernetes為Dockerd、Kubelet、Kube-proxy等保留的計算資源，這部分保證Kubernetes正常工作。
- Eviction Thread：當(dāng)節(jié)點內(nèi)存或磁盤資源緊張時達到閾值，kubelet會根據(jù)Pod 的 QoS優(yōu)先級回收Pod占用的資源。
- Fragments Resource：通常情況下，Node節(jié)點上會剩余一些資源碎片，這些資源無法滿足調(diào)度Pod的資源需求。
- Node Allocatable Capacity: 能夠被Kubernetes調(diào)度和使用的計算資源，它的計算方法為：[Node Allocatable Capacity] = [Node Capacity] - [System Reserved] - [Kubernetes Reserved] - [Eviction Thread] - [Fragments Resource]
圖3 Node節(jié)點維度的計算資源
資源未能充分使用原因
應(yīng)用層
- 采用傳統(tǒng)資源評估分配方法進行云上資源分配
容器資源規(guī)格Resource Request和Limit的填寫讓Kubernetes的使用者困惑，應(yīng)用管理員需要預(yù)留較多的冗余資源，來應(yīng)對流量的波動，保障業(yè)務(wù)運行的穩(wěn)定性，導(dǎo)致資源冗余性有余，利用率不足。在圖4中，某教學(xué)類系統(tǒng)CPU請求率為2%到5%（請求率=使用值/請求值），資源規(guī)格Request值設(shè)置有冗余，資源利用率有一定的提升空間。
圖4 教學(xué)類項目資源使用率
- 對容器的自動彈性能力保持謹(jǐn)慎，按需自動擴縮容未能有效運用
在應(yīng)用層開啟彈性能力賦能業(yè)務(wù)是我們需要重點考慮的問題。容器秒級啟動的特性，讓我們可以在業(yè)務(wù)中利用彈性擴縮容按需分配資源。G行在研究探索過程中發(fā)現(xiàn)在線類交易業(yè)務(wù)流量存在波峰波谷現(xiàn)象，若此類業(yè)務(wù)開啟彈性擴縮容，會避免大量資源浪費。圖5為某在線交易項目微服務(wù)模塊的CPU使用率情況，我們可以看到該業(yè)務(wù)每天會有突發(fā)性流量高峰，其他時間段流量處于較低的水平，有明顯的流量波峰和波谷的特征。非常適合利用容器的極速彈性能力實現(xiàn)資源優(yōu)化。
圖5 在線交易項目微服務(wù)模塊CPU使用率
調(diào)度層
- 原生調(diào)度無法滿足實際使用場景
Kubernetes默認(rèn)使用原生調(diào)度器Kube-scheduler，它的主要職責(zé)是為一個新創(chuàng)建出來的 Pod，尋找一個最合適的 Node節(jié)點。G行在探索過程中發(fā)現(xiàn)由于原生 Kubernetes 調(diào)度器只能基于資源的 Resource Request 進行調(diào)度，有些節(jié)點 Pod 的真實資源使用率，往往與其所申請資源的Request差異很大，這直接導(dǎo)致集群負(fù)載不均的問題和部分節(jié)點的資源使用不充分。Kubernetes 原生調(diào)度與資源綁定功能已經(jīng)無法滿足復(fù)雜的算力場景。圖6為某集群節(jié)點的CPU使用率，從中可以看到使用原生調(diào)度器的場景下每個節(jié)點的CPU使用率并不均勻并且存在個別節(jié)點資源使用不充分的情況。
圖6 集群節(jié)點CPU使用率
資源層
- 資源碎片使資源池?zé)o法充分利用
由于 Kubernetes 調(diào)度程序無法預(yù)測未來的 Pod 大小和節(jié)點添加，隨著時間的推移，最終會導(dǎo)致任何節(jié)點都無法滿足Pod的資源調(diào)度，即使節(jié)點上可能剩余很多資源。這樣就產(chǎn)生一個假的資源緊張現(xiàn)象。結(jié)合圖7和圖8展示的G行某集群節(jié)點CPU資源使用情況和Pod業(yè)務(wù)資源規(guī)格可以看出節(jié)點計算資源總量為16核，已請求13.15核，但業(yè)務(wù)的請求規(guī)格為4核，這直接導(dǎo)致節(jié)點有至少2核的資源碎片無法被其他Pod調(diào)度。
圖7 G行某集群節(jié)點CPU使用情況
資源優(yōu)化措施
通過分析上面影響資源利用率的原因做出以下相應(yīng)改進措施。
應(yīng)用層
- 結(jié)合云的特性優(yōu)化資源評估方法，規(guī)范調(diào)配常駐資源
針對使用方普遍存在的過度申請冗余資源的情況。在資源申請方面，G行通過非功能測試評估業(yè)務(wù)部門未來一段時間的業(yè)務(wù)規(guī)劃，梳理出合規(guī)并有一定冗余量的資源規(guī)格；在資源優(yōu)化方面，通過持續(xù)收集容器的資源用量，進行匯總分析，根據(jù)歷史數(shù)據(jù)和智能算法為每個容器生成資源規(guī)格的合理推薦值，沉淀形成資源評估分配規(guī)范標(biāo)準(zhǔn)；在資源運營方面，強化資源使用跟蹤，監(jiān)控資源運行數(shù)據(jù)，按日發(fā)布資源利用率情況，按月發(fā)布項目運營分析報告及綜合效能評分，協(xié)助各項目組優(yōu)化資源部署，提升資源效能。
從圖9展示的資源利用率變化趨勢圖可以看出，針對某電子化項目資源利用率低的問題做出整改措施后，利用率有明顯的上升變化。
圖9 某電子化項目資源使用優(yōu)化趨勢圖
- 在充分測試后，有效推進彈性技術(shù)賦能業(yè)務(wù)
在線類業(yè)務(wù)的使用量會根據(jù)負(fù)載情況出現(xiàn)波動，所以在設(shè)置資源規(guī)格時應(yīng)該充分考慮周期性特點使用彈性資源，以便業(yè)務(wù)在流量谷底可以降低資源使用，而在高峰之前又能及時提升能力。Kubernetes提供了自動擴展功能，如基于指標(biāo)的自動水平彈性擴縮容HPA，可以根據(jù)工作負(fù)載的 CPU 或內(nèi)存使用率自動擴縮 Pod 副本數(shù)，通過使用彈性能力實現(xiàn)資源按需分配。
從圖10和圖11可以看到某業(yè)務(wù)在CPU負(fù)載超過目標(biāo)閾值45秒后，Pod自動擴容到3副本。彈性擴縮容幫助業(yè)務(wù)減少冗余資源的設(shè)置、規(guī)避容量風(fēng)險。
圖10 擴容CPU平均使用率
圖11 擴容Pod副本數(shù)
調(diào)度層
- 調(diào)度感知實際資源負(fù)載
由于原生Kubernetes調(diào)度器依賴于Request 靜態(tài)配置，而不是基于實際節(jié)點的負(fù)載情況調(diào)度Pod，因此會出現(xiàn)集群各個節(jié)點負(fù)載不均衡的現(xiàn)象。我們期望動態(tài)獲取當(dāng)前節(jié)點 的實時資源水位，據(jù)此打分從而干預(yù)調(diào)度結(jié)果，平衡各個計算節(jié)點的資源使用，充分發(fā)揮資源池的資源供給。
資源層
- 資源碎片再平衡
原生Kubernetes調(diào)度器會根據(jù)當(dāng)時集群的資源描述做出最佳的調(diào)度決定，但基于靜態(tài)數(shù)據(jù)的調(diào)度有時并不能適應(yīng)之后資源的動態(tài)變化，我們期望通過識別和遷移節(jié)點間的特定 Pod 來實現(xiàn)可用資源片段的整合，解決資源池的資源碎片，更充分利用好現(xiàn)有資源，節(jié)省不必要的開支。
總結(jié)
本文首先介紹容器環(huán)境各層使用資源的背景，通過生產(chǎn)環(huán)境的資源使用實踐，分析造成資源使用率低于預(yù)期的原因，最后提出相應(yīng)解決方案。
云上資源優(yōu)化并不是盲目追求低成本，而是在業(yè)務(wù)價值得到保障前提下有效提高投入產(chǎn)出比。優(yōu)化需要統(tǒng)籌多方指標(biāo)達到最優(yōu)解，任何時候都不能忽視系統(tǒng)安全性、穩(wěn)定性、可擴展性和性能，這樣才能取得最優(yōu)效果?？傊?，上云用云是個循序漸進的過程，云上資源優(yōu)化也是反復(fù)迭代過程，需要覆蓋業(yè)務(wù)上云全周期形成閉環(huán)、持續(xù)跟蹤、持續(xù)分析、持續(xù)優(yōu)化最終達到最佳效果。
本文是介紹G行全棧云容器環(huán)境降本增效之路的入門文章，之后會不定期更新系列文章介紹G行容器云資源優(yōu)化實踐和效益，助力充分發(fā)揮云效能，服務(wù)好廣大客戶。
網(wǎng)頁標(biāo)題：G行探索全棧云容器環(huán)境降本增效之路——基礎(chǔ)篇
轉(zhuǎn)載來源：http://www.5511xx.com/article/ccooogd.html
