Crane如何做到利用率提升3倍穩定性還不受損？-有解無憂

作為云平臺用戶，我們都希望購買的服務器物盡其用，能夠達到最大利用率，然而要達到理論上的節點負載目標是很的，計算節點總是存在一些裝箱碎片和低負載導致的閑置資源，下圖展示了某個生產系統的CPU資源現狀，從圖中可以看出，浪費主要來自以下幾個方面：

業務需求與節點可調度資源很難完全匹配，因此在每個節點上都可能剩余一些碎片資源無法被分配出去，
業務通常為了絕對穩定，會申請超出自身需求的資源，這會導致業務鎖定了資源但事實上未能有效利用，
資源用量存在波峰波谷，很多在線業務都是有著規律性的服務高峰和低峰的，如通常白天負載較高，資源用量較大，而夜間在線訪問降低，資源用量也會跌入低谷，

Crane提供了Request推薦、副本數推薦、HPA推薦以及EPA等業務優化能力，能輔助業務自動化決策進行資源配置優化，然而在較大的組織中，業務改需要所有業務組件負責人的支持和配合，周期長、見效慢，如何在不改造業務的前提下，迅速提升集群資源利用率，在提升部署密度的同時保證延遲敏感和高優業務的穩定性和服務質量不受干擾，Crane混部能力給出了答案，

Crane提供了高優敏感業務與低優批處理業務的混部能力，能將集群利用率提升3倍！

混部的核心挑戰

所謂混部，就是將不同優先級的作業負載混合部署到相同集群中，一般來說，支撐在線服務的延遲敏感型（Latency Sensitive）業務優先級較高，支撐離線計算的高吞吐型（Batch）業務優先級通常較低，

看起來將這些不同型別的業務部署在相同集群，復用計算資源，就可以有效提升資源利用率，那么為什么混部只有在頂尖科技公司才有大規模應用呢？理想很美好，現實很骨感，如果只是簡單的將不同業務型別部署到一起，而不進行任何層面的資源隔離，那么在線業務服務質量必然會被影響，這也是為什么混部難以落地的核心原因，

干擾的來源

Kubernetes將計算資源分為不可壓縮資源和可壓縮資源，不可壓縮資源是指物理記憶體等被應用程式獨占的資源，在某個時刻一旦分配給某個行程，就不可以再被重新分配；可壓縮資源是指比如可以分時復用的CPU資源，多個行程可以共享同一CPU核，雖然在CPU在某個時鐘周期只為單一任務服務，但從宏觀時間維度，CPU是可以同時服務于多個行程的，當多個行程都有CPU需求時，這些需求交給作業系統統一分配和調度，當多個行程爭搶資源時，可能會導致應用性能下降，這便是我們所說的干擾，

USE方法（Utilization，Saturation，Errors）是性能測驗領域中廣泛采用的指導理論，在評估系統性能時，通過資源利用率，飽和度和錯誤率，來迅速的定位資源的瓶頸和錯誤所在，如下圖所示，針對不同資源都可以通過USE方法指導我們如何進行干擾檢測，

首先從資源維度，干擾可能發生在任何一個資源維度，比如常見的CPU以及CPU相關的L1,、L2、LLC快取、記憶體帶寬、磁盤IO、網路IO等，其次從干擾發生的層級來看，干擾可能發生在應用代碼、作業系統、硬體等不同層級，

對于應用而言，任何一環都可能成為干擾的來源；同時這些因素之間也會互相關聯，例如應用網路流量上升，不僅會造成帶寬的搶占，通常還會導致CPU資源消耗上升；又比如一個應用雖然計算邏輯簡單，但需要頻繁訪問記憶體資料，如果此時快取失效，則應用需要訪問物理記憶體，而CPU負載會因為忙等而上升，

因此判斷干擾是否發生，進一步尋找干擾源，并通過技術手段避免干擾是復雜的，這是干擾檢測自動化門檻高的核心原因，如何能在關聯的因素中識別干擾以及繞過表象找到真實的干擾源是混部需要解決的核心問題，

