コンテナ化メカニズム：cgroup

コンテナ化メカニズムに関する一連の記事を続けます。 前回は、「名前空間」のメカニズムを使用してプロセスを分離することについて説明しました。 しかし、コンテナ化のためには、リソースの分離だけでは十分ではありません。 隔離された環境でアプリケーションを実行する場合、このアプリケーションに十分なリソースが割り当てられ、余分なリソースを消費しないようにして、システムの残りの部分を混乱させないようにする必要があります。 この問題を解決するために、Linuxカーネルには特別なメカニズムがあります-cgroups（コントロールグループ、コントロールグループの略）。 今日の記事で彼についてお話します。


今日のcgroupsのトピックは特に関連性があります。今年1月にリリースされたバージョン4.5のコアには、このメカニズムの新しいバージョンであるグループv2が正式に追加されました。
作業中、cgroupsは本質的に書き直されました。

なぜこのような根本的な変更が必要でしたか？ この質問に答えるために、cgroupsの最初のバージョンがどのように実装されたかを詳細に検討しましょう。

Cgroups：簡単な歴史

cgroupの開発は、2006年にGoogleの従業員Paul ManagementとRohit Setによって開始されました。 「コントロールグループ」という用語は使用されませんでしたが、代わりに「プロセスコンテナ」という用語が使用されました。 実際、最初は彼らは現代の意味でcgroupを作成するという目標を設定していませんでした。 最初のアイデアははるかに控えめでした：CPU時間とメモリをタスク間で分散するように設計されたcpusetメカニズムを改善すること。 しかし、時間が経つにつれて、すべてがより大きなプロジェクトに成長しました。

2007年末に、ネームプロセスコンテナはコントロールグループに置き換えられました。 これは、「コンテナ」という用語の解釈の矛盾を回避するために行われました（当時OpenVZプロジェクトはすでに活発に開発されていましたが、「コンテナ」という言葉は新しい現代的な意味で使用され始めました）。

2008年に、cgroupsがLinuxカーネル（バージョン2.6.24）に公式に追加されました。 以前のカーネルバージョンと比較したこのカーネルバージョンの新機能

cgroupで動作するように特別に設計された単一のシステムコールは追加されていません。 主な変更点には、cgroupfsとしても知られるcgroupsファイルシステムがあります。

init / main.cで、ブート時にcgoupsをアクティブにする関数への参照が追加されました：cgroup_initおよびcgroup_init_early。 プロセスの生成と終了に使用される関数fork（）およびexit（）はわずかに変更されました。

/ proc仮想ファイルシステムに新しいディレクトリが追加されました：/ proc / {pid} / cgroup（各プロセス用）および/ proc / cgroups（システム全体用）。

建築

cgroupsメカニズムは、コア（ cgroup core ）といわゆるサブシステムの2つのコンポーネントで構成されています。 そのようなサブシステム12のカーネルバージョン4.4.0.21では：

• blkio-ブロックデバイスからの読み取りと書き込みの制限を設定します。
• cpuacct-プロセッサリソースの使用に関するレポートを生成します。
• cpu-制御グループ内のプロセスのCPUへのアクセスを提供します。
• cpuset-プロセッサコア間でコントロールグループ内のタスクを配布します。
• デバイス - デバイスへのアクセスを許可またはブロックします。
• フリーザー -コントロールグループ内のタスクを一時停止および再開します
• hugetlb-コントロールグループのメモリの大きなページのサポートをアクティブにします。
• メモリ -プロセスグループのメモリの割り当てを制御します。
• net_cls-ネットワークパケットに特別なタグを付けます。これにより、制御グループ内の特定のタスクによって生成されたパケットを識別できます。
• netprio-トラフィックを動的に優先順位付けするために使用されます。
• pids-制御グループ内のプロセスの数を制限するために使用されます。

次のコマンドを使用して、コンソールにサブシステムを一覧表示できます。

$ ls /sys/fs/cgroup/ blkio cpu,cpuacct freezer net_cls perf_event cpu cpuset hugetlb net_cls,net_prio pids cpuacct devices memory net_prio systemd 

各サブシステムは、すべての設定が書き込まれる制御ファイルを含むディレクトリです。 これらの各ディレクトリには、次の制御ファイルが含まれています。

• cgroup.clone_children-親コントロールプロパティを子コントロールグループに渡すことができます。
• タスク-制御グループに含まれるすべてのプロセスのPIDのリストが含まれます。
  cgroup.procs-制御グループに含まれるプロセスグループのTGIDのリストが含まれています。
