Linux Cgroups（Linux Control Group）是 Linux 內核中用來為進程設置資源限制的一個功能。它最主要的作用就是限制一個進程組能夠使用的資源上限，包括 CPU、內存、磁盤、網絡帶寬等。此外，Cgroups 還能夠對進程進行優先級設置、審計，以及將進程掛起和恢復等操作。

那么為什么除了 Namespace 之外還需要 Cgroups 呢？因為雖然容器里的 1 號進程只能看到容器里的情況，但是在宿主機上，它作為 100 號進程（比如宿主機上它的 PID 是 100）與其他所有進程之間依然是平等的競爭關系。也就是說，雖然 100 號進程表面上被隔離了起來，但是它能夠使用的資源（比如 CPU、內存）是全部的，它可能把所有資源耗光。那么這樣顯然不是一個容器應該表現出來的合理行為。

在 Linux 中，Cgroups 給用戶暴露出來的操作接口是文件系統，即操作接口是以文件和目錄的方式組織在操作系統的 /sys/fs/cgroup 路徑下。我們可以通過 mount 命令來查看一下，可以發現輸出結果是一系列文件系統目錄。

 

我們查看 /sys/fs/cgroup 的時候還可以看到一系列子目錄，這些子目錄又被稱為子系統。這些都是我這臺機器上當前可以被 Cgroups 進行限制的資源種類。比如：

• cpu 只要限制 CPU 的使用時間
• cpuset 為進程分配單獨的 CPU 核和對應的內存節點
• memory 為進程設定內存使用的限制
• blkio 塊設備設定 IO 限制，一般用于磁盤等設備

 

而在子目錄下面可以看到該子系統對應的資源可以被限制的方法，比如對于 CPU 子系統來說，我們可以看到如下幾個配置文件。

 

其中 cpu.cfs_period_us 和 cpu.cfs_quota_us 這兩個文件組合使用可以限制進程在長度為 cfs_period 的一段時間內，只能被分配到總量為 cfs_quota 的 CPU 時間。

Cgoups 配置示例

下面基于 Cgroups 提供的操作接口進行配置，我們先在相應的子系統中再創建一個目錄，比如 container ，這個目錄就被稱為“控制組”。當將這個目錄創建好了之后，你會發現這個目錄已經生成了該子系統對應的資源限制文件。

 

接下去，我們通過修改 container 中的文件內容來設置限制。比如向 container 中的 cpu.cfs_quota_us 中寫入 20 ms，也就是 20000，就表示每 cpu_period_us （100ms）被控制組限制的進程只能使用 20ms 的 CPU 時間。

接下去我們把要限制的進程 PID 寫入 container 目錄中的 tasks 文件中，那么該設置對要限制的進程就有效了。

 

 

Docker 實現

對于 Docker 等 Linux 容器項目來說，它們只需要在每個子系統下面，為每個容器創建一個控制組（也就是創建一個新目錄），然后在啟動容器進程之后，把這個進程的 PID 寫入到這個控制組的 tasks 文件中即可。而控制組中的資源限制要填上什么值，就要看用戶執行 docker run 時指定的參數內容。在 Docker 主機中，每個子系統下面都有 docker 控制組。

 

下面我們來演示 docker 進行設置的效果，就會在 CPU 子系統的 docker 控制組中進行相關的設置。

docker run -it --rm --cpu-period=100000 --cpu-quota=20000 -d alpine sleep 500s

如下所示，docker 還會在 docker 控制組創建一個新的目錄，在這個目錄中對資源進行設置，從而達到限制資源使用的效果。

 

跟 Namespace 情況類似，Cgoups 對資源的限制能力也有很多不完善的地方，其中被提及最多的是 /proc 文件系統的問題。/proc 目錄存儲著當前內核運行狀態的一系列特殊文件，用戶可以通過訪問這些文件，查看系統以及當前正在運行的進程的信息，比如 CPU 使用情況、內存占用率等，這些文件也是 top 指令查看系統信息的主要數據來源。

但是，如果你在容器里執行 top 指令，就會發現，它顯示的信息居然還是宿主機的 CPU 和內存數據。這是因為  /proc 文件系統并不知道用戶通過 Cgroups 給這個容器做了什么樣的資源限制，所以它返回的還是整個宿主機的。那么這個問題會導致，容器內的應用程序讀取到的 CPU 核數、可用內存等信息還是宿主機的，而不是做了限制之后的。這就是容器相比較于虛擬機另一個不盡如人意的地方。