docker kill が実行中のコンテナーを強制終了できない場合があるのはなぜですか?

Docker Kill メイン プロセス

1. Docker エンジンは SIGKILL を使用して、containerd 経由でコンテナのメイン プロセスに送信します。コンテナ終了メッセージがcontainerdから受信されると、コンテナの強制終了が成功します。

2. 前のステップで待機がタイムアウトになった場合、Docker エンジンは Containerd をスキップし、kill システム コールを通じてコン​​テナのメイン プロセスに SIGKILL シグナルを送信します。 kill システム コールによってメイン プロセスが現時点では存在しないことが返された場合、Docker kill は成功です。そうしないと、containerd がエンジンを通過してコンテナが終了するまで、エンジンは停止したままになります。

問題が発生すると、ホスト マシン上で多数のストレス プロセス (実際にはコンテナ プロセス) が D 状態になり、システムの応答が遅くなります。この問題は次のように説明できます:

1, Docker kill が、containerd を介してコンテナのメイン プロセスに間接的に SIGKill シグナルを送信した後、システムの応答が遅いため、内部の子プロセス (ストレス) ) コンテナーは D 状態にあるため、タイムアウト期間中、Containerd はコンテナーの終了を報告しませんでした。 Docker kill は、Sigkill を直接送信する段階に達しました。

2, この段階の前に、コンテナ内のメイン プロセスが終了しているため、システム コール kill と send SIGKILL はすぐに、プロセスが存在しません。エンジンはコンテナーを強制終了したと認識し、Docker kill は正常に戻ります。

3. 一定の時間が経過すると、コンテナのサブプロセスが D 状態から回復します。サブプロセスは終了し、containerd はコンテナの終了を報告し、エンジンはリソースをクリーンアップします。このとき、Docker ps は、コンテナが終了状態にあることを確認します。

コンテナ マスター/子プロセスは D 状態です

プロセス D 状態は、プロセスが中断不可能なスリープ状態にあり、通常は IO リソースを待っていることを示します。もちろん、システム IO に問題がある場合には、多数のプロセスが D 状態になることがあります。この状態では、シグナルはプロセスをウェイクアップできず、プロセスが D 状態から戻るのを待つことしかできません。また、従来のカーネルでは、プロセスが D 状態になった場合、理論的にはシステムを再起動する以外に D 状態から戻す方法も手段もありません。

その他の関連チュートリアルについては、PHP 中国語 Web サイトの docker チュートリアル 列に注目してください。

以上がdocker kill が実行中のコンテナーを強制終了できない場合があるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。