5 分で Docker の 2 番目の原則を理解しましょう。これは Cgroups の最も簡単な入門です。

[[379411]]

この記事はWeChat公式アカウント「妹の味」から転載したもので、著者は妹が飼っている犬です。記事を転載する場合は、ミスシスターテイスト公式アカウントまでご連絡ください。

Docker に触れたことのある学生の多くは、cgroup という用語に出会ったことがあるでしょう。 CPU、メモリなどのリソース制限を実装するのは Linux 上の古い技術です。しかし、多くの学生から、この技術は少しわかりにくく、理解するのが難しいという報告がありました。

これがこの記事の目的であり、最もシンプルかつ直感的な方法で cgroups が何であるかを理解できるようにします。

cgroups は、docker 関数を実装するための重要な基盤機能です。上図に示すように、cgroups を使用すると、オペレーティング システムのさまざまなリソースをプールに変換し、構成を通じて対応するリソースを取得できます。

それで、それはどのように達成されるのでしょうか?

cgroups という用語に注意してください。これには 2 つの特性があります。まず、c は Control を意味し、これは動詞です。 2 番目の部分はグループであり、これがグループであることを証明します。

1. 動詞の目的

制御は何を制限するために使用しますか? CPUとメモリ以外に何がありますか?

現在のシステムでサポートされている制限されたターゲットを表示するには、mount コマンドを使用します。サブシステムと呼ばれる特別な用語があります。

 # マウント | grep cgroup
 /sys/fs/cgroup上のtmpfsタイプ tmpfs (ro、nosuid、nodev、noexec、mode=755)
 /sys/fs/cgroup/systemd上のcgroupタイプ cgroup (rw、nosuid、nodev、noexec、relatime、xattr、release_agent=/usr/lib/systemd/systemd-cgroups-agent、 name =systemd)
 /sys/fs/cgroup/blkio上のcgroup タイプ cgroup (rw、nosuid、nodev、noexec、relatime、blkio)
 /sys/fs/cgroup/devices上のcgroupタイプ cgroup (rw、nosuid、nodev、noexec、relatime、devices)
 /sys/fs/cgroup/cpu、cpuacct上のcgroup タイプ (rw、nosuid、nodev、noexec、relatime、cpuacct、cpu)
 /sys/fs/cgroup/net_cls、net_prio上のcgroup タイプ (rw、nosuid、nodev、noexec、relatime、net_prio、net_cls)
 /sys/fs/cgroup/cpuset上のcgroupタイプ cgroup (rw、nosuid、nodev、noexec、relatime、cpuset)
 /sys/fs/cgroup/memory上のcgroupタイプ cgroup (rw、nosuid、nodev、noexec、relatime、memory)
 /sys/fs/cgroup/freezer上のcgroupタイプ cgroup (rw、nosuid、nodev、noexec、relatime、freezer)
 /sys/fs/cgroup/pids上のcgroupタイプ cgroup (rw、nosuid、nodev、noexec、relatime、pids)
 /sys/fs/cgroup/hugetlb上のcgroupタイプ cgroup (rw、nosuid、nodev、noexec、relatime、hugetlb)
 /sys/fs/cgroup/perf_event上のcgroupタイプ cgroup (rw、nosuid、nodev、noexec、relatime、perf_event)

システムのバージョンによって微妙な違いがあります。一般的に、サブシステムの分類には次のものが含まれます。

• cpu、cpuacct cpuは主にプロセスのCPU使用量を制限し、cpuacctはcgroup内のプロセスのCPU使用量レポートをカウントできます。
• cpusetは、Numaと同様に、cgroup内のプロセスに個別のCPUノードまたはメモリノードを割り当てることができます。
• blkio は、物理デバイス (ディスク、SSD、USB など) などのプロセスのブロック デバイス IO を制限できます。
• デバイス プロセスが特定のデバイスにアクセスする能力を制御します
• net_clsはcgroup内のプロセスのネットワークパケットをマークし、その後tcモジュール（トラフィック制御）を使用してパケットを制御できます。
• net_prio — このサブシステムはネットワークトラフィックの優先順位付けに使用されます
• フリーザーは cgroup 内のプロセスを一時停止または再開できます。
• nsは異なるcgroup下のプロセスに異なる名前空間を使用さ​​せることができる
• hugetlb は主に、大規模ページ ファイル システムである HugeTLB システムに限定されます。

内容は多岐にわたりますが、私たちが普段注目するのはメモリとCPUです。これらの複雑な詳細は、設計原理の理解には影響しません。

CPU を例に取って、システムの実際のパフォーマンスを見てみましょう。

2. CPU使用制限の例

まず、CPU サブシステム ディレクトリに入ります。

 /sys/fs/cgroup/cpu に移動します

次に、グループ名 xjjdog で cgroup を作成します。この名前はコントロールグループと呼ばれます。

 mkdir xjjdog

このとき、不思議なことが起こりました。 ll コマンドを使用して xjjdog ディレクトリの内容を表示すると、システムによってデフォルトで多数のファイルが生成されたことがわかります。

 #ll xjjdog/
