关于腾讯云:Cranescheduler基于真实负载进行调度

作者

邱天，腾讯云高级工程师，负责腾讯云 TKE 动静调度器与重调度器产品。

背景

原生 kubernetes 调度器只能基于资源的 resource request 进行调度，然而 Pod 的实在资源使用率，往往与其所申请资源的 request/limit 差别很大，这间接导致了集群负载不均的问题：

1. 集群中的局部节点，资源的实在使用率远低于 resource request，却没有被调度更多的 Pod，这造成了比拟大的资源节约；
2. 而集群中的另外一些节点，其资源的实在使用率事实上曾经过载，却无奈为调度器所感知到，这极大可能影响到业务的稳定性。

这些无疑都与企业上云的最后目标相悖，为业务投入了足够的资源，却没有达到现实的成果。

既然问题的本源在于 resource request 与实在使用率之间的「鸿沟」，那为什么不能让调度器间接基于实在使用率进行调度呢？这就是 Crane-scheduler 设计的初衷。Crane-scheduler 基于集群的实在负载数据结构了一个简略却无效的模型，作用于调度过程中的 Filter 与 Score 阶段，并提供了一种灵便的调度策略配置形式，从而无效缓解了 kubernetes 集群中各种资源的负载不均问题。换句话说，Crane-scheduler 着力于调度层面，让集群资源应用最大化的同时排除了稳定性的后顾之忧，真正实现「降本增效」。

整体架构

如上图所示，Crane-scheduler 依赖于 Node-exporter 与 Prometheus 两个组件，前者从节点收集负载数据，后者则对数据进行聚合。而 Crane-scheduler 自身也蕴含两个局部:

1. Scheduler-Controller 周期性地从 Prometheus 拉取各个节点的实在负载数据，再以 Annotation 的模式标记在各个节点上；
2. Scheduler 则间接在从候选节点的 Annotation 读取负载信息，并基于这些负载信息在 Filter 阶段对节点进行过滤以及在 Score 阶段对节点进行打分；

基于上述架构，最终实现了基于实在负载对 Pod 进行无效调度。

调度策略

下图是官网提供的 Pod 的调度上下文以及调度框架公开的扩大点：

Crane-scheduler 次要作用于图中的 Filter 与 Score 阶段，并对用户提供了一个十分凋谢的策略配置。这也是 Crane-Scheduler 与社区同类型的调度器最大的区别之一：

1) 前者提供了一个泛化的调度策略配置接口，给予了用户极大的灵活性；
2) 后者往往只能反对 cpu/memory 等少数几种指标的感知调度，且指标聚合形式，打分策略均受限。
在 Crane-scheduler 中，用户能够为候选节点配置任意的评估指标类型（只有从 Prometheus 能拉到相干数据），不论是罕用到的 CPU/Memory 使用率，还是 IO、Network Bandwidth 或者 GPU 使用率，均能够失效，并且反对相干策略的自定义配置。

数据拉取

如「整体架构」中所述，Crane-scheduler 所需的负载数据均是通过 Controller 异步拉取。这种数据拉取形式：

1. 一方面，保障了调度器自身的性能；
2. 另一方面，无效加重了 Prometheus 的压力，避免了业务突增时组件被打爆的状况产生。

此外，用户能够间接 Describe 节点，查看到节点的负载信息，不便问题定位：

[root@test01 ~]# kubectl describe node test01
Name:               test01
...
Annotations:        cpu_usage_avg_5m: 0.33142,2022-04-18T00:45:18Z
                    cpu_usage_max_avg_1d: 0.33495,2022-04-17T23:33:18Z
                    cpu_usage_max_avg_1h: 0.33295,2022-04-18T00:33:18Z
                    mem_usage_avg_5m: 0.03401,2022-04-18T00:45:18Z
                    mem_usage_max_avg_1d: 0.03461,2022-04-17T23:33:20Z
                    mem_usage_max_avg_1h: 0.03425,2022-04-18T00:33:18Z
                    node.alpha.kubernetes.io/ttl: 0
                    node_hot_value: 0,2022-04-18T00:45:18Z
                    volumes.kubernetes.io/controller-managed-attach-detach: true
...

用户能够自定义负载数据的类型与拉取周期，默认状况下，数据拉取的配置如下：

  syncPolicy:
    ## cpu usage
    - name: cpu_usage_avg_5m
      period: 3m
    - name: cpu_usage_max_avg_1h
      period: 15m
    - name: cpu_usage_max_avg_1d
      period: 3h
    ## memory usage
    - name: mem_usage_avg_5m
      period: 3m
    - name: mem_usage_max_avg_1h
      period: 15m
    - name: mem_usage_max_avg_1d
      period: 3h

