クラスターのインストール

バージョン 3.10.45 の時点では、OpenShift Container Platform を IBM POWER サーバーにインストールできます。

OpenShift Container Platform は開発環境の単一システムでのみインストールできます。オールインワン環境 は実稼働環境として使用できません。

以下の表では、単一 マスター (etcd が同じホストにインストールされている) および 2 つの ノード のサンプル環境について説明しています。

以下では、ネイティブ HA メソッドを使用する、3 つのマスター、1 つの HAProxy ロードバランサー、2 つの ノード のサンプル環境を説明しています。 etcd はマスターノードで静的 Pod として実行されます。

以下では、ネイティブ HA メソッドを使用する、3 つの マスター、1 つの HAProxy ロードバランサー、3 つの外部のクラスター化された etcd ホスト、 2 つの ノード のサンプル環境を説明しています。

OpenShift Container Platform は、OpenShift Container Platform の統合レジストリーを使用してスタンドアロンレジストリーとして機能するようにインストールすることもできます。このシナリオの詳細は、スタンドアロンレジストリーのインストール を参照してください。

システムコンテナーのインストールタイプは以下のイメージを使用します。

デフォルトで、上記のイメージはすべて registry.redhat.io の Red Hat Registry からプルされます。

プライベートレジストリーを使用してインストール中にこれらのイメージをプルする必要がある場合は、あらかじめレジストリー情報を指定できます。必要に応じてインベントリーファイルで以下の Ansible 変数を設定できます。

oreg_url='<registry_hostname>/openshift3/ose-${component}:${version}'
openshift_docker_insecure_registries=<registry_hostname>
openshift_docker_blocked_registries=<registry_hostname>

デフォルトコンポーネントは、oreg_url 値からイメージの接頭辞およびバージョンを継承します。

安全でないブロックされた追加のコンテナーレジストリーの設定はインストールプロセスの開始時に行われ、必要なイメージをプルする前にそれらの設定が適用されるようにします。

インストールプロセスでは、通常の systemctl コマンドを使用してサービスの起動、停止、ポーリングを実行するために使われる関連の systemd ユニットを作成します。システムコンテナーインストールの場合、それらのユニット名は RPM インストールのものと一致します。

すべての OpenShift Container Platform 設定ファイルは、コンテナー化インストール時に RPM ベースのインストールの場合と同じ場所に置かれ、 os-treeアップグレード後も存続します。

ただし、デフォルトのイメージストリームおよびテンプレートファイル は、標準の /usr/share/openshift/examples/ ディレクトリーが RHEL Atomic Host では読み取り専用であるため、そのディレクトリーにではなく Atomic Host インストールの /etc/origin/examples/ にインストールされます。

RHEL Atomic Host インストールが持つ root ファイルシステムは通常非常に小さいサイズです。ただし、etcd、マスター、ノードコンテナーは /var/lib/ ディレクトリーにデータを維持します。そのため、OpenShift Container Platform をインストールする前に root ファイルシステムに十分な空き領域があることを確認してください。詳細は システム要件 のセクションを参照してください。

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

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

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

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

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

NVMe や SSD などのシリアル書き込み (fsync) を迅速に処理するストレージで etcd を使用することが強く推奨されます。Ceph、NFS、およびスピニングディスクは推奨されません。

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

パフォーマンスに関するガイダンスについては、 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 vs. 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 をクラウドプロバイダーにインストールする場合に考慮すべき事柄がいくつかあります。

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

OverlayFS は、ユニオンファイルシステムのタイプです。OverlayFS により、あるファイルシステムを別のファイルシステムに重ねることができます。上位のファイルシステムで変更が記録されても、下位のファイルシステムは変更されません。

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

overlay2 ドライバーを使用するには、下層が XFS ファイルシステムを使用する必要があります。下層のファイルシステムは、変更されないファイルシステムです。

Docker サービスの OverlayFS ストレージドライバーの有効化については、Red Hat Enterprise Linux Atomic Host ドキュメント を参照してください。

Docker に含まれる docker-storage-setup スクリプトを使用してシンプールデバイスを作成し、Docker ストレージドライバーを設定できます。これは Docker のインストール後に実行でき、イメージまたはコンテナーの作成前に実行する必要があります。このスクリプトは /etc/sysconfig/docker-storage-setup ファイルから設定オプションを読み取り、論理ボリュームを作成するための 3 つのオプションをサポートします。

追加のブロックデバイスを使用することは最も信頼性の高いオプションですが、Docker ストレージを設定する前に他のブロックデバイスをホストに追加する必要があります。他のオプションはいずれも、ホストのプロビジョニング時に利用可能な空きスペースを残しておく必要があります。ルートファイルシステムボリュームグループの残りの空きスペースを使用すると、Red Hat Mobile Application Platform (RHMAP) などの一部のアプリケーションで問題が生じることが確認されています。

docker-pool を作成した後に Docker ストレージを再設定する必要がある場合は、以下を実行します。

LVM 管理の詳細は、論理ボリュームマネージャー管理 を参照してください。

OpenShift Container Platform は、イメージが信頼済みのソースのものかを暗号で確認することができます。Container Security Guide には、イメージ署名の仕組みの概要が記載されています。

atomic コマンドラインインターフェイス (CLI) (バージョン 1.12.5 以降) を使用してイメージ署名の検証を設定できます。atomic CLI は RHEL Atomic Host システムにプリインストールされています。

以下のファイルとディレクトリーは、ホストの信頼設定を設定しています。

信頼設定は、各ノードで直接管理するか、または個別のホストでファイルを管理でき、Ansible などを使用してそれらのファイルを適切なノードに配布できます。Ansible を使用したファイル配布の自動化の例については、Container Image Signing Integration Guide を参照してください。

コンテナーのログファイル (コンテナーが実行されているノード上の /var/lib/docker/containers/<hash>/<hash>-json.log ファイル) が問題を生じさせかねないサイズに拡張してしまうことを防ぐために、Docker の json-file ロギングドライバーを設定し、ログファイルのサイズと数を制限できます。

コンテナーログは、コンテナーが実行されているノードの /var/lib/docker/containers/<hash>/ ディレクトリーで確認できます。以下は例になります。

# ls -lh /var/lib/docker/containers/f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8/
total 2.6M
-rw-r--r--. 1 root root 5.6K Nov 24 00:12 config.json
-rw-r--r--. 1 root root 649K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.1
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.2
-rw-r--r--. 1 root root 1.3K Nov 24 00:12 hostconfig.json
drwx------. 2 root root    6 Nov 24 00:12 secrets

ボリュームのプロビジョニングが Dockerfile の VOLUME 指示または docker run -v <volumename> コマンドを使用して実行されると、ホストのストレージ領域が使用されます。このストレージを使用すると、予期しない領域不足の問題が生じ、ホストが停止する可能性があります。

OpenShift Container Platform では、独自のイメージを実行しようとするユーザーには、ノードホストのストレージ領域全体が一杯になるリスクがあります。この問題に対する 1 つの解決策として、ユーザーがボリュームを持つイメージを実行できないようにする方法があります。これにより、ユーザーがアクセスできるストレージのみを制限し、クラスター管理者はストレージのクォータを割り当てることができます。

docker-novolume-plugin を使用して、ローカルボリュームが定義されたコンテナーの起動を禁止することにより、この問題を解決することができます。とくに、このプラグインは以下を含む docker run コマンドをブロックします。

プラグインはバインドマウントへの参照をブロックしません。

docker-novolume-plugin を有効にするには、各ノードホストで以下の手順を実行します。

このプラグインを有効にした後に、ローカルボリュームが定義されたコンテナーは起動に失敗し、以下のエラーメッセージを表示します。

runContainer: API error (500): authorization denied by plugin
docker-novolume-plugin: volumes are not allowed

ノード設定の定義用の ConfigMap は openshift-node プロジェクトで利用できる状態でなければなりません。ConfigMap はノードラベルの信頼できる定義となり、以前の openshift_node_labels の値は事実上、無視されます。

デフォルトで、クラスターのインストール時にインストーラーは以下のデフォルト ConfigMap を作成します。

以下の ConfigMap も作成され、複数のロールにノードをラベル付けします。

以下の ConfigMap は、それぞれの既存のデフォルトノードグループの CRI-O バリアントです。

最新の openshift-ansible パッケージのインストール後に、ノードグループ定義のデフォルトセットを /usr/share/ansible/openshift-ansible/roles/openshift_facts/defaults/main.yml ファイル内で YAML 形式で確認することができます。

