前言
Docker容器技術相信大家或多或少都聽說過吧，現在可謂是紅極一時。它的優勢主要有以下幾點：
- 不需要再啟動內核，所以應用擴縮容時可以秒速啟動。
- 資源利用率高，直接使用宿主機內核調度資源，性能損失小。
- 一鍵啟動所有依賴服務，鏡像一次編譯，隨處使用。測試和生產環境高度一致。
- 應用的運行環境和宿主機環境無關，完全由鏡像控制，一台物理機上部署多種環境的鏡像測試。
- 實現了持續的交付和部署。
但是我們在學習一樣東西時不能僅僅停留於表面的命令，更重要的是深入進去理解，Docker的核心技術主要基於Linux的namespace，cgroup和Union Fs文件系統，以及Docker自身的網絡。
今天的這篇文章主要是介紹Docker的核心技術namespace，cgroup，Union FS（docker的網絡后續會出），總結一下這段時間的學習。
Namespace
Linux Namespace是Linux Kernel提供的資源隔離方案：
- 系統可以為進程分配不同的namespace，每個進程都會有自己的namespace
- 並保證不同的namespace資源獨立分配，進程彼此隔離，即不同的namespace下的進程互不干擾
為了隔離不同的資源，Linux Kernel提供了六種不同類型的namespace:
注：UTS全稱：UNIX Time Sharing UNIX分時操作系統
Linux對namespace的實現
既然namespace和進程相關，那么我們可以在task_struct結構體中看到包含和namespace相關聯的變量。
## \kernel\msm-4.4\include\linux\sched.h
struct task_struct { // 當然task_struct中還包含關於進程的其他信息 比如進程狀態等
...
/* namespaces */
struct nsproxy *nsproxy;
...
}
其中nsproxy結構體包含了關於各種命名空間實現
# \kernel\msm-4.4\include\linux\nsproxy.h
/*
* A structure to contain pointers to all per-process
* namespaces - fs (mount), uts, network, sysvipc, etc.
*
* The pid namespace is an exception -- it's accessed using
* task_active_pid_ns. The pid namespace here is the
* namespace that children will use.
*
* 'count' is the number of tasks holding a reference.
* The count for each namespace, then, will be the number
* of nsproxies pointing to it, not the number of tasks.
*
* The nsproxy is shared by tasks which share all namespaces.
* As soon as a single namespace is cloned or unshared, the
* nsproxy is copied.
*/
struct nsproxy {
atomic_t count;
struct uts_namespace *uts_ns;
struct ipc_namespace *ipc_ns;
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns_for_children;
struct net *net_ns;
};
extern struct nsproxy init_nsproxy; // init_nsproxy是對除了.mnt_ns之外的namespace進行系統初始化
Linux對namespace的操作方法
主要是三個命令：clone，setns，unshare
clone
// linux中輕量級的進程是由clone()函數創建的
/*
fn 當一個新進程通過clone創建時，它通過調用fn所指向的函數開始執行
child_stack 為子進程分配的堆棧空間
flags 在創建新進程的系統調用時可以通過flags參數指定需要新建的namespace類型
CLONE_NEWIPC 對應IPC命名空間
CLONE_NEWNET 對應NET命名空間
CLONE_NEWNS 對應Mount命名空間
CLONE_NEWPID 對應PID命名空間
CLONE_NEWUSER 對應User命名空間
CLONE_NEWUTS 對應UTS命名空間
CLONE_NEWCGROUP 對應cgroup命名空間，使進程有一個獨立的cgroup控制組，始於Linux 4.6
*/
int clone(int (*fn)(void *), void *child_stack, int flags, void *arg)
clone創建一個新的進程加入到新的命名空間中，不會影響當前進程，而且clone創建的子進程可以共享父進程的虛擬空間地址，文件描述符，信號處理表等。
注：
（1） clone和fork的調用方式很不相同，clone調用需要傳入一個函數int (*fn)(void *)，該函數在子進程中執行。
（2）clone和fork最大不同在於clone不再復制父進程的棧空間，而是自己創建一個新的。 （void *child_stack,）也就是第二個參數，需要分配棧指針的空間大小，所以它不再是繼承或者復制，而是全新的創造。
setns
/*
fd 指向/proc/[pid]/ns命名空間的文件描述符
nstype 對應命名空間的flags 如果為0表示允許進入任何一個命名空間
*/
int setns(int fd, int nstype)
// 舉例
int fd = pidfd_open(1234, 0);
setns(fd, CLONE_NEWUSER | CLONE_NEWNET | CLONE_NEWUTS);
調用某個線程（單線程即進程）加入指定的namespace
unshare
int unshare(int flags)
可以將調用進程移動到新的namespace，是當前進程退出當前的命名空間，進入新的命名空間。注意與clone()的區別。
關於namespace常用的操作
查看當前系統的 namespace： lsns –t <type>
[root@aliyun ns]# lsns -t mnt
NS TYPE NPROCS PID USER COMMAND
4026531840 mnt 88 1 root /usr/lib/systemd/systemd --system --deserialize 17
4026531856 mnt 1 13 root kdevtmpfs
4026532151 mnt 1 541 chrony /usr/sbin/chronyd
查看某進程的 namespace： ll /proc/<pid>/ns/
# 先查出進程id
[root@aliyun proc]# docker inspect 97649934abf3 | grep -i pid
"Pid": 26103,
"PidMode": "",
"PidsLimit": null,
# 查看某進程的namespace
[root@aliyun proc]# ll /proc/26103/ns
total 0
lrwxrwxrwx 1 root root 0 Aug 31 15:19 ipc -> ipc:[4026532163]
lrwxrwxrwx 1 root root 0 Aug 31 15:19 mnt -> mnt:[4026532161]
lrwxrwxrwx 1 root root 0 Aug 31 15:17 net -> net:[4026532166]
lrwxrwxrwx 1 root root 0 Aug 31 15:19 pid -> pid:[4026532164]
lrwxrwxrwx 1 root root 0 Aug 31 15:19 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Aug 31 15:19 uts -> uts:[4026532162]
進入某 namespace 運行命令： nsenter -t <pid> -n ip addr 其中-t參數表示目標進程id，-n參數表示net命名空間。nsenter相當於在setns的示例程序上做了一層封裝，是我們無需指定命名空間的文件描述符，而是指定進程號即可。
nsenter可以在指定進程的命令下運行指定程序的命令，因為大多數的容器為了輕量級是不包含較為基礎的命令的，這就為調試容器網絡帶來了很大的困擾，只能通過docker inspect 容器id獲取容器的ip，以及無法測試和其他網絡的連通性（其實可以通過docker網絡的管理），nsenter命令可以進入該容器的網絡命名空間，使用宿主機命令調試網絡。
# 在宿主機下使用ip addr查看容器中的網絡信息
[root@aliyun proc]# docker inspect 97649934abf3 | grep -i pid
"Pid": 26103,
"PidMode": "",
"PidsLimit": null,
[root@aliyun proc]# nsenter -t 26103 -n ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
# 容器中的網絡信息 可以發現完全相同
[root@97649934abf3 /]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
namespace練習
# 在新的network namespace中執行sleep指令
[root@aliyun proc]# unshare -fn sleep 60
# 查看sleep進程ip
[root@aliyun /]# ps -ef | grep sleep
root 27992 2567 0 15:47 pts/0 00:00:00 unshare -fn sleep 60
root 27993 27992 0 15:47 pts/0 00:00:00 sleep 60
root 28000 25995 0 15:47 pts/1 00:00:00 grep --color=auto sleep
# 查看sleep的net namespace
[root@aliyun /]# lsns -t net
NS TYPE NPROCS PID USER COMMAND
4026531956 net 92 1 root /usr/lib/systemd/systemd --system --deserialize 17
4026532160 net 2 27992 root unshare -fn sleep 60
# 通過nsenter進入sleep的net namespace查看網絡信息（注意操作需要在sleep進程的存活時間內完成60s）
[root@aliyun /]# nsenter -t 27992 -n ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Cgroup
Cgroup（control groups）是linux下用於對一個或一組進程進行資源限制和監控的機制，可以對諸如 CPU 使用時間、內存、磁盤 I/O 等進程所需的資源進行限制。舉個簡單的例子，我系統中跑了一個while(true)程序，系統的cpu資源立馬爆了，這時候我們可以通過cgroup對它限制cpu資源的使用。
Cgroup 在不同的系統資源管理子系統中以層級樹（Hierarchy）的方式來組織管理：每個 Cgroup 都可以包含其他的子 Cgroup，因此子 Cgroup 能使用的資源除了受本 Cgroup 配置 的資源參數限制，還受到父 Cgroup 設置的資源限制。
Linux對cgroup的實現
同樣我們可以在task_struct結構體中看到cgroups相關聯的變量
## \kernel\msm-4.4\include\linux\sched.h
struct task_struct {
/* Control Group info protected by css_set_lock: */
struct css_set __rcu *cgroups;
/* cg_list protected by css_set_lock and tsk->alloc_lock: */
struct list_head cg_list;
}
struct css_set {
/*
* Set of subsystem states, one for each subsystem. This array is
* immutable after creation apart from the init_css_set during
* subsystem registration (at boot time).
*/
struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];
}
Cgroup下的子系統
在/sys/fs/cgroup下我們可以看到cgroup所包含的子系統：
- blkio：這個子系統設置限制每個塊設備的輸入輸出控制。例如:磁盤，光盤以及 USB 等等；
- cpu：這個子系統使用調度程序為 cgroup 任務提供 CPU 的訪問；
- cpuacct：產生 cgroup 任務的 CPU 資源報告；
- cpuset：如果是多核心的CPU，這個子系統會為 cgroup 任務分配單獨的 CPU 和內存；
- devices：允許或拒絕 cgroup 任務對設備的訪問；
- freezer：暫停和恢復 cgroup 任務；
- memory：設置每個 cgroup 的內存限制以及產生內存資源報告；
- net_cls：標記每個網絡包以供 cgroup 方便使用；
- ns：名稱空間子系統；
- pid: 進程標識子系統。
比較重要和常用的就是cpu子系統和memory子系統
CPU子系統
cpu子系統中的主要內容如下
Go語言演示cgroup對cpu的限制
編寫一個test.go測試文件並運行
package main
func main(){
i := 0
go func(){
for {
i++
}
}()
for {
i++
}
}
使用top查看cpu在沒有限制下的占用率，可以看到test文件占到90%多的cpu資源
在cgroup cpu子系統中建立文件夾，並使用cgroup進行限制
[root@aliyun test]# mkdir /sys/fs/cgroup/cpu/test
[root@aliyun test]# cd /sys/fs/cgroup/cpu/test
[root@aliyun test]# 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
# 將cpu.cfs_quota_us的值設置為2000 cpu.cfs_period_us時間片默認的值還是為100000，可以將test.go執行的進程對cpu的利用率降低到2%左右
[root@aliyun test]# ehco 2000 > cpu.cfs_quota_us
# 將test的進程id加入到cgroup.procs中
[root@aliyun test]# ehco 31944 > cgroup.procs
此時再用top查看進程資源信息就可以看到test測試文件對cpu的占用資源瞬間下降到2%作用，效果明顯！
注：
關於 tasks 和 cgroup.procs，網上很多文章將 cgroup 的 Task 簡單解釋為 OS 進程，這其實不夠准確，更精確地說，cgroup.procs 文件中的 PID 列表才是我們通常意義上的進程列表，而 tasks 文件中包含的 PID 實際上可以是 Linux 輕量級進程(Light-Weight-Process,LWP) 的 PID，而由於 Linux pthread 庫的線程實際上輕量級進程實現的。簡單來說：Linux 進程主線程 PID = 進程 PID，而其它線程的 PID (LWP PID)則是獨立分配的
當要向某個 Cgroup 加入 Thread 時，將Thread PID 寫入 tasks 或 cgroup.procs 即可，cgroup.procs 會自動變更為該 task 所屬的 Proc PID。如果要加入 Proc 時，則只能寫入到 cgroup.procs 文件，tasks 文件會自動更新為該 Proc 下所有的 Thread PID，通過tasks，我們可以實現線程級別的管理。
Memory子系統
cgroup的memory子系統全稱為 Memory Resource Controller ，它能夠限制cgroup中所有任務的使用的內存和交換內存進行限制，並且采取control措施：當OOM時，是否要kill進程。
Go語言演示cgroup對memory的限制
編寫一個mem.go文件
package main
// 參考《自動動手寫Docker》
import (
"fmt"
"io/ioutil"
"os"
"os/exec"
"path"
"strconv"
"syscall"
)
const CgroupMemoryHierarchyMount = "/sys/fs/cgroup/memory"
func main() {
if os.Args[0] == "/proc/self/exe" {
fmt.Println("---------- 2 ------------")
fmt.Printf("Current pid: %d\n", syscall.Getpid())
// 創建stress子進程，施加內存壓力
allocMemSize := "99m" //
fmt.Printf("allocMemSize: %v\n", allocMemSize)
stressCmd := fmt.Sprintf("stress --vm-bytes %s --vm-keep -m 1", allocMemSize)
cmd := exec.Command("sh", "-c", stressCmd)
cmd.SysProcAttr = &syscall.SysProcAttr{}
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
if err := cmd.Run(); err != nil {
fmt.Printf("stress run error: %v", err)
os.Exit(-1)
}
}
fmt.Println("---------- 1 ------------")
cmd := exec.Command("/proc/self/exe")
cmd.SysProcAttr = &syscall.SysProcAttr{
Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWNS | syscall.CLONE_NEWPID,
}
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
// 啟動子進程
if err := cmd.Start(); err != nil {
fmt.Printf("/proc/self/exe start error: %v", err)
os.Exit(-1)
}
cmdPid := cmd.Process.Pid
fmt.Printf("cmdPid: %d\n", cmdPid)
// 創建子cgroup
memoryGroup := path.Join(CgroupMemoryHierarchyMount, "test_memory_limit")
os.Mkdir(memoryGroup, 0755)
// 設定內存限制
ioutil.WriteFile(path.Join(memoryGroup, "memory.limit_in_bytes"),
[]byte("100m"), 0644)
// 將進程加入cgroup
ioutil.WriteFile(path.Join(memoryGroup, "tasks"),
[]byte(strconv.Itoa(cmdPid)), 0644)
cmd.Process.Wait()
}
函數解讀（在啟動時，stress占99M內存，cgroup限制最多使用100M內存）
- 一開始我們使用
go run mem.go或者go build .運行時，並不滿足if os.Args[0] == "/proc/self/exe"的條件，所以跳過。 - 然后函數
cmd := exec.Command("/proc/self/exe")創建了一個/proc/self/exe的子進程 - 在
/sys/fs/cgroup/memory/創建test_memory_limit文件，設置內存限制為100M - 把子進程加入到task文件中
- 等待子進程結束
- 子進程其實還是當前的程序，不過它的名字為
proc/self/exe，符合最初的if語句判斷，之后會創建stress子進程，然后運行stress。
啟動
下面進入test_memory_limit目錄查看內存最大限制和task，發現內存最大限制與我們設計的一樣。
[root@aliyun test_memory_limit]# cat memory.limit_in_bytes
104857600 // 剛好為100M
[root@aliyun test_memory_limit]# cat cgroups.proc
3599 // proc/self/exe進程
3602
3603 // stress進程
可以通過top查看資源占有率
cgroup.procs下為cgrouptest_memory_list中的進程，這些是真實的進程，可以通過pstree -p查看
下面看看將stress的內存超過100M的限制，是否會OOM掉。
修改代碼，將內存設置為110M，再運行
可以發現整個進程直接被KILL -9殺掉了。這就是cgroup對於memory的限制。
Docker演示cgroup限制cpu和memory
# 啟動一個nginx鏡像
docker run -d --cpu-shares 513 --cpus 0.2 --memory 1024M --memory-swap 1234M --memory-swappiness 7 -p 8081:80 nginx
# 參數解析
-d docker容器在后台運行·
--cpu-shares 513 表示相對分配的配額
--cpus 0.2 其實就是通過cpu.cfs_period_us和cpu.cfs_quota_us的比率來限制對cpu資源的利用率
--memory 1024 其實就是memory.limit_in_byte
--memory-swap 1234M 其實就是memory.memsw.limit_in_byte
--memory-swappiness 7 其實就是memory.swappiness
-p 8081:80（暴露在外的宿主機端口:nginx端口）
# 查看容器id
f4437f9db69d
下面我們進入cgroup下cpu子系統中可以發現有一個docker文件，進入docker文件中可以看到以剛才容器id命名的文件夾
進入該文件夾下，可以發現與我們之前的test.go案例非常一致。
剛剛docker啟動時配置的參數--cpu-shares 513能在cpu.shares文件中體現
而參數--cpus 0.2就是 cpu.cfs_quota_us和cpu.cfs_period_us的比率。
同理進入cgroup下memory子系統中也可以發現一個docker文件，與之對應也有一個容器id命名的文件夾
進入該文件夾下，查看與docker參數相對於的配置信息
docker啟動時配置的參數--memory 1024能在memory.limit_in_bytes中體現
而參數--memory-swap 1234M能在memory.memsw.limit_in_byte中體現
參數--memory-swappiness 7能在memory.swappiness中體現
以上就是對於cgroup中最重要的兩個子系統cpu子系統和memory子系統進行分析~
Union FS
Docker鏡像里面其實是一層層的文件系統，叫做Union FS（聯合文件系統），UnionFS可以將幾層目錄掛載到一起，形成一個虛擬文件系統。（舉個簡單的例子：我們有兩個文件夾a和b，a文件夾下又包含a1.txt a2.txt，b文件夾下又包含b1.txt b2.txt，我們通過創建一個新的文件夾c，通過Union FS就可以在c文件夾下訪問到a1.txt a2.txt b1.txt b2.txt，這樣就把a，b兩個文件夾聯合起來了）
從基本看一個典型的Linux文件系統由bootfs和rootfs兩部分組成：
-
bootfs(boot file system)主要包含bootloader和kernel，bootloader主要引導加載kernel，linux剛啟動時會加載bootfs文件系統，當boot加載完成之后整個內核就都在內存中了，內存的使用權已由bootfs轉交給內核，此時bootfs會被umount掉。在Docker鏡像的最底層就是bootfs。
-
rootfs(root file system)在bootfs之上，包含的就是典型的Linux系統中的/dev、/proc、/bin、/etc等標准目錄和文件。rootfs就是各種不同的操作系統發行版，比如Ubuntu，CentOS等。
Mount命令實現聯合文件系統案例
# 創建文件夾
[root@aliyun uniontest]# mkdir lower upper merge work
# 在lower和upper文件下內寫入文件
[root@aliyun uniontest]# echo "from lower" > lower/in_lower.txt
[root@aliyun uniontest]# echo "from upper" > upper/in_upper.txt
[root@aliyun uniontest]# echo "from lower" > lower/in_both.txt
[root@aliyun uniontest]# echo "from upper" > upper/in_both.txt
# 使用mount命令掛載
[root@aliyun uniontest]# mount -t overlay overlay -o lowerdir=lower/,upperdir=upper/,workdir=work merge
# 查看聯合掛載后的文件
[root@aliyun uniontest]# tree
.
├── lower
│ ├── in_both.txt
│ └── in_lower.txt
├── merge
│ ├── in_both.txt
│ ├── in_lower.txt
│ └── in_upper.txt
├── upper
│ ├── in_both.txt
│ └── in_upper.txt
└── work
└── work
5 directories, 7 files
# 可以看到顯示的是upper層
[root@aliyun uniontest]# cat merge/in_both.txt
from upper
Overlay2
先來區分幾個概念。
- OverlayFS 指的是 Linux 的內核驅動
- overlay/overlay2 指的是 Docker 的存儲驅動。
在上述圖中可以看到三個層結構，即：lowerdir、upperdir、merged，其中lowerdir是只讀的image layer，其實就是rootfs。image layer可以分很多層，所以對應的lowerdir是可以有多個目錄。而upperdir則是在lowerdir之上的一層，這層是讀寫層，在啟動一個容器時候會進行創建，所有的對容器數據更改都發生在這里層。最后merged目錄是容器的掛載點，也就是給用戶暴露的統一視角。而這些目錄層都保存在了/var/lib/docker/overlay2/
下面我們從下載一個容器進行分析，可以發現只有一層文件
下面進入/var/lib/docker/overlay2中查看，可以發現確實只有一層文件
小寫的l文件夾是對這層的符號連接，只是為了減少mount參數可能達到的限制作用
進入到e757開頭的文件夾中查看，可以發現diff文件夾中是當前層的鏡像內容，link文件中是短名稱
下面啟動一個鏡像后再進行查看可以發現多了兩層文件
下面查看一下聯合掛載的情況，我們可以看出，overlay2將lowerdir、upperdir、workdir聯合掛載，形成最終的merged掛載點，其中lowerdir是鏡像只讀層，upperdir是容器可讀可寫層，workdir是執行涉及修改lowerdir執行copy_up操作的中轉層（例如，upperdir中不存在，需要從lowerdir中進行復制）
根據這個掛載我們可以分析一下掛載過程：
-
首先
VKYIMVSFFSVOAWCBIZZQ6RNFB4短鏈接對應的是8cbdc1ab4a0567cf7841b3a6326bbbec185850b56dff309a572a6cff5be7742f-init/diff鏡像配置文件夾（標記為①）4LISVLHRVBORTVPCSNCJHBMVSZ短鏈接對應的是e75746dca68dcf02f7fd5dc90a5828066c4d66ab8e6719030362e546e98bdc62/diff鏡像文件夾（標記為②）且①和②都是屬於lowerdir層，只讀層。 -
查看①中的信息
可以看到diff文件中的內容
- 查看②中對應
dev和etc文件夾中的信息
- 最后查看
upperdir和merged的文件
下面我們再做個測試，進入剛剛啟動的ubuntu容器中，創建一個test.txt文件
接下來我們查看容器的容器的可讀寫層，可以在容器層本身存放內容的diff文件夾和merged文件夾文件中都可以看到test.txt。而在鏡像的只讀層卻沒有看到，說明分析的是正確的。
總結
以上就是對Docker核心的三個技術進行的分析操作，花費了大概三四天的時間，不過對於個人來說還是很有收獲的，以前對於這些也聽過，但是了解不是很深入，這次強迫自己認真的去學習一番，希望日后都可以進入這種深入的學習。文章可能有點長~哈哈
有問題的地方，希望大家多多指正，我會加以更改的~
參考文檔：
https://staight.github.io/2019/09/23/nsenter命令簡介/
https://www.cnblogs.com/sammyliu/p/5886833.html
https://wudaijun.com/2018/10/linux-cgroup/
https://lessisbetter.site/2020/09/01/cgroup-3-cpu-md/
https://lessisbetter.site/2020/08/30/cgroup-2-memory/
https://www.jianshu.com/p/274af1c0163e
https://zhuanlan.zhihu.com/p/41958018
https://www.cnblogs.com/wdliu/p/10483252.html
《趣談Linux操作系統》
本文由博客一文多發平台 OpenWrite 發布！