pid limiting documentation #13006
pid limiting documentation #13006
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
Deploy preview for kubernetes-io-vnext-staging processing. Building with commit 7f3d0ef https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/5c7ff0111aab9b00083d1145 |
k8s-ci-robot
added
language/en
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/milestone 1.14 |
|
@derekwaynecarr: GitHub didn't allow me to request PR reviews from the following users: robertkrawitz. Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
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. |
| {{% capture overview %}} | ||
| {{< feature-state state="beta" >}} | ||
|
|
||
| This page explains how to configure pid limiting with the `kubelet`. |
There was a problem hiding this comment.
"pid (process ID)" the first time. Hopefully nobody's confused, but...
| The `SupportNodePidsLimit` feature gate is *alpha*. | ||
|
|
||
| If enabled, the node allocatable feature is able to reserve a number of pids for | ||
| system components. The `pids` resource is supported when specifying `system-reserved` |
There was a problem hiding this comment.
Resource name is pid, not pids kubernetes/kubernetes#73651 (comment)
There was a problem hiding this comment.
@RobertKrawitz i suspect this feature is related to #12932 correct ?
if so @derekwaynecarr would you mind cross linking the page here please ?
There was a problem hiding this comment.
Yes, this is the documentation for #12932
| @@ -250,4 +250,7 @@ for `kube-reserved` and `system-reserved`. | |||
| As of Kubernetes version 1.8, the `storage` key name was changed to `ephemeral-storage` | |||
| for the alpha release. | |||
|
|
|||
| As of Kubernetes version 1.14, the `kubelet` supports specifying `pids` as a resource | |||
|
|
||
| This page explains how to configure pid limiting with the `kubelet`. | ||
|
|
||
| Pids are a fundamental resource on Linux hosts. It is trivial to hit the task |
There was a problem hiding this comment.
Should we suggest ways to make more process IDs available?
Eg, on Linux set kernel.pid_max via sysctl, modern kernels support 222-1 process IDs.
There was a problem hiding this comment.
Simply raising the process limit isn't necessarily the right answer either -- it probably means more time spent doing accounting, scanning the process table, etc. Not to mention the resources that are consumed by that many processes.
Before we go into that, I think we want to decide what level of discussion we want here.
There was a problem hiding this comment.
The aim I'd have here is to let a less experienced administrator realize that:
- they can have kubelet & their container runtime limit how many pids are available to a pod
- they can raise the system-wide pid ceiling from the default, which is typically quite low
and that making both changes together can work well.
(A high pid ceiling, system wide, helps avoid collisions when IDs are reused, and a low limit per pod protects the other pods and the rest of the system).
There was a problem hiding this comment.
The system-wide pid-max is typically 32K (bigger on machines with more than 32 CPU threads available). Whether that's too small on any given system depends, but I'm not convinced it would be a good idea for an inexperienced admin to simply raise the process limit without an understanding of the workload being run and analyzing the entire system's capacity.
The per-pod limit only protects the system to the extent that the number of pods is limited.
The node limit has nothing to do with collisions; it's simply a hard upper limit on the number of simultaneous tasks in existence on a node.
|
looks good to me after you address @RobertKrawitz comments |
| - derekwaynecarr | ||
| - dashpole | ||
| - RobertKrawitz | ||
| title: Pid Limiting |
There was a problem hiding this comment.
| title: Pid Limiting | |
| title: Limit processes available to a pod |
There was a problem hiding this comment.
That's not what this is; the functionality of limiting processes available to a pod is pod-max-pids. This is about limiting the number of pids available to all pods collectively (specifically, reserving a certain number of pids for system and/or kubelet use).
There was a problem hiding this comment.
If enabled, the
kubeletargument forpod-max-pidswill write out the configured
This does look like limiting the processes available to a pod.
@derekwaynecarr - how would you feel about having two smaller pages, specific to the tasks they're explaining, and then hyperlinking between the two?
- one page about making sure a pod doesn't use too many process IDs
- another page that describes how to ensure that there are process IDs free for kubelet / the rest of the OS?
There was a problem hiding this comment.
@RobertKrawitz reading the info as it is now i got into the same thinking like @sftim .
However your explanation in the comment does makes so would you or @derekwaynecarr mind adding that info in ?
I personally would like to see more detailed info rather than high level as not everyone knows the difference as you mentioned
jimangel
force-pushed
the
dev-1.14
branch
2 times, most recently
from
2534806
to
ead0a28
Compare
|
1.14 was released today and is now |
|
Cleaning things up post 1.14 release. Closing this PR on dev-1.14 due to no action - feel free to reopen against master! Thanks! |
Pid limiting documentation for 1.14.