基于volcano实现节点真实负载感知调度
本文分享自华为云社区《基于volcano实现节点真实负载感知调度》，作者： 可以交个朋友。
背景
默认调度器调度器视某个节点的空闲可调度资源=节点可分配资源 - SUM(节点上已调度Pod们的request),当某个Pod处于pending状态待调度时，默认调度器根据Pod中指定的request值和各个节点的空闲可调度资源比较，如果某个节点空闲可调度资源 < pod的request值，则节点不可被调度，反之则可能被调度。
从这里可以看出，默认调度主要是依据各个pod创建时设置的request值，可能导致：
- 业务实际负载需要的资源远大于创建时指定的request值，导致节点部署过密，影响业务运行稳定性；
- 业务实际负载需要的资源小于创建时候指定的request值，导致节点部署稀疏，造成资源浪费
基于volcano节点真实负载感知调度方案介绍
默认调度器基于上述调度策略的主要原因是，k8s自己没有真实去获取节点真实资源消耗，导致无法实现更合理的节点的空闲可调度资源=节点可分配资源 - 节点真实资源使用。开源Prometheus可以获取到各个节点的真实负载情况，基于volcano调度插件的能力可以实现基于应用能够基于真实负载调度，在资源满足的情况下，Pod优先被调度至真实负载低的节点，集群各节点负载趋于均衡。
CCE集群开启负载感知调度
限制
已创建v1.21及以上版本的集群
已安装Volcano 1.11.14及以上版本的插件
已安装CCE云原生监控插件（kube-prometheus-stack），并选择server模式
开启负载感知调度
安装Volcano调度器、云原生监控插件（安装server模式，agent模式没有custom-metrics API）
集群通过Custom Metrics API提供资源指标，修改adapter-config的configMap，添加自定义指标采集规则。配置项与密钥->命名空间选择 “monitoring” ->找到user-adapter-config 点击 “更新”
编辑->添加新规则
- seriesQuery: '{__name__=~"node_cpu_seconds_total"}'
resources:
overrides:
instance:
resource: node
name:
matches: node_cpu_seconds_total
as: node_cpu_usage_avg
metricsQuery: avg_over_time((1 - avg (irate(<<.Series>>{mode="idle"}[5m])) by (instance))[10m:30s])
- seriesQuery: '{__name__=~"node_memory_MemTotal_bytes"}'
resources:
overrides:
instance:
resource: node
name:
matches: node_memory_MemTotal_bytes
as: node_memory_usage_avg
metricsQuery: avg_over_time(((1-node_memory_MemAvailable_bytes/<<.Series>>))[10m:30s])
CPU平均利用率采集规则
node_cpu_usage_avg： 表示节点的CPU平均利用率，该指标名不可修改。
metricsQuery: avg_over_time((1 - avg (irate(<<.Series>>{mode=“idle”}[5m])) by (instance))[10m:30s])：为节点CPU平均利用率的查询语句。当前metricsQuery表示查询所有节点最近10分钟的CPU平均利用率，如果希望调整平均值的计算周期，可以修改上述标红的10m。(30s是分辨率)
Memory平均利用率采集规则：
node_memory_usage_avg： 表示节点的Memory利用率，该指标名不可修改。
metricsQuery:avg_over_time(((1-node_memory_MemAvailable_bytes/<<.Series>>))[10m:30s]) 为节点Memory平均利用率的查询语句。
当前metricsQuery表示查询所有节点最近10分钟的Memory平均利用率，如果希望调整平均值的计算周期为，可以修改上述标红的10m。(30s是分辨率)
新部署metrics-api-server负载，使其加载user-adapter-config的最新配置
开启负载感知调度能力。配置中心->调度配置->默认调度器”volcano”->资源利用率优化调度->支持负载感知调度
负载感知调度根据CPU、Memory真实负载信息对节点进行打分排序，优先选择负载更低的节点参与调度。
如果我们更偏向于将负载调度到cpu真实负载低的节点，或内存真实负载低的节点，可以通过调整权重来影响节点打分，负载优先选择得分最高的节点参与调度
节点打分公式：
节点得分=负载感知策略权重 *（（1 - CPU资源利用率） * CPU权重 + （1 - Memory资源利用率） * 内存权重）/（CPU权重 + 内存权重）
真实负载阈值，从CPU和内存两方面限制节点真实负载的水位，防止节点压力过高，真实负载阈值的生效方式分为“软约束“和“硬约束“
软约束：节点 CPU、内存真实负载达到阈值后，新的任务优先被分配至真实负载未达到阈值的节点，但是该节点依然允许调度。
效果验证
环境准备
创建1个负载 cpu：request 0.1 limit 6，使其调度在 “192.168.64.81” 这个节点上，节点CPU request的分配率：42.48% 实际占用率 76.9%
创建1个负载 cpu：request 4 limit 4，使其调度在 “192.168.64.219” 这个节点上，节点CPU request的分配率：91.15% 实际占用率 1.4%
验证未开启负载感知调度时，新建负载的调度情况
创建1个负载，CPU request 0.1 limit 0.1 内存 request 100MiB limit 100MiB
查看工作负载的调度情况，发现负载调度到了cpu request分配率低，但是实际CPU占用率高的节点 “192.168.64.81” 上
再添加1个副本，仍然调度到"192.168.64.81"上
验证开启负载感知调度时，新建负载的调度情况
开启负载感知调度，CPU 真实负载阈值设置为70% 硬约束
创建1个负载，CPU request 0.1 limit 0.1 内存 request 100MiB limit 100MiB
信息填写完整后，点击右上角yaml创建，添加一行shcedulerName: volcano
查看工作负载调度情况，发现负载调度到了cpu request分配率高，但是实际CPU占用率低的节点 “192.168.64.219” 上
再添加1个副本，仍然调度在节点 “192.168.64.219” 上
