cgroup v2 で何が変わったのか TechFeed Experts Night#28 〜 コンテナ技術最前線 加藤泰文 2024-05-08 1/22

自己紹介 　 加藤泰文（かとうやすふみ） TenForward • X: @ten_forward • Bluesky: tenforward.bsky.social • https://github.com/tenforward/ • コンテナ趣味人 • 仕事はセキュリティやってます 2/22

自己紹介 今日は時間が短いので概要だけお伝えします。もう少し深く知りたい！ と思ったら、ぜひこ ちらをご覧ください。 趣味の一環で技術評論社のサイト gihyo.jp で コンテナの連載をやっています（2014 年〜） 「LXC で学ぶコンテナ入門 －軽量仮想化環境を 実現する技術」 その他、linuxcontainers.org プロジェクト のプロダクトやページ、マニュアル等の翻訳 をしています 3/22

自己紹介 　 連載をもとに大幅に加筆した同人本を書き、技術書典に出展。販売中。 • サークル名：lxc-jp 4/22

自己紹介 もっと DeepDive したい方に向けて、技術書 典にて、サークル「Linux カーネルもくもく 会」から「cgroup の歩き方」を販売中 cgroup v1 のカーネルコードリーディングを している本です 5/22

本日の内容 今日お話すること • cgroup とは • cgroup v1/v2 の特徴 • cgroup v1 に比べて v2 は何が良くなったのか? 今日お話しないこと • コンテナエンジンや Kubernetes で cgroup v2 をどのように使うのか? 6/22

cgroup とは

cgroup とは コンテナを使わなくても、Linux を起動すれば必ずお世話になっている機能。 • タスク（プロセス・スレッド）のグループ化 • グループ化したプロセスに対して共通の管理を行う • リソース制限 • アクセス制限… 7/22

用語 これは、あとで説明する cgroup のバージョンによらず同じです。 cgroup とは、 • 機能自体を表す • cgroup 機能を使って作成したグループを cgroup と呼ぶ 8/22

cgroup の使い方 • cgroup 用の疑似ファイルシステムをマウントして使用する（/sys/fs/cgroup） • 通常のファイルシステム同様にツリー構造を取り、ディレクトリーがグループ （=cgroup）を表す • ディレクトリー中に出現するファイルを使って設定値を設定したり取得したりする （cgroup の操作例） # echo $$ > /sys/fs/cgroup/test/cgroup.procs（cgroup へのカレントプロセスの登録） # cat /sys/fs/cgroup/test/cpu.stat（CPU 統計値の取得） 9/22

cgroup の構成 コア 　 cgroup 自体の管理、タスク管理 （ 「コア」という言葉が明確に定義されて使用されているわけではありません） コントローラー 　 各種リソースの制御。リソースごとにコントローラーが実装されている 10/22

cgroup のバージョン • cgroup v1 • 2.6.24 以来少しずつ機能追加され実装されてきた • 「コンテナナニソレ？」という時代から実装されてきたため「控えめ」な実装 • 自由度高い、汎用性重視 • コントローラーごとに別々に実装、コントローラーごとにマウントできる • 複数階層構造 • cgroup v2 • 4.5 カーネルで stable に • v1 が持つ問題点を解決 • 単一階層構造 • cgroup ごとにコントローラーの有効・無効を設定できる 11/22

cgroup v1

cgroup v1 の特徴 自由度が高い。 • 複数階層構造（cgroupfs を複数マウントでき、それぞれで独立したツリーを構成できる） • 特定の階層に結びつけるコントローラーは任意 12/22

cgroup v1 の問題点 • 汎用性を持たせるため自由度高く設計されていたが、自由度を高く構成できなかった → 結局、複数の階層すべてを同じ構成にした cgroup ツリーを形成して使っていた • コントローラー間の連携ができない → （例）Linux の I/O はメモリーを使うが、IO とメモリーを扱うコントローラーは別々 に実装され、連携できない。連携しようにも他のコントローラーがマウントされるかど うか不明 • コントローラー操作の一貫性の欠如 → コントローラーは別々に設計・実装されたため、操作性がバラバラ • どのノードにもタスクが所属でき、リソース配分を設定できた → 親子 cgroup 間のスレッドにどうリソースが配分すればよいかわからない。決まって いない • すべてのコントローラーがスレッド単位で制御されていた → スレッド単位でリソース制御する必要があるリソースは少ない。CPU は制御する意味 があるが、メモリーは意味がない 13/22

cgroup v2

cgroup v2 の特徴 • 全体的な規約が定められた • 単一階層構造（システム上に cgroup ツリーはひとつ） • cgroup ごとに使うコントローラーを設定する 14/22

cgroup v2 の特徴 Linux で cgroup の存在が当たり前になったため、遠慮なく実装できる状況。 • 全体的な規約が定められた コントローラーは規約に沿って実装されるため、操作は統一される • 単一階層構造 cgroup ツリーはシステムに 1 つ。ツリー内でコントローラーの制御を行う • コントローラー間の連携 必ずシステムに 1 つしかない cgroup ツリー内でコントローラーが管理される • プロセス単位の管理 全コントローラーで統一したポリシーでリソース制御が可能に。スレッド単位で管理が必 要なコントローラーは、他のコントローラーと矛盾しない形で別に管理方法が定められた • プロセスが所属できるのは末端の cgroup のみ（リソース配分する場合） 親子 cgroup のタスク間のリソース制御を考える必要はなくなった 15/22

cgroup v2 で良くなった点 色々きちんとしたのはわかるけど、実際使う場合にどんなメリットが? 良くなった点、便利になった点をいくつかピックアップしてみます。 16/22

cgroup v2 で良くなった点（1） I/O 制御がきちんと効く • Linux では、ディスクのデータを読み書きするとき、通常はメモリーを経由する • メモリーと IO コントローラーが連携する必要がある • v1：コントローラーがバラバラに実装されているのでできない。ダイレクト I/O のときのみ 制御できた • v2：単一階層構造なのでメモリーと IO コントローラーが連携できる 　 17/22

cgroup v2 で良くなった点（2） メモリーの最低保証値の設定ができる • v1：上限の設定のみ • v2：memory.min,memory.low により最低保証値の設定ができる。cgroup 内のタス クのメモリー使用量が設定値より小さければメモリーは回収されない 18/22

cgroup v2 で良くなった点（3） cgroup 内のタスクをまとめて OOM Killer の対象にできる（OOM Killer が発動しないのが一番ですが…w） • v1：cgroup 内のどのタスクが OOM Killer の対象になるかわからない • v2：OOM Killer 発動時、cgroup 内のタスク全部をまとめて kill できるようになった 19/22

その他 cgroup v2 で変わった点 システムで cgroup が当たり前になってきたので、色々なところで cgroup がサポートされ るようになってきた。 • なくなったコントローラーがある 周辺ツールが直接 cgroup を理解するようになってきた（例: iptables、eBPF） • デバイスコントローラー インターフェースファイルはなくなり、BPF プログラムで制御するようになった 20/22

まとめ

まとめ いろいろ書きましたが、まとめると cgroup が便利にちゃんと動くようになりました ということみたいです。 （紹介した以外にもいろいろ便利な機能が追加されています） 21/22

以上 ご清聴ありがとうございました 22/22