使用负载热点打散重调度

使用限制

• 仅支持ACK集群Pro版。具体操作，请参见创建ACK托管集群。

• 使用负载热点打散重调度，需满足以下版本要求。

  组件	版本要求
  ACK调度器版本	v1.22.15-ack-4.0及以上，v1.24.6-ack-4.0及以上
  ack-koordinator(ack-slo-manager)	v1.1.1-ack.1及以上
  Helm版本	v3.0及以上

费用说明

ack-koordinator组件本身的安装和使用是免费的，不过需要注意的是，在以下场景中可能产生额外的费用：

• ack-koordinator是非托管组件，安装后将占用Worker节点资源。您可以在安装组件时配置各模块的资源申请量。

• ack-koordinator默认会将资源画像、精细化调度等功能的监控指标以Prometheus的格式对外透出。若您配置组件时开启了ACK-Koordinator开启Prometheus监控指标选项并使用了阿里云Prometheus服务，这些指标将被视为自定义指标并产生相应费用。具体费用取决于您的集群规模和应用数量等因素。建议您在启用此功能前，仔细阅读阿里云Prometheus计费说明，了解自定义指标的免费额度和收费策略。您可以通过账单和用量查询，监控和管理您的资源使用情况。

负载热点打散重调度介绍

以下介绍负载热点打散重调度相关的概念。

负载感知调度

调度器支持负载感知调度，能够在调度时选择负载较低的节点运行新的Pod。节点的利用率会随着时间、集群环境变化、工作负载的流量或请求等动态变化，继而导致集群内节点间原本负载均衡的情况被打破，甚至有可能出现极端负载不均衡的情况，影响到工作负载运行时质量。ack-koordinator组件提供重调度能力，防止负载出现极端不均衡的情况。通过将负载感知调度和热点打散重调度结合使用，可以获得集群良好的负载均衡效果。关于负载感知调度，请参见使用负载感知调度。

koord-descheduler模块工作原理

ack-koordinator组件提供koord-descheduler模块，其中LowNodeLoad插件负责感知负载水位并完成热点打散重调度工作。与Kubernetes原生的Descheduler的插件LowNodeUtilization不同，LowNodeLoad是根据节点真实利用率决策重调度，而LowNodeUtilization是根据资源分配率决策重调度。

模块执行过程

koord-descheduler模块周期性运行，每个周期内的执行过程分为以下三个阶段。

1. 数据收集：获取集群内的节点和工作负载信息，以及相关的资源利用率数据。

2. 策略插件执行。

   下文以LowNodeLoad为例。

   1. 筛选负载热点节点。关于节点分类，请参见下文LowNodeLoad负载水位参数说明。

   2. 遍历热点节点，从中筛选可以迁移的Pod，并进行排序。关于Pod打分排序，请参见下文Pod打分策略。

   3. 遍历每个待迁移的Pod，检查其是否满足迁移条件，综合考虑集群容量、资源利用率水位、副本数比例等约束。详细信息，请参见下文负载热点打散重调度策略说明。

   4. 若满足条件则将Pod归类为待迁移副本，若不满足则继续遍历其他Pod和热点节点。

3. 容器驱逐迁移：针对待迁移的Pod发起Evict驱逐操作。关于Evict驱逐，请参见Evict驱逐。

LowNodeLoad负载水位参数说明

以下图为例，将lowThresholds设置为45%，将highThresholds设置为70%，那么节点的分类标准如下。同理，如果lowThresholds和highThresholds的值发生变更，节点的分类标准也会相应发生变化。

资源利用率数据默认每分钟更新一次，粒度为最近5分钟的平均值。

• 空闲节点（Idle Node）：资源利用率低于45%的节点。

• 正常节点（Normal Node）：资源利用率高于等于45%且低于等于70%的节点。此节点的负载水位区间是期望达到的合理区间范围。

• 热点节点（Hotspot Node）：资源利用率高于70%的节点。热点节点将驱逐一部分Pod，降低负载水位，使其不超过70%。

负载热点打散重调度策略说明

kubectl get event | grep stress-demo-588f9646cf-7****
55s         Normal    Evicting           podmigrationjob/3bf8f623-4d10-4fc5-ab4e-2bead3c4****   Pod "default/stress-demo-588f9646cf-7****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(76.72%)>threshold(50.00%)"
22s         Normal    EvictComplete      podmigrationjob/3bf8f623-4d10-4fc5-ab4e-2bead3c4****   Pod "default/stress-demo-588f9646cf-7****" has been evicted
55s         Normal    Descheduled        pod/stress-demo-588f9646cf-7****                       Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(76.72%)>threshold(50.00%)"
55s         Normal    Killing            pod/stress-demo-588f9646cf-7****                       Stopping container stress

