Scheduling is based on resources requested, while quota and hard limits refer to
resource limits, which can be set higher than requested resources. The difference
between request and limit determines the level of overcommit; for instance, if a
container is given a memory request of 1Gi and a memory limit of 2Gi, it is
scheduled based on the 1Gi request being available on the node, but could use
up to 2Gi; so it is 200% overcommitted.
If OpenShift Origin administrators would like to control the level of overcommit
and manage container density on nodes, masters can be configured
to override the ratio between request and limit set on developer
containers. In conjunction with a per-project
LimitRange specifying limits and defaults, this adjusts the container
limit and request to achieve the desired level of overcommit.
This requires configuring the
ClusterResourceOverride admission controller in the
master-config.yaml as in the following example (reuse the existing configuration tree
if it exists, or introduce absent elements as needed):
memoryRequestToLimitPercent: 25 (2)
cpuRequestToLimitPercent: 25 (3)
limitCPUToMemoryPercent: 200 (4)
||This is the plug-in name; case matters and anything but an exact match for a plug-in name is ignored.
||(optional, 1-100) If a container memory limit has been specified or defaulted, the memory request is overridden to this percentage of the limit.
||(optional, 1-100) If a container CPU limit has been specified or defaulted, the CPU request is overridden to this percentage of the limit.
||(optional, positive integer) If a container memory limit has been specified or defaulted, the CPU limit is overridden to a percentage of the memory limit, with a 100 percentage scaling 1Gi of RAM to equal 1 CPU core. This is processed prior to overriding CPU request (if configured).
After changing the master configuration, a master restart is required.
Note that these overrides have no effect if no limits have
been set on containers. Create a LimitRange
object with default limits (per individual project, or in the
template) in order to ensure that the overrides apply.
Note also that after overrides, the container limits and requests must still
be validated by any LimitRange objects in the project. It is possible,
for example, for developers to specify a limit close to the minimum
limit, and have the request then be overridden below the minimum limit,
causing the pod to be forbidden. This unfortunate user experience should
be addressed with future work, but for now, configure this capability
and LimitRanges with caution.
When configured, overrides can be disabled per-project (for example,
to allow infrastructure components to be configured independently of
overrides) by editing the project and adding the following annotation: