コンテナが単一プロセス モデルであるのはなぜですか?

現在、Go 言語の主な応用分野の 1 つは、コンテナ (Docker に代表される)、Kubernetes、Prometheus などを含むクラウド ネイティブ テクノロジーです。後ほど、クラウド ネイティブ テクノロジー スタックの主要テクノロジーを紹介する一連の記事を書く予定です。

過去 2 年間、多くの大企業にとって主要な技術的方向性の 1 つは、アプリケーションをクラウドに移行することでした。このプロセスにおける典型的な誤用は、コンテナを仮想マシンとして使用し、コンテナ内で一連のプロセスを開始することです。ただし、コンテナと仮想マシンのプロセス管理機能には大きな違いがあります。コンテナでも仮想マシンでも、プロセス番号 1 が存在します。仮想マシンでは systemd プロセスであり、コンテナではエントリポイントの起動プロセスです。その後、他のすべてのスレッドはプロセス番号 1 の子プロセス、または子プロセスの子プロセスとなり、これを再帰的に繰り返します。ここでの主な違いは、systemd プロセスがゾンビ プロセスをリサイクルできるかどうかです。より多くのコンテナ技術の専門家とコミュニケーションを取りたい場合は、私の WeChat liyingjiese を追加し、「グループに参加」と記入してください。このグループは、世界中の大手企業のベストプラクティスと業界の最新動向を毎週報告しています。

[[277611]]

ゾンビプロセス

ゾンビ プロセスといえば、Linux システムにおけるプロセスの状態について簡単に説明します。 ps や top などのコマンドを使用して、システム内のプロセスを表示できます。たとえば、ecs 仮想マシンで ps aux を実行すると、次の出力が得られます。

 [root@emr-header-1 ~]# ps 補助
ユーザーPID %CPU %MEM VSZ RSS TTY STAT 開始時間コマンド
ルート 1 0.1 0.0 190992 3568 ? Ss 3月16日 289:04 /usr/lib/systemd/systemd --switched-root --system --de  
ルート 2 0.0 0.0 0 0 ? S 3月16日 0:05 [kthreadd]
ルート 3 0.0 0.0 0 0 ? S 3月16日 13:01 [ksoftirqd/0]
ルート 5 0.0 0.0 0 0 ? S< 3月16日 0:00 [kworker/0:0H]
ルート 7 0.0 0.0 0 0 ? S 3月16日 14:41 [移行/0]
ルート 8 0.0 0.0 0 0 ? S 3月16日 0:00 [rcu_bh]
ルート 9 0.0 0.0 0 0 ? S 3月16日 243:19 [rcu_sched]
ルート 10 0.0 0.0 0 0 ? S 3月16日 0:50 [ウォッチドッグ/0]
ルート 11 0.0 0.0 0 0 ? S 3月16日 0:39 [ウォッチドッグ/1]
ルート 12 0.0 0.0 0 0 ? S 3月16日 23:51 [移行/1]
ルート 13 0.0 0.0 0 0 ? S 3月16日 15:44 [ksoftirqd/1]
ルート 15 0.0 0.0 0 0 ? S< 3月16日 0:00 [kworker/1:0H]

最初のものは、先ほど説明したプロセス No. 1 systemd であることがわかります。 STAT 列はプロセスのステータスです。ここでのステ​​ータスはすべて S に関連していますが、通常は R、D、Z などのステータスもあります。各ステータスの意味を簡単に説明すると次のようになります。

• S:割り込み可能なスリープは、中国語では割り込み可能なスリープ状態とも呼ばれ、特定のリソースまたはイベントの準備が整うのを待っているため、システムによってプロセスが一時的に中断されていることを意味します。リソースまたはイベントが準備完了になると、プロセスは R 状態に切り替わります。
• R:これは Running の略で、Runnable を指す場合もあります。これは、プロセスが実行中であるか、実行を待機中であることを示します。
• Z:ゾンビ、つまりゾンビプロセスです。各プロセスは pid などの特定のリソースを占有することがわかっています。プロセスが終了してもリソースがリサイクルされない場合、そのプロセスはゾンビ プロセスになります。
• D:ディスク スリープは、中断不可能なスリープとも呼ばれ、中断不可能なスリープ状態です。通常、プロセスは IO やその他のリソースを待機しており、中断することはできません。 D状態 実際に初めてPSを使うときに、つまづく人も多いと思います。通常、IO およびその他のリソースの準備が完了すると、D 状態は R 状態に切り替わります。プロセスが長時間 D 状態にある場合、IO に問題があることが多いです。ほとんどの場合、解決策はマシンを再起動することです。
• I:アイドル、つまりアイドル状態、割り込み不可能なスリープ状態にあるカーネル スレッド。 D 状態プロセスとの主な違いは、実際には負荷の増加を引き起こさない可能性があることです。