步骤一：安装或修改组件ack-koordinator并开启重调度

步骤二：开启负载热点打散重调度插件

1. 使用如下YAML文件，创建koord-descheduler-config.yaml。

   koord-descheduler-config.yaml是ConfigMap格式的对象，用于启用重调度插件LowNodeLoad。

   展开查看YAML文件内容

   # koord-descheduler-config.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: koord-descheduler-config
     namespace: kube-system
   data:
     koord-descheduler-config: |
       # 以下为koord-desheduler系统配置，请保持不变。
       apiVersion: descheduler/v1alpha2
       kind: DeschedulerConfiguration
       leaderElection:
         resourceLock: leases
         resourceName: koord-descheduler
         resourceNamespace: kube-system
       deschedulingInterval: 120s # 执行周期间隔，120s执行一次重调度插件。
       dryRun: false # 全局只读模式开关，开启后koord-descheduler整体不做任何操作。
       # 以上为系统配置。
   
       profiles:
       - name: koord-descheduler
         plugins:
           deschedule:
             disabled:
               - name: "*"
           balance:
             enabled:
               - name: LowNodeLoad # 配置开启负载热点打散插件LowNodeLoad。
           evict:
             disabled:
               - name: "*"
             enabled:
               - name: MigrationController # 配置开启驱逐迁移控制器。
   
         pluginConfig:
         - name: MigrationController # 重调度迁移控制参数。
           args:
             apiVersion: descheduler/v1alpha2
             kind: MigrationControllerArgs
             defaultJobMode: EvictDirectly
   
         - name: LowNodeLoad # 负载热点打散插件配置。
           args:
             apiVersion: descheduler/v1alpha2
             kind: LowNodeLoadArgs
   
             lowThresholds:  # lowThresholds表示空闲节点的准入水位阈值，判断条件为“所有资源维度均低于阈值”。
               cpu: 20 # CPU利用率为20%。
               memory: 30  # Memory利用率为30%。
             highThresholds: # highThresholds表示热点节点的准入水位阈值，判断条件为“只要有一个资源维度均高于阈值”。
               cpu: 50  # CPU利用率为50%。
               memory: 60 # Memory利用率为60%。
   
             evictableNamespaces: # 参与重调度的Namespace，include和exclude是互斥的，只能配置其中一种。
               include: # include表示只处理下面配置的Namespace。
                 - default
               # exclude: # exclude表示需要排除的Namespace。
                 # - "kube-system"
                 # - "koordinator-system"

2. 执行如下命令，将配置更新到集群。

   kubectl apply -f koord-descheduler-config.yaml

3. 执行如下命令，重启重调度器模块koord-descheduler。

   重启重调度器模块koord-descheduler后，koord-descheduler会使用修改后的最新配置。

   kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 0
   deployment.apps/ack-koord-descheduler scaled
   kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 1
   deployment.apps/ack-koord-descheduler scaled

步骤三（可选）：开启调度器负载均衡插件

开启调度器负载均衡插件，以获得集群良好的负载均衡效果。具体操作步骤，请参见步骤一：开启负载感知调度。

步骤四：验证重调度能力

下文以拥有3台104核 396 GB节点的集群为例进行说明。

1. 使用如下YAML文件，创建stress-demo.yaml。

   展开查看YAML文件内容。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: stress-demo
     namespace: default
     labels:
       app: stress-demo
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: stress-demo
     template:
       metadata:
         name: stress-demo
         labels:
           app: stress-demo
       spec:
         containers:
           - args:
               - '--vm'
               - '2'
               - '--vm-bytes'
               - '1600M'
               - '-c'
               - '2'
               - '--vm-hang'
               - '2'
             command:
               - stress
             image: polinux/stress
             imagePullPolicy: Always
             name: stress
             resources:
               limits:
                 cpu: '2'
                 memory: 4Gi
               requests:
                 cpu: '2'
                 memory: 4Gi
         restartPolicy: Always

2. 执行如下命令，创建压测Pod。

   kubectl create -f stress-demo.yaml
   deployment.apps/stress-demo created

