Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

4.9. Descheduler

4.9.1. Descheduler 概述
复制链接

调度程序（scheduler）被用来决定最适合托管新 pod 的节点，而 descheduler 可以用来驱除正在运行的 pod，从而使 pod 能够重新调度到更合适的节点上。

4.9.1.1. 关于 descheduler
复制链接

您可以使用 descheduler 根据特定策略驱除 pod，以便 pod 重新调度到更合适的节点上。

descheduler 适合于在以下情况下 处理运行的 pod：

  • 节点使用不足或过度使用。
  • Pod 和节点关联性要求（如污点或标签）已更改，并且原始的调度不再适合于某些节点。
  • 节点失败需要移动 pod。
  • 集群中添加了新节点。
  • Pod 重启的次数太多。
重要

descheduler 不调度被驱除的 pod。调度被驱除 pod 的任务由调度程序（scheduler）执行。

当 descheduler 决定从节点驱除 pod 时，它会使用以下机制：

  • openshift-* 和 kube-system 命名空间中的 Pod 不会被驱除。
  • priorityClassName 被设置为 system-cluster-critical 或 system-node-critical 的关键 pod 不会被驱除。
  • 不属于复制控制器、副本集、部署、有状态集或作业一部分的静态、镜像或独立 pod 不会被驱除，因为这些 pod 不会被重新创建。
  • 与守护进程集关联的 pod 不会被驱除。
  • 具有本地存储的 Pod 不会被驱除。
  • BestEffort pod 会在 Burstable 和 Guaranteed pod 之前被驱除。
  • 具有 descheduler.alpha.kubernetes.io/evict 注解的所有 pod 类型都可以被驱除。此注解用于覆盖防止驱除的检查，用户可以选择驱除哪些 pod。用户应该知道如何创建 pod 以及是否重新创建 pod。
  • 对于受 Pod Disruption Budget (PDB) 限制的 pod，如果进行 deschedule 会违反 Pod disruption budget (PDB)，则 pod 不会被驱除。通过使用驱除子资源来处理 PDB 来驱除 pod 。

4.9.1.2. Descheduler 配置集
复制链接

使用 descheduler 配置集启用根据 pod 生命周期或节点使用率等标准重新平衡集群的特定驱除策略。

以下 descheduler 配置集可用：

AffinityAndTaints

此配置集驱除违反了 pod 间的反关联性、节点关联性和节点污点的 pod。

它启用了以下策略：

  • RemovePodsViolatingInterPodAntiAffinity：删除违反了 pod 间的反关联性的 pod。
  • RemovePodsViolatingNodeAffinity：移除违反了节点关联性的 pod。

  • RemovePodsViolatingNodeTaints：移除违反了节点上的 NoSchedule 污点的 pod。

    移除具有节点关联性类型 requiredDuringSchedulingIgnoredDuringExecution的 pod。

TopologyAndDuplicates

此配置集会驱除 pod 以努力在节点间平均分配类似的 pod 或相同拓扑域的 pod。

它启用了以下策略：

  • RemovePodsViolatingTopologySpreadConstraint：找到未平衡的拓扑域，并在 DoNotSchedule 约束被违反时尝试从较大的 pod 驱除 pod。
  • RemoveDuplicates：确保只有一个 pod 与同一节点上运行的副本集、复制控制器、部署或作业相关联。如果存在多个重复的 pod，则这些重复的 pod 会被驱除以更好地在集群中的 pod 分布。
警告

不要使用以下配置集启用 TopologyAndDuplicates: SoftTopologyAndDuplicates 或 CompactAndScale。将这些配置集启用在一起会导致冲突。

LifecycleAndUtilization

此配置集驱除长时间运行的 pod，并平衡节点之间的资源使用情况。

它启用了以下策略：

  • RemovePodsHavingTooManyRestarts ：删除容器重启了多次的 pod。

    在所有容器（包括初始容器）中被重启的总数超过 100 次的 Pod 。

  • LowNodeUtilization：查找使用率不足的节点，并在可能的情况下从其他过度使用的节点中驱除 pod，以希望这些被驱除的 pod 可以在使用率低的节点上被重新创建。

    • 如果节点的用量低于 20%（CPU、内存和 pod 的数量）,则该节点将被视为使用率不足。
    • 如果节点的用量超过 50%（CPU、内存和 pod 的数量）,则该节点将被视为过量使用。

    另外，您可以通过将技术预览字段 devLowNodeUtilizationThresholds 设置为以下值来调整这些使用率使用率/过量使用阈值百分比：Low 为 10%/30%，Medium 为 20%/50%，或 High 为 40%/70%。默认值为 Medium。

  • PodLifeTime：驱除太老的 pod。

    默认情况下，会删除超过 24 小时的 pod。您可以自定义 pod 生命周期值。

警告

不要启用带有以下任意配置集的 LifecycleAndUtilization ：LongLifecycle 或 CompactAndScale。将这些配置集启用在一起会导致冲突。

