#工作负载重新平衡（Descheduler）

Kubernetes 调度是一个瞬时决策。当创建 Pod 时，kube-scheduler 会根据当时的集群状态选择最合适的节点。随着集群不断变化，最初的决策可能会变得过时：节点可能变得过载或利用不足，taint 或 label 可能发生变化，亲和性规则可能被更新，故障节点可能恢复，新节点也可能被加入。

Alauda Build of Descheduler 插件通过识别违反调度策略或被放置在不太合适节点上的运行中 Pod，驱逐这些 Pod，并允许默认调度器将替换 Pod 放置到更合适的节点上，从而帮助你重新平衡集群。

descheduler 本身不会调度替换 Pod。它只会调用 Kubernetes eviction API。默认调度器会重新调度由 Deployment、ReplicaSet、StatefulSet 或 Job 等控制器管理的 Pod。

使用 descheduler 的典型场景包括：

• 节点利用不足或利用过高。
• 在 Pod 被调度后，node labels、node taints、Pod affinity 或 Pod anti-affinity 需求发生了变化。
• 节点故障导致 Pod 被迁移到较少数量的节点上，而恢复后的节点应重新承载工作负载。
• 新增了节点，希望将现有工作负载重新分布。
• Pod 重启次数过多，或者运行时间超过了预期生命周期。

#Pod 驱逐规则和适用性

为保持集群稳定性，descheduler 在决定驱逐哪些 Pod 时必须保持保守。除非你已确认工作负载可以安全重建，并且驱逐在运维上是可接受的，否则请保留这些保护措施。

• 受保护的 Pod：
  • 位于系统或平台命名空间中的 Pod，例如 kube-system 和 ACP 平台命名空间。如果你添加了命名空间 include 或 exclude 规则，请继续将平台命名空间排除在外。
  • priorityClassName 设置为 system-cluster-critical 或 system-node-critical 的关键 Pod。
  • Static Pod、mirrored Pod 或未由控制器管理的独立 Pod，因为这些 Pod 不会被自动重建。
  • 与 DaemonSet 关联的 Pod。
  • 使用本地存储的 Pod，除非策略显式禁用了 PodsWithLocalStorage 保护。
• Pod Disruption Budgets (PDBs)：descheduler 使用 eviction 子资源。如果驱逐 Pod 会违反其 PDB，则不会驱逐该 Pod。
• 驱逐顺序：当有多个 Pod 满足条件时，会优先选择较低优先级的 Pod；对于相同优先级的 Pod，BestEffort Pod 会先于 Burstable 和 Guaranteed Pod 被驱逐。
• 显式驱逐覆盖：带有注解 descheduler.alpha.kubernetes.io/evict 的 Pod 即使在某些内部 descheduler 检查中通常会被跳过，也仍然有资格被驱逐。该注解不会绕过 PDB 保护。仅在你清楚该 Pod 将如何被重建时使用。
• 驱逐偏好：带有注解 descheduler.alpha.kubernetes.io/prefer-no-eviction 的 Pod 会请求 descheduler 避免驱逐它。该偏好是建议性还是强制性的，取决于 DefaultEvictor 的 noEvictionPolicy 设置。

#了解 Descheduler 策略

descheduler 策略启用策略插件。请选择与运维目标匹配的策略；避免在同一个策略配置文件中启用方向相反的策略，例如同时使用 LowNodeUtilization 分散工作负载和 HighNodeUtilization 压缩工作负载。

常见策略组：

#在 ACP 中安装 Descheduler

Alauda Build of Descheduler 在 ACP 中作为 Cluster Plugin 进行打包和管理。

1. 上传插件包：

   • 从 Alauda Customer Portal 获取 Alauda Build of Descheduler 插件包。
   • 使用 violet 工具将其发布到平台。有关详细的 CLI 说明，请参阅 CLI Tools。
   • 导航到 Administrator > Marketplace > Upload Packages，并确认该包已出现在 Cluster Plugin 选项卡下。

2. 安装插件：

   • 导航到 Administrator > Marketplace > Cluster Plugins。
   • 选择目标集群，找到 Alauda Build of Descheduler 插件，并单击 Install。
   • 如有需要，在动态表单中调整安装时的配置选项，然后确认安装。

#配置调度策略

插件安装后，不要直接编辑 Helm values。已安装的插件会渲染 Kubernetes 资源，而运行时 descheduler 策略会以 YAML 形式存储在 descheduler ConfigMap 中。

#运行模式

• CronJob（推荐）：descheduler 作为 Job 定期运行。当集群状态稳定时，这种模式可以避免运行持久化智能体。更新后的策略 YAML 会在下一次计划的 Job 中加载。
• Deployment：descheduler 作为持续运行的 Pod 运行，并按照插件安装时配置的间隔对集群进行协调。更新策略 YAML 后，请重启 descheduler Pod，以便运行中的进程重新加载配置。

#编辑策略 YAML

定位 descheduler 策略 ConfigMap：

kubectl get configmap -n kube-system -l app.kubernetes.io/name=descheduler

在编辑之前先备份当前策略：

kubectl get configmap -n kube-system <descheduler-configmap-name> -o yaml > descheduler-configmap.backup.yaml

编辑上一个命令返回的 ConfigMap：

kubectl edit configmap -n kube-system <descheduler-configmap-name>

在 data.policy.yaml 中，请保留现有策略，只合并你需要更改的字段。不要用示例替换整个策略，因为这样可能会移除现有的保护、已启用策略、命名空间过滤器或驱逐限制。

