ACC-LのDockerによるスケーラビリティの限界(overlay2)

技術的な記事 ID: KB95991
最終更新: 2022-09-22 08:32:31 Etc/GMT

環境

Application and Change Control (ACC) 6.4.22 またはそれ以上
ContainerランタイムとしてDockerまたはKubernetesを使用

注:このKBは、overlay2としてストレージドライバに限定されます。

問題

コンテナの数が例えば20個を超えると、デプロイ時間が増加します。
Kubernetesでコンテナをデプロイしている間、コンテナの数が増えるとデプロイ時間が3倍から4倍になる。このデプロイの増加は、コンテナオーケストレーターに問題を生じさせる。

原因

ACCには、ファイルシステムのフックとコールバックを取得するためのシステムコールのフックを行うドライバモジュールが含まれています。コールバックを受けると、実行可能ファイルやファイルに対して、実行のALLOWやDENY、CHANGE CONTROLの判断が行われる。この決定を行うには、物理および仮想の両方の新しいブロックデバイスをすべてスキャンし、フックを追加する必要があります(サポートされている場合)。

Kubernetes によるコンテナのデプロイ（大規模化）を、コンテナランタイムとして docker を用いて実行した場合、上記のような問題が発生する。各コンテナイメージは、マウントとアンマウントの呼び出しを複数回受けることになります。また、 Pod の並列展開により、ボトルネックや共有リソースの競合（データ競合を回避するために保護されている）が発生します。このボトルネックは、呼び出しの処理の遅延につながり、 Pod の NotReady や Terminating のような状態を作り出します。

解決策

この問題を解決するには、 solidcore.conf ファイルの ProcPassThru リストに、以下のプロセスを既存のリストと一緒に追加してください。

runc
runc:[2:INIT]
kubelet
dockerd

追加されると、以下のように表示されます:

ProcPassThruList = { .....
runc
runc:[2:INIT]
…
}

特定のアプリケーションのために、信頼できるリポジトリからのプロセスを追加して、さらに支援することもできます。

そのようなプロセスを識別する手順は次のとおりです:

Kubernetes で遅延や NotReady ステータスに気づいたときのトップ出力を観察する。
CPU を多く消費しているプロセスで、上記の信頼できる部分に準拠しているものをリストアップする。
上記で提案したように ProcPassThruList にリストを追加する。

注: コンテナが 30 個以上ある場合は、デプロイメントにかかる時間が長くなることが予想されます。上記の手順により、30 個未満のコンテナのデプロイメント時間が短縮されます。30 という数字は、テストにおける最悪のケースを表しています。アプリケーションの種類によっては、この数より多くなることもあります。

免責事項

この記事の内容のオリジナルは英語です。英語の内容と翻訳に相違がある場合、常に英語の内容が正確です。一部の内容は Microsoft の機械翻訳による訳文となっています。

影響を受ける製品

言語:

この記事は、次の言語で表示可能です:

Knowledge Center

ACC-LのDockerによるスケーラビリティの限界(overlay2)

環境

問題

原因

解決策

免責事項

影響を受ける製品

言語:

Title

Title

Knowledge Center

ACC-LのDockerによるスケーラビリティの限界(overlay2)

環境

問題

原因

解決策

免責事項

影響を受ける製品

言語:

地域を選択してください

Title

Title