• cgroup.event_control-コントロールグループのステータスが変化した場合に通知を送信できます。
• release_agent-notify_on_releaseオプションが有効な場合に実行されるコマンドが含まれます。 たとえば、空のコントロールグループを自動的に削除するために使用できます。
• notify_on_release-release_agentで指定されたコマンドの実行を有効にする（または無効にする、またはその逆）ブール変数（0または1）が含まれます。

各サブシステムには、独自の制御ファイルもあります。 それらのいくつかについて以下で説明します。

制御グループを作成するには、いずれかのサブシステムにネストされたディレクトリを作成するだけです。 制御ファイルは、このサブディレクトリに自動的に追加されます（これについては、後で詳しく説明します）。 グループへのプロセスの追加は非常に簡単です。PIDをタスク制御ファイルに書き込むだけです。

サブシステムに組み込まれている制御グループのセットは階層と呼ばれますが、簡単な実用例を使用してcgroupの機能の原理を分析してみましょう。

cgroups階層：実用的な紹介

例1：プロセッサリソース管理

コマンドを実行します：

 $ mkdir /sys/fs/cgroup/cpuset/group0 

このコマンドを使用して、次の制御ファイルを含む制御グループを作成しました。

 $ ls /sys/fs/cgroup/cpuset/group0 group.clone_children cpuset.memory_pressure cgroup.procs cpuset.memory_spread_page cpuset.cpu_exclusive cpuset.memory_spread_slab cpuset.cpus cpuset.mems cpuset.effective_cpus cpuset.sched_load_balance cpuset.effective_mems cpuset.sched_relax_domain_level cpuset.mem_exclusive notify_on_release cpuset.mem_hardwall tasks cpuset.memory_migrate 

これまでのところ、私たちのグループにはプロセスはありません。 プロセスを追加するには、そのPIDをタスクファイルに書き込む必要があります。次に例を示します。

 $ echo $$ > /sys/fs/cgroup/cpuset/group0/tasks 

$$文字は、現在のシェルによって実行されているプロセスのPIDを示します。

このプロセスはどのCPUコアにも割り当てられていません。これは次のコマンドで確認されます。

 $ cat /proc/$$/status |grep '_allowed' Cpus_allowed: 2 Cpus_allowed_list: 0-1 Mems_allowed: 00000000,00000001 Mems_allowed_list: 0 

このコマンドの出力は、対象のプロセスに番号0および1の2つのCPUコアが使用可能であることを示しています。

このプロセスを番号0のカーネルに「バインド」してみましょう。

 $ echo 0 >/sys/fs/cgroup/cpuset/group0/cpuset.cpus 

何が起こったのか確認してください：

 $ cat /proc/$$/status |grep '_allowed' Cpus_allowed: 1 Cpus_allowed_list: 0 Mems_allowed: 00000000,00000001 Mems_allowed_list: 0 

例2：メモリ管理

前の例で作成したグループを別のサブシステムに埋め込みます。

 $ mkdir /sys/fs/cgroup/memory/group0 

次に、実行します：

 $ echo $$ > /sys/fs/cgroup/memory/group0/tasks 

制御グループgroup0のメモリ消費を制限してみましょう。 これを行うには、ファイルmemory.limit_in_bytesに適切な制限を規定する必要があります。

 $ echo 40M > /sys/fs/cgroup/memory/group0/memory.limit_in_bytes 

cgroupsエンジンは、非常に広範なメモリ管理機能を提供します。 たとえば、その助けにより、重要なプロセスがOOMキラーのホットハンドから攻撃されるのを防ぐことができます。

 $ echo 1 > /sys/fs/cgroup/memory/group0/memory.oom_control $ cat /sys/fs/cgroup/memory/group0/memory.oom_control oom_kill_disable 1 under_oom 0 

たとえば、sshデーモンを別の制御グループに配置し、このグループのOOM-killerを無効にすると、メモリ消費が誇張されても「殺される」ことはありません。

例3：デバイス管理

コントロールグループを別の階層に追加します。

 $ mkdir /sys/fs/cgroup/devices/group0 

デフォルトでは、グループにはデバイスへのアクセスに関する制限がありません。

 $ cat /sys/fs/cgroup/devices/group0/devices.list a *:* rwm 

制限を設定してみましょう。

 $ echo 'c 1:3 rmw' > /sys/fs/cgroup/devices/group0/devices.deny 

