被集群节点负载不均所困扰？TKE 重磅推出全链路调度解决方案

引言

在 K8s 集群运营过程当中，经常会被节点 CPU 和内存的高使用率所困扰，既影响了节点上 Pod 的稳定运行，也会增长节点故障的概率。为了应对集群节点高负载的问题，平衡各个节点之间的资源使用率，应该基于节点的实际资源利用率监控信息，从如下两个策略入手：

• 在 Pod 调度阶段，应当优先将 Pod 调度到资源利用率低的节点上运行，不调度到资源利用率已经很高的节点上
• 在监控到节点资源率较高时，能够自动干预，迁移节点上的一些 Pod 到利用率低的节点上

为此，咱们提供 动态调度器 + Descheduler 的方案来实现，目前在公有云 TKE 集群内【组件管理】- 【调度】分类下已经提供这两个插件的安装入口，文末还针对具体的客户案例提供了最佳实践的例子。

动态调度器

原生的 Kubernetes 调度器有一些很好的调度策略用来应对节点资源分配不均的问题，好比 BalancedResourceAllocation，可是存在一个问题是这样的资源分配是静态的，不能表明资源真实使用状况，节点的 CPU/内存利用率 常常处于不均衡的状态。因此，须要有一种策略能够基于节点的实际资源利用率进行调度。动态调度器所作的就是这样的工做。

技术原理

原生 K8s 调度器提供了 scheduler extender 机制来提供调度扩展的能力。相比修改原生 scheduler 代码添加策略，或者实现一个自定义的调度器，使用 scheduler extender 的方式侵入性更少，实现更加灵活。因此咱们选择基于 scheduler extender 的方式来添加基于节点的实际资源利用率进行调度的策略。

scheduler extender 能够在原生调度器的预选和优选阶段加入自定义的逻辑，提供和原生调度器内部策略一样的效果。

架构

• node-annotator：负责拉取 Prometheus 中的监控数据，按期同步到 Node 的 annotation 里面，同时负责其余逻辑，如动态调度器调度有效性衡量指标，防止调度热点等逻辑。
• dynamic-scheduler：负责 scheduler extender 的优选和预选接口逻辑实现，在预选阶段过滤掉资源利用率高于阈值的节点，在优选阶段优先选择资源利用率低的节点进行调度。

实现细节

1. 动态调度器的策略在优选阶段的权重如何配置？

   原生调度器的调度策略在优选阶段有一个权重配置，每一个策略的评分乘以权重获得该策略的总得分。对权重越高的策略，符合条件的节点越容易调度上。默认全部策略配置权重为 1，为了提高动态调度器策略的效果，咱们把动态调度器优选策略的权重设置为 2。

2. 动态调度器如何防止调度热点？

   在集群中，若是出现一个新增的节点，为了防止新增的节点调度上过多的节点，咱们会经过监听调度器调度成功事件，获取调度结果，标记每一个节点过去一段时间的调度 Pod 数,好比 1min、5min、30min 内的调度 Pod 数量，衡量节点的热点值而后补偿到节点的优选评分中。

产品能力

组件依赖

组件依赖较少，仅依赖基础的节点监控组件 node-exporter 和 Prometheus。Prometheus 支持托管和自建两种方式，使用托管方式能够一键安装动态调度器，而使用自建 Prometheus 也提供了监控指标配置方法。

组件配置

调度策略目前能够基于 CPU 和内存两种资源利用率。

预选阶段

配置节点 5分钟内 CPU 利用率、1小时内最大 CPU 利用率，5分钟内平均内存利用率，1小时内最大内存利用率的阈值，超过了就会在预选阶段过滤节点。

优选阶段

动态调度器优选阶段的评分根据截图中 6个指标综合评分得出，6个指标各自的权重表示优选时更侧重于哪一个指标的值，使用 1h 和 1d 内最大利用率的意义是要记录节点 1h 和 1d 内的利用率峰值，由于有的业务 Pod 的峰值周期多是按照小时或者天，避免调度新的 Pod 时致使在峰值时间节点的负载进一步升高。

产品效果

