This repository was archived by the owner on May 6, 2020. It is now read-only.
This repository was archived by the owner on May 6, 2020. It is now read-only.
Add support for managing compute resources #341
Description
Kubernetes supports the notion of CPU resources assigned to a container
spec.containers[].resources.limits.cpu
...
Although requests and limits can only be specified on individual Containers, it is convenient to talk about Pod resource requests and limits. A Pod resource request/limit for a particular resource type is the sum of the resource requests/limits of that type for each Container in the Pod.
...
Limits and requests for CPU resources are measured in cpu units. One cpu, in Kubernetes, is equivalent to:
1 AWS vCPU
1 GCP Core
1 Azure vCore
1 Hyperthread on a bare-metal Intel processor with Hyperthreading
Similarly in docker we have
--cpus | | Number of CPUs
--cpu-period | 0 | Limit CPU CFS (Completely Fair Scheduler) period
--cpu-quota | 0 | Limit CPU CFS (Completely Fair Scheduler) quota
--cpu-rt-period | 0 | Limit CPU real-time period in microseconds
--cpu-rt-runtime | 0 | Limit CPU real-time runtime in microseconds
--cpu-shares, -c | 0 | CPU shares (relative weight)
--cpus | | Number of CPUs
--cpuset-cpus | | CPUs in which to allow execution (0-3, 0,1)
--cpuset-mems | | MEMs in which to allow execution (0-3, 0,1)
Which manifests in the config file as
// LinuxCPU for Linux cgroup 'cpu' resource management
type LinuxCPU struct {
// CPU shares (relative weight (ratio) vs. other cgroups with cpu shares).
Shares *uint64 `json:"shares,omitempty"`
// CPU hardcap limit (in usecs). Allowed cpu time in a given period.
Quota *int64 `json:"quota,omitempty"`
// CPU period to be used for hardcapping (in usecs).
Period *uint64 `json:"period,omitempty"`
// How much time realtime scheduling may use (in usecs).
RealtimeRuntime *int64 `json:"realtimeRuntime,omitempty"`
// CPU period to be used for realtime scheduling (in usecs).
RealtimePeriod *uint64 `json:"realtimePeriod,omitempty"`
// CPUs to use within the cpuset. Default is to use any CPU available.
Cpus string `json:"cpus,omitempty"`
// List of memory nodes in the cpuset. Default is to use any available memory node.
Mems string `json:"mems,omitempty"`
}
The clear containers runtime should support at the very least the --cpus option.
However in the case of runc the CPU's visible to the application is the full set available to the host.
In the case or runc the cpu cgroups are used to actually constrain the process.
The mimic this behavior such that the application seems very similar availability of vCPU's for threading we should
- allocate the number of vCPU == number of physical CPU's on the host
- constrain QEMU to limit the CPU consumption
However on systems with very large number of CPUs, hence adding up to larger memory consumption per container, we can consider limiting the number of vCPU to equal the requests CPU shares, while still applying cgroups.