Deprecate CronJob deployment approach

[knelasevero]

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: #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.

[pravarag]

Hi @knelasevero , if this approach is being actively considered, I would like to contribute in any way possible. Kindly let me know :)

[knelasevero]

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ChandonPierre]

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

[Deltachaos]

The downside of a single pod running as a controller is, that descheduler stops if the node where the descheduler runs is going down.

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[aslafy-z]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale