RFE Optional CronJob Parameter: Auto-Suspend Kubernetes CronJob After Specified Number of Successful Executions about kubernetes HOT 9 OPEN

hey @sftim,

In my opionion, integrating a maximum successful execution limit for CronJobs directly into Kubernetes offers significant advantages over external controllers, enhancing the user experience seamlessly. This native feature simplifies management by removing the need for bespoke controllers or additional logic, thereby reducing complexity and error potential.

A native implementation also mitigates the resource overhead linked with external controllers, such as operational and maintenance costs, and potential performance degradation from managing multiple controllers. By incorporating this feature directly into Kubernetes, we foster community contributions and continuous improvement, ensuring robustness under diverse operational conditions.

The feature is designed as an optional parameter that activates only when configured by the user (with a default value of 0, for example), ensuring it does not impact existing CronJobs. This approach offers flexibility, allowing users to adapt the feature as needed without disrupting existing setups and preserving Kubernetes' commitment to modularity and user-driven configuration.

This optional parameter would benefit use cases like mine, where automation dynamically creates cronjobs to monitor specific conditions over short periods. Kubernetes, with its distributed architecture and reliable scheduling, is ideally suited for this. The proposed feature would automatically suspend these cronjobs after their intended number of executions, streamlining management and enhancing efficiency.

Consider the built-in Jobs history limits in Kubernetes, which already streamline job management and could have been handled by an external controller. However, having this functionality built into Kubernetes provides a more convenient, reliable, and cohesive experience. This proposed feature follows a similar rationale, embedding essential functionality directly within Kubernetes to enhance user convenience.

from kubernetes.

@jangel97 you should take this to a SIG Apps Zoom meeting (or Slack conversation) and test the water to see if other people are sold on adding more code to maintain.

If they're not, it'll likely find a better home out of tree. If there is interest, the next step is to find a project manager (KEP owner) willing to supervise delivery for the enhancement.

from kubernetes.

Hey @sftim ! Thank you for letting me know about this!

from kubernetes.

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

from kubernetes.

My key question: why should we build this into Kubernetes (and not, for example, let someone write an external controller that achieves the same outcome)?

from kubernetes.

If the only benefit of it not being an external controller is not needing an external controller, I think you'll want a stronger case @jangel97.

You could build an out-of-tree prototype to show how it might work. Would you be willing to do that?

from kubernetes.

@sftim,

The proposal not only removes the requirement for an external controller but also enhances functionality to support a variety of potential use cases. For example, including this feature in Kubernetes cronjobs would perfectly address my requirements, and likely those of others. Take the implementation of Job history limits as another instance; it was introduced to meet a common need, providing multiple users with a native solution to manage job subresources as per need.

When you mention an out-of-tree prototype, are you suggesting a demonstration of how the proposed implementation would work? If so, I'm on board with that. Additionally, I'm keen to collaborate on the implementation tasks, provided that there's agreement on the viability of this proposal.

from kubernetes.

I agree with @sftim this seems like an opportunity to write something outside of the k8s code base, I could see this wanting more and more features that would be more quickly approved in another project anyhow. Creating a new type of 'job' object with this project, so that if there was enough adoption, perhaps this could merge into the k8s codebase some day. IMO, this use case is not so common.

from kubernetes.

@jwhittem, I agree that if this RFE doesn't receive sufficient support from the community, due to it being a niche use case, it would be more appropriate to integrate this setting into another project that more specifically focuses on job time scheduling (or just doing my custom thing for myself).

As for future RFEs concerning this setting, I find it hard to foresee any, as the setting appears to be quite distinct and standalone.

from kubernetes.