16.3. 取消调度
16.3.1. 概述
分离涉及根据 特定的策略 驱除 pod，以便可将 pod 重新调度到更合适的节点上。
集群可以从取消调度和重新调度已在运行的 pod 中受益，原因如下：
- 节点使用不足或过度使用。
- Pod 和节点关联性要求（如污点或标签）已更改，并且原始的调度不再适合于某些节点。
- 节点失败需要移动 pod。
- 集群中添加了新节点。
descheduler 不调度被驱除的 pod。调度程序 自动为被驱除的 pod 执行此任务。
务必要注意，有许多核心组件（如 DNS）对于集群全面运行至关重要，但在常规集群节点而非 master 上运行。如果组件被驱除，集群可能会停止正常工作。要防止 descheduler 删除这些 pod，请将 pod 配置为 关键 pod，方法是将 scheduler.alpha.kubernetes.io/critical-pod 注解添加到 pod 规格中。
descheduler 作业被视为关键 pod，可防止 descheduler pod 被 descheduler 驱除。
descheduler 作业和 descheduler pod 在 kube-system 项目中创建，默认创建。
descheduler 只是一个技术预览功能。技术预览功能不包括在红帽生产服务级别协议（SLA）中，且其功能可能并不完善。因此，红帽不建议在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
如需红帽技术预览功能支持范围的更多信息，请参阅 https://access.redhat.com/support/offerings/techpreview/。
descheduler 不会驱除以下类型的 pod：
-
关键 pod（带有
scheduler.alpha.kubernetes.io/critical-pod注解）。 - Pod（静态和镜像 pod 或独立模式的 pod）与 Replica Set、Replication Controller、Deployment 或 Job 没有关联（因为这些 pod 不会被重新创建）。
- 与 DaemonSet 关联的 Pod。
- 具有本地存储的 Pod。
- 如果取消调度违反了 PDB，受 Pod Disruption Budget (PDB) 限制的 Pod 不会被驱除。可以使用一个驱除策略来驱除 pod。
在 Burstable 和 Guaranteed pod 之前，pod 会被驱除。
以下小节描述了配置和运行 descheduler 的流程：
- 创建角色。
- 在策略文件中定义取消调度行为。
- 创建配置映射以引用策略文件。
- 创建 descheduler 作业配置。
- 运行 descheduler 作业。
