Pod Sorting And Precise Execution For Crane Agent

该proposal丰富了crane-agent的排序策略，完善了通用排序。并且实现了一套精准操作(压制/驱逐)的框架，在执行压制/驱逐等操作时，操作到用户指定的水位线即停止的精确操作逻辑，避免了对于低优pod的过度操作；

具体来说：

  • 丰富了crane-agent的排序策略，完善了通用排序和cpu usage为主要参考的cpu维度排序；
  • 针对cpu usage，实现了执行压制/驱逐等操作时，操作到用户指定的水位线即停止的精确操作逻辑，避免了对于低优pod的过度操作；
  • 实现了一套精确操作(压制/驱逐)的框架，通过完善自定义指标的一些列属性和实现，即可在无需关心具体细节的情况下，同样具有同cpu usage一样的精确操作能力，具有一定的普适性和扩展性。

Table of Contents

Motivation

当前在crane-agent中，当超过NodeQOS中指定的水位线后，执行evict，throttle等操作时先对低优先级的pod进行排序，当前排序的依据是pod的ProrityClass，然后在排序的pod进行throttle或者evict操作；

目前存在的问题有：

  1. 排序只参考ProrityClass，无法满足基于其他特性的排序；同时也无法满足按照水位线精确操作对灵活排序的需求，无法满足尽快让节点达到指定的水位线的要求。例如我们希望尽快降低低优先级业务的cpu使用量时，应该选出cpu使用量较多的pod，这样能够更快地降低cpu用量，保障高优业务不受影响。

  2. 在触发NodeQOS中指定的水位线后，会对于节点上的所有低于指定ProrityClass的pod进行操作；例如，当前节点上有10个pod低于指定ProrityClass，在触发水位线后，会对这10个pod都进行操作，但是实际上可能在操作完成对第一个pod的操作后就可以低于NodeQOS中的指标值了，对剩下的pod的操作，属于过度操作，是可以避免的。如果能以NodeQOS中的指标值作为水位线对pod进行精确的操作，操作到刚好低于水位线是更为合适的，就能避免对低优先级服务的过度影响。

Goals

  • 丰富了crane-agent的排序策略，包括以pod cpu用量为主要参照的排序，以pod内存用量为主要参照的排序，基于运行时间的排序，基于扩展资源使用率的排序。
  • 实现一套包含排序和精确操作的框架，支持对不同的指标丰富排序规则，并且实现精确操作。
  • 实现针对cpu usage和memmory usage的精确操作，当整机负载超过NodeQOS中指定的水位线后，会先对低优先级的pod进行排序，然后按照顺序操作到刚好低于水位线为止。

Proposal

丰富pod的排序策略

  • 该proposal实现了一些通用的排序方法（之后会更多地完善）：

    classAndPriority： 比较两个pod的QOSClass和class value，优先比较QOSClass，再比较class value；priority高的排在后面优先级更高

    runningTime：比较两个pod的运行时间，运行时间长的排在后面优先级更高

    如果仅需使用这两个排序策略，使用默认的排序方法即可：会首先比较pod的优先级，之后比较pod对应指标的用量，之后比较pod的运行时长，有一个维度可以比较出结果即为pod的排序结果

    1. func GeneralSorter(pods []podinfo.PodContext) {
    2.     orderedBy(classAndPriority, runningTime).Sort(pods)
    3. }

  • cpu usage 使用量的排序

    会依次比较两个pod的优先级，如果优先级相同的情况下，再比较cpu用量，如果cpu用量也相同的情况下继续比较ext cpu资源用量（这个是cpu属性较为特殊的一点）, 最后比较pod的运行时长，当某一个指标存在差异时即可返回比较结果

    1. func CpuUsageSorter(pods []podinfo.PodContext) {
    2.     orderedBy(classAndPriority, cpuUsage, extCpuUsage, runningTime).Sort(pods)
    3. }

  • ext cpu usage 使用量的排序

    会首先比较两个pod是否使用了扩展的cpu资源，在都使用了的情况下，比较 扩展cpu资源使用量/ 扩展cpu资源limit的比值

  • 针对需要自定义的指标，可以通过实现如下的方法，并且随意搭配通用的排序方法即可方便地实现pod的灵活自定义排序，以代表自定义metric指标，代表自定义的针对的排序策略

    1. func <metric>Sorter(pods []podinfo.PodContext) {
    2.     orderedBy(classAndPriority, <metric-sort-func>, runningTime).Sort(pods)
    3. }

    其中只需要实现如下的排序方法即可

    1. func (p1, p2 podinfo.PodContext) int32

