-
Notifications
You must be signed in to change notification settings - Fork 14k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify CPU and memory limit enforcement differences #46222
base: main
Are you sure you want to change the base?
Conversation
Clairify the container runtime and kubelet do not enforece memory limits, the kernel does. Also clarify that workloads won't always be OOM killed, and more clearly spell out the differences between memory and CPU limits Signed-off-by: Peter Hunt <pehunt@redhat.com>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
@kubernetes/sig-node-pr-reviews FYI |
`CPU` limits are enforced by CPU throttling. When a container approaches | ||
its `CPU` limit, the kernel will restrict access to the CPU corresponding to the | ||
container's limit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cpu
(lower case) please @haircommander; the original is wrong, but we should fix it. In the actual API, it's cpu
.
`memory` limits are enforced by the kernel with OOM (out of memory) kills. When | ||
a pod uses more than its `memory` limit, the kernel may terminate it. However, | ||
if there is available memory on the node, the kernel may choose not to terminate | ||
the offending pod. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
What happens to memory allocation attempts -
sbrk()
and friends - that would assign memory above the limit, if they were to succeed? Ideally, let's be clear about where the enforcement does and doesn't happen. -
The container runtime or kernel might apply a higher limit than you request. For example, if you specify a limit of 2097159 bytes (a shade over 2MiB), the kernel is likely to round things up to a whole page size. That's if your container runtime even lets you request a limit that small!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great update, thank you!
its `CPU` limit, the kernel will restrict access to the CPU corresponding to the | ||
container's limit. | ||
|
||
`memory` limits are enforced by the kernel with OOM (out of memory) kills. When |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`memory` limits are enforced by the kernel with OOM (out of memory) kills. When | |
`memory` limits are enforced by the kernel with out of memory (OOM) kills. When |
Limits can be implemented either reactively (the system intervenes once it sees a violation) | ||
or by enforcement (the system prevents the container from ever exceeding the limit). Different | ||
runtimes can have different ways to implement the same restrictions. | ||
`CPU` limits are enforced by CPU throttling. When a container approaches |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we link a follow-up resource on how CPU throttling works in linux?
@haircommander Whenever you get a chance, please review the feedback from the reviewers and respond to them accordingly. Thanks! |
Clairify the container runtime and kubelet do not enforece memory limits, the kernel does. Also clarify that workloads won't always be OOM killed, and more clearly spell out the differences between memory and CPU limits