前言
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 發布!