openshift_node_groups:
  - name: node-config-master 1
    labels:
      - 'node-role.kubernetes.io/master=true' 2
    edits: [] 3
  - name: node-config-infra
    labels:
      - 'node-role.kubernetes.io/infra=true'
    edits: []
  - name: node-config-compute
    labels:
      - 'node-role.kubernetes.io/compute=true'
    edits: []
  - name: node-config-master-infra
    labels:
      - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true'
    edits: []
  - name: node-config-all-in-one
    labels:
      - 'node-role.kubernetes.io/infra=true,node-role.kubernetes.io/master=true,node-role.kubernetes.io/compute=true'
    edits: []

openshift_node_groups 変数をインベントリーファイルの [OSEv3:vars] グループに設定しない場合、これらのデフォルト値が使用されます。ただし、カスタムノードグループを設定する必要がある場合、計画されているすべてのノードグループを含む、openshift_node_groups 構造をインベントリーファイルに定義する必要があります。

openshift_node_groups 値はデフォルト値にマージされないため、YAML 定義を Python ディクショナリーに変換する必要があります。次に、edits フィールドを設定し、キーと値のペアを指定してノード設定変数を変更できます。

たとえば、インベントリーファイルの以下のエントリーは、node-config-master、node-config-infra および node-config-compute という名前のグループを定義します。

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true']}]

新規ノードグループ名を他のラベルで定義することもできます。 インベントリーファイルの以下のエントリーは、node-config-master、node-config-infra、node-config-compute および node-config-compute-storage という名前のグループを定義します。

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true']}, {'name': 'node-config-compute-storage', 'labels': ['node-role.kubernetes.io/compute-storage=true']}]

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'kubeletArguments.experimental-allocatable-ignore-eviction','value': ['true']}, {'key': 'kubeletArguments.eviction-hard', 'value': ['memory.available<1Ki']}]}]

openshift_node_groups=[{'name': 'node-config-master', 'labels': ['node-role.kubernetes.io/master=true']}, {'name': 'node-config-infra', 'labels': ['node-role.kubernetes.io/infra=true']}, {'name': 'node-config-compute', 'labels': ['node-role.kubernetes.io/compute=true'], 'edits': [{ 'key': 'volumeConfig.localQuota','value': {'perFSGroup':'512Mi'}}]}]

openshift_node_group.yml Playbook が実行されるたびに、edits フォールドで定義した変更により、関連の ConfigMap (この例では node-config-compute) が更新され、最終的にホスト上のノードの設定ファイルに影響を与えます。

どのノードホストにどの ConfigMap を使用するかについてのマッピングでは、インベントリーの [nodes] グループで定義されるすべてのホストが openshift_node_group_name 変数を使用して node group に割り当てられる必要があります。

openshift_node_group_name の値は、各ノードを設定する ConfigMap を選択するために使用されます。以下は例になります。

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'

他のカスタム ConfigMaps が openshift_node_groups に定義されている場合、それらを使用することもできます。以下は例になります。

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
gluster[1:6].example.com openshift_node_group_name='node-config-compute-storage'

クラスターインストール時に、ラベル をノードホストに割り当てることができます。これらのラベルを使用し、スケジューラー を使用して Pod のノードへの配置を判別できます。

ノードホストに割り当てられるデフォルトラベルを変更する必要がある場合、独自のカスタムノードグループを作成する必要があります。openshift_node_labels 変数を設定してラベルを変更することはできなくなりました。デフォルトノードグループを変更するには、ノードグループ定義 を参照してください。

node-role.kubernetes.io/infra=true (このグループを使用するホストは 専用インフラストラクチャーノード とも呼ばれ、さらに 専用インフラストラクチャーノードの設定 で説明されています) 以外には、実際のラベル名および値は任意であり、クラスターの要件に基づいて適切とみなされる方法で割り当てることができます。

[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'

# default selectors for router and registry services
# openshift_router_selector='node-role.kubernetes.io/infra=true'
# openshift_registry_selector='node-role.kubernetes.io/infra=true'

[nodes]
infra-node1.example.com openshift_node_group_name='node-config-infra'

openshift_hosted_manage_registry=false
openshift_hosted_manage_router=false

[nodes]
master.example.com openshift_node_group_name='node-config-master-infra'

デプロイを正常に実行するには、有効なイメージタグが必要です。インベントリーファイルの以下の変数について interoperability matrix で説明されているように、<tag> を OpenShift Container Platform 3.11 と互換性のある Red Hat Gluster Storage のバージョンに置き換えます。

レジストリーストレージのオプションが使用されていない場合、デフォルトの OpenShift Container レジストリーは一時的で、Pod が存在しなくなるとすべてのデータが失われます。

通常インストーラー (advanced installer) を使用している場合にレジストリーストレージを有効にするには、以下のいくつかのオプションを選択できます。

オプション A: NFS ホストグループ

次の変数が設定されている場合、クラスターインストール時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に NFS ボリュームが作成されます。たとえば、次のオプションを使用した場合、ボリュームパスは /exports/registry になります。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_nfs_options='*(rw,root_squash)'
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=10Gi

オプション B: 外部 NFS ホスト

外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。次のオプションを使用した場合、リモートボリュームパスは nfs.example.com:/exports/registry になります。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_host=nfs.example.com
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=10Gi

NFS を使用した OpenShift Container Platform のアップグレードまたはインストール

オプション C: OpenStack プラットフォーム

OpenStack ストレージ設定がすでに存在している必要があります。

[OSEv3:vars]

openshift_hosted_registry_storage_kind=openstack
openshift_hosted_registry_storage_access_modes=['ReadWriteOnce']
openshift_hosted_registry_storage_openstack_filesystem=ext4
openshift_hosted_registry_storage_openstack_volumeID=3a650b4f-c8c5-4e0a-8ca5-eaee11f16c57
openshift_hosted_registry_storage_volume_size=10Gi

オプション D: AWS または別の S3 ストレージソリューション

シンプルストレージソリューション (S3) バケットがすでに存在している必要があります。

[OSEv3:vars]

#openshift_hosted_registry_storage_kind=object
#openshift_hosted_registry_storage_provider=s3
#openshift_hosted_registry_storage_s3_accesskey=access_key_id
#openshift_hosted_registry_storage_s3_secretkey=secret_access_key
#openshift_hosted_registry_storage_s3_bucket=bucket_name
#openshift_hosted_registry_storage_s3_region=bucket_region
#openshift_hosted_registry_storage_s3_chunksize=26214400
#openshift_hosted_registry_storage_s3_rootdirectory=/registry
#openshift_hosted_registry_pullthrough=true
#openshift_hosted_registry_acceptschema2=true
#openshift_hosted_registry_enforcequota=true

Minio や ExoScale などの別の S3 サービスを使用している場合は、リージョンエンドポイントパラメーターも追加します。

openshift_hosted_registry_storage_s3_regionendpoint=https://myendpoint.example.com/

オプション E: コンバージドモード

コンバージドモードの設定 と同様に、Red Hat Gluster Storage はクラスターの初期インストール時に OpenShift Container レジストリーのストレージを提供するように設定できます。 これにより、冗長で信頼性の高いレジストリーのストレージを確保できます。

オプション F: Google Compute Engine (GCE) 上の Google Cloud Storage (GCS) バケット

GCS バケットがすでに存在している必要があります。

[OSEv3:vars]

openshift_hosted_registry_storage_provider=gcs
openshift_hosted_registry_storage_gcs_bucket=bucket01
openshift_hosted_registry_storage_gcs_keyfile=test.key
openshift_hosted_registry_storage_gcs_rootdirectory=/registry

オプション G: vSphere ボリュームおよび vSphere Cloud Provider (VCP)

vSphere Cloud Provider は、OpenShift Container Platform ノードでアクセスできるデータストアで設定される必要があります。

レジストリーに vSphere ボリュームを使用する場合、ストレージアクセスモードを ReadWriteOnce に設定し、レプリカ数を 1 に設定する必要があります。

[OSEv3:vars]

openshift_hosted_registry_storage_kind=vsphere
openshift_hosted_registry_storage_access_modes=['ReadWriteOnce']
openshift_hosted_registry_storage_annotations=['volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/vsphere-volume']
openshift_hosted_registry_replicas=1

メトリクスに永続ストレージを使用するには、openshift_metrics_cassandra_storage_type 変数を設定する必要があります。openshift_metrics_cassandra_storage_type が設定されていない場合、クラスターのメトリクスデータは emptyDir ボリュームに保存されます。 このボリュームは、Cassandra Pod が終了すると削除されます。

クラスターインストール時にクラスターメトリクスストレージを有効にするには、次の 3 つのオプションを選択できます。

オプション A: 動的

OpenShift Container Platform 環境がクラウドプロバイダーの 動的ボリュームプロビジョニング をサポートする場合、以下の変数を使用します。

[OSEv3:vars]

openshift_metrics_cassandra_storage_type=dynamic

gluster-storage および glusterfs-storage-block などのデフォルトで動的にプロビジョニングされたボリュームタイプが複数ある場合、変数でプロビジョニングされたボリュームタイプを指定できます。以下の変数を使用します。

[OSEv3:vars]

openshift_metrics_cassandra_storage_type=pv
openshift_metrics_cassandra_pvc_storage_class_name=glusterfs-storage-block

動的プロビジョニングを有効または無効にするために DynamicProvisioningEnabled を使用する方法についての詳細は、Volume Configuration を参照してください。

オプション B: NFS ホストグループ

次の変数が設定されている場合、NFS ボリュームはクラスターインストール時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に作成されます。たとえば、以下のオプションを使用した場合、ボリュームパスは /exports/metrics になります。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_metrics_storage_kind=nfs
openshift_metrics_storage_access_modes=['ReadWriteOnce']
openshift_metrics_storage_nfs_directory=/exports
openshift_metrics_storage_nfs_options='*(rw,root_squash)'
openshift_metrics_storage_volume_name=metrics
openshift_metrics_storage_volume_size=10Gi

オプション C: 外部 NFS ホスト

外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_metrics_storage_kind=nfs
openshift_metrics_storage_access_modes=['ReadWriteOnce']
openshift_metrics_storage_host=nfs.example.com
openshift_metrics_storage_nfs_directory=/exports
openshift_metrics_storage_volume_name=metrics
openshift_metrics_storage_volume_size=10Gi

以下のオプションを使用した場合、リモートボリュームのパスは nfs.example.com:/exports/metrics になります。

NFS を使用した OpenShift Container Platform のアップグレードまたはインストール

コアの OpenShift Container Platform コンポーネントでの NFS の使用は推奨されていません。 NFS (および NFS プロトコル) を使用すると、OpenShift Container Platform インフラストラクチャーを設定するアプリケーションに必要な適切な整合性が確保されなくなるためです。

そのため、インストーラーおよび更新 Playbook には、コアインフラストラクチャーコンポーネントで NFS の使用を有効にするオプションが必要になります。

# Enable unsupported configurations, things that will yield a partially
# functioning cluster but would not be supported for production use
#openshift_enable_unsupported_configurations=false

クラスターのアップグレードまたはインストール時に以下のメッセージが表示される場合、追加の手順が必要になります。

TASK [Run variable sanity checks] **********************************************
fatal: [host.example.com]: FAILED! => {"failed": true, "msg": "last_checked_host: host.example.com, last_checked_var: openshift_hosted_registry_storage_kind;nfs is an unsupported type for openshift_hosted_registry_storage_kind. openshift_enable_unsupported_configurations=True mustbe specified to continue with this configuration."}

Ansible インベントリーファイルで、以下のパラメーターを指定します。

[OSEv3:vars]
openshift_enable_unsupported_configurations=True

ロギングに永続ストレージを使用するには、openshift_logging_es_pvc_dynamic 変数を設定する必要があります。openshift_logging_es_pvc_dynamic が設定されていない場合、クラスターのロギングデータは emptyDir ボリュームに保存されます。 このボリュームは、Elasticsearch Pod が終了すると削除されます。

クラスターインストール時にクラスターロギングストレージを有効にするには、次の 3 つのオプションを選択できます。

オプション A: 動的

OpenShift Container Platform 環境に動的ボリュームプロビジョニングがある場合、クラウドプロバイダー経由か、または独立したストレージプロバイダーによって設定されている可能性があります。たとえば、クラウドプロバイダーには GCE にプロビジョナー kubernetes.io/gce-pd が指定された StorageClass があり、GlusterFS などの独立したストレージプロバイダーには、プロビジョナー kubernetes.io/glusterfs が指定された StorageClass がある可能性があります。いずれの場合も、以下の変数を使用します。

[OSEv3:vars]

openshift_logging_es_pvc_dynamic=true

動的プロビジョニングについての詳細は、動的プロビジョニングとストレージクラスの作成 を参照してください。

gluster-storage および glusterfs-storage-block などのデフォルトで動的にプロビジョニングされたボリュームタイプが複数ある場合、変数でプロビジョニングされたボリュームタイプを指定できます。以下の変数を使用します。

[OSEv3:vars]

openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_storage_class_name=glusterfs-storage-block

動的プロビジョニングを有効または無効にするために DynamicProvisioningEnabled を使用する方法についての詳細は、Volume Configuration を参照してください。

オプション B: NFS ホストグループ

次の変数が設定されている場合、NFS ボリュームはクラスターインストール時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に作成されます。たとえば、以下のオプションを使用した場合、ボリュームパスは /exports/logging になります。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_nfs_directory=/exports 1
openshift_logging_storage_nfs_options='*(rw,root_squash)' 2
openshift_logging_storage_volume_name=logging 3
openshift_logging_storage_volume_size=10Gi
openshift_enable_unsupported_configurations=true
openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_size=10Gi
openshift_logging_es_pvc_storage_class_name=''
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_pvc_prefix=logging

オプション C: 外部 NFS ホスト

外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。

[OSEv3:vars]

# nfs_directory must conform to DNS-1123 subdomain must consist of lower case
# alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_host=nfs.example.com 1
openshift_logging_storage_nfs_directory=/exports 2
openshift_logging_storage_volume_name=logging 3
openshift_logging_storage_volume_size=10Gi
openshift_enable_unsupported_configurations=true
openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_size=10Gi
openshift_logging_es_pvc_storage_class_name=''
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_pvc_prefix=logging

以下のオプションを使用した場合、リモートボリュームのパスは nfs.example.com:/exports/logging になります。

NFS を使用した OpenShift Container Platform のアップグレードまたはインストール

コアの OpenShift Container Platform コンポーネントでの NFS の使用は推奨されていません。 NFS (および NFS プロトコル) を使用すると、OpenShift Container Platform インフラストラクチャーを設定するアプリケーションに必要な適切な整合性が確保されなくなるためです。

そのため、インストーラーおよび更新 Playbook には、コアインフラストラクチャーコンポーネントで NFS の使用を有効にするオプションが必要になります。

# Enable unsupported configurations, things that will yield a partially
# functioning cluster but would not be supported for production use
#openshift_enable_unsupported_configurations=false

クラスターのアップグレードまたはインストール時に以下のメッセージが表示される場合、追加の手順が必要になります。

TASK [Run variable sanity checks] **********************************************
fatal: [host.example.com]: FAILED! => {"failed": true, "msg": "last_checked_host: host.example.com, last_checked_var: openshift_hosted_registry_storage_kind;nfs is an unsupported type for openshift_hosted_registry_storage_kind. openshift_enable_unsupported_configurations=True mustbe specified to continue with this configuration."}

Ansible インベントリーファイルで、以下のパラメーターを指定します。

[OSEv3:vars]
openshift_enable_unsupported_configurations=True

OpenShift Ansible Broker (OAB) は、インストール時にデフォルトで有効になります。

OAB をインストールしない場合は、インベントリーファイルで ansible_service_broker_install パラメーター値を false に設定します。

ansible_service_broker_install=false

テンプレートサービスブローカー (TSB) は、インストール時にデフォルトで有効になります。

TSB をインストールしない場合は、template_service_broker_install パラメーターの値を false に設定します。

template_service_broker_install=false

TSB を設定するには、テンプレートとイメージストリームをサービスカタログに読み込めるように 1 つ以上のプロジェクトをブローカーのソースの namespace として定義する必要があります。インベントリーファイルの [OSEv3:vars] セクションの以下の箇所を変更して、ソースプロジェクトを設定します。

openshift_template_service_broker_namespaces=['openshift','myproject']

以下の表は、単一マスター (同じホストに静的 Pod として実行されている単一 etcd インスタンスがある)、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャー をホストする node-role.kubernetes.io/infra=true ラベル付きの 2 つのノードの環境の例を示しています。

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[etcd]、および [nodes] セクションに記載されています。

# Create an OSEv3 group that contains the masters, nodes, and etcd groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
# SSH user, this user should allow ssh based auth without requiring a password
ansible_ssh_user=root

# If ansible_ssh_user is not root, ansible_become must be set to true
#ansible_become=true

openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
master.example.com

# host group for nodes, includes region info
[nodes]
master.example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。

以下の表は、単一マスター、3 つの etcd ホスト、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャー をホストする node-role.kubernetes.io/infra=true ラベル付きの 2 つのノードの環境の例を示しています。

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[nodes]、および [etcd] セクションに記載されています。

# Create an OSEv3 group that contains the masters, nodes, and etcd groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# host group for nodes, includes region info
[nodes]
master.example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。

以下の表は、 ネイティブ HA 方法を使用する 3 つの マスター、1 つの HAProxy ロードバランサー、3 つの etcd ホスト、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャー をホストする node-role.kubernetes.io/infra=true ラベル付きの 2 つのノードの環境の例を示しています。

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[etcd]、[lb] および [nodes] セクションに記載されています。

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# Native high availbility cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# apply updated node defaults
openshift_node_groups=[{'name': 'node-config-all-in-one', 'labels': ['node-role.kubernetes.io/master=true', 'node-role.kubernetes.io/infra=true', 'node-role.kubernetes.io/compute=true'], 'edits':}]

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。

以下の表は、ネイティブ HA 方法を使用する 3 つの マスター (各ホストに静的 Pod として実行される etcd がある)、1 つの HAProxy ロードバランサー、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャー をホストする node-role.kubernetes.io/infra=true ラベル付きの 2 つのノードの環境の例を示しています。

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[etcd]、[lb] および [nodes] セクションに記載されています。

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]

