Kubernetes Descheduler 完整指南：5 分钟解决集群资源不均衡的重新调度

Kubernetes Descheduler 完整指南5 分钟解决集群资源不均衡的重新调度【免费下载链接】deschedulerDescheduler for Kubernetes项目地址: https://gitcode.com/gh_mirrors/de/descheduler凌晨两点监控群炸了3 台节点内存告警连片另外 7 台却空着六成。你盯着 kubectl top 发愣——Pod 全挤在最早加入的几台机器上。原生调度器只决定新 Pod 落在哪对已经在跑的 Pod 视而不见。Kubernetes Descheduler 补的就是这一刀它按策略扫描整个集群把站错位置的运行中 Pod 驱逐出去再交给原生调度器重新安排让节点资源重新拉平。它到底在干什么这节用一分钟讲清它的工作方式。把集群想成一家大排档。开业那天领位原生调度器按当时的空桌给客人Pod安排座位一切正常。但客人会拼桌、翻台、换包厢半年后座位全乱了靠窗挤爆角落空一片。Descheduler 就是每晚打烊后的巡场经理扫一眼全场把坐错桌的客人礼貌请离。它自己不排座只负责请出去重建和落座仍由领位完成。一轮扫描叫一个 Descheduling Cycle重新调度周期。每个 Profile 按顺序跑 Sort → Filter → 策略执行策略分两类Deschedule 逐个处理 PodBalance 全局统筹。5 分钟跑起来这节给你能跑起来的最短路径。官方镜像从 v0.10.0 起就在 k8s 镜像仓库发布当前版本 v0.36.0选与集群小版本对齐的版本即可v0.36 对应 k8s 1.36。先用 Job 跑一次验证没问题再换 CronJob 定时跑。# kind 本地集群拉不到多架构镜像需先手动加载 kind create cluster docker pull registry.k8s.io/descheduler/descheduler:v0.36.0 kind load docker-image registry.k8s.io/descheduler/descheduler:v0.36.0 kubectl create -f kubernetes/base/rbac.yaml kubectl create -f kubernetes/base/configmap.yaml kubectl create -f kubernetes/job/job.yaml # 定时跑就换成 kubernetes/cronjob/cronjob.yaml清单在仓库 kubernetes/ 目录下configmap 里就是策略文件。想看它干了什么翻 Job 的日志即可。按需取药这节按你想解决的问题对号入座每种策略只讲三件事触发条件、最关键参数、最小片段。先看策略总览 Pod 赖着不走怎么办用 PodLifeTime。触发条件Pod 年龄超过设定秒数。最关键参数是 maxPodLifeTimeSeconds单位秒。适合治把 Pod 当虚拟机的团队逼着应用学会优雅重启。pluginConfig: - name: PodLifeTime args: maxPodLifeTimeSeconds: 604800 # 7 天 plugins: deschedule: enabled: [PodLifeTime]⚖️ 内存堆在少数节点上一对策略按方向选。LowNodeUtilization 把 Pod 从超过 targetThresholds 的挤满节点挪向低于 thresholds 的空节点空节点或挤满节点只要有一侧为零它就放弃不乱动。HighNodeUtilization 反过来把低于 thresholds 的闲节点腾空配合 Cluster Autoscaler 缩容省钱但它要求调度器启用 MostAllocated 打分策略。pluginConfig: - name: LowNodeUtilization args: thresholds: # 利用率低于它 空节点迁入目标 memory: 20 targetThresholds: # 高于它 挤满节点迁出来源 memory: 70 plugins: balance: enabled: [LowNodeUtilization]HighNodeUtilization 写法相同只留 thresholds: {memory: 20}同样挂到 balance 下。 坏节点怎么自动清场用 RemovePodsViolatingNodeTaints。污点taint是节点贴的生人勿近标签Pod 的容忍失效后就待不住了。节点失联、硬件故障被打上污点后这个策略把上面的 Pod 清走。最关键参数是 excludedTaints用来排除不想触发驱逐的污点。pluginConfig: - name: RemovePodsViolatingNodeTaints args: excludedTaints: - node.kubernetes.io/unreachable # 失联污点不触发驱逐 plugins: deschedule: enabled: [RemovePodsViolatingNodeTaints]还有 RemoveDuplicates同节点挤了同一种 Pod 的副本、RemovePodsHavingTooManyRestarts参数 podRestartThreshold: 100重启超 100 次才动手、RemoveFailedPods 等写法完全相同。配置心法这节讲哪些字段值得动、动了付出什么。阈值thresholds 不能高于 targetThresholds取值 0~100没写的资源默认 100%等于该维度不生效。日志级别默认 -v3 够看结果排查为什么没驱逐要开 -v4它会打印每个 Pod 被放过的原因。命名空间过滤多数策略收 namespaces.include/exclude二选一不能混用两个利用率策略用 evictableNamespaces且只能在驱逐前排除。标签选择器labelSelector 是标准 k8s 写法用 component: redis 这类条件把打击面缩小到一类 Pod。nodeFit在 DefaultEvictor 里设 nodeFit: true驱逐前先确认别的节点接得住代价是更保守。限流maxNoOfPodsToEvictPerNode、maxNoOfPodsToEvictTotal 给单轮驱逐封顶防止一次抽干。动手前三问目标 Pod 配了 PDBPodDisruption Budget规定副本至多能同时不可用几个吗驱逐走 eviction 接口PDB 是最后一道闸没配的心里要有数。被驱逐的 Pod 谁负责重建Descheduler 只请人不排座裸 Pod没有控制器驱逐后不会回来。阈值离集群真实水位有多远先用 Job 干跑一轮看日志再定数。落地节奏与避坑这节是上线清单按顺序执行。先拿非关键集群试跑一周误驱逐的代价不可逆。先跑 Job 再上 CronJob手动触发可控验证策略无误后再交给定时器。关键应用先补 PDB它是驱逐前唯一的自动刹车。日志开到 -v4 看为什么不驱逐猜配置不如看日志。给 DefaultEvictor 设 nodeFit: true避免 Pod 被请出去后无家可回。Descheduler 小版本对齐集群版本v0.36 对 k8s 1.36官方只测最近三个版本差太远没人兜底。下一步值得看的是和 Node Problem Detector、Cluster Autoscaler 的组合拳探测器给坏节点打污点Descheduler 清场Autoscaler 把空节点缩掉三件套拼出节点自愈闭环。【免费下载链接】deschedulerDescheduler for Kubernetes项目地址: https://gitcode.com/gh_mirrors/de/descheduler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考