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

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

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

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

以下の表では、単一マスター、3 つの etcd ホスト、および 2 つのノードのサンプル環境について説明しています。

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

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

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

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

デフォルトで、上記のイメージはすべて registry.access.redhat.com の 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 値からイメージのプレフィックスおよびバージョンを継承します。

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

インストールプロセスでは、通常の 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 サブスクリプションがなければなりません。これがない場合は、営業担当者にお問い合わせください。

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

/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

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

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

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

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

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

docker-pool を作成した後に Docker ストレージを再設定する必要がある場合は、まず docker-pool 論理ボリュームを削除する必要があります。専用のボリュームグループを使用している場合は、上記の手順に従って、docker-storage-setup を再設定する前にそのボリュームグループと関連する物理ボリュームを削除する必要もあります。

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

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

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

ホストシステムにインストールされていない場合は、atomic パッケージをインストールします。

$ yum install atomic

atomic trust サブコマンドは信頼設定を管理します。デフォルトの設定では、すべてのレジストリーをホワイトリストに入れます。これは、署名の検証が設定されていないことを意味します。

$ atomic trust show
* (default)                         accept

適切な設定として、特定のレジストリーまたは namespace をホワイトリストに入れ、信頼されていないレジストリーはブラックリストに入れ (拒否)、ベンダーレジストリーで署名検証が必要になるようにします。以下のコマンドセットは、この設定例を実行します。

$ atomic trust add --type insecureAcceptAnything 172.30.1.1:5000

$ atomic trust add --sigstoretype atomic \
  --pubkeys pub@example.com \
  172.30.1.1:5000/production

$ atomic trust add --sigstoretype atomic \
  --pubkeys /etc/pki/example.com.pub \
  172.30.1.1:5000/production

$ atomic trust add --sigstoretype web \
  --sigstore https://access.redhat.com/webassets/docker/content/sigstore \
  --pubkeys /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release \
  registry.access.redhat.com

# atomic trust show
* (default)                         accept
172.30.1.1:5000                     accept
172.30.1.1:5000/production          signed security@example.com
registry.access.redhat.com          signed security@redhat.com,security@redhat.com

署名されたすべてのソースが検証される場合、グローバルの reject デフォルトによりノードをさらに強化できます。

$ atomic trust default reject

$ atomic trust show
* (default)                         reject
172.30.1.1:5000                     accept
172.30.1.1:5000/production          signed security@example.com
registry.access.redhat.com          signed security@redhat.com,security@redhat.com

追加の例として atomic man ページの man atomic-trust を使用します。

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

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

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

たとえば、最大ファイルサイズを 1MB に設定し、最新の 3 つのログファイルを保持するには、/etc/sysconfig/docker ファイルを編集して、max-size=1M と max-file=3 を設定します。

OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=1M --log-opt max-file=3'

次に Docker サービスを再起動します。

# systemctl restart docker

コンテナーログは、コンテナーが実行されているノードの /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

ロギングドライバーの設定方法に関する詳細は、Docker ドキュメントを参照してください。

ボリュームのプロビジョニングが 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 も作成され、複数のロールにノードをラベル付けします。

最新の 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: []

インベントリーファイルの [OSEv3:vars] グループに openshift_node_groups 変数が設定されていない場合には、上記で定義したデフォルト値が使用されます。ただし、これらのデフォルト値とは違う値を使用する場合には、インベントリーファイルに (任意の全ノードグループなどを含む) 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']}]

インベントリーファイルにエントリーを設定する場合、ノードグループの ConfigMap も設定できます。

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.pods-per-core','value': ['20']}]}]

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'

ラベル は、クラスターインストール時にノードホストに割り当てることができます。これは、スケジューラー を使用して Pod のノードへの配置を判別するのに役立ちます。以前はノードラベルは openshift_node_labels 変数を使用して設定できましたが、OpenShift Container Platform 3.10 より、ノードホストに割り当てられたデフォルトラベルを変更する必要がある場合には、独自のカスタムノードホストを作成する必要があります。デフォルトノードグループの変更方法についての詳細は、「ノードグループ定義」を参照してください。

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'

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

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

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

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

[OSEv3:vars]

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]

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 などのデフォルトで動的にプロビジョニングされたボリュームタイプが複数ある場合、変数でプロビジョニングされたボリュームタイプを指定できます。たとえば、openshift_logging_es_pvc_storage_class_name=glusterfs-storage-block openshift_metrics_cassandra_pvc_storage_class_name=glusterfs-storage-block のようになります。

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

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

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

[OSEv3:vars]

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]

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

[OSEv3:vars]

openshift_logging_es_pvc_dynamic=true

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

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

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

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

[OSEv3:vars]

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_nfs_directory=/exports
openshift_logging_storage_nfs_options='*(rw,root_squash)'
openshift_logging_storage_volume_name=logging
openshift_logging_storage_volume_size=10Gi

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

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

[OSEv3:vars]

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_host=nfs.example.com
openshift_logging_storage_nfs_directory=/exports
openshift_logging_storage_volume_name=logging
openshift_logging_storage_volume_size=10Gi

以下のオプションを使用した場合、リモートボリュームのパスは 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']

デフォルトでは、TSB は Pod のデプロイにノードセレクター {"node-role.kubernetes.io/infra":"true"} を使用します。インベントリーファイルの [OSEv3:vars] セクションに必要なノードセレクターを設定してこれを変更できます。

template_service_broker_selector={"node-role.kubernetes.io/infra":"true"}

以下の表は、単一マスター (同じホストに単一 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
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

# 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
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

# 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
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

# 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_kubelet_args={'pods-per-core': ['10'], 'max-pods': ['250'], 'image-gc-high-threshold': ['90'], 'image-gc-low-threshold': ['80']}

# enable ntp on masters to ensure proper failover
openshift_clock_enabled=true

# 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 つのマスター (各ホストに etcd がある)、1 つの HAProxy ロードバランサー、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 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
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

# 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.access.redhat.com/openshift3/ose-ansible:v3.10

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

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

エラーを解決した後に、インストールを継続できます。

残りの Playbook のみを実行する必要がある場合、失敗したフェーズの Playbook から実行し、その後に残りの Playbook を順番に実行します。

# ansible-playbook [-i /path/to/inventory] <playbook_file_location>

以下の表は、Playbook が実行される順序で Playbook を一覧表示しています。

uninstall.yml Playbook を使用すると、ノードコンポーネントを特定のホストからアンインストールし、それ以外のホストとクラスターをそのままにしておくことができます。

Playbook が完了すると、すべての OpenShift Container Platform コンテンツが指定したホストから削除されます。

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

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

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