Filter 策略

用户能够在 Filter 策略中配置相干指标的阈值，若候选节点的以后负载数据超过了任一所配置的指标阈值，则这个节点将会被过滤，默认配置如下：

  predicate:
    ## cpu usage
    - name: cpu_usage_avg_5m
      maxLimitPecent: 0.65
    - name: cpu_usage_max_avg_1h
      maxLimitPecent: 0.75
    ## memory usage
    - name: mem_usage_avg_5m
      maxLimitPecent: 0.65
    - name: mem_usage_max_avg_1h
      maxLimitPecent: 0.75

Score 策略

用户能够在 Score 策略中配置相干指标的权重，候选节点的最终得分为不同指标得分的加权和，默认配置如下：

  priority:
    ### score = sum((1 - usage) * weight) * MaxScore / sum(weight)
    ## cpu usage
    - name: cpu_usage_avg_5m
      weight: 0.2
    - name: cpu_usage_max_avg_1h
      weight: 0.3
    - name: cpu_usage_max_avg_1d
      weight: 0.5
    ## memory usage
    - name: mem_usage_avg_5m
      weight: 0.2
    - name: mem_usage_max_avg_1h
      weight: 0.3
    - name: mem_usage_max_avg_1d
      weight: 0.5

调度热点

在理论生产环境中，因为 Pod 创立胜利当前，其负载并不会立马回升，这就导致了一个问题：如果齐全基于节点实时负载对 Pod 调度，经常会呈现调度热点（短时间大量 pod 被调度到同一个节点上）。为了解决这个问题，咱们设置了一个单列指标 Hot Vaule，用来评估某个节点在近段时间内被调度的频繁水平，对节点实时负载进行对冲。最终节点的 Priority 为上一大节中的 Score 减去 Hot Value。Hot Value 默认配置如下：

  hotValue:
    - timeRange: 5m
      count: 5
    - timeRange: 1m
      count: 2

注： 该配置示意，节点在 5 分钟内被调度 5 个 pod，或者 1 分钟内被调度 2 个 pod，HotValue 加 10 分。

案例分享

Crane-scheduler 目前有泛滥私有云用户，包含斗鱼直播、酷狗、一汽大众、猎豹挪动等公司均在应用，并给予了产品不错的反馈。这里咱们先分享一个某私有云用户的实在案例。该客户集群中的业务大多是内存消耗型的，因而极易呈现内存利用率很高的节点，并且各个节点的内存利用率散布也很不均匀，如下图所示：

理解到用户的状况后，咱们举荐其应用 Crane-scheduler，组件运行一段时间后，该用户集群内各节点的内存利用率数据分布产生了显著变动，如下图：

可见，用户集群的内存使用率更加趋于平衡。

另外，Crane-scheduler 也在公司外部各个 BG 的自研上云环境中，也失去了宽泛的应用。上面是外部自研上云平台 TKEx-CSIG 的两个生产集群的 CPU 使用率散布状况，其中集群 A 未部署 Crane-scheduler：

集群 B 部署了组件并运行过一段时间：

很显著，在集群 B 中，节点 CPU 使用率散布在两端（< 10% 与 > 80%）所占的比例，要显著小于集群 A，并且整体散布也更加紧凑，相对而言更加平衡与衰弱。

衍生浏览：什么是 Crane

为推动云原生用户在确保业务稳定性的根底上做到真正的极致降本，腾讯推出了业界第一个基于云原生技术的老本优化开源我的项目 Crane（Cloud Resource Analytics and Economics）。Crane 遵循 FinOps 规范，旨在为云原生用户提供云老本优化一站式解决方案。

Crane-scheduler 作为 Crane 的调度插件实现了基于实在负载的调度性能，旨在从调度层面帮忙业务降本增效。

近期，Crane 胜利退出 CNCF Landscape，欢送关注我的项目：https://github.com/gocrane/crane。

对于咱们

更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~

福利：

①公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~

②公众号后盾回复【系列】，可取得《15 个系列 100+ 篇超实用云原生原创干货合集》，蕴含 Kubernetes 降本增效、K8s 性能优化实际、最佳实际等系列。

③公众号后盾回复【白皮书】，可取得《腾讯云容器平安白皮书》&《降本之源 - 云原生老本治理白皮书 v1.0》

④公众号后盾回复【光速入门】，可取得腾讯云专家 5 万字精髓教程，光速入门 Prometheus 和 Grafana。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！