Crane的混部方案

Crane為混部場景提供了一套開箱即用的解決方案，借助Kubernetes CRD，該方案可靈活適配于多優先級的在線混部場景以及在離線混部場景，混部方案的能力概覽如下：

節點負載畫像與彈性資源回收
Crane實時采集節點利用率資料，并基于多種預測演算法計算出未來的閑置資源，為節點構建畫像，并將其以擴展資源形式更新成節點可調度資源，彈性資源的多少隨高優業務真實用量變化，高優業務用量上升，彈性資源減少，
彈性資源再分配
低優業務使用彈性資源，調度器確保低優業務首次調度時有足夠彈性資源可用，防止節點過載，
基于自定義水位線的干擾檢測和主動回避能力
- NodeQoS API允許集群運維定義節點水位，包括總CPU水位，或者彈性資源分配率、彈性資源水位等，并定義當真實用量達到水位時的回避動作，
- PodQoS API 定義不同型別作業負載的資源隔離策略，如CPU調度優先級，磁盤IO等，同時定義該型別業務允許的回避動作，
- AvoidanceAction定義調度禁止、壓制、驅逐等動作引數，當節點水位被觸發，只有允許某個動作的業務Pod才可以執行該操作，
基于內核隔離的增強QoS能力
Crane的開源方案中，可以通過動態調節CGroup壓制干擾源資源上限，同時，為支撐大規模生產系統的的隔離需求，Crane基于騰訊RUE內核，通過多級CPU調度優先級，以及絕對搶占等特性，保證高優業務不受低優業務的影響，
支持模擬調度的優雅驅逐等增強的重調度能力
當壓制不足以抑制干擾時，就需要從節點中驅逐低優Pod以確保高優業務的服務質量，Crane支持模擬調度的優雅驅逐重調度能力能夠借助集群全域視角和預調度能力降低重調度對應用的影響，

閑置資源回收

雖然Kubernetes提供了集群自動擴縮容能力，能夠讓云用戶在業務負載降低時縮小集群規模，節省成本，然而集群擴縮容效率依賴基礎架構和資源供給等因素約束，通常不是一個高頻操作，絕大多數云用戶的業務還運行在采用包年包月的固定節點池，

混部的第一步是從集群中識別出閑置資源并轉換成可被臨時借用的彈性算力，并更新成為節點可分配資源，Crane借助資源預測和本地實時檢測兩種手段計算節點可用彈性資源，

Crane Agent啟動時會自動依據如下的默認模版為節點創建TSP物件，Craned中的資源預測組件獲取該TSP物件以后立即讀取節點資源用量歷史，通過內置預測演算法進行預測，并將預測結果更新至TSP.Status，

apiVersion: v1
data:
  spec: |
    predictionMetrics:
    - algorithm:
        algorithmType: dsp
        dsp:
          estimators:
            fft:
            - highFrequencyThreshold: "0.05"
              lowAmplitudeThreshold: "1.0"
              marginFraction: "0.2"
              maxNumOfSpectrumItems: 20
              minNumOfSpectrumItems: 10
          historyLength: 3d
          sampleInterval: 60s
      resourceIdentif    ier: cpu
      type: ExpressionQuery
      expressionQuery:
        expression: 'sum(count(node_cpu_seconds_total{mode="idle",instance=~"({{.metadata.name}})(:\\d+)?"}) by (mode, cpu)) - sum(irate(node_cpu_seconds_total{mode="idle",instance=~"({{.metadata.name}})(:\\d+)?"}[5m]))'
    predictionWindowSeconds: 3600    
kind: ConfigMap
metadata:
  name: noderesource-tsp-template
  namespace: default

Crane Agent中的Node Resource Controller組件周期性檢測該節點的實時負載資訊，并按如下公式計算實時彈性CPU：
彈性CPU = 節點可分配CPU*（1-預留比例） -（節點實際CPU用量 - 彈性資源用量 + 綁核業務獨占的CPU）