合計 0
 -rw-r --r-- 1 ルート ルート 0 1月28日 21:09 cgroup.clone_children  
 --w--w--w- 1 ルート ルート 0 1月28日 21:09 cgroup.event_control  
 -rw-r --r-- 1 ルート ルート 0 1月28日 21:09 cgroup.procs  
 -r --r--r-- 1 root root 0 1月28日 21:09 cpuacct.stat  
 -rw-r --r-- 1 root root 0 1月28日 21:09 cpuacct.usage  
 -r --r--r-- 1 root root 0 1月28日 21:09 cpuacct.usage_percpu  
 -rw-r --r-- 1 ルート ルート 0 1月28日 21:09 cpu.cfs_period_us  
 -rw-r --r-- 1 ルート ルート 0 1月28日 21:09 cpu.cfs_quota_us  
 -rw-r --r-- 1 ルート ルート 0 1月28日 21:09 cpu.rt_period_us  
 -rw-r --r-- 1 ルート ルート 0 1月28日 21:09 cpu.rt_runtime_us  
 -rw-r --r-- 1 root root 0 1月28日 21:09 cpu.shares  
 -r --r--r-- 1 root root 0 1月28日 21:09 cpu.stat  
 -rw-r --r-- 1 root root 0 1月28日 21:09 notification_on_release  
 -rw-r --r-- 1 root root 0 1月28日 21:09 タスク 

これらのファイル内の値を制御することで、リソースを制限することができます。例えば、cpu.cfs_quota_us ファイルに 100000 (10 万) と書き込むと、xjjdog の cgroup が使用され、CPU のコアが最大 1 つ使用できることが証明されます。 20000 と書くと、CPU コアの最大 1/5 が使用されていることが証明されます。

これは、cpu.cfs_period_us 構成ファイルがデフォルトで 1 つの CPU コアを 100,000 個の部分に分割するためです。

次に 20000 と書いて試してみます。

 sudo エコー 20000 > xjjdog/cpu.cfs_quota_us

現在のシェルの pid を制御対象プロセスのリストに追加します。

エコー $$ > xjjdog/tasks

実行が完了すると、無限ループが開始されます。

 true の場合;do ;done;

シェルを再度開き、top を使用して CPU 使用率を確認します。無限ループでは CPU が最大で 20% しか使用されていないことがわかります。 us は 20% 未満に留まり、CPU を継続的に切り替えます。

以下のコマンドを 1 つずつテストすると、CPU 使用率が徐々に増加し、ほぼ限界に達することがわかります。

 sudo エコー 40000 > xjjdog/cpu.cfs_quota_us
 sudo エコー 60000 > xjjdog/cpu.cfs_quota_us
 sudo エコー 100000 > xjjdog/cpu.cfs_quota_us

その他のリソース制約も同様のアプローチに従います。最も重要なことは、cpu.cfs_quota_us などの単語の意味を知ることです。これらはマニュアルを読めば簡単に理解できます。たとえば、quota は割り当てを意味し、明らかにリソースの使用を制限することを意味します。

上記のように、サブシステムは複数のタスクを制御し、それらを制御グループに含めることができます。前回の記事では、docker システムの 1 番目のプロセスとして bash プロセスを使用できることを説明しました。同様に、このプロセス 1 の子プロセスは同じ制限構成を共有します。

3. グループの意味

一般的に、グループとはさまざまなリソースをグループ化することを指します。名前が異なるリソースには、異なる分離構成があります。しかし、他にも多くの機能があります。

さらに重要なのはその階層です。これも比較的理解しやすいもので、主に構成を簡素化するために存在します。

たとえば、上記の xjjdog ディレクトリでは、CPU が 0.5 コアに制限されます。今回は、CPU の使用を 0.5 コア、メモリを 1 GB に制限する別のアプリケーションを用意したいと思います。次に、xjjdog ディレクトリの下に xjjdog0 ディレクトリを直接作成し、xjjdog0 ディレクトリの下のメモリのみを構成できます。

さらに、外側のレイヤーで CPU クォータを 2 コアに制限し、継承されたディレクトリで 1/5 コアに制限すると、オペレーティング システムの 2/5 コアしか使用できなくなります。これも継承の特徴です。

終わり

cgroups は、2006 年に Google のエンジニア (Rohit Seth と Paul Menage) によって作成されました。 2008 年に Linux バージョン 2.6.24 に統合されたこのテクノロジは非常に古いと言えます。 Cgroups は現在、systemd、Docker、Linux Containers (LXC) などのテクノロジーの基盤となっています。

たとえば、Windows プラットフォーム上の WSL には cgroups 機能がないため、mount コマンドを使用して確認すると、基盤が不足しているため Docker を実行できないことがわかります。ただし、WSL2 ではすでにそれが実現されています。

Docker の現在の開発状況に少し不安を感じている学生もいますが、こうした共通の基本原理を理解してコンテナ標準を読んでいくと、Docker に置き換えても containerd に置き換えても上位層の実装は同じであることがわかります。

著者について: Sister Taste (xjjdog)、プログラマーが寄り道をすることを許可しない公開アカウント。インフラストラクチャと Linux に重点を置きます。 10 年間のアーキテクチャと 1 日あたり数千億のトラフィックを基に、私たちはお客様とともに高並行性の世界を探求し、新たな体験をお届けします。私の個人WeChatはxjjdog0です。今後のコミュニケーションのために、私を友達として追加してください。