Kubernetes Descheduler Helm 部署策略怎么选装完如何确认它在干活【免费下载链接】deschedulerDescheduler for Kubernetes项目地址: https://gitcode.com/gh_mirrors/de/deschedulerDescheduler for Kubernetes 会周期性扫描集群把节点放错位置的 Pod 驱逐掉交给调度器重新安置。官方仓库里自带 Helm chart一条helm install就能把 CronJob、RBAC 和策略 ConfigMap 全部铺好。本文按先判断值不值得上 → 怎么装 → 策略取舍 → 验证生效的顺序走一遍全程只用最小可运行的命令集。一、先判断你的集群有哪些 Pod 值得被挪走一个跑了几个月的集群常见病灶是节点冷热不均一部分节点 CPU 长期贴着 90%另一部分刚过 10%而调度器只管能不能放得下不管放得匀不匀。Descheduler 解决的就是这类存量问题它盯的信号可以归纳成 4 类资源占用失衡节点负载明显低于目标水位或个别节点长期过载对应LowNodeUtilization/HighNodeUtilization。规则违反Pod 所在节点已经不满足它的节点亲和、污点容忍、Pod 间反亲和或拓扑分布约束对应RemovePodsViolatingNodeAffinity、RemovePodsViolatingNodeTaints、RemovePodsViolatingInterPodAntiAffinity、RemovePodsViolatingTopologySpreadConstraint。冗余副本同一 Deployment 的多个副本挤在同一个节点上对应RemoveDuplicates。健康异常容器反复崩溃、重启次数越过阈值对应RemovePodsHavingTooManyRestarts。如果你的集群里这四类问题一个都没有Descheduler 开了也是空转如果第一类是主要矛盾那核心就是后面要讲的LowNodeUtilization阈值怎么调。二、Descheduler 怎么装前置检查与 chart 安装先过三关版本对应Descheduler 的版本号和 Kubernetes 小版本是对齐的比如 v0.36 对应 K8s v1.36且每个版本只在最近 3 个 K8s 小版本上测试过。装之前先kubectl version确认集群不低于 1.21并据此选镜像 tag。Helm 3.xchart 用了batch/v1的 CronJobHelm 2 直接不可用。集群管理员权限chart 要创建 ClusterRole、ClusterRoleBinding 和 ServiceAccount没有 cluster-admin 等价权限会在渲染后 apply 失败。拿到 chart 的方式是克隆仓库进入 chart 目录git clone https://gitcode.com/gh_mirrors/de/descheduler cd descheduler/charts/descheduler安装时只改最影响行为的两三个参数即可helm install descheduler . -n kube-system --set schedule*/15 * * * *values.yaml 里值得注意的 key 有这几个scheduleCronJob 触发周期chart 默认是*/2 * * * *每 2 分钟一轮生产环境建议放宽到 10~15 分钟避免驱逐风暴。image.tag留空时取 chart 的 appVersion当前 v0.36.0想锁定版本就显式给值。kind默认CronJob改Deployment则常驻运行按deschedulingInterval循环需要同时配置leaderElection。deschedulerPolicy策略本体以profilesplugins的形式渲染成 ConfigMap 挂到 Pod 的/policy-dir/policy.yaml下一节展开。serviceMonitor.enabled默认 false装了 Prometheus Operator 再打开见第四节。改deschedulerPolicy后 Job Pod 会带checksum/config注解ConfigMap 一变就自动滚动重建不需要额外操作。三、内置策略的取舍默认开了什么HighNodeUtilization 为什么关着Descheduler 的每个调度周期都会按 profile 依次执行 Sort → Filter → 驱逐插件一轮跑完叫一个 Descheduling Cycle策略插件的实现都放在 pkg/framework/plugins/ 目录可以直接对照源码看每个插件的入参。默认渲染出的 policy 已经把插件分成了两组balance 组RemoveDuplicates、RemovePodsViolatingTopologySpreadConstraint、LowNodeUtilization目标是把负载摊匀是集群调优的主力。deschedule 组RemovePodsHavingTooManyRestarts、RemovePodsViolatingNodeTaints、RemovePodsViolatingNodeAffinity、RemovePodsViolatingInterPodAntiAffinity目标是清理不该在这的 Pod。各策略的适用形态可以对照这张图左边是重复副本与高重启次数中间是反亲和与拓扑分布右边是污点与节点标签几个取舍建议LowNodeUtilization 的阈值是重点。默认thresholds为 cpu/memory/pods 各 20、targetThresholds各 50含义是只有当某节点利用率低于 20 且集群平均低于 50 时才启动驱逐以把该节点抬到 50 附近为目标。业务波动大的集群可以把 target 压到 30防止来回搬 Pod。HighNodeUtilization 默认不开它需要接 metrics.k8s.io 的实时用量要在 policy 里加metricsProviderssource 为 KubernetesMetricschart 检测到后会为 ClusterRole 追加 metrics 资源权限。开了 balance 组的 LowNodeUtilization 后通常不需要再叠加它。DefaultEvictor 的 Pod 保护默认禁用了PodsWithLocalStorage带本地盘的 Pod 不动启用了PodsWithPVC。如果你的业务大量使用 emptyDir/emptyDir本地存储驱逐前务必确认这一项。RemovePodsHavingTooManyRestarts默认阈值是 100 次对频繁重启但没坏透的 Pod 很激进建议按业务容忍度上调。权限方面 chart 遵循最小集只有对pods/eviction的 create 权限会真正产生驱逐其余 nodes/namespaces/pods/PDB 等只是只读 watchevents 用于记录驱逐事件只有在配置了 KubernetesMetrics 时才会额外授予 metrics.k8s.io 的 get/list。想核对完整规则可以看 clusterrole.yaml。四、装完之后如何确认它真的在工作安装后等第一个 schedule 周期触发看最近一次 Job 的日志最直接kubectl get pods -n kube-system -l app.kubernetes.io/namedescheduler日志里出现running profile default以及各策略的执行记录说明周期在跑看到evicting pod说明确实有 Pod 被挪动。确认没有误伤的方式是紧接着跑一遍kubectl get pods -A核对被驱逐的 Pod 都在其他节点重新拉起了。指标层面Descheduler 在 10258 端口暴露/metrics核心有四个descheduler_pods_evicted_total按策略、命名空间、节点分标签的驱逐计数resulterror表示驱逐失败这个标签最值得配告警。descheduler_loop_duration_seconds一个完整周期耗时接近 schedule 间隔就说明周期太密了。descheduler_strategy_duration_seconds单个策略耗时能定位哪个插件拖慢周期。descheduler_build_info版本核对用。Prometheus 集成只需--set serviceMonitor.enabledtruechart 会渲染一个 monitoring.coreos.com/v1 的 ServiceMonitor配合namespace指向 Prometheus 所在命名空间即可。五、收尾前检查一遍的三件事跑完验证后把这三项过一遍再收工schedule是否已放宽到业务可接受的间隔LowNodeUtilization的targetThresholds是否贴合当前集群水位以及descheduler_pods_evicted_total{resulterror}是否持续为零。之后每周一看一次descheduler_loop_duration_seconds和驱逐计数即可等下一个 schedule 周期触发翻一遍 Job 日志确认没有任何 Pod 被误驱逐这次部署就算落地了。【免费下载链接】deschedulerDescheduler for Kubernetes项目地址: https://gitcode.com/gh_mirrors/de/descheduler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes Descheduler Helm 部署策略怎么选装完如何确认它在干活【免费下载链接】deschedulerDescheduler for Kubernetes项目地址: https://gitcode.com/gh_mirrors/de/deschedulerDescheduler for Kubernetes 会周期性扫描集群把节点放错位置的 Pod 驱逐掉交给调度器重新安置。官方仓库里自带 Helm chart一条helm install就能把 CronJob、RBAC 和策略 ConfigMap 全部铺好。本文按先判断值不值得上 → 怎么装 → 策略取舍 → 验证生效的顺序走一遍全程只用最小可运行的命令集。一、先判断你的集群有哪些 Pod 值得被挪走一个跑了几个月的集群常见病灶是节点冷热不均一部分节点 CPU 长期贴着 90%另一部分刚过 10%而调度器只管能不能放得下不管放得匀不匀。Descheduler 解决的就是这类存量问题它盯的信号可以归纳成 4 类资源占用失衡节点负载明显低于目标水位或个别节点长期过载对应LowNodeUtilization/HighNodeUtilization。规则违反Pod 所在节点已经不满足它的节点亲和、污点容忍、Pod 间反亲和或拓扑分布约束对应RemovePodsViolatingNodeAffinity、RemovePodsViolatingNodeTaints、RemovePodsViolatingInterPodAntiAffinity、RemovePodsViolatingTopologySpreadConstraint。冗余副本同一 Deployment 的多个副本挤在同一个节点上对应RemoveDuplicates。健康异常容器反复崩溃、重启次数越过阈值对应RemovePodsHavingTooManyRestarts。如果你的集群里这四类问题一个都没有Descheduler 开了也是空转如果第一类是主要矛盾那核心就是后面要讲的LowNodeUtilization阈值怎么调。二、Descheduler 怎么装前置检查与 chart 安装先过三关版本对应Descheduler 的版本号和 Kubernetes 小版本是对齐的比如 v0.36 对应 K8s v1.36且每个版本只在最近 3 个 K8s 小版本上测试过。装之前先kubectl version确认集群不低于 1.21并据此选镜像 tag。Helm 3.xchart 用了batch/v1的 CronJobHelm 2 直接不可用。集群管理员权限chart 要创建 ClusterRole、ClusterRoleBinding 和 ServiceAccount没有 cluster-admin 等价权限会在渲染后 apply 失败。拿到 chart 的方式是克隆仓库进入 chart 目录git clone https://gitcode.com/gh_mirrors/de/descheduler cd descheduler/charts/descheduler安装时只改最影响行为的两三个参数即可helm install descheduler . -n kube-system --set schedule*/15 * * * *values.yaml 里值得注意的 key 有这几个scheduleCronJob 触发周期chart 默认是*/2 * * * *每 2 分钟一轮生产环境建议放宽到 10~15 分钟避免驱逐风暴。image.tag留空时取 chart 的 appVersion当前 v0.36.0想锁定版本就显式给值。kind默认CronJob改Deployment则常驻运行按deschedulingInterval循环需要同时配置leaderElection。deschedulerPolicy策略本体以profilesplugins的形式渲染成 ConfigMap 挂到 Pod 的/policy-dir/policy.yaml下一节展开。serviceMonitor.enabled默认 false装了 Prometheus Operator 再打开见第四节。改deschedulerPolicy后 Job Pod 会带checksum/config注解ConfigMap 一变就自动滚动重建不需要额外操作。三、内置策略的取舍默认开了什么HighNodeUtilization 为什么关着Descheduler 的每个调度周期都会按 profile 依次执行 Sort → Filter → 驱逐插件一轮跑完叫一个 Descheduling Cycle策略插件的实现都放在 pkg/framework/plugins/ 目录可以直接对照源码看每个插件的入参。默认渲染出的 policy 已经把插件分成了两组balance 组RemoveDuplicates、RemovePodsViolatingTopologySpreadConstraint、LowNodeUtilization目标是把负载摊匀是集群调优的主力。deschedule 组RemovePodsHavingTooManyRestarts、RemovePodsViolatingNodeTaints、RemovePodsViolatingNodeAffinity、RemovePodsViolatingInterPodAntiAffinity目标是清理不该在这的 Pod。各策略的适用形态可以对照这张图左边是重复副本与高重启次数中间是反亲和与拓扑分布右边是污点与节点标签几个取舍建议LowNodeUtilization 的阈值是重点。默认thresholds为 cpu/memory/pods 各 20、targetThresholds各 50含义是只有当某节点利用率低于 20 且集群平均低于 50 时才启动驱逐以把该节点抬到 50 附近为目标。业务波动大的集群可以把 target 压到 30防止来回搬 Pod。HighNodeUtilization 默认不开它需要接 metrics.k8s.io 的实时用量要在 policy 里加metricsProviderssource 为 KubernetesMetricschart 检测到后会为 ClusterRole 追加 metrics 资源权限。开了 balance 组的 LowNodeUtilization 后通常不需要再叠加它。DefaultEvictor 的 Pod 保护默认禁用了PodsWithLocalStorage带本地盘的 Pod 不动启用了PodsWithPVC。如果你的业务大量使用 emptyDir/emptyDir本地存储驱逐前务必确认这一项。RemovePodsHavingTooManyRestarts默认阈值是 100 次对频繁重启但没坏透的 Pod 很激进建议按业务容忍度上调。权限方面 chart 遵循最小集只有对pods/eviction的 create 权限会真正产生驱逐其余 nodes/namespaces/pods/PDB 等只是只读 watchevents 用于记录驱逐事件只有在配置了 KubernetesMetrics 时才会额外授予 metrics.k8s.io 的 get/list。想核对完整规则可以看 clusterrole.yaml。四、装完之后如何确认它真的在工作安装后等第一个 schedule 周期触发看最近一次 Job 的日志最直接kubectl get pods -n kube-system -l app.kubernetes.io/namedescheduler日志里出现running profile default以及各策略的执行记录说明周期在跑看到evicting pod说明确实有 Pod 被挪动。确认没有误伤的方式是紧接着跑一遍kubectl get pods -A核对被驱逐的 Pod 都在其他节点重新拉起了。指标层面Descheduler 在 10258 端口暴露/metrics核心有四个descheduler_pods_evicted_total按策略、命名空间、节点分标签的驱逐计数resulterror表示驱逐失败这个标签最值得配告警。descheduler_loop_duration_seconds一个完整周期耗时接近 schedule 间隔就说明周期太密了。descheduler_strategy_duration_seconds单个策略耗时能定位哪个插件拖慢周期。descheduler_build_info版本核对用。Prometheus 集成只需--set serviceMonitor.enabledtruechart 会渲染一个 monitoring.coreos.com/v1 的 ServiceMonitor配合namespace指向 Prometheus 所在命名空间即可。五、收尾前检查一遍的三件事跑完验证后把这三项过一遍再收工schedule是否已放宽到业务可接受的间隔LowNodeUtilization的targetThresholds是否贴合当前集群水位以及descheduler_pods_evicted_total{resulterror}是否持续为零。之后每周一看一次descheduler_loop_duration_seconds和驱逐计数即可等下一个 schedule 周期触发翻一遍 Job 日志确认没有任何 Pod 被误驱逐这次部署就算落地了。【免费下载链接】deschedulerDescheduler for Kubernetes项目地址: https://gitcode.com/gh_mirrors/de/descheduler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