節點可分配CPU：節點可分配CPU，即Node.Status.Allocatable.CPU
預留比例：保證始終有一定的空閑資源不能被復用，保證集群的穩定
節點實際CPU用量：節點實際的CPU用量，即node_cpu_seconds_total
彈性資源用量：節點實際用量包含了使用彈性資源的部分業務，而這部分開銷是是彈性資源，因此需要算入彈性CPU中
綁核業務獨占的CPU：被業務系結的CPU不可二次分配，因此需要再彈性CPU中扣除

Node Resource Controller 同時監聽節點TSP物件變化，當讀取到TSP物件的狀態變化時，同時參考本地實時可回收彈性資源以及預測結果，并取其中較小的值更新為節點彈性資源gocrane.io/cpu，記憶體等其他資源原理與CPU一致，

彈性資源使用

彈性資源更新成為節點Allocatable Resource以后，低優業務即可通過資源宣告將彈性資源利用起來，Kubernetes調度器確保節點彈性資源能夠滿足業務需求才能成功調度，

spec: 
   containers:
   - image: nginx
     name: extended-resource-demo
     resources:
       limits:
         gocrane.io/cpu: "2"
         gocrane.io/memory: "2000Mi"
       requests:
         gocrane.io/cpu: "2"
         gocrane.io/memory: "2000Mi"

干擾檢測與主動回避

彈性資源再分配能有效提升單節點業務部署密度，而更高的部署密度意味著業務面臨的資源競爭的可能性更大，Crane實時對節點和應用進行多維度的指標檢測，通過靈活可配的例外定義規則和篩選策略，判斷干擾是否發生，并且在干擾發生時犧牲低優Pod以確保高優業務的服務等級不變，

全維度指標采集

Crane Agent通過多種手段收集全維度指標，將這些指標統一保存在stateMap中，用于資源回收和干擾檢測，

基于多種手段：
通過決議系統檔案、呼叫cAdvisor介面、eBPF Hook等多種手段，采集包括CPU 利用率、CPI、虛擬機CPU Steal Time、記憶體利用率、進出網路流量和磁盤讀寫IO等指標，Crane用戶也可以撰寫插件采集自定義指標，

完整的指標檢測有助于干擾的分析，為之后更為完善的應用畫像，應用特性分析，應用之間的干擾情況提供充分的依據，

干擾判斷

下圖展示了Crane Agent的核心組件，在State Collector定期采集全維度指標以后，stateMap會交由Analyzer進行干擾判斷，

當前的干擾判斷規則沿用了Kubernetes健康檢查的判斷邏輯，用戶可基于NodeQOS物件定義干擾判斷規則，該物件可定義指標采集規則，干擾判斷所依賴的指標名稱以及其對應的干擾水位線等，同時通過AvoidanceAction定義干擾發生時需要執行的回避動作，詳情參見下面的配置示例：

apiVersion: ensurance.crane.io/v1alpha1
kind: NodeQOS
metadata:
  name: "cpu-usage-percent-watermark"
spec:
  nodeQualityProbe: 
    timeoutSeconds: 10
    nodeLocalGet:
      localCacheTTLSeconds: 60
  rules:
  - name: "cpu-usage-percent"
    avoidanceThreshold: 2 # 當達到閾值并持續多次，則規則被觸發
    restoreThreshold: 2 # 當閾值未達到并繼續多次, 則規則恢復
    actionName: "throttle" # 當觸發閾值時執行的 AvoidanceAction 名稱
    strategy: "None" # 動作的策略，可以將其設定為Preview以不實際執行
    metricRule:
      name: "cpu_total_utilization" # 水位線指標名稱
      value: 80 # 水位線指標的閾值，cpu用量達到80%

NodeQOS中的actionName屬性關聯了回避動作的名稱，需要創建AvoidanceAction物件完成回避動作的完整引數配置，當前支持 Scheduling Disable（關閉節點調度）、Throttle（通過Cgroup調節Pod的可用資源上限）, Eviction（驅逐Pod）三類操作操作；同時，如果節點干擾消失，Crane Agent也會自行執行逆操作，恢復節點和業務的資源配置狀態，