SoftTopologyAndDuplicates

这个配置集与 TopologyAndDuplicates 相同，不同之处在于具有软拓扑约束的 pod（如 whenUnsatisfiable: ScheduleAnyway ）也被视为驱除。

警告

不要同时启用 SoftTopologyAndDuplicates 和 TopologyAndDuplicates。启用两者会导致冲突。

EvictPodsWithLocalStorage
此配置集允许具有本地存储的 pod 有资格被驱除。
EvictPodsWithPVC
此配置集允许带有持久性卷声明的 pod 有资格驱除。如果使用 Kubernetes NFS Subdir External Provisioner，您必须为安装置备程序的命名空间添加排除的命名空间。
CompactAndScale

此配置集启用了 HighNodeUtilization 策略，它尝试从使用率低的节点驱除 pod，以允许工作负载在较小的一组节点上运行。如果节点的用量低于 20%（CPU、内存和 pod 的数量）,则该节点将被视为使用率不足。

另外，您可以通过将技术预览字段 devHighNodeUtilizationThresholds 设置为以下值来调整使用率不足的百分比： Minimal 为 10%，Modest 为 20%，或 Moderate 代表 30%。默认值为 Modest。

警告

不要启用 CompactAndScale，包含以下配置集：LifecycleAndUtilization, LongLifecycle, 或 TopologyAndDuplicates。将这些配置集启用在一起会导致冲突。

KubeVirtRelieveAndMigrate

这个配置集是 LongLifeCycle 配置集的一个增强版本。

KubeVirtRelieveAndMigrate 配置集从高成本节点驱除 pod，以减少整体资源费用并启用工作负载迁移。它还定期重新平衡工作负载，以帮助在节点间维护类似的备用容量，从而更好地处理突然负载激增。节点可能会遇到以下成本：

  • 资源利用率 ：增加资源压力会导致运行应用程序的开销增加。
  • 节点维护 ：节点上的容器数量更多，会增加资源消耗和维护成本。

该配置集启用了 LowNodeUtilization 策略，它带有 EvictionsInBackground alpha 功能。该配置集还会公开以下自定义字段：

  • devActualUtilizationProfile: 启用负载均衡的取消调度。
  • devLowNodeUtilizationThresholds ：为 LowNodeUtilization 策略设置实验性阈值。不要将此字段与 devDeviationThresholds 搭配使用。
  • devDeviationThresholds ：以低量资源使用率为低等资源的节点，以帮助从过度利用的节点重新分发工作负载。不要将此字段与 devLowNodeUtilizationThresholds 搭配使用。支持的值是：Low (10%:10%), Medium (20%:20%), High (30%:30%), AsymmetricLow (0%:10%), AsymmetricMedium (0%:20%), AsymmetricHigh (0%:30%).
  • devEnableSoftTainter ：启用软包含组件，以动态应用或删除软污点作为调度提示。

配置示例

apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  managementState: Managed
  deschedulingIntervalSeconds: 30
  mode: "Automatic"
  profiles:
    - KubeVirtRelieveAndMigrate
  profileCustomizations:
    devEnableSoftTainter: true
    devDeviationThresholds: AsymmetricLow
    devActualUtilizationProfile: PrometheusCPUCombined

KubeVirtRelieveAndMigrate 配置集要求在所有 worker 节点上启用 PSI 指标。您可以通过应用以下 MachineConfig 自定义资源 (CR) 来启用此项：

MachineConfig CR 示例

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-openshift-machineconfig-worker-psi-karg
spec:
  kernelArguments:
    - psi=1

注意

MachineConfig 对象的名称非常重要，因为机器配置以字典顺序处理。默认情况下，以 98- 开头的配置会禁用 PSI。要确保启用了 PSI，请将您的配置命名为具有更高前缀，如 99-openshift-machineconfig-worker-psi-karg。

您可以将这个配置集与 SoftTopologyAndDuplicates 配置集一起使用，以根据软拓扑约束重新平衡 pod，这在托管 control plane 环境中很有用。

LongLifecycle

此配置集在节点间平衡资源使用量并启用以下策略：

  • RemovePodsHavingTooManyRestarts ：删除其容器重启次数太多的 pod，以及其中所有容器（包括 Init 容器）重启的总数超过 100 的 pod。重启虚拟机客户端操作系统不会增加这个计数。

  • LowNodeUtilization ：在存在没有被充分利用的节点时，将 pod 从过度使用的节点上驱除。被驱除的 pod 的目标节点将由调度程序决定。

    • 如果节点的用量低于 20%（CPU、内存和 pod 的数量）,则该节点将被视为使用率不足。
    • 如果节点的用量超过 50%（CPU、内存和 pod 的数量）,则该节点将被视为过量使用。
警告

不要启用带有以下任意配置集的 LongLifecycle: LifecycleAndUtilization 或 CompactAndScale。将这些配置集启用在一起会导致冲突。

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

Legal Notice

Theme

© 2026 Red Hat返回顶部