透过现象看本质——聊一聊docker的硬件资源控制与验证
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了透过现象看本质——聊一聊docker的硬件资源控制与验证相关的知识，希望对你有一定的参考价值。
透过现象看本质——聊一聊docker的硬件资源控制与验证前言
? 前面两篇文章主要介绍了有关docker的基础概念、安装、以及对镜像容器的相关操作。重点在于命令的含义以及常用的一些命令的可选项的含义的理解，本文在此基础上来聊一聊基于硬件层面是上有关docker的资源（物理）控制。
一、docker管理资源机制——Control group
? Control group 是Linux内核提供的一种限制所使用物理资源的机制，这些资源主要是CPU、内存、blkio，而Control group简称为Cgroup，我们可以在下面的目录中查看：
[root@docker cgroup]# ls
blkio cpuacct cpuset freezer memory net_cls,net_prio perf_event systemd
cpu cpu,cpuacct devices hugetlb net_cls net_prio pids
? 在该目录下我们可以看到有blkio、cpuset、memory、cpu等与物理硬件资源对应的文件以及目录。下面就基于上述的三个方面来聊一聊docker是如何使用该机制对这些资源进行管理的。
二、对CPU的控制
? 对CPU的控制有下面几种方式：
- 限制CPU的使用率；
- 多任务按比例分配CPU；
- 限制CPU内核（核心数）使用；
2.1基于使用率限制CPU
我们可以在文件中查看默认的限制设置，我们先运行一个容器（两种方式，我们使用run的命令来快速运行一个容器）：
#检查本地是否有镜像或容器存在
[root@docker ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
[root@docker ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
#运行一个容器
[root@docker ~]# docker run -itd --name test centos:7 /bin/bash
Unable to find image ‘centos:7‘ locally
7: Pulling from library/centos
ab5ef0e58194: Pull complete
Digest: sha256:4a701376d03f6b39b8c2a8f4a8e499441b0d567f9ab9d58e4991de4472fb813c
Status: Downloaded newer image for centos:7
ff84f35a0d6fdc77d292f7168546848385ab382f3dc1486077933e944c4424b9
[root@docker ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ff84f35a0d6f centos:7 "/bin/bash" About a minute ago Up About a minute test
我们进入docker目录下的容器编号目录中，查看cpu.cfs_quota_us文件，其中的内容默认为-1（我们可以对此更改）
[root@docker ~]# cd /sys/fs/cgroup/cpu/docker/ff84f35a0d6fdc77d292f7168546848385ab382f3dc1486077933e944c4424b9/
[root@docker ff84f35a0d6fdc77d292f7168546848385ab382f3dc1486077933e944c4424b9]# ls
cgroup.clone_children cpuacct.stat cpu.cfs_period_us cpu.rt_runtime_us notify_on_release
cgroup.event_control cpuacct.usage cpu.cfs_quota_us cpu.shares tasks
cgroup.procs cpuacct.usage_percpu cpu.rt_period_us cpu.stat
[root@docker ff84f35a0d6fdc77d292f7168546848385ab382f3dc1486077933e944c4424b9]# cat cpu.cfs_quota_us
-1
? 果然，默认的配额值为-1，这就表示默认情况下是不对CPU资源进行控制的，显然这样在使用容器的过程中非常容易出现问题，例如一台真实服务器运行着各种各样的数量非常多的容器，而其中一台容器占据了接近90%的CPU使用率，那么剩下来的如此多的容器只能在剩余的10%中获取使用，这很容易引发业务故障，因此我们需要对CPU包括随后的内存及文件IO流进行优化处理的配置。
? 首先，本小节是对CPU的使用率进行的控制，那么下面就来看看怎么配置的吧。
我们可以直接进入这个文件进行设置，那么怎么设置呢？
这就需要说明一下了，CPU的百分比是以1000位单位的，因此总额为100000，即10万，那么我们写入20000，则使用率为20%。除了直接改（echo也行）也可以在命令行中进行设置：
[root@docker ~]# docker run -itd --name test1 --cpu-quota 20000 centos:7 /bin/bash
31f9d00fca956d315736dad8a1f2e4c01128d44370af4b37c10298fd2c6a3ee6
[root@docker ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
31f9d00fca95 centos:7 "/bin/bash" 14 seconds ago Up 12 seconds test1
ff84f35a0d6f centos:7 "/bin/bash" 14 minutes ago Up 14 minutes test
那么我们怎么验证或者说测试这个使用率占比最高是在20%呢？
我们可以进入这个容器中执行操作，使得CPU满载，另外开一个terminal使用top命令查看CPU使用情况即可。
#下载bc工具，一种任意精度的计算器语言，可以理解为用于精确计算的
[root@31f9d00fca95 /]# yum install bc -y
#我们使用该工具来计算圆周率
[root@31f9d00fca95 /]# echo "scale=5000; 4*a(1)" | bc -l -q
#说明:其中a是bc的一个内置函数，代表arctan（三角函数哈~），由于tan（pi/4）=1，所以4*arctan（1）=pi 【pi就是π】，5000表示计算精确到小数点后面的5000位，-l表示使用标准数学库，-q表示 不在界面中输出。
? 为了演示整个效果我在另外一个终端使用top命令查看，可以发现整个CPU使用率在20%左右，会有所上浮但是不会过分离谱，计算完成后将会释放资源的。截取两张图作为验证结果：
2.2基于比例分配CPU
? 对于上面基于使用率分配给容器的方式可能只适合于少量的容器情况下，容器数量多的时候并不好计算以及设置使用率，这时我们可以通过按比例分配的方式（通过--cpu-share选项配置），这样既方便又灵活。具体看下面的实例演示：
#创建两个容器，并且使得两个容器的CPU比例分配为1:2
[root@docker ~]# docker run -itd --name c1 --cpu-shares 512 centos:7 /bin/bash
6ec8bb5d2fde0cba2ec436484ec037f694c3eaff744a90fd08173205c8121956
[root@docker ~]# docker run -itd --name c2 --cpu-shares 1024 centos:7 /bin/bash
03a587d09afb591bfaaff79a7c998872b85f4375f9ebd48e9aee9c220ed53f98
#查看容器
[root@docker ~]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
03a587d09afb centos:7 "/bin/bash" About a minute ago Up About a minute c2
6ec8bb5d2fde centos:7 "/bin/bash" 2 minutes ago Up 2 minutes c1
31f9d00fca95 centos:7 "/bin/bash" 29 minutes ago Up 29 minutes test1
ff84f35a0d6f centos:7 "/bin/bash" 44 minutes ago Up 44 minutes 那么怎么进行测试验证呢？
我们开两个终端用于进入容器测试，另外一个终端使用docker stats命令查看验证。
#进入两个容器都进行下面的操作，我们以其中一个进行演示
[root@docker ~]# docker exec -it 03a587d09afb /bin/bash
[root@03a587d09afb /]# yum install -y epel-release
[root@03a587d09afb /]# yum install stress -y
#stress是压测工具，依赖于上面的epel-release开始在两个终端上使用stress命令压测
[root@6ec8bb5d2fde /]# stress -c 4
stress: info: [98] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
^C#验证到结果后就退出吧，因为CPU很累的
[root@03a587d09afb /]# stress -c 4
stress: info: [97] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
^C#验证到结果后就退出吧，因为CPU很累的
结果：
当然这个是会动态变化的，不一定完全是1:2的关系但是一定是接近这个比例的哈~~
2.3基于CPU内核使用限制
? 在docker中可以使用--cpuset-cpus选项来使某些程序独享CPU的内核，以便提高其处理速度。如果我们的CPU核心数为4那么对应的编号为0,1,2,3，可以通过top命令来查看，按下数字1后就可以查看CPU编号以及对应信息了。
具体的控制设置如下：
[root@docker ~]# docker run -itd --name test2 --cpuset-cpus 1,3 centos:7 /bin/bash
116606ef1e11b0afa09da67b2782c1cc0d042eb026cbfe113d7dac11ae818dcc
#即基于cpuset-cpus进行设置使用第二种方式的测试方法，基于top命令查看验证，结果如下图所示：
? 当然，基于CPU的限制控制也可以三种方式结合使用，本文主要是为了讲解这三种方式。
三、对内存的控制
? 内存使用相对于CPU而言比较简单了，通过-m参数进行设置。
实例演示：
[root@docker ~]# docker run -itd --name demo -m 512m centos:7 /bin/bash
c69071b6dbc302c5f4d34782a0b7eb663e40cd5f847f4aac45a375c3d4e817d9在另一个终端上进行查看：docker stats
结果如下图：
限制的大小为512m，就表示只能使用这么大的内存
四、对blkio的控制
? 对应blkio的设置，主要是对于在一台服务器上进行容器的混合部署的场景，就会出现同时有多个程序写入磁盘数据的情况，此时可以通过--device-write-iops选项来限制写入的iops，相应的有--device-read-bps选项可以限制读取的iops。但是这种方法只能针对blkio限制的是设备，而不是分区。罗列一下吧：
--device-read-bps：限制读某个设备的bps（数据量）使用多
--device-write-iops：限制写入某个设备的iops（次数）
实例演示：
[root@docker ~]# docker run -itd --name test4 --device-write-bps /dev/sda:30m centos:7 /bin/bash
16004244b632b8ada5faefdca57e321664e89fe9472dd6195f8eb7f07d7602ee
表示对sda磁盘设备限制写入的带宽为30m，需要进行高并发的操作，可以进行大量的写入操作即可，这里就不测试验证的演示了
五、总结
? 本文主要讲述的是docker的资源控制的设置（基于CPU、内存、IO）以及对应的测试验证方法。
以上是关于透过现象看本质——聊一聊docker的硬件资源控制与验证的主要内容，如果未能解决你的问题，请参考以下文章