Container Service for Kubernetes：啟用動態資源超賣

1、開啟動態資源超賣

您可以通過ConfigMap開啟動態資源超賣功能，也可以在ConfigMap中配置相關參數，例如節點資源的預留係數、計算節點資源容量的策略等，實現更靈活的超賣資源管理。

1. 參見以下ConfigMap，建立configmap.yaml檔案。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ack-slo-config
     namespace: kube-system
   data:
     colocation-config: |
       {
         "enable": true,
         "metricAggregateDurationSeconds": 60,
         "cpuReclaimThresholdPercent": 60,
         "memoryReclaimThresholdPercent": 70,
         "memoryCalculatePolicy": "usage"
       }

   您可以修改ConfigMap中的配置項，實現對batch-cpu和batch-memory資源的靈活管理。

   參數說明

   參數	格式	說明
   enable	Boolean	是否開啟節點Batch資源的動態更新。關閉時，Batch資源量會被重設為0。預設值為 false。
   metricAggregateDurationSeconds	Int	系統在多長時間周期內彙總一次指標資料，以決定是否需要更新或調整Batch資源，單位為秒。通常建議使用預設值，60秒。
   cpuReclaimThresholdPercent	Int	計算節點batch-cpu資源容量時的預留係數。關於如何計算可動態超賣的CPU資源量，請參見計算可用的動態超賣資源量。預設值為65，單位為百分比。
   memoryReclaimThresholdPercent	Int	計算節點batch-memory資源容量時的預留係數。關於如何計算可動態超賣的記憶體資源量，請參見計算可用的動態超賣資源量。預設值為65，單位為百分比。
   memoryCalculatePolicy	String	計算節點batch-memory資源容量時所採用的策略。 "usage"：預設值，表示會按照高優先順序Pod的記憶體真實使用量計算可用的batch-memory資源，包括節點未申請的資源以及已申請但未使用的資源量。 "request"：會按照高優先順序Pod的記憶體Request計算可用的batch-memory資源，僅包括節點未申請的資源。

   計算可用的動態超賣資源量

   根據Usage計算可用資源

   節點的Batch容量預設會根據實際的資源使用率情況動態進行計算，包括節點未申請的資源以及已申請但未使用的資源量。如需計算當前batch-cpu或batch-memory的可用資源量，可參見以下公式。

   nodeBatchAllocatable = nodeAllocatable * thresholdPercent - podUsage(non-BE) - systemUsage

   • nodeAllocatable：節點可分配的CPU或記憶體資源總量。

   • thresholdPercent：預留水位比例。您可以參見上方參數說明表格靈活調整。

   • podUsage(non-BE)：高優先順序Pod的資源用量，即非BE類型Pod的資源使用量。

   • systemUsage：節點系統資源真實用量。

   根據Pod Request計算Batch記憶體可用資源

   對於batch-memory的資源超賣，您還可以按Pod Request進行計算，僅包括節點未申請的資源。解釋說明，可參見參數說明中memoryCalculatePolicy的參數說明。

   您仍然可以參見以下公式來計算。

   nodeBatchAllocatable = nodeAllocatable * thresholdPercent - podRequest(non-BE) - systemUsage

   其中，podRequest(non-BE)表示高優先順序Pod的資源Request，即非BE類型Pod的資源Request之和。

2. 查看命名空間kube-system下是否存在ConfigMap ack-slo-config。

   • 存在：使用PATCH方式進行更新，避免幹擾ConfigMap中其他配置項。

     kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"

   • 不存在：執行以下命令建立ConfigMap。

     kubectl apply -f configmap.yaml

2、為應用Pod申請Batch資源

配置完成後，根據節點當前可用的Batch資源總量，您可以在Pod YAML檔案的metadata欄位中通過Labelkoordinator.sh/qosClass來聲明Pod對應的QoS類，並在Request和Limit中聲明所需的資源。

1. 執行以下命令，查看節點當前可用的Batch資源總量。

   # 將$nodeName替換為要查詢的目標節點名稱。
   kubectl get node $nodeName -o yaml

   預期輸出：

   # 節點資訊。
   status:
     allocatable:
       # 單位為毫核，1核=1000毫核，如下表示50核。
       kubernetes.io/batch-cpu: 50000
       # 單位為位元組，以下表示50 GB。
       kubernetes.io/batch-memory: 53687091200

