You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Identify the tests within the sonobuoy testsuite that test for cgroup resource constraints.
Verify whether either kubelet or crio already set resource limits, since there are no failing sonobuoy tests regarding cgroup resource limits in the default testset.
The text was updated successfully, but these errors were encountered:
Verify whether either kubelet or crio already set resource limits, since there are no failing sonobuoy tests regarding cgroup resource limits in the default testset.
Not sure if this is exactly what you were talking about, but crio does include a global default pid_limit in crio.conf.
I noticed it today, apparently it's kind of low: cri-o/cri-o#1921
The spec implies that the runtime is reponsible for setting the cgroup limits.
If this is the case - then why are there no failing tests, because currently lxcri
only set's very of them?
The CgroupPath is part of the OCI spec and is passed to the runtime, and if I'm not mistaken the parent cgroup path already exists. This leads me to the conclusion that either the limits are already set by cri-o or kubelet on the parent cgroup,
or there are no tests (within the default testset ) that check that the limits actually work.
Cgroup2 support in the OCI spec is still in progress and I want to make sure that the limits are correctly applied and don't break anything.
But maybe we can just enable the limits and add a switch to manually disable them --cgroup-limits ? Similar to
--cgroup-devices allow only devices permitted by container spec (default: true) [$LXCRI_CGROUP_DEVICES]
Implement resource limits for
cgroup2
https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md#control-groups
The text was updated successfully, but these errors were encountered: