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

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

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

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

システムの一時ディレクトリーは、Python の標準ライブラリーにある tempfile モジュールで定義されるルールに基づいて決定されます。

コンテナーデーモンを実行する各システムにストレージを設定する必要があります。コンテナー化インストールの場合、マスターにストレージが必要です。また、デフォルトで Web コンソールがマスターのコンテナーで実行されますが、Web コンソールを実行するためにストレージがマスター上で必要になります。コンテナーはノードで実行されるため、ストレージは常にノード上で必要になります。ストレージのサイズは、ワークロード、コンテナーの数、実行されているコンテナーのサイズ、およびコンテナーのストレージ要件によって異なります。また、コンテナー化された etcd には設定済みのコンテナーストレージが必要です。

テストまたはサンプル環境は最小要件で機能します。実稼働環境の場合、以下の推奨事項が当てはまります。

最低 3 つの etcd ホストと 1 つのロードバランサーが複数のマスターホスト間で必要になります。

パフォーマンスのガイダンスについては、「Recommended Practices for OpenShift Container Platform Master Hosts」を参照してください。

詳しくは、「サイジングに関する考慮事項」と「Cluster Limits」を参照してください。

コンバージドモードまたはインデペンデントモードのクラスターで使用されるノードはストレージノードとみなされます。単一ノードは複数のグループに分割できませんが、ストレージノードはそれぞれ別個のクラスターグループに分類できます。ストレージノードの各グループについては、以下が当てはまります。

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

デフォルトで、OpenShift Container Platform マスターおよびノードは、それらが実行されるシステムで利用可能なすべてのコアを使用します。GOMAXPROCS 環境変数を設定することにより、OpenShift Container Platform で使用するコア数を選択することができます。GOMAXPROCS 環境変数の機能などの詳細については、Go Language ドキュメント を参照してください。

たとえば、以下を実行してからサーバーを起動し、OpenShift Container Platform が 1 つのコアでのみ実行されるようにします。

# export GOMAXPROCS=1

OverlayFS は、ファイルシステム上に別のファイルシステムを重ねる (オーバーレイする) ことができるユニオンファイルシステムです。

Red Hat Enterprise Linux 7.4 の時点で、OpenShift Container Platform 環境を OverlayFS を使用できるように設定するオプションがあります。古いバージョンの overlay ドライバーのほかにも、overlay2 グラフドライバーが完全にサポートされています。ただし、Red Hat では、速度と実装の単純さを考慮し、overlay ではなく overlay2 を使用することを推奨しています。

「Comparing the Overlay Versus Overlay2 Graph Drivers 」には、overlay および overlay2 ドライバーの詳細情報が記載されています。

Docker サービスの overlay2 グラフドライバーを有効化する方法については、Atomic Host ドキュメントの 「Overlay Graph Driver」セクションを参照してください。

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

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

OpenShift Container Platform では、完全に機能する DNS サーバーが環境になければなりません。この場合、DNS ソフトウェアを実行する別個のホストを使用することが適しており、これによりプラットフォームで実行されるホストおよびコンテナーに対して名前解決を実行することができます。

OpenShift Container Platform の主要コンポーネントはコンテナーの内部で実行され、名前解決に以下のプロセスを使用します。

OpenShift Container Platform 3.2 の時点で、dnsmasq はすべてのマスターおよびノードで自動的に設定されます。Pod は DNS としてノードを使用し、ノードは要求を転送します。デフォルトで、dnsmasq はポート 53 でリッスンするようにノード上に設定されます。そのため、ノードはその他の種類の DNS アプリケーションを実行することができません。

以下はレコードのサンプルセットです。

master1    A   10.64.33.100
master2    A   10.64.33.103
node1      A   10.64.33.101
node2      A   10.64.33.102

適切に機能する DNS 環境がない場合には、以下に関連する障害が発生します。

*.cloudapps.example.com. 300 IN  A 192.168.133.2

共有ネットワークは、マスターとノードホスト間に存在する必要があります。標準クラスターインストールプロセスを使用して高可用性のために複数のマスターを設定する計画をしている場合、インストールのプロセスで 仮想 IP (VIP) として設定される IP を選択する必要もあります。選択した IP はすべてのノード間でルーティングできる必要があり、FQDN を使用して設定する場合は、すべてのノード上で解決する必要があります。

[OSEv3:vars]
os_firewall_use_firewalld=True

Kubernetes の永続ボリュームフレームワークにより、お使いの環境で利用可能なネットワークストレージを使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これは、アプリケーションのニーズに応じて初回 OpenShift Container Platform インストールの完了後に行うことができ、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。

「クラスターの設定』ガイドは、NFS、GlusterFS, Ceph RBD、OpenStack Cinder、AWS Elastic Block Store (EBS)、GCE Persistent Disks、および iSCSI を使用して永続ストレージを OpenShift Container Platform クラスターにプロビジョニングする方法についてのクラスター管理者向けの情報を提供しています。

OpenShift Container Platform をクラウドプロバイダーにインストールする場合に考慮すべき事柄がいくつかあります。

# ansible-playbook  [-i /path/to/inventory] \
    /usr/share/ansible/openshift-ansible/playbooks/byo/openshift_facts.yml