metric属性的定义

为了更好的基于NodeQOS配置的metric进行排序和精准控制，对metric引入属性的概念。

metric的属性包含如下几个：

  1. Name 表明了metric的名称，需要同collector模块中收集到的指标名称一致
  2. ActionPriority 表示指标的优先级，0为最低，10为最高
  3. SortAble 表明该指标是否可以排序
  4. SortFunc 对应的排序方法，排序方法可以排列组合一些通用方法，再结合指标自身的排序，将在下文详细介绍
  5. ThrottleAble 表明针对该指标，是否可以对pod进行压制，例如针对cpu使用量这个metric，就有相对应的压制手段，但是对于memory使用量这种指标，就只能进行pod的驱逐，无法进行有效的压制
  6. ThrottleQuantified 表明压制（restore）一个pod后，能否准确计算出经过压制后释放出的对应metric的资源量，我们将可以准确量化的指标称为可Quantified，否则为不可Quantified； 比如cpu用量，可以通过限制cgroup用量进行压制，同时可以通过当前运行值和压制后的值计算压制后释放的cpu使用量；而比如memory usage就不属于压制可量化metric，因为memory没有对应的throttle实现，也就无法准确衡量压制一个pod后释放出来的memory资源具体用量；
  7. ThrottleFunc，执行Throttle动作的具体方法，如果不可Throttle，返回的released为空
  8. RestoreFunc，被Throttle后，执行恢复动作的具体方法，如果不可Restore，返回的released为空
  9. EvictAble，EvictQuantified，EvictFunc 对evict动作的相关定义，具体内容和Throttle动作类似
  1. type metric struct {
  2.     Name WaterLineMetric
  4.     ActionPriority int
  6.     SortAble bool
  7.     SortFunc func(pods []podinfo.PodContext)
  9.     ThrottleAble      bool
  10.     ThrottleQuantified bool
  11.     ThrottleFunc      func(ctx *ExecuteContext, index int, ThrottleDownPods ThrottlePods, totalReleasedResource *ReleaseResource) (errPodKeys []string, released ReleaseResource)
  12.     RestoreFunc       func(ctx *ExecuteContext, index int, ThrottleUpPods ThrottlePods, totalReleasedResource *ReleaseResource) (errPodKeys []string, released ReleaseResource)
  14.     EvictAble      bool
  15.     EvictQuantified bool
  16.     EvictFunc      func(wg *sync.WaitGroup, ctx *ExecuteContext, index int, totalReleasedResource *ReleaseResource, EvictPods EvictPods) (errPodKeys []string, released ReleaseResource)
  17. }

用户可以自行定义自己的metric，在构造完成后，通过registerMetricMap()进行注册即可

如何根据水位线进行精准控制

  • 根据多个NodeQOS及其中的objectiveEnsurances构建多条水位线:

    1. 按照objectiveEnsurances对应的action进行分类，目前crane-agent有3个针对节点QOS进行保障的操作，分别是Evict，ThtottleDown（当前用量高于objectiveEnsurances中的值时对pod进行用量压制）和ThrottleUp（当前用量低于objectiveEnsurances中的值时对pod的用量进行放宽恢复），因此会有三个水位线集合，分别是 ThrottleDownWaterLine，ThrottleUpWaterLine和EvictWaterLine

    2. 再对同一操作种类中的水位线按照其metric rule（图中以metric A，metric Z作为示意）进行分类，并记录每个objectiveEnsurances水位线的值，记为waterLine；

      ThrottleDownWaterLine，ThrottleUpWaterLine和EvictWaterLine的结构是这样的： type WaterLines map[WaterLineMetric]*WaterLine

      其中WaterLineMetric就是上面的metric的Name字段，value的WaterLine就是资源数值 type WaterLine resource.Quantity

    最终形成一个类似下图的数据存储：
    Pod Sorting And Precise Execution For Crane Agent - 图1

  • 构造实时用量到水位线的差值：
    结合当前节点的指标实时用量与WaterLines中该指标对应的水位线中最小值的差值构造如下的数据结构，代表到当前用量到水位线的差值
    type GapToWaterLines map[WaterLineMetric]float64

    其中key值为metric的Name字段，value为用量到水位线的差值；

    需要注意对于ThrottleUp，需要用水位线最小值-当前用量作为gap值，对于其他两者，使用当前用量-水位线最小值作为gap值，即始终保持gap值为正

    下面三个数据分别代表了需要执行evict，ThtottleDown和ThrottleUp操作的指标及其对应的到最低水位线的差值

    1. EvictGapToWaterLines[metrics]     
    2. ThrottoleDownGapToWaterLines[metrics]
    3. ThrottleUpGapWaterLine[metrics]

  • 以CpuUsage这个metric为例，构造节点cpu用量相关的waterline的流程和相关数据结构如下：
    Pod Sorting And Precise Execution For Crane Agent - 图2

