Add startup resource requirements

[alikhil]

What would you like to be added:

I would like startup resources requirements to be added. Now we have request and limits and I want something like startup-request for CPU and RAM.

Why is this needed:

Some applications use a lot of RAM and CPU during the startup and use not much while running. Now, such applications need to require high requests to be able to started. And when app is running and uses few resources it blocks unused resources so that other applications cannot use it.

For example, there is an app which requires 1 GB RAM and 1 CPU during the startup. And when it finished all preparations and started to work in normal mode it requires only 200 MB RAM and 200m CPU. Now, to make it deployable to k8s we need to set resource requests as 1 GB for RAM and 1 core for CPU which is honest. But when app is running it uses only fifth part of requested resources and other applications can not claim to use these resources.

What I am suggesting for this cases is to introduce startup-request which will be actual until startupProbe (introduced in 1.16) returns OK. So, when app finished startup, k8s frees unnecessary resources (making them available for other apps) and application left only with resources specified in request section

[alikhil]

/sig apps

[danielqsj]

/cc

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[alikhil]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[alikhil]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[alikhil]

/remove-lifecycle stale

[povils]

Would running sidecar container which would do sleep x and requesting 1 GB RAM and 1 CPU ? so that during scheduling the scheduler will ensure the pod will have enough resources

[alikhil]

@povils thank you for your response! I think with the solution you have provided it is possible to ensure resources, but my point is that it would be nice to free resources that are needed only during the startup. Sidecar container will not solve this problem because after heavy startup operations k8s still keeps resources requests reserved.

Please try to reread my initial message, and let me know if it does not help. Maybe I need to reformulate/rewrite my point to be more clear.

[prydonius]

/assign @kow3ns
/triage accepted

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[alikhil]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[alikhil]

/remove-lifecycle stale

[k8s-triage-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[alikhil]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[alikhil]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[Nmaxime]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[alikhil]

/remove-lifecycle stale

[philomory]

I think this would be a fantastic feature, as we ourselves have fair number of apps like this. The only caveat is that if the container within the pod ever crashes, it may not be able to restart as normal and would probably instead need to be rescheduled onto a new node. In the common case of a pod managed by a controller of some sort this wouldn't be that big of a deal, but in the case of a "bare pod" declared directly via e.g. kubectl create pod, it would potentially cause issues (though, not unsolvable ones).

[jhonDoe15]

@philomory Could you expand on the issue you're displaying?

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[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

[alikhil]

/remove-lifecycle stale