前言

資源使用背景

當前眾多金融企業開始將業務應用進行容器化部署，以期實現業務應用開發的敏捷迭代、運行環境的快速部署、業務負載的彈性伸縮、應用系統的全生命周期管理等效果。助力企業金融科技創新和金融場景創新，拓寬金融業行業邊界，讓金融服務內容更加多元，挖掘用戶更多潛在需求，提升用戶黏性和服務體驗，全面增強企業競爭力。

當前上云用云作為G行數字化轉型的關鍵一步已走到決定性階段。從內部來看，隨著上云由外圍系統過渡到核心系統，用云進入深水區，目標從如何上云用云，變成如何用好云。安全可靠、控制成本和優化性能是目前G行云使用方案需要關注的三個重要維度。從外部來看，一方面全球經濟下行處于下行期，另一方面近期一些互聯網頭部企業相繼發生系統崩潰事件，促使業界對云使用的資源優化和安全運行討論又一次達到高峰。

在云資源降本增效的過程中，我們目標是要降本不降質，不能以降低系統穩定性、效率、安全運營等為代價。本文基于有效保障業務平穩運行的前提下，探索常見容器環境的資源優化方法，對如何提升資源利用率，控制云成本做出思考和總結。

資源使用背景

為方便理解，我們將容器環境應用架構分為如圖1所示的應用層、調度層、資源層。逐一闡述各層資源使用情況。

圖1 容器環境應用基礎架構

應用層

Kubernetes 使用了Request（請求）和Limit（限額）來描述容器對CPU和內存資源的需求。

Request：容器預留的資源量。即便容器沒有實際使用到這些資源，Kubernetes也會為容器預留好這些資源，其他容器無法在資源池內申請這些資源。

Limit：限制容器使用的資源上限。容器在實際運行的時候不能超過的資源閾值。如果容器使用的資源超過了這個值，就會觸發K8s后續對應的操作。對于CPU來說，由于CPU 是可壓縮資源，所以如果容器使用的CPU超過了 limit 設置的值，會導致CPU節流服務降級，影響應用處理速度。但對于內存這種不可壓縮資源，如果內存的使用量超過了limit的值，則會觸發OOMKilled。

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

圖2 集群工作節點應用CPU超賣情況

調度層

在Kubernetes中，調度是指將Pod放置到合適的節點上，以便節點上的Kubelet能夠運行這些Pod。原生Kubernetes調度器Kube-scheduler給一個Pod做調度選擇時包含兩個階段—預選和優選。

預選階段會將所有滿足Pod調度需求的節點選出來。其中PodFitsResurces策略會檢查候選節點的可用資源是否滿足Pod的Request資源請求。

優選階段會對每個通過預選的節點優先級打分。其中LeastRequestedPriority策略會優先從預選節點列表選擇資源占用最小的節點。BalancedResourceAllocation策略會優先從預選節點選擇CPU和內存占用率最均衡的節點。

從原生Kubernetes調度器的策略可以看出，Pod請求值Request配置的準確性直接影響集群節點資源利用率和集群負載的均衡性。

資源層

Node節點資源并不能完全被Pod所使用，這就引入了一個問題，Kubernetes如何劃分節點上的計算資源。Kubernetes將節點上的計算資源分為如圖3所示幾部分，其中：

• System Reserved：系統保留的計算資源，不能被Kubernetes調度和使用，比如 sshd 等等。
• Kubernetes Reserved：Kubernetes為Dockerd、Kubelet、Kube-proxy等保留的計算資源，這部分保證Kubernetes正常工作。
• Eviction Thread：當節點內存或磁盤資源緊張時達到閾值，kubelet會根據Pod 的 QoS優先級回收Pod占用的資源。
• Fragments Resource：通常情況下，Node節點上會剩余一些資源碎片，這些資源無法滿足調度Pod的資源需求。
• Node Allocatable Capacity: 能夠被Kubernetes調度和使用的計算資源，它的計算方法為：[Node Allocatable Capacity] = [Node Capacity] - [System Reserved] - [Kubernetes Reserved] - [Eviction Thread] - [Fragments Resource]

圖3 Node節點維度的計算資源

資源未能充分使用原因

應用層

• 采用傳統資源評估分配方法進行云上資源分配

容器資源規格Resource Request和Limit的填寫讓Kubernetes的使用者困惑，應用管理員需要預留較多的冗余資源，來應對流量的波動，保障業務運行的穩定性，導致資源冗余性有余，利用率不足。在圖4中，某教學類系統CPU請求率為2%到5%（請求率=使用值/請求值），資源規格Request值設置有冗余，資源利用率有一定的提升空間。

圖4 教學類項目資源使用率

• 對容器的自動彈性能力保持謹慎，按需自動擴縮容未能有效運用

在應用層開啟彈性能力賦能業務是我們需要重點考慮的問題。容器秒級啟動的特性，讓我們可以在業務中利用彈性擴縮容按需分配資源。G行在研究探索過程中發現在線類交易業務流量存在波峰波谷現象，若此類業務開啟彈性擴縮容，會避免大量資源浪費。圖5為某在線交易項目微服務模塊的CPU使用率情況，我們可以看到該業務每天會有突發性流量高峰，其他時間段流量處于較低的水平，有明顯的流量波峰和波谷的特征。非常適合利用容器的極速彈性能力實現資源優化。

