Open knelasevero opened 10 months ago
Hi @knelasevero , if this approach is being actively considered, I would like to contribute in any way possible. Kindly let me know :)
First step would be implementing a feature to better control intervals between loops with a cron like semantics
I think we are very supportive of it.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Since there are some proposals to change descheduler to more of a controller than it is right now, with long running implications
Where can I read about these proposals?
I'm very interested in a descheduler controller - Instead of implementing my own, I'd rather work towards a proposed and agreed upon approach
The downside of a single pod running as a controller is, that descheduler stops if the node where the descheduler runs is going down.
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
This came up during community meeting of Jan 16 2024. Since there are some proposals to change descheduler to more of a controller than it is right now, with long running implications, maybe supporting the CronJob deployment approach isn't great for us in the future.
One of the reasons why folks use the CronJob approach is to have more control over which time the evictions are performed, as it happens here: https://github.com/kubernetes-sigs/descheduler/issues/1338
I remember getting questions from people asking the same thing (how to run it only at night). So before deprecating it might also be good to add a feature to better control intervals between loops with a cron like semantics.