Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第2章 システムおよび環境要件

2.1. システム要件

OpenShift Container Platform 環境のホストは以下のハードウェア仕様およびシステムレベルの要件を満たしている必要があります。

2.1.1. Red Hat サブスクリプション

まず、お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがなければなりません。これがない場合は、営業担当者にお問い合わせください。

2.1.2. ハードウェアの最小要件

システムの要件はホストのタイプによって異なります。

マスター

  • 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
  • ベース OS: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ Red Hat Enterprise Linux (RHEL) 7.5 以降、または RHEL Atomic Host 7.4.5 以降

    • IBM POWER9: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL-ALT 7.5
    • IBM POWER8: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL 7.5RHEL を使用する場合は、以下の最小限のカーネルバージョンを使用する必要があります。
    • RHEL 7.5: 3.10.0-862.31.1
    • RHEL 7.6: 3.10.0-957.27.2
    • RHEL 7.7: 3.10.0-1062
  • 4 つ以上の vCPU (追加することを強く推奨します)
  • 最小 16 GB RAM (特に etcd がマスター上の同一の場所に配置されている場合、メモリーの追加を強く推奨します)
  • /var/ を含むファイルシステムの最小 40 GB のハードディスク領域。 redcircle 1
  • /usr/local/bin/ を含むファイルシステムの最小 1 GB のハードディスク領域。
  • システムの一時ディレクトリーを含むファイルシステムの最小 1 GB のハードディスク領域。 redcircle 2
  • 同一の場所に配置された etcd を含むマスターは最小 4 コアを必要とします。2 コアのシステムは機能しません。

ノード

  • 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
  • ベース OS: 「最低限の」インストールオプションを持つ RHEL 7.5 以降 または RHEL Atomic Host 7.4.5 以降

    • IBM POWER9: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL-ALT 7.5
    • IBM POWER8: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL 7.5RHEL を使用する場合は、以下の最小限のカーネルバージョンを使用する必要があります。
    • RHEL 7.5: 3.10.0-862.31.1
    • RHEL 7.6: 3.10.0-957.27.2
    • RHEL 7.7: 3.10.0-1062
  • NetworkManager 1.0 以降。
  • 1 vCPU。
  • 最小 8 GB の RAM。
  • /var/ を含むファイルシステムの 15 GB 以上のハードディスク領域。 redcircle 1
  • /usr/local/bin/ を含むファイルシステムの最小 1 GB のハードディスク領域。
  • システムの一時ディレクトリーを含むファイルシステムの最小 1 GB のハードディスク領域。 redcircle 2
  • Docker のストレージバックエンドのコンテナーを実行するシステムごとに使用する 15 GB 以上の追加の未割り当て領域。詳細は、「Docker ストレージの設定」を参照してください。ノード上で実行されるコンテナーのサイズおよび数によって、追加の領域が必要になる可能性があります。

外部 etcd ノード

Ansible コントローラー

Ansible Playbook を実行するホストには、ホストあたり 75MiB 以上の空きメモリーがインベントリーで必要になります。

redcircle 1 RHEL Atomic Host で /var/ファイルシステムのサイジング要件を満たすには、デフォルト設定に変更を加える必要があります。インストール時またはインストール後にこの設定を行う方法については、「Managing Storage in Red Hat Enterprise Linux Atomic Host」を参照してください。

redcircle 2 システムの一時ディレクトリーは、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. ストレージ管理

表2.1 OpenShift Container Platform コンポーネントがデータを書き込む主なディレクトリー

ディレクトリー備考サイジング予想される拡張

/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 権限が必要) を参照してください。

詳細は、以下の記事を参照してください。