このコマンドは、コントロールグループの禁止リストに/ dev / nullデバイスを含めます。 制御ファイルに「c 1：3 rmw」という形式の行を書きました。 最初に、デバイスのタイプを示します。この例では、これは文字デバイス（文字デバイスの略）で示される文字デバイスです。 他の2つのタイプのデバイスは、ブロックデバイス（b）とすべての可能なデバイス（a）です。 以下は、デバイスのメジャー番号とマイナー番号です。 次の形式のコマンドを使用して、番号を確認できます。

 $ ls -l /dev/null 

もちろん、/ dev / nullの代わりに、他のパスを指定できます。 このコマンドの出力は次のようになります。

 crw-rw-rw- 1 root root 1, 3 May 30 10:49 /dev/null 

出力の最初の桁はメジャーで、2番目はマイナー番号です。

最後の3文字はアクセス権を示します。r-指定したデバイスからファイルを読み取る許可、w-指定したデバイスに書き込む許可、m-新しいデバイスファイルを作成する許可

次に、実行します：

 $ echo $$ > /sys/fs/cgroup/devices/group0/tasks $ echo "test" > /dev/null 

最後のコマンドが実行されると、システムはエラーメッセージを表示します。

 -bash: /dev/null: Operation not permitted 

アクセスが拒否されるため、どのような方法でもdevice / dev / nullと対話することはできません。

アクセスを復元する：

 $ echo a > /sys/fs/cgroup/devices/group0/devices.allow 

このコマンドの結果、エントリa *：* rwmが/sys/fs/cgroup/devices/group0/devices.allowファイルに追加され、すべての制限が削除されます。

cgroupとコンテナー

与えられた例から、cgroupsの原理が何であるかは明らかです。特定のプロセスをグループに入れ、それをサブシステムに「埋め込み」ます。 ここで、より複雑な例を調べて、LXCの例を使用して現代のコンテナー化ツールでcgroupがどのように使用されるかを考えてみましょう。

LXCをインストールし、コンテナーを作成します。

 $ sudo apt-get install lxc debootstrap bridge-utils $ sudo lxc-create -n ubuntu -t ubuntu -f /usr/share/doc/lxc/examples/lxc-veth.conf $ lxc-start -d -n ubuntu 

コンテナを作成して起動した後、cgroupsディレクトリで何が変更されたかを見てみましょう。

 $ ls /sys/fs/cgroup/memory cgroup.clone_children memory.limit_in_bytes memory.swappiness cgroup.event_control memory.max_usage_in_bytes memory.usage_in_bytes cgroup.procs memory.move_charge_at_immigrate memory.use_hierarchy cgroup.sane_behavior memory.numa_stat notify_on_release lxc memory.oom_control release_agent memory.failcnt memory.pressure_level tasks memory.force_empty memory.soft_limit_in_bytes 

ご覧のとおり、各階層にlxcディレクトリが表示され、Ubuntuサブディレクトリが含まれています。 lxcディレクトリ内の新しいコンテナごとに個別のサブディレクトリが作成されます。 このコンテナで実行されているすべてのプロセスのPIDは、ファイル/ sys / fs / cgroup / cpu / lxc / [コンテナ名] / tasksに書き込まれます

cgroups制御ファイルを使用するか、次のような特別なlxcコマンドを使用して、コンテナにリソースを割り当てることができます。

 $ lxc-cgroup -n [ ] memory.limit_in_bytes 400 

コンテナーはDocker、systemd-nspawnなどのコンテナーでも同様です。

cgroupの欠点

存在のほぼ10年間、cgroupsメカニズムは繰り返し批判されています。 LWN.netの1つの記事の著者が述べたように、cgroupsコアの開発者は積極的にそれを嫌っています。 この嫌悪の理由は、この記事の例からも理解できますが、感情なしで可能な限り中立にしようとしましたが、コントロールグループを各サブシステムに個別に統合することは非常に不便です。 さらに詳しく見ると、このアプローチは極端な矛盾によって特徴付けられることがわかります。

たとえば、ネストされたコントロールグループを作成すると、一部のサブシステムでは親グループの設定が継承され、一部では継承されません。

cpusetサブシステムでは、親コントロールグループの変更は自動的にネストされたグループに渡されますが、他のサブシステムではそうではないため、clone.childrenパラメーターをアクティブにする必要があります。

cgroupsのこれらの欠点やその他の欠点の除去については、カーネル開発コミュニティで長い間続けられています。 この主題に関する最初のテキストの1つは、 2012年の初めからのものです。

このテキストの著者であるFacebookエンジニアのTeje Hyeは、cgroupの主な問題は、サブシステムが制御グループの多数の階層に接続されている誤った組織であると明示的に指摘しました。 彼は、ただ1つの階層を使用し、各グループのサブシステムを個別に追加することを提案しました。 このアプローチでは、名前が変更されるまで深刻な変更が必要でした。リソース分離メカニズムは、 cgroupではなくcgroup （単数）と呼ばれるようになりました。

実装されたイノベーションの本質をさらに詳しく調べます。

Cgroup v2：新機能

上記のように、cgroup v2はカーネルバージョン4.5以降のLinuxカーネルに含まれています。 ただし、古いバージョンもサポートされています。 バージョン4.6には、カーネルのロード時に最初のバージョンのサポートを無効にできるパッチが既に存在します。

現在、cgroup v2では、blkio、メモリ、PIDの3つのサブシステムのみで作業できます。 CPUリソースの管理を可能にするパッチ（これまでのテストバージョン）が既に登場しています。

Cgroup v2は、次のコマンドを使用してマウントされます。

 $ mount -t cgroup2 none [ ] 

/ cgroup2ディレクトリにcgroup 2をマウントしたとします。 次の制御ファイルがこのディレクトリに自動的に作成されます。

• cgroup.controllers-サポートされているサブシステムのリストが含まれています。
• cgroup.procs-マウントすると、ゾンビプロセスを含む、システムで実行中のすべてのプロセスのリストが含まれます。 グループを作成すると、そのファイルも作成されます。 プロセスがグループに追加されるまで空です。
• cgroup.subtree_control-この制御グループに対してアクティブ化されたサブシステムのリストが含まれています。 デフォルトは空です。

新しいコントロールグループごとに同じファイルが作成されます。 ルートディレクトリにないcgroup.eventsファイルもグループに追加されます。

新しいグループは次のように作成されます。

 $ mkdir /cgroup2/group1 

グループにサブシステムを追加するには、このサブシステムの名前をcgroup.subtree_controlファイルに書き込みます。

 $ echo "+pid" > /cgroup2/group1/cgroup.subtree_control 

同様のコマンドを使用してサブシステムを削除し、プラスの代わりにマイナスのみを配置します。

 $ echo "-pid" > /cgroup2/group1/cgroup.subtree_control 

グループのサブシステムがアクティブになると、追加の制御ファイルがそのグループに作成されます。 たとえば、PIDサブシステムをアクティブにすると、pids.maxおよびpids.currentファイルがディレクトリに表示されます。 これらのファイルの最初のファイルはグループ内のプロセスの数を制限するために使用され、2番目のファイルは現在グループに含まれているプロセスの数に関する情報を含んでいます。

既存のグループ内で、サブグループを作成できます。

 $ mkdir /cgroup2/group1/subgroup1 $ mkdir /cgroup2/group1/subgroup2 $ echo "+memory" > /cgroup2/group1/cgroup.subtree_control, 

すべてのサブグループは、親グループの特性を継承します。 上記の例では、PIDサブシステムはgroup1とその中にネストされた両方のサブグループの両方でアクティブになります。 pids.maxおよびpids.currentファイルもそれらに追加されます。 上記はスキームを使用して説明できます。



ネストされたグループ（上記を参照）との誤解を避けるため、次のルールがcgroup v2に適用されます。サブシステムが既にアクティブになっている場合、ネストされたグループにプロセスを追加できません。



cgroupsの最初のバージョンでは、これらのサブグループが異なるサブシステムに組み込まれた異なる階層の一部である場合、プロセスは同時に複数のサブグループに属することができました。 2番目のバージョンでは、1つのプロセスが1つのサブグループのみに属することができるため、混乱を避けられます。

おわりに

この記事では、cgroupsメカニズムの仕組みと、新しいバージョンに加えられた変更について説明しました。 質問や追加がある場合-コメントへようこそ。

トピックをさらに深く掘り下げたい人のために、興味深い資料へのリンクのリストを以下に示します。

• https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt-cgroupsの最初のバージョンのドキュメント。
• https://www.kernel.org/doc/Documentation/cgroup-v2.txt-cgroup v2 documentation;
• https://www.youtube.com/watch?v=PzpG40WiEfM-cgroup v2の革新に関するTechen Heによる講義。
• https://events.linuxfoundation.org/sites/events/files/slides/2014-KLF.pdf-すべての革新と変更の詳細な説明を含むcgroup v2に関するレポートのプレゼンテーション。

何らかの理由でここにコメントを残せない場合は、 当社のブログにようこそ。