下面的AvoidanceAction示例展示了如何通過調節CGroup對Pod的可用資源進行壓制：

apiVersion: ensurance.crane.io/v1alpha1
kind: AvoidanceAction
metadata:
  name: throttle
  labels:
    app: system
spec:
  coolDownSeconds: 300
  throttle:
    cpuThrottle:
      minCPURatio: 10 #CPU 配額的最小比例，Pod不會被限制低于此值
      stepCPURatio: 10 #在觸發的回避動作中減少相應Pod的CPU配額占比，也是恢復動作中增加的CPU配額占比
  description: "throttle low priority pods"

壓制目標的選擇

NodeQOS定義了干擾判斷規則以及當干擾發生時需要執行的回避動作，那么回避動作會應用在哪些物件上呢？

Crane針對Kubelet內置驅逐規則做了一定程度的擴展，這些內置規則包括：

是否使用了彈性資源
比較優先級與QOSClass
比較CPU/記憶體用量的絕對值
比較實際用量與彈性資源上限的比值
運行時間等

Crane用戶也可以針對自定義水位線指標實作特定的驅逐選擇規則，

除此之外，Crane用戶可以通過定義PodQOS來定義特定Namespace、特定優先級、特定標簽的Pod允許執行特定的驅逐動作，如下面的例子，為有preemptible_job: "true"標簽的離線BestEffort Pod配置可被壓制操作，通過PodQOS的精細化管控，我們實作了業務側的個性化需求：比如 logstash服務的負責人希望這類業務接受驅逐但不接受壓制；而運行了數個星期的AI訓練任務寧愿被壓制而不是被驅逐，

apiVersion: ensurance.crane.io/v1alpha1
kind: PodQOS
metadata:
  name: all-elastic-pods
spec:
  allowedActions:
    - throttle
  labelSelector:
    matchLabels:
      preemptible_job: "true"
  scopeSelector:
    matchExpressions:
      - operator: In
        scopeName: QOSClass
        values:
          - BestEffort

支持優雅驅逐的重調度器

Crane Agent是運行在每個節點的Daemonset Pod，它所做的決策都是基于節點而缺乏全域視角，當多個節點同時發生干擾，Agent需要對某低優業務進行驅逐時，若無PDB對最大可用副本數進行保護，很可能會導致該業務的多個Pod同時被驅逐，進而造成服務質量下降，
Crane Agent支持與中心化部署的重調度器聯動，由Crane Agent為待驅逐Pod打上標簽，并交由重調度器統一進行驅逐，
Crane增強的Descheduler支持優雅驅逐能力，包括：

支持模擬調度，集群資源不足時可停止驅逐，該程序模擬Filter，PreFilter程序，不僅包含了Scheduler默認包含的插件，同時支持調度器擴展插件，模擬實際調度程序
有全域視圖，在多Workload并行，同一Workload內串行驅逐，適用于固定時間視窗騰空節點和基于特定標簽批量驅逐Pod/Workload/母機的場景
可以通過先擴容后縮容的方式實作無感驅逐，保證Workload可用性

RUE內核提供混部的穩定底座

如意，TencentOS RUE(Resource Utilization Enhancement)，是 TencentOS 產品矩陣中一款專為云原生場景下服務器資源 QoS 設計，提升資源利用率，降低運營成本的產品，如意統一調度分配云上機器的 CPU、IO、網路、記憶體等資源，相比傳統的服務器資源管理方案，如意更適用于云場景，能夠顯著提升云上機器的資源使用效率，降低云上客戶的運營成本，為公有云、混合云、私有云等客戶提供資源增值服務，如意的核心技術能做到不同優先級的業務之間不互相干擾，實作資源利用率、資源隔離性能、資源服務質量的高效統一，

相比傳統的資源管理方案，如意具有以下特點:

為云而生:對接 K8S 等主流資源管理平臺，以容器為物件進行資源調度，
多優先級:支持三檔基礎優先級，支持更多優先級擴展，
多種資源:對CPU、IO、網路、記憶體等服務器資源進行全面統一調度，
資源隔離:低優先級器可以使用空閑資源，不會對高優先級容器造成影響，
穩定有效:在騰訊云百萬級別資料中心上驗證，服務眾多客戶，

以干擾最容易發生的CPU資源為例，如意CPU QoS 允許用戶將服務器上的容器劃分成不同優先級，根據優先級分配 CPU 資源，保障低優先級容器不會對高優先級容器造成干擾(包括調度時延，CPU 使用時間等)，同時允許低優先級容器使用空閑 CPU 資源，從而提升 CPU 利用率，降低計算成本，

Crane涵蓋了RUE的大部分功能，涉及CPU，記憶體，IO，網路等多個維度，通過PodQOS和NodeQOS為應用提供批量化的RUE隔離能力，使得用戶無需關注復雜的CGroup配置便能輕松實作內核層面的資源隔離和保障，

最佳實踐

安裝配置

參考教程安裝 Crane 和 Fadvisor部分，即可安裝Crane-Agent和Crane，其中NodeResource作為FeatureGate控制彈性資源復用功能的開啟，目前默認開啟，用戶無需配置；如需使用到節點彈性資源TSP預測，需要同時部署監控組件，參考教程安裝 Prometheus 和 Grafana部分，CraneTimeSeriesPrediction作為FeatureGate控制預測功能的開啟，默認開啟，用戶無需再做配置，

Crane-Agent支持Docker和Containerd，自動探測無需用戶配置；支持cgroupfs，systemd兩種cgroup-driver，默認使用cgroupfs，如需更改，command添加--cgroup-driver="systemd"即可，

下面以將業務分為高低兩個優先級為例說明如何配置使用；

通過PodQOS支持的scopeSelector為業務做區分和分級；同時配置低優先級的資源配置使用彈性資源，如gocrane.io/cpu
為每級業務創建對應的PodQOS，指定其對應范圍和允許的回避動作以及資源隔離策略
創建NodeQOS指定一潭訓多條水位線和對應的回避操作，比如60%時開始壓制，70%時開始驅逐等

apiVersion: ensurance.crane.io/v1alpha1
kind: PodQOS
metadata:
  name: high
    ...
  allowedActions:
  scopeSelector:
    ...
  resourceQOS:
    cpuQOS:
      cpuPriority: 0

apiVersion: ensurance.crane.io/v1alpha1
kind: PodQOS
metadata:
  name: low
    ...
  allowedActions:
    - eviction
  scopeSelector:
    ...
  resourceQOS:
    cpuQOS:
      cpuPriority: 7

apiVersion: ensurance.crane.io/v1alpha1
kind: NodeQOS
metadata:
  name: "watermark"
     ...  
    actionName: throttle
    metricRule:
      name: cpu_total_utilization 
      value: 70

Housekeeper

隨著 Housekeeper（騰訊云原生運維新范式）的推出，QoS Agent 已經結合原生節點的能力提供了可搶占式 Job 的能力，該型別 Job 使用的資源是集群中的閑置資源，不占用集群/節點真實的剩余可調度量，在發生資源競爭時，該部分資源會被優先回收，保證正常使用節點資源的業務的穩定性，更多請參考：可搶占式Job（https://cloud.tencent.com/document/product/457/81751）

擴展閱讀

混部在離線作業調度時應優先選擇滿足彈性資源用量中真實負載較低的節點進行部署，避免節點負載不均；同時，需保障高優和延遲敏感業務的資源訴求，如調度到資源寬裕的節點，滿足NUMA拓撲的綁核需求等，Crane通過真實負載調度和CPU拓撲感知調度滿足了如上需求，具體可參考Crane-Scheduler和CPU拓撲感知調度，

【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/539639.html

標籤：其他

上一篇：紛繁復雜見真章，華為云產品需求管理利器CodeArts Req解讀

下一篇：智能PDU,網路遠程管理電源能耗提升配電效率