#示例：重新平衡利用率过高的节点

此示例启用 LowNodeUtilization，并设置与常见分散型 descheduling 相同的阈值模式：CPU、内存和 Pod 容量低于 20% 的节点属于利用不足；上述任一资源高于 50% 的节点属于利用过高。

相关策略片段：

apiVersion: "descheduler/v1alpha2"
kind: "DeschedulerPolicy"
maxNoOfPodsToEvictTotal: 20
profiles:
  - name: default
    pluginConfig:
      - name: DefaultEvictor
        args:
          nodeFit: true
      - name: LowNodeUtilization
        args:
          thresholds:
            cpu: 20
            memory: 20
            pods: 20
          targetThresholds:
            cpu: 50
            memory: 50
            pods: 50
          evictionLimits:
            node: 5
    plugins:
      balance:
        enabled:
          - LowNodeUtilization

注意：

• thresholds 和 targetThresholds 必须定义相同的资源键。
• 有效百分比范围为 0 到 100。
• 对于同一资源，thresholds 不能大于 targetThresholds。
• 只有当至少存在一个利用不足的节点和一个利用过高的节点时，该策略才会运行。
• 默认情况下，node utilization 是根据 Pod resource requests 和 node allocatable resources 计算的。如果你需要基于实际使用量的 descheduling，请在策略中配置受支持的 metrics provider 和 metricsUtilization。

#常见策略定制

#示例：生命周期和健康清理

此片段会驱逐运行超过 24 小时的 Pod，以及容器重启超过 100 次的 Pod：

profiles:
  - name: default
    pluginConfig:
      - name: PodLifeTime
        args:
          maxPodLifeTimeSeconds: 86400
      - name: RemovePodsHavingTooManyRestarts
        args:
          podRestartThreshold: 100
          includingInitContainers: true
    plugins:
      deschedule:
        enabled:
          - PodLifeTime
          - RemovePodsHavingTooManyRestarts

#示例：亲和性、taints 和拓扑漂移

此片段会驱逐不再匹配更新后的 node taints、必需 node affinity、Pod 间反亲和性或硬 topology spread 约束的 Pod：

profiles:
  - name: default
    pluginConfig:
      - name: RemovePodsViolatingNodeTaints
      - name: RemovePodsViolatingNodeAffinity
        args:
          nodeAffinityType:
            - requiredDuringSchedulingIgnoredDuringExecution
      - name: RemovePodsViolatingInterPodAntiAffinity
      - name: RemovePodsViolatingTopologySpreadConstraint
        args:
          constraints:
            - DoNotSchedule
    plugins:
      deschedule:
        enabled:
          - RemovePodsViolatingNodeTaints
          - RemovePodsViolatingNodeAffinity
          - RemovePodsViolatingInterPodAntiAffinity
      balance:
        enabled:
          - RemovePodsViolatingTopologySpreadConstraint

#验证安装和驱逐

#1. 检查插件安装状态

确认 ModuleInfo 已转换为 Running 状态：

kubectl get moduleinfo -l cpaas.io/module-name=descheduler

#2. 验证策略 ConfigMap

检查策略 YAML 是否包含预期的策略和保护措施：

kubectl get configmap -n kube-system <descheduler-configmap-name> -o yaml

#3. 查看 Descheduler 运行情况和日志

如果作为 CronJob 运行，请列出已完成或正在运行的 Job：

kubectl get jobs -n kube-system -l app.kubernetes.io/name=descheduler

如果作为 Deployment 运行，请确认正在运行的 Pod，并在策略变更后将其重启：

kubectl get pods -n kube-system -l app.kubernetes.io/name=descheduler
kubectl rollout restart deployment -n kube-system -l app.kubernetes.io/name=descheduler

获取 descheduler 日志，以检查节点评估、被跳过的 Pod 和驱逐操作：

kubectl logs -n kube-system -l app.kubernetes.io/name=descheduler --tail=100

驱逐日志示例：

I0601 15:30:15.123456       1 evictions.go:160] "Evicting pod" pod="default/my-app-67d7f8d68c-xxxxx" reason="RemoveDuplicates"

#4. 检查 Pod 事件

当 Pod 被 descheduler 驱逐时，请检查 Pod 事件和 Pod 描述。事件原因会因策略而异，因此不要只依赖单一的 reason=Descheduled 过滤条件。

kubectl get events -n <namespace> --field-selector involvedObject.kind=Pod --sort-by=.lastTimestamp
kubectl describe pod -n <namespace> <pod-name>

#运维建议

• 从较小范围开始：限制命名空间、设置保守的驱逐限制，并在扩大策略范围前验证日志。
• 在启用可能驱逐大量 Pod 的策略之前，确保工作负载具有控制器并且副本数充足。
• 对关键应用保持 PDB 处于最新状态。descheduler 会遵守 PDB，但缺少 PDB 就没有中断预算。
• 仅当调度器或 autoscaler 已配置为压缩 Pod 时，才使用 HighNodeUtilization。否则，被驱逐的 Pod 可能会再次被分散。
• 除非工作负载具有明确且经过测试的恢复路径，否则不要禁用本地存储、DaemonSet、系统关键或独立 Pod 的保护。
• 对于基于实际使用量的决策，请确认已配置 metrics provider，且所选策略会使用这些指标；否则利用率策略将基于 requests。