以水位线为基准进行pod的精确操作

该proposal为了实现以水位线为基准进行pod的精确操作，将对analyzer部分和executor部分做一定的修改，大体流程是：

在analyzer阶段构造针对不同操作（驱逐，压制等）和不同metric的水位线，将原先的排序逻辑删除，后移到需要进行正式操作的executor阶段，并且可能会需要进行多轮排序；

在executor阶段，根据水位线中的涉及的指标进行其相应的排序，获取最新用量，构造GapToWaterLines，并进行精确操作

analyzer阶段

在该阶段进行NodeQOS到WaterLines的转换，并对相同actionName和metricrule的规则进行合并，具体内容上文已经介绍过了

executor阶段

压制过程：

  1. 首先分析ThrottoleDownGapToWaterLines中涉及的metrics，将这些metrics根据其Quantified属性区分为两部分，如果存在不可Quantified的metric，则通过GetHighestPriorityThrottleAbleMetric获取具有最高ActionPriority的一个throttleAble（具有throttleFunc）的metric对所选择的所有pod进行压制操作，因为但凡存在一个不可Quantified的metric，就无法进行精确的操作

  2. 通过getStateFunc()获取当前节点和workload的最新用量，依据ThrottoleDownGapToWaterLines和实时用量构造GapToWaterLine（需要注意的是，在构造GapToWaterLine时，会以注册过的metric进行遍历，所以最终构造出来的GapToWaterLine中的metrics，会是ThrottoleDownGapToWaterLines 中注册过的metric，避免了在NodeQOS中配置错误不存在或未注册metric的情况）

  3. 如果GapToWaterLine中有metric的实时用量无法获取（HasUsageMissedMetric），则通过GetHighestPriorityThrottleAbleMetric获取具有最高ActionPriority的一个throttleAble（具有throttleFunc）的metric对所选择的所有pod进行压制操作，因为如果存在metric实时用量无法获取，就无法获知和水位线的gap，也就无法进行精确的操作

  4. 如果不存在3中的情况，则遍历ThrottoleDownGapToWaterLines中可以量化的metric：如果metric具有排序方法则直接使用其SortFunc对pod进行排序，如果没有就使用GeneralSorter进行排序，之后使用其对应的ThrottleFunc对pod进行压制，并计算释放出来的对应metric的资源量，直到ThrottoleDownGapToWaterLines中该metric对应的gap已不存在

  1. //将所有触发水位线的metrics根据其Quantified属性区分为两部分
  2. metricsQuantified, MetricsNotQuantified := ThrottleDownWaterLine.DivideMetricsByQuantified()
  3. // 如果存在不可Quantified的metric，获取具有最高ActionPriority的一个throttleAble的metric对所选择的所有pod进行操作
  4. if len(MetricsNotThrottleQuantified) != 0 {
  5.     highestPrioriyMetric := GetHighestPriorityThrottleAbleMetric()
  6.     if highestPrioriyMetric != "" {
  7.         t.throttlePods(ctx, &totalReleased, highestPrioriyMetric)
  8.     }
  9. } else {
  10.     //获取节点和workload的最新用量，构造和水位线差距
  11.     ThrottoleDownGapToWaterLines = buildGapToWaterLine(ctx.getStateFunc())
  12.     //如果触发水位线中存在metric的实时用量无法获取，则获取具有最高ActionPriority的一个throttleAble的metric对所选择的所有pod进行压制操作
  13.     if ThrottoleDownGapToWaterLines.HasUsageMissedMetric() {
  14.         highestPrioriyMetric := ThrottleDownWaterLine.GetHighestPriorityThrottleAbleMetric()
  15.         if highestPrioriyMetric != "" {
  16.             throttlePods(ctx, &totalReleased, highestPrioriyMetric)
  17.         }
  18.     } else {
  19.         var released ReleaseResource
  20.         //遍历触发水位线的metric中可以量化的metric：如果metric具有排序方法则直接使用其SortFunc对pod进行排序，否则使用GeneralSorter排序；
  21.         //之后使用其对应的操作方法对pod执行操作，并计算释放出来的对应metric的资源量，直到对应metric到水位线的差距已不存在
  22.         for _, m := range metricsQuantified {
  23.             if m.SortAble {
  24.                 m.SortFunc(ThrottleDownPods)
  25.             } else {
  26.                 GeneralSorter(ThrottleDownPods)
  27.             }
  29.             for !ThrottoleDownGapToWaterLines.TargetGapsRemoved(m) {
  30.                 for index, _ := range ThrottleDownPods {
  31.                     released = m.ThrottleFunc(ctx, index, ThrottleDownPods, &totalReleased)
  32.                     ThrottoleDownGapToWaterLines[m] -= released[m]
  33.                 }
  34.             }
  35.         }
  36.     }
  37. }

