第2章 システムおよび環境要件
2.1. システム要件
OpenShift Container Platform 環境のホストは以下のハードウェア仕様およびシステムレベルの要件を満たしている必要があります。
2.1.1. Red Hat サブスクリプション
まず、お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがなければなりません。これがない場合は、営業担当者にお問い合わせください。
2.1.2. ハードウェアの最小要件
システムの要件はホストのタイプによって異なります。
| |
| |
外部 etcd ノード |
|
Ansible コントローラー | Ansible Playbook を実行するホストには、ホストあたり 75MiB 以上の空きメモリーがインベントリーで必要になります。 |
RHEL Atomic Host で /var/ファイルシステムのサイジング要件を満たすには、デフォルト設定に変更を加える必要があります。インストール時またはインストール後にこの設定を行う方法については、Managing Storage in Red Hat Enterprise Linux Atomic Host を参照してください。
システムの一時ディレクトリーは、Python の標準ライブラリーの
tempfile
モジュールで定義されるルールに基づいて決定されます。
コンテナーデーモンを実行する各システムのストレージを設定する必要があります。コンテナー化インストールの場合、マスターにストレージが必要になります。また、Web コンソールはマスターのコンテナーで実行され、マスターには Web コンソールを実行するためにストレージが必要です。コンテナーはノードで実行されるため、ノードにはストレージが常に必要になります。ストレージのサイズはワークロード、コンテナー数、実行中のコンテナーのサイズおよびコンテナーのストレージ要件によって異なります。また、ストレージをコンテナー化された etcd を実行するように設定する必要もあります。
NVMe や SSD などのシリアル書き込み (fsync) を迅速に処理するストレージで etcd を使用することが強く推奨されます。Ceph、NFS、およびスピニングディスクは推奨されません。
2.1.3. 実稼働環境レベルのハードウェア要件
テストまたはサンプル環境は最小要件で機能します。実稼働環境の場合、以下の推奨事項が当てはまります。
- マスターホスト
- 外部 etcd を含む可用性の高い OpenShift Container Platform クラスターにおいて、マスターホストには、上記の表にある最小要件のほかに、1000 Pod に対して 1 CPU コアと 1.5 GB のメモリーが必要になります。したがって、2000 Pod で設定される OpenShift Container Platform クラスターのマスターホストの推奨されるサイズとして、2 CPU コアと 16 GB の RAM に 2 CPU コアと 3 GB の RAM を追加した合計 4 CPU コアと 19 GB の RAM が最小要件として必要になります。
パフォーマンスに関するガイダンスについては、 Recommended Practices for OpenShift Container Platform Master Hosts を参照してください。
- ノードホスト
- ノードホストのサイズは、そのワークロードの予想されるサイズによって異なります。OpenShift Container Platform クラスターの管理者は、予想されるワークロードを計算し、オーバーヘッドの約 10 パーセントを追加する必要があります。実稼働環境の場合、ノードホストの障害が最大容量に影響を与えることがないよう、十分なリソースを割り当てるようにします。
詳細は、 サイジングに関する考慮事項および Cluster Limits を参照してください。
ノードでの物理リソースの過剰なサブスクライブは、Kubernetes スケジューラーが Pod の配置時に行うリソース保証に影響を与えます。メモリースワップを防ぐ ために実行できる処置について確認してください。
2.1.4. ストレージ管理
ディレクトリー | 注記 | サイジング | 予想される拡張 |
---|---|---|---|
/var/lib/openshift | 単一マスターモードの場合に etcd ストレージのみに使用され、etcd は atomic-openshift-master プロセスで組み込まれます。 | 10GB 未満。 | 環境と共に徐々に拡張します。メタデータのみを格納します。 |
/var/lib/etcd | 複数マスターモードの場合や etcd が管理者によってスタンドアロンにされる場合に etcd ストレージに使用されます。 | 20 GB 未満。 | 環境と共に徐々に拡張します。メタデータのみを格納します。 |
/var/lib/docker | ランタイムが docker の場合、これはマウントポイントになります。アクティブなコンテナーランタイム (Pod を含む) およびローカルイメージのストレージに使用されるストレージです (レジストリーストレージには使用されません)。マウントポイントは手動ではなく、docker-storage で管理される必要があります。 | 16 GB メモリーの場合、1 ノードにつき 50 GB。 メモリーに 8 GB が追加されるたびに 20-25 GB を追加します。 | 拡張は実行中のコンテナーの容量によって制限されます。 |
/var/lib/containers | ランタイムが CRI-O の場合、これはマウントポイントになります。アクティブなコンテナーランタイム (Pod を含む) およびローカルイメージのストレージに使用されるストレージです (レジストリーストレージには使用されません)。 | 16 GB メモリーの場合、1 ノードにつき 50 GB。 メモリーに 8 GB が追加されるたびに 20-25 GB を追加します。 | 拡張は実行中のコンテナーの容量によって制限されます。 |
/var/lib/origin/openshift.local.volumes | Pod の一時ボリュームストレージです。これには、ランタイムにコンテナーにマウントされる外部のすべての内容が含まれます。環境変数、kube シークレット、および永続ストレージ PV でサポートされていないデータボリュームが含まれます。 | 変動あり。 | ストレージを必要とする Pod が永続ボリュームを使用している場合は最小になります。一時ストレージを使用する場合はすぐに拡張する可能性があります。 |
/var/log | すべてのコンポーネントのログファイルです。 | 10 から 30 GB。 | ログファイルはすぐに拡張する可能性があります。 サイズは拡張するディスク別に管理するか、ログローテーションを使用して管理できます。 |
2.1.5. Red Hat Gluster Storage ハードウェア要件
コンバージドモードまたはインデペンデントモードのクラスターで使用されるノードはストレージノードとみなされます。単一ノードは複数のグループに分割できませんが、ストレージノードはそれぞれ別個のクラスターグループに分類できます。ストレージノードの各グループについては、以下が当てはまります。
- Gluster ストレージのボリュームタイプオプションに基づき、1 つのグループあたり最低でも 1 つまたは複数のストレージが必要です。
各ストレージノードには 8 GB 以上の RAM が必要です。これにより、Red Hat Gluster Storage Pod、その他のアプリケーションおよび基礎となる OS を実行できます。
- 各 GlusterFS ボリュームはストレージクラスターにあるすべてのストレージノードのメモリー (約 30 MB) も消費します。RAM の合計量は、コンカレントボリュームがいくつ求められているか、またはいくつ予想されるかによって決める必要があります。
各ストレージノードには、現在のデータまたはメタデータを含まない 1 つ以上の raw ブロックデバイスが必要です。それらのブロックデバイス全体は GlusterFS ストレージで使用されます。以下が存在しないことを確認してください。
- パーティションテーブル (GPT または MSDOS)
- ファイルシステムまたは未処理のファイルシステムの署名
- 以前のボリュームグループの LVM2 署名および論理ボリューム
- LVM2 物理ボリュームの LVM2 メタデータ
不確かな場合には、
wipefs -a <device>
で上記のすべてを消去する必要があります。
2 つのクラスター、つまりインフラストラクチャーアプリケーション (OpenShift Container レジストリーなど) のストレージ専用のクラスターと一般的なアプリケーションのストレージ専用のクラスターについて計画することをお勧めします。これには、合計で 6 つのストレージノードが必要になります。この設定は I/O およびボリューム作成のパフォーマンスへの潜在的な影響を回避するために推奨されます。
2.1.6. ハードウェア要件のモニターリング
モニターリングスタックは追加のリソース要件を課すもので、デフォルトでインストールされます。コンピューティングリソースの推奨事項 および クラスターモニターリングのドキュメント を参照してください。
2.1.7. SELinux 要件
Security-Enhanced Linux (SELinux) をすべてのサーバーで有効にしてから OpenShift Container Platform をインストールする必要があります。そうでないと、インストーラーは失敗します。 さらに、/etc/selinux/config ファイルで SELINUX=enforcing
および SELINUXTYPE=targeted
を設定します。
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
2.1.8. オプション: コアの使用についての設定
デフォルトで、OpenShift Container Platform マスターおよびノードは、それらが実行されるシステムで利用可能なすべてのコアを使用します。GOMAXPROCS
環境変数を設定することにより、OpenShift Container Platform で使用するコア数を選択することができます。GOMAXPROCS
環境変数の機能などの詳細については、Go Language ドキュメント を参照してください。
たとえば、以下を実行してからサーバーを起動し、OpenShift Container Platform が 1 つのコアでのみ実行されるようにします。
# export GOMAXPROCS=1
2.1.9. オプション: OverlayFS の使用
OverlayFS は、ファイルシステム上に別のファイルシステムを重ねる (オーバーレイする) ことができるユニオンファイルシステムです。
Red Hat Enterprise Linux 7.4 の時点で、OpenShift Container Platform 環境を OverlayFS を使用できるように設定するオプションがあります。古いバージョンの overlay
ドライバーのほかにも、overlay2
グラフドライバーが完全にサポートされています。ただし、Red Hat では、速度と実装の単純さを考慮し、overlay
ではなく overlay2
を使用することを推奨しています。
Comparing the Overlay vs. Overlay2 Graph Drivers には、overlay および overlay2 ドライバーの詳細情報が記載されています。
Docker サービスの overlay2 グラフドライバーを有効化する方法については、Atomic Host ドキュメントの Overlay Graph Driver
セクションを参照してください。
2.1.10. セキュリティー警告
OpenShift Container Platform は、クラスター内のホストでコンテナーを実行し、ビルド操作やレジストリーサービスなど一部のケースでは特権付きコンテナーを使用して実行します。さらに、これらのコンテナーはホストの Docker daemon にアクセスし、docker build
および docker push
の操作を実行します。実質的に root アクセスが可能であるため、任意のイメージでの docker run
操作の実行については関連するセキュリティーリスクについてクラスター管理者が認識している必要があります。docker build
の操作についてはとくに注意が必要です。
特定のビルドをノードに割り当て、それらのノードのみにリスクを制限することで有害なコンテナーに関連する危険にさらされるリスクを制限できます。これを実行するには、開発ガイドの 特定のノードへのビルドの割り当て のセクションを参照してください。クラスター管理者の場合は、グローバルビルドのデフォルト設定およびオーバーライドの設定 のセクションを参照してください。
SCC (Security Context Constraints) を使用して、Pod が実行可能なアクションおよび、アクセス可能な機能を制御できます。Dockerfile の USER で実行するイメージを有効にする方法は、Managing Security Context Constraints(ユーザーには cluster-admin 権限が必要) を参照してください。
詳細は、以下の記事を参照してください。