圖5 在線交易項目微服務模塊CPU使用率

調度層

• 原生調度無法滿足實際使用場景

Kubernetes默認使用原生調度器Kube-scheduler，它的主要職責是為一個新創建出來的 Pod，尋找一個最合適的 Node節點。G行在探索過程中發現由于原生 Kubernetes 調度器只能基于資源的 Resource Request 進行調度，有些節點 Pod 的真實資源使用率，往往與其所申請資源的Request差異很大，這直接導致集群負載不均的問題和部分節點的資源使用不充分。Kubernetes 原生調度與資源綁定功能已經無法滿足復雜的算力場景。圖6為某集群節點的CPU使用率，從中可以看到使用原生調度器的場景下每個節點的CPU使用率并不均勻并且存在個別節點資源使用不充分的情況。

圖6 集群節點CPU使用率

資源層

• 資源碎片使資源池無法充分利用

由于 Kubernetes 調度程序無法預測未來的 Pod 大小和節點添加，隨著時間的推移，最終會導致任何節點都無法滿足Pod的資源調度，即使節點上可能剩余很多資源。這樣就產生一個假的資源緊張現象。結合圖7和圖8展示的G行某集群節點CPU資源使用情況和Pod業務資源規格可以看出節點計算資源總量為16核，已請求13.15核，但業務的請求規格為4核，這直接導致節點有至少2核的資源碎片無法被其他Pod調度。

圖7 G行某集群節點CPU使用情況

資源優化措施

通過分析上面影響資源利用率的原因做出以下相應改進措施。

應用層

• 結合云的特性優化資源評估方法，規范調配常駐資源

針對使用方普遍存在的過度申請冗余資源的情況。在資源申請方面，G行通過非功能測試評估業務部門未來一段時間的業務規劃，梳理出合規并有一定冗余量的資源規格；在資源優化方面，通過持續收集容器的資源用量，進行匯總分析，根據歷史數據和智能算法為每個容器生成資源規格的合理推薦值，沉淀形成資源評估分配規范標準；在資源運營方面，強化資源使用跟蹤，監控資源運行數據，按日發布資源利用率情況，按月發布項目運營分析報告及綜合效能評分，協助各項目組優化資源部署，提升資源效能。

從圖9展示的資源利用率變化趨勢圖可以看出，針對某電子化項目資源利用率低的問題做出整改措施后，利用率有明顯的上升變化。

圖9 某電子化項目資源使用優化趨勢圖

• 在充分測試后，有效推進彈性技術賦能業務

在線類業務的使用量會根據負載情況出現波動，所以在設置資源規格時應該充分考慮周期性特點使用彈性資源，以便業務在流量谷底可以降低資源使用，而在高峰之前又能及時提升能力。Kubernetes提供了自動擴展功能，如基于指標的自動水平彈性擴縮容HPA，可以根據工作負載的 CPU 或內存使用率自動擴縮 Pod 副本數，通過使用彈性能力實現資源按需分配。

從圖10和圖11可以看到某業務在CPU負載超過目標閾值45秒后，Pod自動擴容到3副本。彈性擴縮容幫助業務減少冗余資源的設置、規避容量風險。

圖10 擴容CPU平均使用率

圖11 擴容Pod副本數

調度層

• 調度感知實際資源負載

由于原生Kubernetes調度器依賴于Request 靜態配置，而不是基于實際節點的負載情況調度Pod，因此會出現集群各個節點負載不均衡的現象。我們期望動態獲取當前節點  的實時資源水位，據此打分從而干預調度結果，平衡各個計算節點的資源使用，充分發揮資源池的資源供給。

資源層

• 資源碎片再平衡

原生Kubernetes調度器會根據當時集群的資源描述做出最佳的調度決定，但基于靜態數據的調度有時并不能適應之后資源的動態變化，我們期望通過識別和遷移節點間的特定 Pod 來實現可用資源片段的整合，解決資源池的資源碎片，更充分利用好現有資源，節省不必要的開支。

總結

本文首先介紹容器環境各層使用資源的背景，通過生產環境的資源使用實踐，分析造成資源使用率低于預期的原因，最后提出相應解決方案。

云上資源優化并不是盲目追求低成本，而是在業務價值得到保障前提下有效提高投入產出比。優化需要統籌多方指標達到最優解，任何時候都不能忽視系統安全性、穩定性、可擴展性和性能，這樣才能取得最優效果。總之，上云用云是個循序漸進的過程，云上資源優化也是反復迭代過程，需要覆蓋業務上云全周期形成閉環、持續跟蹤、持續分析、持續優化最終達到最佳效果。

本文是介紹G行全棧云容器環境降本增效之路的入門文章，之后會不定期更新系列文章介紹G行容器云資源優化實踐和效益，助力充分發揮云效能，服務好廣大客戶。