ゾンビプロセスに関しては、ここで議論を続けましょう。通常の使用では、子プロセスを作成するには、通常、親プロセスがシステム コール wait() または waitpid() を介して子プロセスが終了するのを待機し、子プロセスのリソースを再利用する必要があります。この方法に加えて、リサイクルは非同期的に実行することもできます。この方法の基本は、子プロセスが終了した後、親プロセスに SIGCHLD シグナルを送信することです。これに基づいて、親プロセスは子プロセスのリソースをリサイクルするための SIGCHLD シグナル処理関数を登録します。これら 2 つの方法を覚えておいてください。それらについては後で説明します。

ゾンビ プロセスの最大の害は、プロセス番号などのリソースが永続的に占有されることです。システムには最大プロセス数 n の制限があり、プロセス番号 1 から n が占有されると、システムはプロセスとスレッドを作成できなくなります (OS では、プロセスとスレッドは同じデータ構造 task_struct で表されます)。この時点で、ユーザーの直感では、シェルはコマンドを実行できないと感じます。その理由は、シェルコマンド実行の本質は fork だからです。

 [root@emr-header-1 ~]# ulimit -a
コアファイルサイズ(ブロック、-c) 0
データセグメントサイズ(キロバイト、-d) 無制限
スケジュール優先度 (-e) 0
ファイルサイズ（ブロック、-f）無制限
保留中のシグナル (-i) 63471
最大ロックメモリ (キロバイト、-l) 64
最大メモリサイズ(キロバイト、-m) 無制限
開いているファイル (-n) 131070
パイプサイズ(512 バイト、-p) 8
 POSIX メッセージ キュー (バイト、-q) 819200
リアルタイム優先度( -r ) 0
スタックサイズ(kbytes, -s) 8192
 CPU時間（秒、-t）無制限
最大 ユーザープロセス (-u) 63471
仮想メモリ (キロバイト、-v) 無制限
ファイルロック (-x) 無制限

孤立したプロセス

前述したように、子プロセスが親プロセスより先に終了し、親プロセスが子プロセスの残りのリソースをリサイクルしない場合は、ゾンビ プロセスが生成されます。ここに別の状況があります。親プロセスが子プロセスより先に終了した場合、子プロセスのリソースを誰が再利用するのでしょうか?

親プロセスは子プロセスより先に終了します。この時点で、まだ実行中の子プロセスを一般に孤立プロセスと呼びます。ただし、実際には孤立プロセスの明確な定義はなく、そのステータスは上記で説明したいくつかのプロセス状態のままです。では、孤立プロセスのリソースを誰が回収するのでしょうか?この状況に対応して、Unix 系システムでは、これらの孤立プロセスの親プロセスをプロセス番号 1、つまり systemd プロセスに設定し、systemd は孤立プロセスのリソースを再利用します。

シングルプロセスモデルの本質

上記の 2 つのセクションを読んだ後、仮想マシンまたは完全な OS がゾンビ プロセスを回避する方法がわかるはずです。ただし、コンテナでは、プロセス 1 が一般にエントリ ポイント プロセスになります。コンテナは、ゾンビプロセス処理を回避するために、孤立プロセスの親プロセスをプロセス番号 1 に設定する上記の方法を処理できません。これにより、孤立プロセスなどの異常なシナリオでは、コンテナ内のゾンビプロセスを完全に処理できないというジレンマが発生します。

したがって、コンテナの単一プロセス モデルの本質は、コンテナ内のプロセス 1 には、複数のプロセスや複数のスレッドなどの複雑なシナリオを管理する機能がないことです。これらの複雑な状況をコンテナ内で処理する必要がある場合、開発者はエントリ ポイント プロセスにこの機能を提供する必要があります。これにより、開発者の精神的負担が増大することは間違いありません。これは、一般的なテクノロジーやプラットフォーム フレームワークが望まない恥ずかしい状況です。

回避方法

開発者がエントリポイント プロセスに複数のプロセスを管理する機能を与えることについてのセクション 2 での説明に加えて、これを行うには Kubernetes を使用することをお勧めします。今では誰もコンテナを手動で管理していないと思います。ほとんどの人はコンテナ オーケストレーションおよびスケジューリング ツール Kubernetes に目を向けています (まだ Swarm を使用している人には、できるだけ早く暗闇を捨てて光に参加することをお勧めします :))。

