-
Bug
-
Resolution: Done-Errata
-
Blocker
-
None
-
None
-
None
-
False
-
None
-
False
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
-
One outcome of the investigation of https://issues.redhat.com/browse/THREESCALE-10003 was that OpenShift moved to cgroups-v2 since OCP 4.14 (see OCPSTRAT-696).
System depends on some cgroups v1 files to detect the CPU shares for calculating the appropriate number of Unicorn workers (the value can be overriden by UNICORN_WORKERS and UNICORN_WORKER_MULTIPLIER env vars).
Specifically, the code checks the value of /sys/fs/cgroup/cpu/cpu.shares which is not present when using cgroups-v2. Instead of CPU shares, CPU weight is used.
More information about this change: https://linuxera.org/cpu-memory-management-kubernetes-cgroupsv2/#cpu-bandwidth-configuration-on-the-node
The article also has some links to the kubernetes source code. Particularly, these are interesting:
We probably need to find a better way to detect the amount of available (requested) CPU, independently of the cgroups version used by the cluster.
- relates to
-
THREESCALE-10189 Tracker issue for THREESCALE-10167 in porta (0.11.8)
- Closed
-
THREESCALE-10190 Tracker issue for THREESCALE-10167 in apicast (0.11.8)
- Closed
-
THREESCALE-10187 Apisonator: Improve CPU detection for the listener workers number
- To Develop
- links to
-
RHEA-2023:120589 Red Hat 3scale API Management 2.13.6 Release - Container Images
- mentioned on