KEP-6063: Update minimum per-pod PID limit from 1024 to 128

[BhargaviGudi]

Summary

Lowers the minimum allowed value for spec.resources.limits.pid from 1024 to 128, based on
empirical PID usage measurements on an OpenShift cluster.

KEP: #6064
Discussion regrading minimum PID limit: #6064 (comment)

Justification

Created a multi-container pod (multi-container-pid-test in namespace pid-measure-test) with 7 containers: 3× busybox, nginx, alpine, redis, and curl. The pod was configured with exec liveness/readiness probes on all containers and PreStop hooks that spawn background processes. All seven containers ran successfully.

Total PIDs used by the pod were measured from the pod cgroup on the worker node:

PID Usage Testing Results

Tested multi-container pods with exec probes and PreStop hooks on OpenShift cluster.

Test Configuration

• multi-container-pid-test: 7 containers with exec liveness/readiness probes + PreStop hooks
• baseline-multi-container: Same 7 containers, no probes (baseline)
• intensive-exec-probes: Single container with aggressive exec probes (5s intervals)

Results (cgroup measurements)

Pod Configuration	Containers	pids.current	pids.peak
Multi-container + exec probes	7	36	47
Baseline (no probes)	7	26	30
Intensive exec probes	1	12	20

Exec Probe/Hook Overhead

• Baseline: 30 PIDs peak
• With exec probes/hooks: 47 PIDs peak
• Overhead: ~17 PIDs

Pod-level cgroup (authoritative):

  pids.current: 36
  pids.peak: 47
  pids.max: 4096

A minimum of 128 provides adequate headroom: ~2.7× over the observed maximum (47 PIDs peak) for a complex multi-container pod with exec probes and PreStop hooks, and ~5× for baseline multi-container workloads (25-30 PIDs). This is sufficient for any standard workload while still allowing meaningful restriction of PID-intensive or untrusted processes.

[kubernetes-prow]

Hi @BhargaviGudi. 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.

Details

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-sigs/prow repository.

[SergeyKanzhelev]

with 7 containers: 3× busybox (sleep), nginx, alpine (sleep), redis, and curl (sleep).

Any exec probes or exec pre-stop hooks? exec into container takes like surprisingly a lot of PIDs.

[BhargaviGudi]

with 7 containers: 3× busybox (sleep), nginx, alpine (sleep), redis, and curl (sleep).

Any exec probes or exec pre-stop hooks? exec into container takes like surprisingly a lot of PIDs.

Tested with exec probes and PreStop hooks - added details to description.
Peak usage with 7 containers + exec probes + hooks: 47 PIDs (2.7× below 128 minimum).
Exec overhead: ~17 PIDs compared to baseline.

[SergeyKanzhelev]

Exec overhead: ~17 PIDs compared to baseline.

17 is not divisible by 7. Was it perhaps 3 PIDs per probe as an absolute worst case than? If so, 7 containers x 2 probe types (readiness and liveness) x 3 processes per probe = 42. This is still lower than 100, so sounds good. Thank you for checking.

/lgtm
/assign @mrunalp

[BhargaviGudi]

17 is not divisible by 7. Was it perhaps 3 PIDs per probe as an absolute worst case than? If so, 7 containers x 2 probe types (readiness and liveness) x 3 processes per probe = 42. This is still lower than 100, so sounds good. Thank you for checking.

The 17 is the measured overhead (47 peak - 30 baseline), not a per-container calculation.
I ran additional testing with 7 identical containers (all busybox), each with 2 exec probes (liveness + readiness):
Per-container: Each has 5 PIDs
Pod total (cgroup):

• pids.current: 14 PIDs (steady state)
• pids.peak: 32 PIDs (when probes execute)

Analysis:

• Each container: ~2 PIDs base (sleep process + container runtime)
• During probe execution: adds ~3-4 PIDs per probe
• 7 containers × 2 probes × ~2 PIDs per probe = ~28 PIDs
• Actual peak: 32 PIDs - Very close! - lower than 100

[SergeyKanzhelev]

yep, we are on the same page.

[BhargaviGudi]

/ok-to-test

[kubernetes-prow]

@BhargaviGudi: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

Details

In response to this:

/ok-to-test

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-sigs/prow repository.

[ngopalak-redhat]

/ok-to-test

[BhargaviGudi]

@haircommander @kannon92 @mrunalp Could you please help me to review this PR? Thanks

[haircommander]

/lgtm

[BhargaviGudi]

@mrunalp Could you please help to review this PR? Thanks

[BhargaviGudi]

The implementation PR (kubernetes/kubernetes#139277) has already been updated to use 128 as the minimum PID limit — all constants, validation, comments, and test cases reflect this change.

[harche]

Verified against the implementation: the new bounds match both enforcement points, API validation (https://github.com/kubernetes/kubernetes/blob/f050421a6693073df402fde0cc9f3568087c2d1e/pkg/apis/core/validation/validation.go#L8279-L8280) and kubelet admission (https://github.com/kubernetes/kubernetes/blob/f050421a6693073df402fde0cc9f3568087c2d1e/pkg/kubelet/lifecycle/features_linux.go#L50-L51), and all five occurrences of 1024 in the doc are covered.

One sequencing note: this overlaps with #6258, both PRs delete the same Valid Values intro line and several lines touched here get the pid to pids rename there. Whichever merges second needs a rebase, and if this one goes second its reapplied lines should pick up the pids spelling.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: BhargaviGudi, mrunalp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• keps/sig-node/OWNERS [mrunalp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[harche]

/lgtm