基于volcano实现节点真实负载感知调度
内容提要
本文介绍了基于volcano实现节点真实负载感知调度的方案，通过volcano调度插件和Prometheus获取节点真实负载情况，提高集群负载均衡。开启负载感知调度需要安装Volcano和CCE云原生监控插件，并进行相关配置。验证结果表明开启负载感知调度后，负载能够调度到真实负载低的节点。
延伸解读
默认调度器的局限与真实负载感知的价值
Kubernetes默认调度器仅依据Pod的request值计算节点空闲资源，无法感知节点实际资源消耗。这可能导致两种问题：若业务实际负载远大于request，节点会部署过密，影响稳定性；若实际负载远小于request，则节点部署稀疏，造成资源浪费。基于Volcano和Prometheus的真实负载感知调度，通过采集节点CPU和内存的真实利用率，使调度决策更贴近实际，从而提升集群负载均衡。
部署前提与关键配置步骤
启用负载感知调度需满足三个条件：集群版本v1.21及以上、已安装Volcano 1.11.14及以上版本、已安装CCE云原生监控插件并选择server模式（agent模式无custom-metrics API）。配置时需修改monitoring命名空间下的user-adapter-config，添加自定义指标采集规则，定义node_cpu_usage_avg和node_memory_usage_avg指标，并重新部署metrics-api-server以加载新配置。最后在调度配置中开启负载感知调度开关。
节点打分与阈值约束机制
负载感知调度根据CPU和内存真实利用率对节点打分，优先选择得分高的节点。打分公式为：节点得分=策略权重*((1-CPU利用率)*CPU权重+(1-内存利用率)*内存权重)/(CPU权重+内存权重)。用户可通过调整CPU和内存权重来影响调度倾向。真实负载阈值分为软约束和硬约束：软约束下，达到阈值的节点仍可被调度，但新任务优先分配至未达阈值的节点；硬约束下，达到阈值的节点禁止调度新任务。
效果验证与调度行为对比
验证环境中有两个节点：192.168.64.81的CPU request分配率42.48%但实际占用率76.9%；192.168.64.219的CPU request分配率91.15%但实际占用率1.4%。未开启负载感知调度时，新负载被调度到192.168.64.81，导致实际负载高的节点更繁忙。开启负载感知调度并设置CPU真实负载阈值70%硬约束后，新负载被调度到192.168.64.219，实现了基于真实负载的均衡调度。
Q&A
默认调度器为什么可能导致节点资源浪费或过载？
默认调度器仅根据Pod的request值计算节点空闲资源，不考虑节点真实负载。如果业务实际负载远大于request值，节点可能部署过密，影响稳定性；如果实际负载远小于request值，节点部署稀疏，造成资源浪费。
如何开启CCE集群的负载感知调度？
需要安装Volcano 1.11.14及以上版本和CCE云原生监控插件（server模式），然后修改adapter-config的configMap添加自定义指标采集规则，新部署metrics-api-server，最后在调度配置中开启负载感知调度。
负载感知调度的节点打分公式是什么？
节点得分 = 负载感知策略权重 * ((1 - CPU资源利用率) * CPU权重 + (1 - Memory资源利用率) * 内存权重) / (CPU权重 + 内存权重)。通过调整权重可以影响调度倾向。
真实负载阈值中的软约束和硬约束有什么区别？
软约束：节点CPU、内存真实负载达到阈值后，新任务优先分配到未达阈值的节点，但该节点仍允许调度。硬约束：节点达到阈值后，不允许调度新任务。
负载感知调度如何采集节点的CPU和内存真实负载？
通过Prometheus采集节点指标，并配置自定义指标采集规则：CPU使用node_cpu_usage_avg指标，查询语句为avg_over_time((1 - avg (irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance))[10m:30s])；内存使用node_memory_usage_avg指标，查询语句为avg_over_time(((1-node_memory_MemAvailable_bytes/node_memory_MemTotal_bytes))[10m:30s])。
开启负载感知调度后，调度效果有什么变化？
验证显示，开启后新建负载会调度到真实CPU占用率低的节点，即使该节点的request分配率较高；而未开启时，负载会调度到request分配率低但实际CPU占用率高的节点。
