透過現象看本質——聊一聊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）以及對應的測試驗證方法。