Cgroup簡介
CGroup 是 Control Groups 的縮寫,是 Linux 內核提供的一種可以限制、記錄、隔離進程組 (process groups) 所使用的物理資源 (如 cpu memory i/o 等等) 的機制。2007 年進入 Linux 2.6.24 內核,CGroups 不是全新創造的,它將進程管理從 cpuset 中剝離出來,作者是 Google 的 Paul Menage。CGroups 也是 LXC 為實現虛擬化所使用的資源管理手段。
Cgroup架構
CGroup 技術可以被用來在操作系統底層限制物理資源,起到 Container 的作用。圖中每一個 JVM 進程對應一個 Container Cgroup 層級,通過 CGroup 提供的各類子系統,可以對每一個 JVM 進程對應的線程級別進行物理限制,這些限制包括 CPU、內存等等許多種類的資源。
Cgroup子系統解釋
子系統 | 描述 |
blkio | 這個子系統為塊設備設定輸入/輸出限制,比如物理設備(磁盤,固態硬盤,USB 等等) |
cpu | 這個子系統使用調度程序提供對 CPU 的 cgroup 任務訪問 |
cpuacct | 這個子系統自動生成 cgroup 中任務所使用的 CPU 報告 |
cpuset | 這個子系統為 cgroup 中的任務分配獨立 CPU(在多核系統)和內存節點 |
devices | 這個子系統可允許或者拒絕 cgroup 中的任務訪問設備 |
freezer | 這個子系統掛起或者恢復 cgroup 中的任務 |
memory | 這個子系統設定 cgroup 中任務使用的內存限制,並自動生成由那些任務使用的內存資源報告 |
net_cls | 這個子系統使用等級識別符(classid)標記網絡數據包,可允許 Linux 流量控制程序(tc)識別從具體 cgroup 中生成的數據包 |
Cgroups限制測試
- /sys/fs/cgroup下面都稱為子系統,目錄下包含了限制的資源種類,CentOS7
- cfs_period 和 cfs_quota的關鍵字,主要是對cpu的限制,功能是限制進程在長度為 cfs_period 的一段時間內,只能被分配到總量為 cfs_quota 的 CPU 時間。
- 驗證cpu限制
- 進入到cpu目錄創建一個自己的容器 busket,系統會默認創建被限制的子系統
-
- 當前目錄默認cpu使用時間
# 默認cpu使用時間(us) ## 結果:100ms cat cpu.cfs_period_us 100000 # 分配的時間 ## -1 表示不限制 cat cpu.cfs_quota_us -1
-
- 執行死循環,驗證不限制的情況是否占滿cpu
# 執行死循環 ## 返回pid while : ; do : ; done & [2] 25013
由於我執行了兩次死循環,所以看到有兩個PID,都把cpu占滿了。由於我的虛擬機是分了3cpus,所以top的整個cups占用達到了70.7%,我執行一個的時候占用大概是36%左右。殺掉兩個進程后,Cpu(s) 降為正常,小於10%。
-
- 更改cpu.cfs_quota_us的值為25000(us), 即單位時間內,即每100毫秒內占用25毫秒的時間,即執行死循環的話,單cpu占用率無限接近25%。驗證一下:
- vi是無權限的,用echo進行修改。
- 更改cpu.cfs_quota_us的值為25000(us), 即單位時間內,即每100毫秒內占用25毫秒的時間,即執行死循環的話,單cpu占用率無限接近25%。驗證一下:
## 更改cpu.cfs_quota_us為25000us echo 25000 > cpu.cfs_quota_us
-
-
- 執行死循環
-
# 執行死循環 ## 返回pid while : ; do : ; done & [1] 4853
-
-
- top
-
-
-
- 把當前跑滿cpu的進程ID寫入限制進程的tasks子系統中。
-
# 把剛才死循環進程id寫入tasks子系統 echo 4853 > tasks
-
-
- 驗證單cpu是否無限接近25%
-
可以看出,cgroup就是通過這種方式將控制組的資源使用進行限制。
docker限制
同理,docker也是通過cgroup進行限制的,可以看到我的子系統下面每個都有docker目錄。
可以看到cpu目錄下有剛才創建的busket,也有docker,還有我安裝的k8s的kubepods, 進入docker后里面又有很多容器ID,進入容器ID后也是一系列子系統文件。所以,docker就是基於namespace隔離出來並且通過cgroup做內核資源限制的虛擬化容器,本質是進程。
參考
https://time.geekbang.org/column/article/14653
https://blog.csdn.net/lbyyy/article/details/54342541