Shulou(Shulou.com)06/02 Report--

This article mainly explains "the use of cpu by docker and its usage in kubernetes". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "docker's use of cpu and its use in kubernetes".

Docker's use of CPU

The main parameters that docker can configure for CPU are as follows:

-- cpu-shares CPU shares (relative weight)-- cpu-period Limit CPU CFS (Completely Fair Scheduler) period-- cpu-quota Limit CPU CFS (Completely Fair Scheduler) quota-- cpuset-cpus CPUs in which to allow execution (0-3,0L1)

These parameters are mainly configured in the corresponding cgroup of the container, and the actual CPU is controlled by cgroup. The corresponding path can be found in cgroup.

Cpuset-cpus [root@node-156 ~] # cat / sys/fs/cgroup/cpuset/docker/12c35c978d926902c3e5f1235b89a07e69d484402ff8890f06d0944cc17f8a71/cpuset.cpus0-31

Cpuset is mainly used to specify the CPU number under which the container is running, which is what we call binding kernel.

C pushare [root @ node-156 ~] # cat / sys/fs/cgroup/cpu/docker/12c35c978d926902c3e5f1235b89a07e69d484402ff8890f06d0944cc17f8a71/cpu.shares1024

Cpushare is mainly used for scheduling weights in cfs. Generally speaking, under the same conditions, the higher the cpusha value, the more time slices will be allocated.

The proportion of CPU time slices of the two containers is not a strict weight ratio, because the two containers may have different requirements for CPU time slices.

Cpu-period and cpu-quota [root@node-156 ~] # cat / sys/fs/cgroup/cpu/docker/12c35c978d926902c3e5f1235b89a07e69d484402ff8890f06d0944cc17f8a71/cpu.cfs_quota_us-1 [root@node-156 ~] # cat / sys/fs/cgroup/cpu/docker/12c35c978d926902c3e5f1235b89a07e69d484402ff8890f06d0944cc17f8a71/cpu.cfs_period_us 100000

The values cfs_quota_us and cfs_period_us are used together, and the ratio of the two, cfs_quota_us/cfs_period_us, represents the actual number of long CPU cores available for the container.

For example, cfs_quota_us=50000,cfs_period_us=100000, the ratio is 0. 5, which means that the container can use 0. 5 cpu. The granularity of this kind of control is finer, and it can be as low as 0.01core when using systemd in cgroup.

If cfs_quota_us is-1, there is no restriction on the container's use of CPU.

Advantages and disadvantages of nuclear binding

Previously, we mainly used cpuset, that is, by binding the core. This method strictly ensures the true number of cores of CPU that the container can use. And through scheduling, other containers do not bind these CPU, so that the container can enjoy these cpu exclusively. This means that the maximum number of CPU used by the container and the number of minimum consumed CPU are these cores.

This method has high security and ensures the efficiency of the container, but it also has many disadvantages:

Inflexible

Resource utilization is low because the container may claim to use multiple CPU, but the actual utilization is very low

Under NUMA architecture, performance may be degraded if CPU affinity is not considered.

Use of CPU in kubernetes

Kubernetes can set two values for the container:

Spec.containers [] .resources.limits.cpuspec.containers [] .resources.requests.cpu

Limits is mainly used to declare the maximum number of CPU cores used. By setting up cfs_quota_us and cfs_period_us. For example, limits.cpu=3, then cfs_quota_us=300000.

The cfs_period_us value generally uses the default value of 100000

Request is mainly used to declare the minimum number of CPU cores. On the one hand, it is reflected in setting cpushare. For example, request.cpu=3, then cpushare=1024*3=3072.

The other is to provide scheduling for use.

When you create a Pod, the Kubernetes scheduler selects a node for the Pod. Each node has the maximum capacity for each resource type: the amount of CPU and memory that can be provided to the Pods. The scheduler ensures that for each resource type, the sum of resource requests for the scheduled container is less than the capacity of the node. Although the actual memory or CPU resource usage on the node is very low, the scheduler still refuses to place Pod on the node if the capacity check fails.

The amount allocated by the computing node CPU is obtained by calculating the request sum of all containers.

You can refer to Managing Compute Resources for Containers

Benefits of kubernetes for CPU use

More flexible, finer-grained control. The limit of CPU is not only at the level of CPU core, but even up to 0.01core.

CPU reuse. After binding the kernel, the container cannot use other CPU, and the CPU bound by the container itself cannot be used by other containers. The minimum and maximum resource usage are all these cores. The kubernetes approach enables all CPU to become a CPU pool, which is provided to CPU.

Controllable and reliable "oversold"

Best-effort task support. It can make full use of idle CPU resources and make best-effort tasks get maximum resource support. At the same time, when resources are tight, you can give priority to killing best-effort to ensure the use of resources in Guaranteed containers. Please refer to Resource Quality of Service in Kubernetes.

Thank you for your reading. the above is the content of "the use of cpu by docker and its usage in kubernetes". After the study of this article, I believe you have a deeper understanding of the use of cpu by docker and its usage in kubernetes, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.