3. 执行如下命令，观察Pod的状态，直到它开始运行。

   kubectl get pod -o wide

   预期输出：

   NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE                    NOMINATED NODE   READINESS GATES
   stress-demo-588f9646cf-s****   1/1     Running   0          82s   10.XX.XX.53   cn-beijing.10.XX.XX.53   <none>           <none>

   可以看到，Pod stress-demo-588f9646cf-s****调度在节点cn-beijing.10.XX.XX.53上。

4. 提升节点cn-beijing.10.XX.XX.53的负载水位，然后执行如下命令，检查每个Node节点的负载。

   kubectl top node

   预期输出：

   NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.10.XX.XX.215   17611m       17%    24358Mi         6%
   cn-beijing.10.XX.XX.53    63472m       63%    11969Mi         3%

   可以看到，节点cn-beijing.10.XX.XX.53的负载较高，为63%，已经超过配置的热点水位50%。节点cn-beijing.10.XX.XX.215负载较低，为17%，低于配置的空闲水位20%。

5. 开启重调度。具体操作，请参见步骤二：开启负载热点打散重调度插件。

6. 执行如下命令，观察Pod变化。

   等待重调度器检查热点节点，并执行驱逐迁移操作。

   说明

   判定为热点节点的默认条件为连续5次检查节点均超过热点水位，即10分钟。

   kubectl get pod -w

   预期输出：

   NAME                           READY   STATUS               RESTARTS   AGE     IP           NODE                     NOMINATED NODE   READINESS GATES
   stress-demo-588f9646cf-s****   1/1     Terminating          0          59s   10.XX.XX.53    cn-beijing.10.XX.XX.53     <none>           <none>
   stress-demo-588f9646cf-7****   1/1     ContainerCreating    0          10s   10.XX.XX.215   cn-beijing.10.XX.XX.215    <none>           <none>

7. 执行如下命令，观察Event。

   kubectl get event | grep stress-demo-588f9646cf-s****

   预期输出：

   2m14s       Normal    Evicting            podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb****   Pod "default/stress-demo-588f9646cf-s****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)"
   101s        Normal    EvictComplete       podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb****   Pod "default/stress-demo-588f9646cf-s****" has been evicted
   2m14s       Normal    Descheduled         pod/stress-demo-588f9646cf-s****                       Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)"
   2m14s       Normal    Killing             pod/stress-demo-588f9646cf-s****                       Stopping container stress

   预期输出为迁移记录，可以看出结果符合预期。热点节点上的Pod被重调度到其他节点。

高级配置参数

koord-descheduler模块高级配置参数介绍

koord-descheduler的所有参数配置以ConfigMap形式提供，以下展示了负载热点打散重调度的高级配置参数格式。

# koord-descheduler-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: koord-descheduler-config
  namespace: kube-system
