淺談Cgroups V2

 王希剛 360雲計算

女主宣言

以前寫過的一篇文章《淺談Cgroups》中對Cgroups v1進行了介紹，Cgroups爲容器實現虛擬化提供了基礎。隨着容器技術不斷髮展，Cgroups v1中管理controller變得複雜起來。Cgroups v2的出現簡化了Hierarchy，並在kernel 4.5.0版本成爲正式特性。本文將從其產生的背景，相比v1具體有哪些變化等方面，對Cgroups v2進行介紹。

PS：豐富的一線技術、多元化的表現形式，盡在「360雲計算」，點關注哦！

1

背景

以前寫過一篇文章對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。
  

相關文章

• http://man7.org/linux/man-pages/man7/cgroups.7.html

• https://facebookmicrosites.github.io/cgroup2/docs/create-cgroups.html

• https://events.static.linuxfound.org/sites/events/files/slides/cgroup_and_namespaces.pdf

• https://lwn.net/Articles/679786/

• https://www.lijiaocn.com/%E6%8A%80%E5%B7%A7/2019/01/28/linux-tool-cgroup-detail.html