驱逐过程：

驱逐和压制的流程是一样的，除了在对pod进行操作的时候需要额外判断一下pod是否已经被驱逐了；取出一个没有执行过的pod，执行驱逐操作，并计算释放出的各metric资源量，同时在对应水位线中减去释放的值，直到满足当前metric水位线要求

  1. metricsEvictQuantified, MetricsNotEvcitQuantified := EvictWaterLine.DivideMetricsByEvictQuantified()
  3. if len(MetricsNotEvcitQuantified) != 0 {
  4.     highestPrioriyMetric := e.EvictWaterLine.GetHighestPriorityEvictAbleMetric()
  5.     if highestPrioriyMetric != "" {
  6.         e.evictPods(ctx, &totalReleased, highestPrioriyMetric)
  7.     }
  8. } else {
  9.     EvictGapToWaterLines = buildGapToWaterLine(ctx.getStateFunc(), ThrottleExecutor{}, *e)
  10.     if EvictGapToWaterLines.HasUsageMissedMetric() {
  11.         highestPrioriyMetric := EvictWaterLine.GetHighestPriorityEvictAbleMetric()
  12.         if highestPrioriyMetric != "" {
  13.             e.evictPods(ctx, &totalReleased, highestPrioriyMetric)
  14.         }
  15.     } else {
  16.         wg := sync.WaitGroup{}
  17.         var released ReleaseResource
  18.         for _, m := range metricsEvictQuantified {
  19.             if MetricMap[m].SortAble {
  20.                 MetricMap[m].SortFunc(e.EvictPods)
  21.             } else {
  22.                 execsort.GeneralSorter(e.EvictPods)
  23.             }
  25.             for !EvictGapToWaterLines.TargetGapsRemoved(m) {
  26.                 if podinfo.HasNoExecutedPod(e.EvictPods) {
  27.                     index := podinfo.GetFirstNoExecutedPod(e.EvictPods)
  28.                     released = MetricMap[m].EvictFunc(&wg, ctx, index, &totalReleased, e.EvictPods)
  30.                     e.EvictPods[index].HasBeenActioned = true
  31.                     ctx.EvictGapToWaterLines[m] -= released[m]
  32.                 }
  33.             }
  34.         }
  35.         wg.Wait()
  36.         }
  37. }

Non-Goals/Future Work

  • 当前只支持cpu usage的精确操作，但是框架可以复用，后续可以基于精准控制的框架，实现更多维度指标的精准控制。
  • 在做精准控制时，目前只考虑metric本身释放量，未考虑不同metric之间的相互影响。比如压制cpu usage时，memory usage也会受到影响。如果指标非常多，不同指标之间的关系会非常复杂，所以暂时不考虑不同metric直接的相互影响。

User Stories

  • 用户可以使用crane-agent进行更好的QOS保障。支持更快速的降低节点负载，以保障高优先级业务不受影响。同时对低优先级业务的压制/驱逐动作，进行精确控制，避免过度操作。
  • 用户可以借助实现的精准操作(压制/驱逐)的框架，在无需关心细节的情况下，通过实现自定义metric相关的属性和方法，即可方便地实现以自定义metric为核心的具有精确操作和排序能力的QOS功能。