data:
  koord-descheduler-config: |
    # 以下为koord-desheduler系统配置，请保持不变。
    apiVersion: descheduler/v1alpha2
    kind: DeschedulerConfiguration
    leaderElection:
      resourceLock: leases
      resourceName: koord-descheduler
      resourceNamespace: kube-system
    deschedulingInterval: 120s # 执行周期间隔，120s执行一次重调度插件。
    dryRun: false # 全局只读模式开关，开启后koord-descheduler整体不做任何操作。
    # 以上为系统配置。

    profiles:
    - name: koord-descheduler
      plugins:
        deschedule:
          disabled:
            - name: "*"
        balance:
          enabled:
            - name: LowNodeLoad # 配置开启负载热点打散插件LowNodeLoad。
        evict:
          disabled:
            - name: "*"
          enabled:
            - name: MigrationController # 配置开启驱逐迁移控制器。

      pluginConfig:
      - name: MigrationController # 重调度迁移控制参数。
        args:
          apiVersion: descheduler/v1alpha2
          kind: MigrationControllerArgs
          defaultJobMode: EvictDirectly
          maxMigratingPerNode: 1 # 每个节点处于迁移状态的Pod的最大数量。
          maxMigratingPerNamespace: 1  # 每个Namespace处于迁移状态的Pod的最大数量。
          maxMigratingPerWorkload: 1 # 每个Workload（例如Deployment）中处于迁移状态的Pod的最大数量。
          maxUnavailablePerWorkload: 2 # 每个Workload（例如Deployment）最大不可用副本数。
          evictLocalStoragePods: false # 是否允许配置了HostPath或EmptyDir的Pod参与重调度
          objectLimiters:
            workload: # Workload级别Pod迁移的流量控制.默认为首次驱逐后，5分钟内最多迁移1个副本。
              duration: 5m
              maxMigrating: 1

      - name: LowNodeLoad # 负载热点打散插件配置。
        args:
          apiVersion: descheduler/v1alpha2
          kind: LowNodeLoadArgs

          lowThresholds:  # lowThresholds表示空闲节点的准入水位阈值，判断条件为“所有资源维度均低于阈值”。
            cpu: 20 # CPU利用率为20%。
            memory: 30  # Memory利用率为30%。
          highThresholds: # highThresholds表示热点节点的准入水位阈值，判断条件为“只要有一个资源维度均高于阈值”。
            cpu: 50  # CPU利用率为50%。
            memory: 60 # Memory利用率为60%。

          anomalyCondition: # 热点节点检查配置。
            consecutiveAbnormalities: 5 # 连续多个执行周期检查中，均超过highThresholds的节点，才会被判定为热点节点。热点节点被驱逐后会重新计数。

          evictableNamespaces: # 参与重调度的Namespace。include和exclude是互斥的，只能配置其中一种。
            include: # include表示只处理下面配置的Namespace。
              - default
            # exclude: # exclude表示需要排除的Namespace。
              # - "kube-system"
              # - "koordinator-system"

          nodeSelector: # 只处理指定的部分节点。
            matchLabels:
              alibabacloud.com/nodepool-id: np77f520e1108f47559e63809713ce****

          podSelectors: # 只处理部分类型的Pod。
          - name: lsPods
            selector:
              matchLabels:
                koordinator.sh/qosClass: "LS"

koord-descheduler系统配置

驱逐迁移控制配置

type MigrationObjectLimiter struct {
    Duration time.Duration `json:"duration,omitempty"`
    MaxMigrating *intstr.IntOrString `json:"maxMigrating,omitempty"`
}

objectLimiters:
  workload:
    duration: 5m
    maxMigrating: 1

LowNodeLoad插件配置

highThresholds:
  cpu: 55 # CPU利用率热点水位55%。
  memory: 75 # Memory利用率热点水位75%。

lowThresholds:
  cpu: 25 # CPU利用率空闲水位25%。
  memory: 25 # Memory利用率空闲水位25%。

evictableNamespaces:
  exclude:
    - "kube-system"
    - "koordinator-system"

type PodSelector struct {
    name     string
    selector metav1.LabelSelector
}

# 只处理LS类型的Pod。
podSelectors:
- name: lsPods
  selector:
    matchLabels:
      koordinator.sh/qosClass: "LS"

常见问题

节点利用率阈值已经达到阈值，但是节点上Pod没有被驱逐怎么办？

出现这种情况时，一般可能是有以下几种原因，请参考对应的解决方法进行调整。

重调度器频繁重启是什么原因？

重调度器的配置ConfigMap格式错误或不存在，请参考高级配置参数检查ConfigMap文件内容和格式并进行修改，修改后重启重调度器。重启重调度器，请参见步骤二：开启负载热点打散重调度插件。

负载感知调度和热点打散重调度如何搭配使用？

开启热点打散重调度后，负载热点上的Pod将会被驱逐。对于上层控制器（例如Deployment）新建的Pod，调度器会根据其配置选择合适的节点进行调度。为了获得更好的负载均衡效果，建议您同时为调度器开启负载感知调度能力，请参见使用负载感知调度。

配置时，建议您将负载感知调度中的节点筛选功能参数loadAwareThreshold配置为与热点打散重调度器的highThresholds参数相同的值，具体请参见策略说明。当节点的负载超过highThresholds时，重调度器将驱逐该节点上的Pod，而调度器则通过loadAwareThreshold拒绝新的Pod被调度到该热点节点上。否则，经驱逐的Pod可能重新被调度到原来的节点，尤其是在Pod指定了节点调度范围，但对应的节点数量较少且利用率较为接近时。

重调度参考的利用率算法是什么？

重调度器会持续对利用率监控一段时间，并对监控数据做平滑均值处理，因此只有节点持续超过阈值才会触发重调度，默认为10分钟左右。此外对于内存资源维度，重调度器参考的内存用量排除了page cache，因为这部分资源是可以被操作系统回收的，而通过kubectl top node返回的利用率是包含page cache的，您可以通过使用阿里云Prometheus监控查看真实的内存用量信息。