# Native high availability cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
master1.example.com
master2.example.com
master3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com openshift_node_group_name='node-config-master'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'
infra-node1.example.com openshift_node_group_name='node-config-infra'
infra-node2.example.com openshift_node_group_name='node-config-infra'

この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。

RPM ベースのインストーラーは、RPM パッケージでインストールされた Ansible を使用し、ローカルホストで使用可能な Playbook と設定ファイルを実行します。

RPM ベースのインストーラーを実行するには、以下の手順を実行します。

. インストールが正常に完了した場合は、インストールを確認します。 インストールが失敗した場合は、インストールを再試行します。

openshift3/ose-ansible イメージは、 OpenShift Container Platform インストーラーのコンテナー化バージョンです。このインストーラーイメージは、RPM ベースのインストーラーと同じ機能を提供しますが、ホストに直接インストールされるのではなく、そのすべての依存関係を提供するコンテナー化環境で実行されます。この使用にあたっての唯一の要件は、コンテナーを実行できることになります。

# atomic install --system \
    --storage=ostree \
    --set INVENTORY_FILE=/path/to/inventory \
    --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/pre-install.yml \ 1
    --set OPTS="-v" \ 2
    registry.redhat.io/openshift3/ose-ansible:v3.11

$ ansible-playbook --user openshift \
  -i openshift-ansible/playbooks/openstack/inventory.py \
  -i inventory \
  openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml

インストーラーはモジュール化された Playbook を使用します。そのため、管理者は必要に応じて特定のコンポーネントをインストールできます。ロールと Playbook を分けることで、アドホックな管理タスクをより適切にターゲット設定できます。 その結果、インストール時の制御レベルが強化され、時間の節約が可能になります。

メインのインストール Playbook である /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.ymlは、一連の個別コンポーネント Playbook を特定の順序で実行します。実行の最後に、インストーラーから完了したフェーズが報告されます。 インストールが失敗した場合は、そのフェーズが失敗したかについて Ansible の実行エラーと共に画面に表示されます。

インターネット接続のある RHEL 7 サーバーで、リポジトリーを同期します。

必要なコンテナーイメージをプルします。

ご使用の環境に内部ネットワークへのアクセスがない場合で、コンテンツの移動に物理メディアが必要になる場合、イメージを圧縮されたファイルにエクスポートします。ホストがインターネットと内部ネットワークの両方に接続されている場合、以下の手順に従い、リポジトリーサーバーの準備および設定 に進みます。