Comments (9)
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.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
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.
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.
Related Issues (20)
- Unstructured converter should produce int64 given uint input HOT 2
- Kubelet stop watching Pods from API-Server HOT 3
- [RFC] Remove Kubelet soft-admission HOT 6
- [FG:InPlacePodVerticalScaling] Race condition setting pod resize status HOT 1
- After the kubelet restarted, the ready state of the pod should not change. HOT 4
- kubectl --server-side apply replaces the live manifest instead of merging when migrating from clinet side apply to server side apply HOT 7
- [Flaking test] unit test TestStoreListResourceVersion HOT 12
- kubectl delete a large number of objects taking too long HOT 4
- High kubepods cgroup cpu.weight/shares starves kernel threads on many core systems HOT 4
- Job may get stuck repeatedly failing with Duplicate value message for uncountedTerminatedPods.failed HOT 14
- kubectl port-forward failing for named ports in native sidecar HOT 6
- [Flaking Test] k8s.io/apiserver/pkg/registry/generic/registry.registry HOT 6
- ExtendedResourceToleration adds tolerations even when the quantity of requested resources is "0" HOT 3
- When a deployment selects a node with the kubelet service not running as the nodeName, the Pods will remain in the pending state, then move to Terminating, and new Pods will be continuously created in a loop, resulting in a large number of Terminating Pods that cannot be terminated. HOT 3
- [Flaking Test] gce-cos-master-serial (etcd failure should recover from sigkill) HOT 3
- Incorrect error reporting in case of missing cgroup controllers HOT 4
- kubelet unbalanced affinity pod in different numa node HOT 11
- KEP-4639 OCI VolumeSource PoC HOT 2
- [Flaking test] [sig-network] Services should release NodePorts on delete HOT 4
- Conntrack tables having stale entries for UDP connection HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kubernetes.