为了衡量动态调度器对加强 Pod 调度到低负载节点的提高效果，结合调度器的实际调度结果，获取全部调度到的节点在调度时刻的的 CPU/内存利用率之后统计如下几个指标：

• cpu_utilization_total_avg ：全部调度到的节点 CPU 利用率平均值。
• memory_utilization_total_avg ：全部调度到的节点内存利用率平均值。
• effective_dynamic_schedule_count ：有效调度次数，当调度到节点的 CPU 利用率小于当前全部节点 CPU 利用率的中位数，咱们认为这是一次有效调度，effective_dynamic_schedule_count 加 0.5分，对内存也是同理。
• total_schedule_count ：全部调度次数，每次新的调度累加1。
• effective_schedule_ratio ：有效调度比率，即 effective_dynamic_schedule_count/total_schedule_count
  下面是在同一集群中不开启动态调度和开启动态调度各自运行一周的指标变化，能够看到对于集群调度的加强效果。

指标	未开启动态调度	开启动态调度
cpu_utilization_total_avg	0.30	0.17
memory_utilization_total_avg	0.28	0.23
effective_dynamic_schedule_count	2160	3620
total_schedule_count	7860	7470
effective_schedule_ratio	0.273	0.486

Descheduler

现有的集群调度场景都是一次性调度，即一锤子买卖。后续出现节点 CPU 和内存利用率太高，也没法自动调整 Pod 的分布，除非触发节点的 eviction manager 后驱逐，或者人工干预。这样在节点 CPU/内存利用率高时，影响了节点上全部 Pod 的稳定性，并且负载低的节点资源还被浪费。

针对此场景，借鉴 K8s 社区 Descheduler 重调度的设计思想，给出基于各节点 CPU/内存实际利用率进行驱逐的策略。

架构

Descheduler 从 apiserver 中获取 Node 和 Pod 信息，从 Prometheus 中获取 Node 和 Pod 监控信息，而后通过Descheduler 的驱逐策略，驱逐 CPU/内存使用率高的节点上的 Pod ，同时咱们增强了 Descheduler 驱逐 Pod 时的排序规则和检查规则，确保驱逐 Pod 时服务不会出现故障。驱逐后的 Pod 通过动态调度器的调度会被调度到低水位的节点上，实现下降高水位节点故障率，提高总体资源利用率的目的。

产品能力

产品依赖

依赖基础的节点监控组件 node-exporter 和Prometheus。Prometheus 支持托管和自建两种方式，使用托管方式能够一键安装 Descheduler，使用自建 Prometheus 也提供了监控指标配置方法。

组件配置

Descheduler 根据用户配置的利用率阈值，超过阈值水位后开始驱逐 Pod ，使节点负载尽可能下降到目标利用率水位如下。

产品效果

经过 K8s 事件

经过 K8s 事件能够看到 Pod 被重调度的信息，因此能够开启集群事件持久化功能来查看 Pod 驱逐历史。

节点负载变化

在相似以下节点 CPU 使用率监控视图内，能够看到在开始驱逐以后，节点的 CPU 利用率降低。

最佳实践

集群状态

拿一个客户的集群为例，因为客户的业务大可能是内存消耗型的，因此更容易出现内存利用率很高的节点，各个节点的内存利用率也很不平均，未使用动态调度器以前的各个节点监控是这样的：

动态调度器配置

配置预选和优选阶段的参数以下：

在预选阶段过滤掉 5分钟内平均内存利用率超过 60%或者 1h内最大内存利用率超过 70%的节点，即 Pod 不会调度到这些这些节点上。

在优选阶段将 5分钟平均内存利用率权重配置为 0.8，1h 和1d 内最大内存利用率权重配置为 0.二、0.2，而将 CPU 的指标权重都配置为 0.1。这样优选时更优先选择调度到内存利用率低的节点上。

Descheduler配置

配置 Descheduler 的参数以下，当节点内存利用率超过 80%这个阈值的时候，Descheduler 开始对节点上的 Pod 进行驱逐，尽可能使节点内存利用率下降到目标值 60% 为止。

集群优化后状态

经过以上的配置，运行一段时间后，集群内各节点的内存利用率数据以下，能够看到集群节点的内存利用率分布已经趋向于均衡：