Kubernetes では、複数のコンテナを Pod にオーケストレーションし、同じ Linux NameSpace を共有できます。この技術の本質は、Kubernetes を使用して一時停止イメージを提供することです。詳しく説明すると、一時停止イメージを使用して最初に NameSpace をインスタンス化し、次に他のコンテナーをこの NameSpace に追加して NameSpace の共有を実現します。突然、これにはコンテナと名前空間の技術的な背景が必要であることに気付きました。スペースが限られているため、この技術的な背景についてはご自身で調べていただければ幸いです。あるいは、次の記事でコンテナ技術の本質について論じるつもりです。

では早速、一時停止について紹介しましょう。 Pause は、Kubernetes バージョン 1.16 で導入されたテクノロジーです。 pause を使用するには、次のように、Pod によって作成された yaml で shareProcessNamespace パラメータを true に指定するだけです。

 APIバージョン: v1
種類: ポッド
メタデータ:
名前: nginx
仕様:
プロセス名前空間を共有: true  
コンテナ:
 -名前: nginx
画像: nginx
 -名前: シェル
画像: ビジーボックス
セキュリティコンテキスト:
  機能:
追加：
    -SYS_PTRACE
標準入力:真 
端末:真 

ポッドを作成する:

 kubectl を適用 -fshare-プロセス名前空間.yaml

Pod に接続し、ps を使用してプロセス リストを表示します。

 / # ps 斧
PIDユーザー     タイムコマンド
1 ルート 0:00 /一時停止
8 root 0:00 nginx: マスタープロセス nginx -g デーモンオフ;
 14 101 0:00 nginx: ワーカープロセス
15 ルート 0:00 sh
 21 ルート 0:00 ps ax

Pod 内のプロセス 1 が /pause になり、他のコンテナのエントリポイント プロセスがプロセス 1 の子プロセスになることがわかります。ここで、問題の核心に迫ります。/pause プロセスは、ゾンビ プロセスを回避するために、どのようにして孤立プロセスの親をプロセス 1 に設定するのでしょうか。ソースコードを見てみましょう。git リポジトリ: pause.c:

 #define STRINGIFY(x) #x
 #define VERSION_STRING(x) STRINGIFY(x) 
 
 #ifndef バージョン
#define バージョンヘッド
#終了
 
静的void sigdown( int signo) {
 psignal(signo, "シャットダウン中、信号を受信しました" );
終了(0);
 } 
 
静的void sigreap( int signo) {
 (waitpid(-1, NULL , WNOHANG) > 0)の間
;
 } 
 
 int main( int argc, char **argv) {
整数i;
 (i = 1; i < argc; ++i)の場合{
 if (!strcasecmp(argv[i], "-v" )) {
  printf( "pause.c %s\n" , VERSION_STRING(VERSION));
 0を返します。
 }
 } 
 
 (getpid() != 1) の場合
/* pause はインフラ コンテナーの外部で使用されるため、エラーにはなりません。 */
 fprintf(stderr, "警告: 一時停止は最初のプロセスである必要があります\n" ); 
 
 （sigaction（SIGINT、＆（struct sigaction）{.sa_handler = sigdown}、 NULL ）< 0）の場合
1 を返します。
 if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL ) < 0)
 2を返します。
 if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap,
                                         .sa_flags = SA_NOCLDSTOP},
 NULL ) < 0)
 3を返します。 
 
のために（;;）
一時停止（）;
 fprintf(stderr, "エラー: 無限ループが終了しました\n" );
 42を返します。
 }

35 行目と 13 行目に特に注意してください。これが上で説明した内容です。

• この方法に加えて、リサイクルは非同期的に実行することもできます。この方法の基本は、子プロセスが終了した後、親プロセスに SIGCHLD シグナルを送信することです。これに基づいて、親プロセスは子プロセスのリソースをリサイクルするための SIGCHLD シグナル処理関数を登録します。

SIGCHLD シグナル処理関数の中核は、 while (waitpid(-1, NULL, WNOHANG) > 0) の行です。ここで、WNOHANG パラメータは、親プロセスがブロックせずに直接戻ることを可能にします。

要約する

コンテナ化への変革への道のりは非常に長いです。変換プロセス中、多くのビジネス関係者は、思考の慣性によりコンテナを仮想マシンとして使用したいと考えますが、これにより多くの問題が発生する可能性があります。おそらく、より良い実践のために、いくつかのコンテナ設計パターンを検討することができるでしょう。