启用动态资源超卖

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:
       # 单位为千分之一核，以下表示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核。
           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. 登录容器服务管理控制台，在左侧导航栏选择集群列表。

2. 在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择运维管理 > Prometheus 监控。

3. 单击其他页签，然后单击k8s-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 Limit中配置了kubernetes.io/batch-memory的应用（简称batch limit），ack-koordinator会等待容器创建后根据batch limit在节点上为其设置Cgroup限制参数。由于部分应用在启动时会根据容器Cgroup参数自动申请内存，若应用在Cgroup的memory.limit参数设置前就完成了启动，其内存的真实用量可能会超过batch limit。而操作系统不会立即缩减该进程的内存使用，从而导致容器的内存Cgroup参数无法设置成功，需等待至其真实用量降低至batch limit以下。

此时，建议您适当调整应用配置参数，控制其内存真实用量在batch limit以下，或在应用启动脚本中首先检查内存限制参数，确认完成设置后再进行启动，确保应用的内存用量存在合理限制，避免出现OOM等情况。

您可以在容器内执行以下命令，查看内存资源限制参数。

# 单位为字节。
cat /sys/fs/cgroup/memory/memory.limit_in_bytes 
# 预期输出。
1048576000