第7章 コンテナーの使用
7.1. コンテナーについて リンクのコピーリンクがクリップボードにコピーされました!
コンテナーは、OpenShift Dedicated アプリケーションの基本単位であり、プロセスを分離して移植可能なマイクロサービスを提供します。クラスターの安定性を維持するには、コンテナーランタイムがワークロードをどのように管理するか、そしてカーネルのメモリー割り当てがノードのリソース制限にどのような影響を与えるかを理解する必要があります。
Linux コンテナーテクノロジー は、指定されたリソースのみと対話するために実行中のプロセスを分離する軽量なメカニズムです。
数多くのアプリケーションインスタンスは、相互のプロセス、ファイル、ネットワークなどを可視化せずに単一ホストのコンテナーで実行される可能性があります。通常、コンテナーは任意のワークロードに使用されますが、各コンテナーは Web サーバーまたはデータベースなどの (通常は "マイクロサービス" と呼ばれることが多い) 単一サービスを提供します。
Linux カーネルは数年にわたりコンテナーテクノロジーの各種機能を統合してきました。OpenShift Dedicated および Kubernetes は複数ホストのインストール間でコンテナーのオーケストレーションを実行する機能を追加します。
7.1.1. コンテナーおよび RHEL カーネルメモリーについて リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux (RHEL) の動作特性上、CPU 使用率の高いノード上のコンテナーは、予想よりも多くのメモリーを消費しているように見える場合があります。メモリー消費量の増加は、RHEL カーネルの kmem_cache によって引き起こされる可能性があります。RHEL カーネルは、それぞれの cgroup に kmem_cache を作成します。パフォーマンスの強化のために、kmem_cache には cpu_cache と任意の NUMA ノードのノードキャッシュが含まれます。これらのキャッシュはすべてカーネルメモリーを消費します。
これらのキャッシュに保存されるメモリーの量は、システムが使用する CPU の数に比例します。結果として、CPU の数が増えると、より多くのカーネルメモリーがこれらのキャッシュに保持されます。これらのキャッシュ内のカーネルメモリーの量が増えると、OpenShift Dedicated コンテナーが設定されたメモリー制限を超え、コンテナーが強制終了される可能性があります。
カーネルメモリーの問題によりコンテナーが失われないようにするには、コンテナーが十分なメモリーを要求することを確認します。以下の式を使用して、kmem_cache が消費するメモリー量を見積ることができます。この場合、nproc は、nproc コマンドで報告される利用可能なプロセス数です。コンテナーの要求の上限が低くなる場合、この値にコンテナーメモリーの要件を加えた分になります。
$(nproc) X 1/2 MiB
7.1.2. コンテナーエンジンとコンテナーランタイムについて リンクのコピーリンクがクリップボードにコピーされました!
コンテナーエンジン は、コマンドラインオプションやイメージのプルなど、ユーザーの要求を処理するソフトウェアです。コンテナーエンジンは、コンテナーランタイム (下位レベルのコンテナーランタイム とも呼ばれる) を使用して、コンテナーのデプロイと操作に必要なコンポーネントを実行および管理します。コンテナーエンジンまたはコンテナーランタイムとやり取りする必要はほとんどありません。
OpenShift Dedicated のドキュメントでは、コンテナーランタイム という用語は、下位レベルのコンテナーランタイムを指すために使用されています。他のドキュメントでは、コンテナーエンジンをコンテナーランタイムと呼んでいる場合があります。
OpenShift Dedicated は、コンテナーエンジンとして CRI-O を使用し、コンテナーランタイムとして crun または runC を使用します。デフォルトのコンテナーランタイムは crun です。
OpenShift Dedicated 4.22 以降、runC コンテナーランタイムは非推奨となりました。