enhancements
enhancements copied to clipboard
kubernetes
KEP-2837: Pod level resource limits
keps/sig-node: add KEP for shared-burstable-limits - pod level resource limits
Welcome @liorokman!
It looks like this is your first PR to kubernetes/enhancements 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.
You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.
You can also check if kubernetes/enhancements has its own contribution guidelines.
You may want to refer to our testing guide if you run into trouble with your tests not passing.
If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!
Thank you, and welcome to Kubernetes. :smiley:
Hi @liorokman. Thanks for your PR.
I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
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.
@liorokman the PR seems to have carried along a number of other KEPs. Can you update the PR to just have the KEP presented? Are you able to present at a future SIG Node meeting the high level overview of the proposal?
@liorokman the PR seems to have carried along a number of other KEPs. Can you update the PR to just have the KEP presented?
Done.
Are you able to present at a future SIG Node meeting the high level overview of the proposal?
I'd be happy to. When is the next SIG Node meeting?
Have you thought about the implications of this feature with vertical pod autoscaling?
If this feature is turned on, the VPA could be set to update the budget of one single container in the pod, and also set to monitor the pod-level cgroup for actual maximum resource consumption. This would make the VPA able to also work correctly for pods with this behavior enabled. In effect, the VPA would work the same, except that it would scale the memory for the entire pod instead of working on the container level.
By allowing the deployment to specify a resource budget for the entire pod and having the Linux kernel play with the details of allowing each container to allocate what it needs, when it needs it, the end result is a more flexible arrangement. This is a win-win scenario:
- the developer doesn't need to micro-manage container limits but is not forced to grant unlimited resources to critical containers,
- the application has less disruption because the VPA isn't evicting the pod to fine-tune the specific container limits,
- the node is less susceptible to the noisy-neighbor problem with pods in the
BurstableQoS level (also making the scheduler placement decisions better for this same reason).
Have you thought about how we could map this pod bounding behavior potentially to a RuntimeClass or kubelet configuration rather expose the knob directly in the end-user pod spec? I am not sure the average end-user would understand
shareBurstableLimits
I see this feature as specific configuration for a specific pod, not as a general configuration that applies to all of the pods running on the node. I'm not sure how it would map to RuntimeClass either.
Maybe a different attribute name would be clearer? Maybe podResourceSharing instead of shareBurstableLimits?
As suggested in the sig-node meeting, I will start by validating the usefulness of this feature with a DaemonSet that directly manipulates the cgroups in parallel with Kubelet.
I will report back once I have some results.
As suggested in the sig-node meeting, I will start by validating the usefulness of this feature with a DaemonSet that directly manipulates the cgroups in parallel with Kubelet.
The DaemonSet can be found here.
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
Hi all,
As an FYI: Enhancements Freeze is now in effect. If you wish to be included in the 1.20 Release, please submit an Exception Request as soon as possible.
As a note, I do not see a corresponding issue for this PR. We require that all KEPs have a milestoned and corresponding issue in the k/enhancements repo along with the following by the Enhancements Freeze deadline (that was Oct 6th):
- The KEP must be merged in an implementable state
- The KEP must have test plans
- The KEP must have graduation criteria
Finally, the format of KEPs has changed. If you could please update and include the missing sections. See for ref https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template
Best, Kirsten 1.20 Enhancements Lead
@vinaykul: GitHub didn't allow me to request PR reviews from the following users: vinaykul.
Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.
In response to this:
/cc
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.
Hi @liorokman,
Would you please open a tracking issue in this repo for your KEP and update its number to match? Thanks!
/hold
This currently isn't in the 1.21 node planning doc: https://docs.google.com/document/d/1U10J0WwgWXkdYrqWGGvO8iH2HKeerQAlygnqgDgWv4E/edit#
@liorokman, are you still pursuing this :) ?
Sorry, not anymore.
Mind if I take a stab at it 🙂?