2. 建立Pod並申請Batch資源。

   重要

   • 若您通過Deployment或其他類型的工作負載提交了Pod，請在template.metadata欄位下進行配置。同一個Pod不能同時申請Batch資源和普通的CPU或Memory資源。

   • Koordinator組件會根據節點當前的實際負載來動態調整可為Pod分配的Batch資源。極少數情況下，kubelet同步節點狀態資訊可能存在一定的延遲，導致Pod因資源不足而調度失敗。此時，請刪除並重建該Pod。

   • 受Kubernetes的約束，擴充資源必須為整數格式，因此batch-cpu資源需要以毫核為單位進行配置。

   metadata:
     labels:
       # 必填，標記為低優先順序Pod。
       koordinator.sh/qosClass: "BE"
   spec:
     containers:
     - resources:
         requests:
           # 單位為毫核，1核=1000毫核，如下表示1核。
           kubernetes.io/batch-cpu: "1k"
           # 單位為位元組，如下表示1 GB。
           kubernetes.io/batch-memory: "1Gi"
         limits:
           kubernetes.io/batch-cpu: "1k"
           kubernetes.io/batch-memory: "1Gi"

通過Prometheus查看Batch資源使用方式

ACK叢集整合了阿里雲Prometheus，提供Prometheus監控大盤。您可以在ACK控制台查看Batch資源的使用方式。

1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇營運管理 > Prometheus 監控。

3. 單擊其他頁簽，然後單擊Kubernetes Reclaimed Resource頁簽。

   可在此頁簽查看叢集混部的資源收益，以及叢集、節點和Pod維度混部資源容量資料。詳細資料，請參見啟用在離線混部監控。

   若自建了Prometheus大盤，也可以參見下述指標查看混部資源資料情況。

   # 節點batch-cpu可分配總量。
   koordlet_node_resource_allocatable{resource="kubernetes.io/batch-cpu",node="$node"}
   # 節點batch-cpu已指派量。
   koordlet_container_resource_requests{resource="kubernetes.io/batch-cpu",node="$node"}
   # 節點batch-memory可分配總量。
   kube_node_status_allocatable{resource="kubernetes.io/batch-memory",node="$node"}
   # 節點batch-memory已指派量。
   koordlet_container_resource_requests{resource="kubernetes.io/batch-memory",node="$node"}

當前已通過ack-slo-manager的舊版本協議使用了動態資源超賣功能，升級為ack-koordinator組件後是否繼續支援？

舊版本的動態資源超賣協議包括兩部分：

• 在Pod的Annotation中填寫的alibabacloud.com/qosClass。

• 在Pod的Request和Limit中填寫的alibabacloud.com/reclaimed。

ack-koordinator相容以上舊版本協議，並在ACK託管叢集Pro版的調度器中統一計算新舊版本協議的資源申請量和可用量。您可將組件無縫升級至ack-koordinator。

ACK託管叢集Pro版的調度器和ack-koordinator對各版本協議的適配如下。

應用使用了Batch資源後，為什麼部分Pod的記憶體資源限制未生效？

問題原因

為應用Pod在limit欄位中配置kubernetes.io/batch-memory（簡稱Batch Limit）後，ack-koordinator會在容器建立後根據Batch Limit在節點上為其設定Cgroup限制參數。

部分應用在啟動時會根據容器Cgroup參數自動申請記憶體。但如果應用啟動速度過快，在Cgroup的memory.limit參數生效前就完成了啟動，其記憶體的真實用量可能會超出Batch Limit。而作業系統不會立即縮減該進程的記憶體使用量，從而導致容器的記憶體Cgroup參數無法生效。只有在容器真實用量首次降低至Batch Limit值以下後，該參數才會生效。

解決方案

為避免此問題導致 OOM 等情況，建議採用以下任一方案：

• 調整應用配置：手動設定應用的記憶體參數（如 Java 的 -Xmx），確保其最大用量低於 Batch Limit 限制。

• 在啟動指令碼中等待：在啟動應用主進程前，加入等待邏輯，直到檢測到 Cgroup 記憶體限制已成功設定。

可在容器內執行以下命令，查看記憶體資源限制參數的生效情況。

# 單位為位元組
cat /sys/fs/cgroup/memory/memory.limit_in_bytes 

# 預期輸出
1048576000

如預期輸出值與配置的 Batch Limit值（換算為位元組後）相符，則表明記憶體限制已生效。