第7章 コンテナーの使用
7.1. コンテナーについて
OpenShift Container Platform アプリケーションの基本的な単位は コンテナー と呼ばれています。Linux コンテナーテクノロジー は、指定されたリソースのみと対話するために実行中のプロセスを分離する軽量なメカニズムです。
数多くのアプリケーションインスタンスは、相互のプロセス、ファイル、ネットワークなどを可視化せずに単一ホストのコンテナーで実行される可能性があります。通常、コンテナーは任意のワークロードに使用されますが、各コンテナーは Web サーバーまたはデータベースなどの (通常は "マイクロサービス" と呼ばれることが多い) 単一サービスを提供します。
Linux カーネルは数年にわたりコンテナーテクノロジーの各種機能を統合してきました。OpenShift Container Platform および 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 Container Platform コンテナーで設定済みのメモリー制限を超える可能性があり、これにより、コンテナーが強制終了される可能性があります。
カーネルメモリーの問題によりコンテナーが失われないようにするには、コンテナーが十分なメモリーを要求することを確認します。以下の式を使用して、kmem_cache が消費するメモリー量を見積ることができます。この場合、nproc は、nproc コマンドで報告される利用可能なプロセス数です。コンテナーの要求の上限が低くなる場合、この値にコンテナーメモリーの要件を加えた分になります。
$(nproc) X 1/2 MiB
7.1.2. コンテナーエンジンとコンテナーランタイムについて
コンテナーエンジン は、コマンドラインオプションやイメージのプルなど、ユーザーの要求を処理するソフトウェアです。コンテナーエンジンは、コンテナーランタイム (下位レベルのコンテナーランタイム とも呼ばれる) を使用して、コンテナーのデプロイと操作に必要なコンポーネントを実行および管理します。コンテナーエンジンまたはコンテナーランタイムとやり取りする必要はほとんどありません。
OpenShift Container Platform のドキュメントでは、コンテナーランタイムという用語を使用して、下位レベルのコンテナー ランタイム を指します。他のドキュメントでは、コンテナーエンジンをコンテナーランタイムと呼んでいる場合があります。
OpenShift Container Platform は、コンテナーエンジンとして CRI-O を使用し、コンテナーランタイムとして runC または crun を使用します。デフォルトのコンテナーランタイムは runC です。どちらのコンテナーランタイムも、Open Container Initiative (OCI) ランタイム仕様に準拠しています。
CRI-O は Kubernetes ネイティブコンテナーエンジン実装です。これはオペレーティングシステムに密接に統合し、Kubernetes の効率的で最適化されたエクスペリエンスを提供します。CRI-O コンテナーエンジンは、各 OpenShift Container Platform クラスターノードで systemd サービスとして実行されます。
Docker によって開発され、Open Container Project によって維持されている runC は、Go で記述された軽量で移植可能なコンテナーランタイムです。Red Hat によって開発された crun は、完全に C で記述された高速で低メモリーのコンテナーランタイムです。OpenShift Container Platform 4.16 の時点で、2 つのいずれかを選択できます。
crun は、runC に対して次のようないくつかの改善点があります。
- 小さいバイナリー
- より迅速な処理
- メモリーのフットプリントが小さい。
runC には、次のような利点があります。
- 最も一般的な OCI コンテナーランタイム。
- 生産期間が長くなります。
- CRI-O のデフォルトのコンテナーランタイム。
必要に応じて、2 つのコンテナーランタイム間を移動できます。
使用するコンテナーランタイムの設定については、CRI-O パラメーターの編集に使用する ContainerRuntimeConfig CR の作成 を参照してください。
