1. 背景

上一篇文章《淺談Cgroups》對cgroup v1進行了介紹，但是由于當前k8s使用cephfs進行數據存儲，當多租戶使用時，需要對IO進行限制。當前cgroup v1由于memcg與blkio沒有協作，導致buffer io的throttle一直沒有實現。并且cgroup v1在內核的實現一直比較混亂，其中主要的原因在于，cgroup為了提供靈活性，允許進程可以屬于多個hierarchy的不同的group。但實際上，多個hierarchy并沒有太大的用處，因為控制器(controller)只能屬于一個hierarchy。 所以在實際使用中，通常是每個hierarchy一個控制器。

這種多hierarchy除了增加代碼的復雜度和理解困難外，并沒有太大的用處。一方面，跟蹤進程所有controller變得復雜;另外，各個controller之間也很難協同工作(因為controller可能屬于不同的hierarchy, 所以從3.16開始，內核開始轉向單一層次(unified hierarchy)。并且實現了對buffer io的限制。

2. Cgroups v2的變化

由于Cgroups v1存在的種種問題，Cgroups v2將多hierarchy的方式變成了unified hierarchy，并將所有的controller掛載到一個unified hierarchy。

當前kernel沒有移除Cgroups v1版本，允許Cgroups v1和v2兩個版本共存。但是相同的controller不能同時mount到這兩個不同的Cgroup版本中。

以下是Cgroups v2的五點改進：

• Cgroups v2 中所有的controller都會被掛載到一個unified hierarchy下，不在存在像v1中允許不同的controller掛載到不同的hierarchy的情況
• Proess只能綁定到cgroup的根(“/“)目錄和cgroup目錄樹中的葉子節點
• 通過cgroup.controllers和cgroup.subtree_control指定哪些controller可以被使用
• v1版本中的task文件和cpuset controller中的cgroup.clone_children文件被移除
• 當cgroup為空時的通知機制得到改進，通過cgroup.events文件通知

3. unified hierarchy

在Cgroups v1允許將不同的controller掛載到不同的hierarchies雖然很靈活，但實際上這種方式對于使用者來說是沒有必要的。因此在Cgroups v2版本中，將所有的controller都掛載到一個hierarchies。

可以使用下面命令將Cgroups v2掛載到文件系統，并且所有可用的controller會自動被掛載進去。

mount -t cgroup2 none $MOUNT_POINT 

一個contoller無法在Cgroups v1和v2中同時使用，如果想在Cgroups v2使用已經被Cgroups v1使用的controller，則需要先將其從Cgroups v1中umount掉。

要注意的是，系統啟動時，systemd默認使用Cgroups v1，并將可以使用的controller mount到/sys/fs/cgroup。如果想在系統啟動時，把Cgroups v1關掉，可以在/etc/default/grub文件下修改kernel參數,增加GRUB_CMDLINE_LINUX_DEFAULT="cgroup_no_v1=all"。(all表示關閉所有的controller，如果想關閉指定的controller，則將all替換成你需要的controller名稱，并已逗號分隔即可)。這樣就可以在Cgroups v2中使用你想要的controller了。

4. controllers

當前cgroup v2支持以下controller:

• io (since Linux 4.5)
• memory (since Linux 4.5)
• pids (since Linux 4.5)
• perf_event (since Linux 4.11)
• rdma (since Linux 4.11)
• cpu (since Linux 4.15)

5. subtree control

在hierarchy下的每一個Cgroup中都會包含如下兩個文件

• cgroup.controllers：這是一個read-only文件。包含了該Cgroup下所有可用的controllers.
• cgroup.subtree_control：這個文件中包含了該Cgroup下已經被開啟的controllers。 并且cgroup.subtree_control中包含的controllers是cgroup.controllers文件controller的子集。

cgroup.subtree_control文件內容格式如下,controller之間使用空格間隔，前面用”+”表示啟用,使用”-“表示停用。比如下面的例子：

echo '+pids -memory' > x/y/cgroup.subtree_control 

Cgroups v2的具體組織結構如下圖所示：

6. "no internal processes" rule

與Cgroups v1不同, Cgroups v2只能將進程綁定到葉子節點。因此不能綁定進程到任何一個已開啟controller的任何subgroup中。

7. cgroup.events file

在Cgroups v2的實現中，也對獲取group empty時獲取通知的機制進行了優化。

Cgroups v1使用release_agent和notify_on_release在v2中被移除。替代的是使用了cgroup.events文件。這是一個只讀的文件，每行一個key value對，key和value之間通過空格分割。

當前在這個文件中只含有一個key就是populated，對應的value是0。0表示cgroup中沒有process，1表示cgroup中包含process。

8. cgroup.stat file

在Cgroups v2 hierarchy下的每個group都會包含一個只讀文件cgroup.stat。它的內容也是key-value的形式。當前這個文件中包含如下兩個key：

• nr_descendants：表示cgroup中存活的subgroup的數量
• nr_dying_descendants：表示cgroup中已經死亡的cgroup的數量

9. 后代Cgroups數量限制

在Cgroups v2 hierarchy中還包含了兩個用于查看和設置該Cgroups下的后代Cgroups數量的限制文件：

• cgroup.max.depth (since Linux 4.14)：這個文件定義子cgroup的***深度。0意味著不能創建cgroup。如果嘗試創建cgroup，會報EAGAIN錯誤;max表示沒有限制，默認值是max。
• cgroup.max.descendants (since Linux 4.14)：當前可以創建的活躍cgroup目錄的***數量，默認值”max”表示不限制。超過限制，返回EAGAIN。

【本文是51CTO專欄機構360技術的原創文章，微信公眾號“360技術（ id: qihoo_tech）”】

戳這里，看該作者更多好文