Dynamic Scheduler 是容器服务 TKE 基于 Kubernetes 原生 Kube-scheduler Extender 机制实现的动态调度器插件,可基于 Node 真实负载进行预选和优选。在 TKE 集群中安装该插件后,该插件将与 Kube-scheduler 协同生效,有效避免原生调度器基于 request 和 limit 调度机制带来的节点负载不均问题。
该组件依赖 Prometheus 监控组件以及相关规则配置,可参见本文 依赖部署 进行操作,避免遇到插件无法正常工作的情况。
Kubernetes 对象名称 | 类型 | 请求资源 | 所属 Namespace |
---|---|---|---|
node-annotator | Deployment | 每个实例 CPU:100m,Memory:100Mi ,共1个实例 | kube-system |
dynamic-scheduler | Deployment | 每个实例 CPU:400m,Memory:200Mi,共3个实例 | kube-system |
dynamic-scheduler | Service | - | kube-system |
node-annotator | ClusterRole | - | kube-system |
node-annotator | ClusterRoleBinding | - | kube-system |
node-annotator | ServiceAccount | - | kube-system |
dynamic-scheduler-policy | ConfigMap | - | kube-system |
restart-kube-scheduler | ConfigMap | - | kube-system |
probe-prometheus | ConfigMap | - | kube-system |
Kubernetes 原生调度器大部分基于 Pod Request 资源进行调度,并不具备根据 Node 当前和过去一段时间的真实负载情况进行相关调度的决策,因此可能会导致如下问题:
集群内部分节点的剩余可调度资源较多(根据节点上运行的 Pod 的 request 和 limit 计算出的值)但真实负载却比较高,而另外节点的剩余可调度资源比较少但真实负载却比较低,此时 Kube-scheduler 会优先将 Pod 调度到剩余资源比较多的节点上(根据 LeastRequestedPriority 策略)。
如下图所示,Kube-Scheduler 会将 Pod 调度到 Node2 上,但明显调度到 Node1(真实负载水位更低)是更优的选择。
为防止低负载的节点被持续调度 Pod,Dynamic Scheduler 支持设置防调度热点策略(统计节点过去几分钟调度 Pod 的数量,并相应减小节点在优选阶段的评分)。
当前采取策略如下:
动态调度器基于 scheduler extender 扩展机制,从 Prometheus 监控数据中获取节点负载数据,开发基于节点实际负载的调度策略,在调度预选和优选阶段进行干预,优先将 Pod 调度到低负载节点上。该组件由 node-annotator 和 Dynamic-scheduler 构成。
node-annotator 组件负责定期从监控中拉取节点负载 metric,同步到节点的 annotation。如下图所示:
注意:组件删除后,node-annotator 生成的 annotation 并不会被自动清除。您可根据需要手动清除。
Dynamic-scheduler 是一个 scheduler-extender,根据 node annotation 负载数据,在节点预选和优选中进行过滤和评分计算。
为了避免 Pod 调度到高负载的 Node 上,需要先通过预选过滤部分高负载的 Node(其中过滤策略和比例可以动态配置,具体请参见本文 组件参数说明)。
如下图所示,Node2 过去5分钟的负载,Node3 过去1小时的负载均超过对应的域值,因此不会参与接下来的优选阶段。
同时为了使集群各节点的负载尽量均衡,Dynamic-scheduler 会根据 Node 负载数据进行打分,负载越低打分越高。
如下图所示,Node1 的打分最高将会被优先调度(其中打分策略和权重可以动态配置,具体请参见本文 组件参数说明)。
注意:
- 为确保组件可以拉取到所需的监控数据、调度策略生效,请按照 依赖部署> **Prometheus 规则配置**步骤配置监控数据采集规则。
- 预选和优选参数已设置默认值,如您无额外需求,可直接采用。
预选参数默认值 | 说明 |
---|---|
5分钟平均 CPU 利用率阈值 | 节点过去5分钟平均 CPU 利用率超过设定阈值,不会调度 Pod 到该节点上。 |
1小时最大 CPU 利用率阈值 | 节点过去1小时最大 CPU 利用率超过设定阈值,不会调度 Pod 到该节点上。 |
5分钟平均内存利用率阈值 | 节点过去5分钟平均内存利用率超过设定阈值,不会调度 Pod 到该节点上。 |
1小时最大内存利用率阈值 | 节点过去1小时最大内存利用率超过设定阈值,不会调度 Pod 到该节点上。 |
优选参数默认值 | 说明 |
---|---|
5分钟平均 CPU 利用率权重 | 该权重越大,过去5分钟节点平均 CPU 利用率对节点的评分影响越大。 |
1小时最大 CPU 利用率权重 | 该权重越大,过去1小时节点最大 CPU 利用率对节点的评分影响越大。 |
1天最大 CPU 利用率权重 | 该权重越大,过去1天内节点最大 CPU 利用率对节点的评分影响越大。 |
5分钟平均内存利用率权重 | 该权重越大,过去5分钟节点平均内存利用率对节点的评分影响越大。 |
1小时最大内存利用率权重 | 该权重越大,过去1小时节点最大内存利用率对节点的评分影响越大。 |
1天最大内存利用率权重 | 该权重越大,过去1天内节点最大内存利用率对节点的评分影响越大。 |
Dynamic Scheduler 动态调度器依赖于 Node 当前和过去一段时间的真实负载情况来进行调度决策,需通过 Prometheus 等监控组件获取系统 Node 真实负载信息。在使用动态调度器之前,需要部署 Prometheus 等监控组件。在容器服务 TKE 中,您可按需选择采用自建的 Prometheus 监控服务或采用 TKE 推出的云原生监控。
通过 node-exporter 实现对 Node 指标的监控,用户可以根据业务需求部署 node-exporter 和 prometheus。
在 node-exporter 获取节点监控数据后,需要通过 Prometheus 对原始的 node-exporter 采集数据进行聚合计算。为了获取动态调度器中需要的 cpu_usage_avg_5m
、cpu_usage_max_avg_1h
、cpu_usage_max_avg_1d
、mem_usage_avg_5m
、mem_usage_max _avg_1h
、mem_usage_max_avg_1d
等指标,需要在 Prometheus 的 rules 规则进行如下配置:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: example-record
spec:
groups:
- name: cpu_mem_usage_active
interval: 30s
rules:
- record: cpu_usage_active
expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[30s])) * 100)
- record: mem_usage_active
expr: 100*(1-node_memory_MemAvailable_bytes/node_memory_MemTotal_bytes)
- name: cpu-usage-5m
interval: 5m
rules:
- record: cpu_usage_max_avg_1h
expr: max_over_time(cpu_usage_avg_5m[1h])
- record: cpu_usage_max_avg_1d
expr: max_over_time(cpu_usage_avg_5m[1d])
- name: cpu-usage-1m
interval: 1m
rules:
- record: cpu_usage_avg_5m
expr: avg_over_time(cpu_usage_active[5m])
- name: mem-usage-5m
interval: 5m
rules:
- record: mem_usage_max_avg_1h
expr: max_over_time(mem_usage_avg_5m[1h])
- record: mem_usage_max_avg_1d
expr: max_over_time(mem_usage_avg_5m[1d])
- name: mem-usage-1m
interval: 1m
rules:
- record: mem_usage_avg_5m
expr: avg_over_time(mem_usage_active[5m])
global:
evaluation_interval: 30s
scrape_interval: 30s
external_labels:
rule_files:
- /etc/prometheus/rules/*.yml # /etc/prometheus/rules/*.yml 是定义的rules文件
/etc/prometheus/rules/
目录下。说明通常情况下,上述 Prometheus 配置文件和 rules 配置文件都是通过 configmap 存储,再挂载到 Prometheus server 容器,因此修改相应的 configmap 即可。
本页内容是否解决了您的问题?