Docker资源限制

Docker资源限制
在使用Docker运行容器时，一台主机上可能会运行几百个容器，这些容器虽然互相隔离，但是底层却使用着相同的CPU、内存和磁盘资源。如果不对容器使用的资源进行限制，那么容器之间会互相影响，小的来说会导致容器资源使用不公平;大的来说，可能会导致主机和集群资源耗尽，服务完全不可用。

CPU和内存的资源限制已经是比较成熟和易用，能够满足大部分用户的需求。磁盘限制也是不错的，虽然现在无法动态地限制容量，但是限制磁盘读写速度也能应对很多场景。

至于网络，Docker现在并没有给出网络限制的方案，也不会在可见的未来做这件事情，因为目前网络是通过插件来实现的，和容器本身的功能相对独立，不是很容易实现，扩展性也很差。

资源限制一方面可以让我们为容器(应用）设置合理的CPU、内存等资源，方便管理;另外一方面也能有效地预防恶意的攻击和异常，对容器来说是非常重要的功能。如果你需要在生产环境使用容器，请务必要花时间去做这件事情。

1、系统压力测试
Stress是一个linux下的压力测试工具，专门为那些想要测试自己的系统，完全高负荷和监督这些设备运行的用户。

安装
yum install stress -y
yum install htop -y

测试场景
测试CPU负荷

stress -c 4(根据自身机器来设定)

没有设置之前的:

设置之后的:

内存测试

stress -i 4 --vm 10 --vm-bytes 1.5G(或者500M) --vm-hang 100 --timeout 100s

新增4个io进程,10个内存分配进程,每次分配大小1.5G或者500M,分配后不释放,测试100s

结果:

磁盘I/O测试

stress -d 1 --hdd-bytes 3G

新增1个写进程,每次写3G文件夹

硬盘测试(不删除)(慎用)

stress -i 1 -d 10 --hdd-bytes 3G --hdd-noclean

新增1个I/O进程,10个写进程,每次写入3G文件夹,且不清除,会逐步将硬盘耗尽

Stress各主用参数说明

• -表示后接一个中划线,–表示后接2个中划线，均可用于stress后接参数，不同表达方式-?
• –help显示帮助信息
• –version显示软件版本信息
• -t secs:
• –timeout secs指定运行多少秒
• –backoff usecs等待usecs微秒后才开始运行
• -c forks:
• –cpu forks产生多个处理sqrt()函数的CPU进程
• -m forks
• –vm forks:产生多个处理malloc()内存分配函数的进程，后接进程数量
• -i forks
• –io forks:产生多个处理sync()函数的磁盘I/O进程
• –vm-bytes bytes:指定内存的byte数，默认值是1
• –vm-hang:表示malloc分配的内存多少时间后在free()释放掉-d :
• –hdd:写进程，写入固定大小，通过mkstemp()函数写入当前目录–hdd-bytes bytes:指定写的byte数，默认1G
• –hdd-bytes bytes:指定写的bvy数，1G
• –hdd-noclean:不要将写入机Laso数据的件pnlink，则写入的文件不删除，会保留在硬盘空间。

2 Cpu资源限制cpu资源

主机上的进程会通过时间分片机制使用CPU，CPU的量化单位是频率，也就是每秒钟能执行的运算次数。为容器限制CPU资源并不能改变CPU的运行频率，而是改变每个容器能使用的CPU时间片。理想状态下，CPU应该一直处于运算状态(并且进程需要的计算量不会超过CPU的处理能力)。

1、限制Cpu share

什么是cpu share?

docker允许用户为每个容器设置一个数字，代表容器的CPU share，默认情况下每个容器的share是1024。这个share 是相对的，本身并不能代表任何确定的意义。当主机上有多个容器运行时，每个容器占用的CPU时间比例为它的 share在总额中的比例。docker会根据主机上运行的容器和进程动态调整每个容器使用CPU的时间比例。
例:
如果主机上有两个一直使用CPU的容器(为了简化理解，不考虑主机上其他进程)，其CPU share都是1024,那么两个容器CPU使用率都是50%;如果把其中一个容器的share设置为512，那么两者CPU的使用率分别为679%和33%;如果删除share为1024的容器，剩下来容器的CPU使用率将会是100%。

好处:
能保证CPU尽可能处于运行状态，充分利用CPU资源，而且保证所有容器的相对公平;

缺点:
无法指定容器使用CPU的确定值。设置CPU share的参数:
-c --cpu-shares，它的值是一个整数。
运行stress容器,启动4个进程来产生计算压力:

docker pull progrium/stress

docker rum --rm -it progrium/stress --cpu 2

默认情况下,容器的CPU share为1024,所有者两个容器的cpu使用率也高大致为2:1

docker run --rm -it -c 512  progrium/stress --cpu 2

2、限制Cpu核数

限制容器能使用的CPU核数

• -c --cpu-shares参数只能限制容器使用CPU的比例，或者说优先级，无法确定地限制容器使用CPU的具体核数;从1.13版本之后，docker提供了–cpus参数可以限定容器能使用的CPU核数。这个功能可以让我们更精确地设置容器CPU使用量，是一种更容易理解也因此更常用的手段。
• –cpus后面跟着一个浮点数，代表容曼多使用的核数，可以精确到小数点二位，也就是说容器最小可以使用0.01核CPU。
• 限制容器只能使用0.5核数CPU:

docker run --rm -it --cpus 2 progrium/stress --cpu 4

如果多个容器都设置了–cpus，并且它们之和超过主机的CPU核数，并不会导致容器失败或者退出，这些容器之间会竞争使用CPU，具体分配的CPU数量取决于主机运行情况和容器的CPU share值。也就是说–cpus只能保证在CPU资源充足的情况下容器最多能使用的CPU数，docker并不能保证在任何情况下容器都能使用这么多的CPU(因为这根本是不可能的)。

3.CPU绑定
限制容器运行在某些CPU核
注·
般并不推荐在生产中样docker允许调度时候
运行哪CPU 上。
运行在哪些上并不是很好做法因为它需要现知道主机上有多少
而且非常不灵活
除非有特需求般并不推荐在生产中样
假主机上有个核可以通过s参只运行在前上

docker run --rm -it --cpuset-cpus=0 progrium/stress --cpu 2

结果:

--cpuset-cpus 参数可以和 -c --cpu-shares一起使用,限制容器只能运行在某些cpu核上,并且配置了使用率

3 Mem资源限制

Docker默认没有对容器内存进行限制，容器可以使用主机提供的所有内存。不限制内存带来的问题:

这是非常危险的事情，如果某个容器运行了恶意的内存消耗软件，或者代码有内存泄露，很可能会导致主机内存耗尽，因此导致服务不可用。可以为每个容器设置内存使用的上限，一旦超过这个上限，容器会被杀死，而不是耗尽主机的内存。

限制内存带来的问题:
限制内存上限虽然能保护主机，但是也可能会伤害到容器里的服务。如果为服务设置的内存上限太小，会导致服务还在正常工作的时候就被OOM杀死;如果设置的过大，会因为调度器算法浪费内存。

合理做法:
1.为应用做内存压力测试，理解正常业务需求下使用的内存情况，然后才能进入生产环境使用

2.一定要限制容器的内存使用上限，尽量保证主机的资源充足，一旦通过监控发现资源不足，就进行扩容或者对容器进行迁移如果可以(内存资源充足的情况)

3.尽量不要使用swap,swap 的使用会导致内存计算复杂，对调度器非常不友好Docker限制容器内存使用量:

docker启动参数中，和内存限制有关的包括(参数的值一般是内存大小，也就是一个正数，后面跟着内存单位b、k、m、g，分别对应bytes、KB、MB、和GB):

• -m --memory: 容器能使用的最大内存大小，最小值为4m
• –memory-swap : 容器能够使用的swap 大小
• –memory-swap 必须在–memory也配置的情况下才能有用。
• 如果–memory-swap的值大于–memory，那么容器能使用的总内存(内存+
  swap)为–memory-swap的值，能使用的 skap值为–mernory swap 减去–memory的值
• 如果–memory-swap为0，或者和-memory的值相同，那么容器能使用两倍于内存的swap大小，如果–memory对应的值是200M，那么容骂可以使用400M
  swap
• 如果–memory-swap的值为-1，那么不限制swap的使用，也就是说主机有多少swap，容器都可以使用
• –memory-swappiness: 默认情况下，主机可以把容器使用的匿名页(anonymous page) swap出来，你可以设置一个0-100之间的值，代表允许swap 出来的比例
• –memory-reservation:设置一个内存使用的soft limit，如果docker 发现主机内存不足，会执行OOM操作。这个值必须小于–memory设置的值
• –kernel-memory: 容器能够使用的 kernel memory大小，最小值为4m。
• –oom-kIll-disable:是否运行oOM的时候杀死容器、只有没置了-m，才可以把这个选项设置为false，否则容器会耗尽主机内存，而且导致主机应用被杀死

如果限制容器的内存使用为64M，在申请64M资源的情况下，容器运行正常(如果主机上内存非常紧张，并不-定能保证这一点)∶

docker run --rm -it -m  64m progrium/stress --vm 1 --vm-bytes 64M --vm-hang 0

docker run --rm -it -m  64m progrium/stress --vm 1 --vm-bytes 200M --vm-hang 0

stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogvm worker 1 [6] forked
stress: dbug: [6] allocating 209715200 bytes ...
stress: dbug: [6] touching bytes in strides of 4096 bytes ...
stress: FAIL: [1] (416) <-- worker 6 got signal 9 *****
stress: WARN: [1] (418) now reaping child worker processes
stress: FAIL: [1] (422) kill error: No such process
stress: FAIL: [1] (452) failed run completed in 0s

192<200所以直接kill掉了

四 IO资源限制【扩展】

对于磁盘来说，考量的参数是容量和读写速度，因此对容器的磁盘限制也应该从这两个维度出发。目前docker支持对磁盘的读写速度进行限制，但是并没有方法能限制容器能使用的磁盘容量(一旦磁盘mount到容器里，容器就能够使用磁盘的所有容量)。

限制磁盘的读写速率

docker 允许你直接限制磁盘的读写速率，对应的参数有:

• –device-read-bps:磁盘每秒最多可以读多少比特(bytes)
• –device-write-bps:磁盘每秒最多可以写多少比特(bytes)
• 上面两个参数的值都是磁盘以及对应的速率，限制limit为正整数，单位可以是kb、mb和 gb。比如可以把设备的读速率限制在1 mb

比如可以把设备读速率限制在1mb:

docker run -it --device /dev/sda:/dev/sda --device-read-bps /dev/sda:1mb nginx bash

cat /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device (在容器里面敲)
8:0 1048576

dd iflag=direct,nonblock if=/dev/sda of=/dev/null bs=5M count=10

10+0 records in
10+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 50.0741 s, 1.0 MB/s

从磁盘中读取50m话费了50s左右,说明磁盘速率限制起了作用
另外另个参数也可以限制磁盘读写频率(每秒能执行多少次读写操作):
–device-read-iops: 磁盘每秒最多可以执行多少IO读操作
–device-write-iops: 磁盘每秒最多可以执行多少IO写操作
上面两个参数的值都是磁盘以及对应的IO上限

比如可以让磁盘每秒钟最多读100次:

docker run -it --device /dev/sda:/dev/sda --device-read-iops /dev/sda:100 nginx bash

dd iflag=direct,nonblock if=/dev/sda of=/dev/null bs=1k count=1000

1000+0 records in
1000+0 records out
1024000 bytes (1.0 MB, 1000 KiB) copied, 9.91181 s, 103 kB/s