Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

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

OpenShift Container Platform 3.10

OpenShift Container Platform 3.10 クラスターのインストール

Red Hat OpenShift Documentation Team

概要

本書を活用した OpenShift Container Platform 3.10 クラスターのインストール

第1章 インストール計画

1.1. クラスターのインストールについて

クラスターを実稼働環境にインストールするために、OpenShift Container Platform は Ansible Playbook を使用して実装されるインストール方法 (インストーラー) を提供します。Ansible についての理解があることが前提となりますが、インストールガイドでは、お使いの環境および必要な OpenShift Container Platform クラスター設定を表すインベントリーファイルの作成、および Ansible CLI ツールを使用したインストールの実行に役立つ情報を提供しています。

注記

Ansible およびその基本的な使用方法については、公式ドキュメントを参照してください。

1.2. 初期計画

実稼働環境に OpenShift Container Platform クラスターをインストールする際に、インストールに影響を与えるいくつかの要因があります。本書を読み進めるにあたって、以下の質問について検討してください。

  • ご使用のオンプレミスサーバーで IBM POWER または x86_64 プロセッサーを使用しているか? いずれかのタイプのプロセッサーを使用するサーバーに OpenShift Container Platform をインストールできます。POWER サーバーを使用する場合は、「IBM POWER でのインストールについての制限および考慮事項」を参照してください。
  • クラスターに必要な Pod の数はどの程度か?サイジングに関する考慮事項」セクションでは、ノードおよび Pod の制限について説明します。これらの制限に基づいて、必要な環境のサイズを計算できます。
  • クラスターに必要なホストの数はどの程度か?環境シナリオ」セクションでは、単一マスターおよび複数マスター設定の複数の設定例について説明します。
  • クラスターに高可用性 は必要か? フォールトトレランスを可能にするための高可用性の使用が推奨されています。この場合、ご使用の環境のベースとして ネイティブの高可用性 (HA) を使用する複数マスターのサンプルの使用を検討されるかもしれません。
  • どのインストールタイプを使用するか? RPM またはシステムコンテナーのどちらか? いずれのインストールも、作業用の OpenShift Container Platform 環境を提供しますが、サービスをインストールし、管理し、更新するために優先する方法があるかもしれません。
  • 認証にどのアイデンティティープロバイダーを使用するか?サポートされているアイデンティティープロバイダーをすでに使用している場合は、インストール時にそのアイデンティティープロバイダーを使用するよう OpenShift Container Platform を設定することを推奨します。
  • 他のテクノロジーとの統合の際に使用するインストールはサポートされるか? テスト済みの統合テクノロジーの一覧は、「OpenShift Container Platform Tested Integrations」を参照してください。

1.2.1. IBM POWER でのインストールについての制限および考慮事項

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

  • クラスターは Power ノードのみを使用する必要があります。イメージにタグを付ける方法により、OpenShift Container Platform では x86 イメージと Power イメージを区別することができません。
  • イメージストリームおよびテンプレートは、アップグレード時にデフォルトでインストールされず、更新されません。イメージストリームは手動でインストールし、更新することができます。
  • オンプレミス Power サーバーにのみインストールできます。OpenShift Container Platform をクラウドプロバイダーのノードにインストールすることはできません。
  • すべてのストレージプロバイダーがサポートされている訳ではありません。以下のストレージプロバイダーのみを使用できます。

    • GlusterFS
    • NFS
    • ローカルストレージ

1.3. サイジングに関する考慮事項

OpenShift Container Platform クラスターに必要なノードと Pod の数を判別します。クラスターの拡張性はクラスター環境内の Pod の数に相関します。この数は、セットアップの他の数に影響を及ぼします。OpenShift Container Platform のオブジェクトの制限についての最新情報は、「クラスターの制限」を参照してください。

1.4. 環境シナリオ

本セクションでは、OpenShift Container Platform 環境の複数の異なるシナリオ例について説明します。これらのシナリオは、実際のサイジングの必要に応じて独自の OpenShift Container Platform クラスターを計画する際のベースとして使用してください。

注記

インストール後の単一マスタークラスターから複数マスターへの移行はサポートされていません。

ラベルの更新に関する情報については、「Updating Labels on Nodes」を参照してください。

1.4.1. 1 システムの単一マスターおよびノード

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

1.4.2. 単一マスターおよび複数ノード

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

ホスト名インストールするインフラストラクチャーコンポーネント

master.example.com

マスター、etcd、ノード

node1.example.com

ノード

node2.example.com

1.4.3. 単一マスター、複数 etcd、および複数ノード

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

ホスト名インストールするインフラストラクチャーコンポーネント

master.example.com

マスターおよびノード

etcd1.example.com

etcd

etcd2.example.com

etcd3.example.com

node1.example.com

ノード

node2.example.com

1.4.4. 同一の場所に配置されたクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター

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

ホスト名インストールするインフラストラクチャーコンポーネント

master1.example.com

マスター (クラスター化、ネイティブ HA を使用) およびノードおよびクラスター化された etcd

master2.example.com

master3.example.com

lb.example.com

API マスターエンドポイントの負荷分散を行う HAProxy

node1.example.com

ノード

node2.example.com

1.4.5. 外部のクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター

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

ホスト名インストールするインフラストラクチャーコンポーネント

master1.example.com

マスター (クラスター化、ネイティブ HA を使用) およびノード

master2.example.com

master3.example.com

lb.example.com

API マスターエンドポイントの負荷分散を行う HAProxy

etcd1.example.com

クラスター化された etcd

etcd2.example.com

etcd3.example.com

node1.example.com

ノード

node2.example.com

1.4.6. スタンドアロンレジストリー

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

1.5. インストールタイプ

RPM インストールは、パッケージ管理ですべてのサービスをインストールし、サービスを同じユーザー空間で実行されるように設定します。システムコンテナーのインストールは、システムコンテナーイメージを使用してサービスをインストールし、個別のコンテナーで個々のサービスを実行します。

OpenShift Container Platform 3.10 以降、Red Hat Enterprise Linux (RHEL) Server をホストの基礎となる OS として使用する場合、RPM 方法はホストに OpenShift Container Platform コンポーネントをインストールするために使用されます。RHEL Atomic Host を使用する場合、システムコンテナー方法がそのホストで使用されます。いずれのインストールタイプもクラスターに同じ機能を提供しますが、オペレーティングシステムによって異なる方法が選択されるため、サービスおよびホストの更新の管理方法が異なります。

RPM を使用する場合、すべてのサービスが外部ソースのパッケージ管理によってインストールされ、更新されます。これらは、同じユーザー空間内のホストの既存設定を変更します。システムコンテナーインストールの場合は、OpenShift Container Platform の各コンポーネントはコンテナーとして同梱され (自己完結型パッケージ)、ホストのカーネルを利用して起動と実行を行います。更新された新しいコンテナーはホストの既存のものを置き換えます。

以下の表およびセクションは、インストールタイプごとの詳細な相違点について説明しています。

表1.1 インストールタイプ間の相違点

 RPM ベースのインストールシステムコンテナーのインストール

配信メカニズム

yum を使用する RPM パッケージ

docker を使用するシステムコンテナー

サービス管理

systemd

docker および systemd ユニット

オペレーティングシステム

Red Hat Enterprise Linux (RHEL)

RHEL Atomic Host

1.5.1. システムコンテナーの必須イメージ

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

  • openshift3/ose
  • openshift3/node
  • openshift3/openvswitch
  • registry.access.redhat.com/rhel7/etcd

デフォルトで、上記のイメージはすべて 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>
注記

ホストの IP アドレスに openshift_docker_insecure_registries 変数を設定することもできます。0.0.0.0/0 は有効な設定ではありません。

デフォルトコンポーネントは、oreg_url 値からイメージのプレフィックスおよびバージョンを継承します。

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

1.5.2. systemd サービス名

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

注記

etcd パッケージは今後 RHEL Atomic Host から削除される予定です。

1.5.3. ファイルパスの場所

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

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

1.5.4. ストレージ要件

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

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

2.1. システム要件

以下のセクションでは、OpenShift Container Platform 環境内のすべてのホストについてのハードウェアの仕様およびシステムレベルの要件を示しています。

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

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

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

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

マスター

  • 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
  • ベース OS:

    • x86_64 またはクラウド: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL 7.4、7.5 または RHEL Atomic Host 7.4.5 以降
    • IBM POWER9: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL-ALT 7.5
    • IBM POWER8: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL 7.5
  • 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:

    • x86_64 またはクラウド: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL 7.4、7.5 または RHEL Atomic Host 7.4.5 以降
    • IBM POWER9: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL-ALT 7.5
    • IBM POWER8: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL 7.5
  • 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 ノード

  • etcd データ用の最小 20 GB のハードディスク領域。
  • etcd ノードを適切なサイズに設定する方法については、CoreOS etcd ドキュメントの「ハードウェア推奨」セクションを参照してください。
  • 現時点で、OpenShift Container Platform はイメージ、ビルド、およびデプロイメントメタデータを etcd に保存します。定期的に古いリソースのプルーニングを実行する必要があります。これらのリソースを多数使用する予定の場合は、大量のメモリーと高速 SSD ドライブを搭載したマシンに etcd を配置します。

Ansible コントローラー

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

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

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

重要

OpenShift Container Platform は、x86_64 アーキテクチャー搭載のサーバーのみをサポートします。

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

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 が最小要件として必要になります。

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

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

ノードホスト
ノードホストのサイズは、そのワークロードの予想されるサイズによって異なります。OpenShift Container Platform クラスターの管理者は、予想されるワークロードを計算し、オーバーヘッドの約 10 パーセントを追加する必要があります。実稼働環境の場合、ノードホストの障害が最大容量に影響を与えることがないよう、十分なリソースを割り当てるようにします。

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

重要

ノードで物理リソースを過剰にサブスクライブすると、Kubernetes スケジューラーが Pod の配置時に行うリソース保証に影響を与えます。Swap メモリーを無効にするために実行できる処置について確認してください。

2.1.4. Red Hat Gluster Storage ハードウェア要件

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

  • 1 グループあたり 3 つ以上のストレージノードが必要です。
  • 各ストレージノードには 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.5. 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.6. オプション: コアの使用についての設定

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

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

# export GOMAXPROCS=1

2.1.7. オプション: OverlayFS の使用

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」セクションを参照してください。

2.1.8. セキュリティー警告

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

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

2.2. 環境要件

以下のセクションでは、OpenShift Container Platform 設定を含む環境の要件を定義します。これには、ネットワークの考慮事項や Git リポジトリーのアクセス、ストレージおよびクラウドインフラストラクチャープロバイダーなどの外部サービスへのアクセスなどの要件が含まれます。

2.2.1. DNS 要件

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

重要

各ホストの /etc/hosts ファイルにエントリーを追加するだけでは不十分です。このファイルはプラットフォームで実行されるコンテナーにはコピーされません。

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

  1. デフォルトで、コンテナーはホストから DNS 設定ファイル (/etc/resolv.conf) を受信します。
  2. OpenShift Container Platform は Pod の最初のネームサーバーをノードの IP アドレスに設定します。

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

注記

NetworkManager はネットワークに自動的に接続するシステムの検出と設定を行うプログラムであり、dnsmasq を DNS IP アドレスで設定するためにノードで必要となります。

NM_CONTROLLED はデフォルトで yes に設定されます。NM_CONTROLLEDno に設定されている場合、NetworkManager のディスパッチスクリプトは関連する origin-upstream-dns.conf dnsmasq ファイルを作成せず、dnsmasq を手動で設定する必要があります。

同様に、ネットワークスクリプト (例: /etc/sysconfig/network-scripts/ifcfg-em1) で PEERDNS パラメーターが no に設定されている場合、dnsmasq ファイルは生成されず、Ansible のインストールは失敗します。PEERDNS 設定が yes に設定されていることを確認してください。

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

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 環境がない場合には、以下に関連する障害が発生します。

  • Ansible ベースの参照スクリプトによる製品のインストール
  • インフラストラクチャーコンテナー (レジストリー、ルーター) のデプロイ
  • OpenShift Container Platform web コンソールへのアクセス (IP アドレスのみではアクセスできないため)

2.2.1.1. ホストを DNS を使用するように設定する

環境内の各ホストが DNS サーバーのホスト名を解決するように設定されていることを確認します。ホストの DNS 解決の設定は、DHCP が有効にされているかどうかによって異なります。

  • DHCP が無効にされている場合、ネットワークインターフェースを static (静的) に設定し、DNS ネームサーバーを NetworkManager に追加します。
  • DHCP が有効にされている場合、NetworkManager ディスパッチスクリプトは DHCP 設定に基づいて DNS を自動的に設定します。

ホストが DNS サーバーで解決できることを確認するには、以下を実行します。

  1. /etc/resolv.conf の内容を確認します。

    $ cat /etc/resolv.conf
    # Generated by NetworkManager
    search example.com
    nameserver 10.64.33.1
    # nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh

    この例では、10.64.33.1 が DNS サーバーのアドレスです。

  2. /etc/resolv.conf に一覧表示されている DNS サーバーが OpenShift Container Platform 環境のすべてのマスターおよびノードの IP アドレスに対してホスト名を解決できることをテストします。

    $ dig <node_hostname> @<IP_address> +short

    例:

    $ dig master.example.com @10.64.33.1 +short
    10.64.33.100
    $ dig node1.example.com @10.64.33.1 +short
    10.64.33.101

2.2.1.2. DNS ワイルドカードの設定

オプションとして、ルーターが使用するワイルドカードを設定し、新規ルートが追加される際に DNS 設定を更新しなくてもよいようにします。

DNS ゾーンのワイルドカードは、最終的には OpenShift Container Platform ルーターの IP アドレスに解決される必要があります。

たとえば、有効期間 (TTL) の低い値が設定されていて、ルーターがデプロイされるホストのパブリック IP アドレスをポイントする cloudapps のワイルドカード DNS エントリーを作成します。

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

仮想マシンが参照されるほとんどすべての場合では、ホスト名を使用する必要があり、使用するホスト名は各ノードの hostname -f コマンドの出力と一致している必要があります。

警告

各ノードホストの/etc/resolv.conf ファイルで、ワイルドカードエントリーを持つ DNS サーバーがネームサーバーとして一覧表示されていないこと、またはワイルドカードドメインが検索一覧に表示されていないことを確認してください。そうでない場合、OpenShift Container Platform が管理するコンテナーはホスト名を適切に解決できないことがあります。

2.2.2. ネットワークアクセス要件

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

2.2.2.1. NetworkManager

NetworkManager はネットワークに自動的に接続するシステムの検出と設定を行うプログラムであり、dnsmasq を DNS IP アドレスで設定するためにノードで必要となります。

NM_CONTROLLED はデフォルトで yes に設定されます。NM_CONTROLLEDno に設定されている場合、NetworkManager のディスパッチスクリプトは関連する origin-upstream-dns.conf dnsmasq ファイルを作成せず、dnsmasq を手動で設定する必要があります。

2.2.2.2. firewalld のファイアウォールとしての設定

デフォルトのファイアウォールは iptables ですが、 新規のインストールには firewalld が推奨されます。 Ansible インベントリーファイルos_firewall_use_firewalld=true を設定することで、firewalld を有効にすることができます。

[OSEv3:vars]
os_firewall_use_firewalld=True

この変数を true に設定することで、必要なポートが開き、ルールがデフォルトゾーンに追加されます。これにより、firewalld が適切に設定されていることを確認できます。

注記

firewalld のデフォルトの設定オプションを使用する際には設定オプションが制限され、これらをオーバーライドすることはできません。たとえば、ストレージネットワークを複数ゾーンのインターフェースでセットアップすることができますが、ノードが通信に使用するインターフェースはデフォルトゾーンになければなりません。

2.2.2.3. 必須ポート

OpenShift Container Platform のインストールは、iptables を使用して各ホストに内部のファイアウォールルール一式を自動的に作成します。ただし、ネットワーク設定でハードウェアベースのファイアウォールなどの外部ファイアウォールを使用する場合、インフラストラクチャーコンポーネントが、特定のプロセスまたはサービスの通信エンドポイントとして機能する特定ポートで相互に通信できることを確認する必要があります。

OpenShift Container Platform で必要な以下のポートがネットワーク上で開いており、ホスト間のアクセスを許可するよう設定されていることを確認してください。設定や使用状況によって、一部はポートはオプションになります。

表2.1 ノード間通信

4789

UDP

別個のホストの Pod 間の SDN 通信に必要です。

表2.2 ノードからマスターへの通信

53 または 8053

TCP/UDP

クラスターサービス (SkyDNS) の DNS 解決に必要です。3.2 よりも前のインストールまたは 3.2 にアップグレードした環境はポート 53 を使用します。新規インストールはデフォルトで 8053 を使用するため、dnsmasq が設定されることがあります。

4789

UDP

別個のホストの Pod 間の SDN 通信に必要です。

443 または 8443

TCP

ノードホストがマスター API と通信するために必要です。ノードホストがステータスをポストバックしたり、タスクを受信したりする際に使用します。

表2.3 マスターからノードへの通信

4789

UDP

別個のホストの Pod 間の SDN 通信に必要です。

10250

TCP

マスターは、oc コマンドについての Kubelet を使用してノードホストにプロキシーします。

10010

TCP

CRI-O を使用している場合は、このポートを開き、oc exec および oc rsh 操作を実行できるようにします。

表2.4 マスター間の通信

53 または 8053

TCP/UDP

クラスターサービス (SkyDNS) の DNS 解決に必要です。3.2 よりも前のインストールまたは 3.2 にアップグレードした環境はポート 53 を使用します。新規インストールはデフォルトで 8053 を使用するため、dnsmasq が設定されることがあります。

2049

TCP/UDP

NFS ホストをインストーラーの一部としてプロビジョニングする場合に必要です。

2379

TCP

スタンドアロン etcd (クラスター化) が状態の変更を受け取るために使用されます。

2380

TCP

etcd はスタンドアロン etcd (クラスター化) を使用する場合、リーダー選定とピアリング接続のためにこのポートがマスター間で開かれていることを要求します。

4789

UDP

別個のホストの Pod 間の SDN 通信に必要です。

表2.5 外部からロードバランサーへの通信

9000

TCP

ネイティブ HA メソッドを選択している場合、HAProxy 統計ページへのアクセスを許可するためのオプションです。

表2.6 外部からマスターへの通信

443 または 8443

TCP

ノードホストがマスター API と通信するために必要です。ノードホストがステータスをポストバックしたり、タスクを受信したりする際に使用します。

8444

TCP

atomic-openshift-master-controllers サービスがリッスンするポートです。/metrics および /healthz エンドポイント用に開いている必要があります。

表2.7 IaaS デプロイメント

22

TCP

インストーラーまたはシステム管理者が SSH で必要とします。

53 または 8053

TCP/UDP

クラスターサービス (SkyDNS) の DNS 解決に必要です。3.2 よりも前のインストールまたは 3.2 にアップグレードした環境はポート 53 を使用します。新規インストールはデフォルトで 8053 を使用するため、dnsmasq が設定されることがあります。マスターホストの内部で開かれている必要があります。

80 または 443

TCP

ルーターの HTTP/HTTPS 用です。ノードホスト、とくにルーターを実行しているノードで外部に開かれている必要があります。

1936

TCP

(オプション) テンプレートルーターを実行して統計にアクセスする際に開かれている必要があります。統計をどのように公開する必要があるかによって、接続に対して外部または内部に開くことができます。この場合、追加の設定が必要になることがあります。詳しくは、以下の「注記」セクションを参照してください。

2379 および 2380

TCP

スタンドアロン etcd 用です。マスターホストの内部で開かれている必要があります。2379 はサーバークライアント接続用です。2380 はサーバー間の接続用で、クラスター化された etcd がある場合にのみ必要となります。

4789

UDP

VxLAN 用 (OpenShift SDN) です。ノードホストの内部で開かれている必要があります。

8443

TCP

OpenShift Container Platform Web コンソール用で、API サーバーと共有します。

10250

TCP

Kubelet 用です。ノード上で外部に開かれている必要があります。

注記

  • 上記の例では、ポート 4789 は UDP (User Datagram Protocol) に使用されます。
  • デプロイメントで SDN を使用している場合、レジストリーがデプロイされているのと同じノードからレジストリーにアクセスしているのでない限り、 Pod のネットワークはサービスプロキシー経由でアクセスされます。
  • OpenShift Container Platform の内部 DNS は SDN 経由で受け取ることができません。クラウド以外のデプロイメントの場合、これはデフォルトで、マスターホストのデフォルトルートに関連付けられた IP アドレスに設定されます。クラウドデプロイメントの場合、これはデフォルトでクラウドメタデータで定義される最初の内部インターフェースに関連付けられた IP アドレスに設定されます。
  • マスターホストはポート 10250 を使用してノードに到達し、SDN を経由しません。デプロイメントのターゲットホストによって異なりますが、openshift_public_hostname の計算された値を使用します。
  • iptables ルールにより、ポート 1936 はアクセス不可能な状態になります。ポート 1936 を開くよう iptables を設定するには以下を使用してください。

    # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp \
        --dport 1936 -j ACCEPT

表2.8 集約ロギング

9200

TCP

Elasticsearch API 用です。Kibana が表示用にログを取得できるようにインフラストラクチャーノードの内部で開かれている必要があります。ルートを使用して Elasticsearch に直接アクセスできるよう外部に開くこともできます。ルートは oc expose を使用して作成できます。

9300

TCP

Elasticsearch のクラスター内での使用向けです。Elasticsearch クラスターのメンバーが相互に通信できるようにインフラストラクチャーノードで内部に開かれている必要があります。

2.2.3. 永続ストレージ

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

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

2.2.4. クラウドプロバイダーの留意事項

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

2.2.4.1. 検出された IP アドレスとホスト名の上書き

一部のデプロイメントでは、ユーザーがホストの検出されたホスト名と IP アドレスを上書きすることが必要です。デフォルト値を確認するには、openshift_facts Playbook を実行します。

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

Amazon Web Services の場合は、「検出された IP アドレスとホスト名の上書き」のセクションを参照してください。

検出された共通の設定を確認してみましょう。それらが想定される内容と異なる場合にはそれらを上書きすることができます。

通常インストール (Advanced installation)」トピックでは、利用可能な Ansible 変数を詳しく説明します。

変数使用法

hostname

  • インスタンス自体から内部 IP に解決する。

ip

  • インスタンスの内部 IP。

public_hostname

  • クラウド外のホストから外部 IP に解決する。
  • プロバイダーの openshift_public_hostname が上書きする。

public_ip

  • インスタンスに関連付けられた外部からアクセス可能な IP。
  • openshift_public_ip が上書きする。

use_openshift_sdn

  • クラウドが GCE でない限り、true になる。
  • openshift_use_openshift_sdn が上書きする。

2.2.4.2. クラウドプロバイダーのインストール後の設定

インストールプロセスの後に、AWSOpenStack、または GCE 用に OpenShift Container Platform を設定することができます。

第3章 ホストの準備

3.1. オペレーティングシステム要件

マスターおよびノードホストのオペレーティングシステムの要件は使用するサーバーのアーキテクチャーによって異なります。

  • x86_64 アーキテクチャーを使用するサーバーの場合は、Extras チャンネルからの最新パッケージを含む Red Hat Enterprise Linux (RHEL) 7.4 または 7.5 のベースインストールまたは RHEL Atomic Host 7.4.2 以降を使用します。
  • クラスドベースのインストールの場合は、Extras チャンネルからの最新パッケージを含む RHEL 7.4 または 7.5 のベースインストールを使用します。
  • IBM POWER8 アーキテクチャーを使用するサーバーの場合は、Extras チャンネルからの最新パッケージを含む RHEL 7.5 のベースインストールを使用します。
  • IBM POWER9 アーキテクチャーを使用するサーバーの場合は、Extras チャンネルからの最新パッケージを含む RHEL-ALT 7.5 のベースインストールを使用します。

それぞれのインストール方法については、必要に応じて以下のドキュメントを参照してください。

3.2. サーバータイプの要件

ノードに IBM POWER サーバーを使用する場合は、IBM POWER サーバーのみを使用できます。IBM POWER サーバーで実行されるノードを x86_64 サーバーを使用する既存クラスターに追加したり、クラスターノードを IBM POWER および x86_64 サーバーの混在環境にデプロイできません。

3.3. パスの設定

各ホストの root ユーザーの PATH には以下のディレクトリーが含まれている必要があります。

  • /bin
  • /sbin
  • /usr/bin
  • /usr/sbin

これらすべてはデフォルトで新規の RHEL 7.x インストールに含まれています。

3.4. ホストアクセスの確保

OpenShift Container インストーラーでは、すべてのホストにアクセスできるユーザーが必要になります。インストーラーを非 root ユーザーとして実行する場合は、それぞれの宛先ホストでパスワードレス sudo 権限を設定する必要があります。

たとえば、インストールプロセスを起動するホストで SSH キーを生成できます。

# ssh-keygen

パスワードは使用しないでください。

SSH キーを配布する簡単な方法として、bash ループを使用できます。

# for host in master.example.com \
    master.example.com \
    node1.example.com \
    node2.example.com; \
    do ssh-copy-id -i ~/.ssh/id_rsa.pub $host; \
    done

設定に従って、上記コマンドのホスト名を変更します。

bash ループの実行後に、SSH でループに一覧表示されている各ホストにアクセスできます。

3.5. プロキシーの上書きの設定

ノードの /etc/environment ファイルに http_proxy または https_proxy 値のいずれかが含まれる場合、OpenShift Container Platform コンポーネント間でのオープンな通信を可能にするため、そのファイルに no_proxy 値を設定する必要もあります。

注記

/etc/environment ファイルの no_proxy パラメーターは、インベントリーファイルに設定するグローバルプロキシー値と同じ値ではありません。グローバルプロキシー値では、プロキシーの設定を使って特定の OpenShift Container Platform サービスを設定します。詳細は、「グローバルプロキシーオプションの設定」を参照してください。

/etc/environment ファイルにプロキシー値が含まれる場合、以下の値を、各ノードでこのファイルの no_proxy パラメーターに以下の値を定義します。

  • マスターおよびノードのホスト名またはそれらのドメインサフィックス。
  • 他の内部ホスト名またはそれらのドメインサフィックス。
  • etcd IP アドレス。etcd アクセスはアドレスで制御されるので、ホスト名ではなく IP アドレスを指定する必要があります。
  • Kubernetes IP アドレス (デフォルトは 172.30.0.1)。インベントリーファイルの openshift_portal_net パラメーターに設定される値である必要があります。
  • Kubernetes の内部ドメインサフィックス: cluster.local
  • Kubernetes の内部ドメインサフィックス: .svc
注記

no_proxy は CIDR をサポートしないので、ドメインサフィックスを使用できます。

http_proxy または https_proxy 値のいずれかを使用する場合、 no_proxy パラメーターの値は以下の例のようになります。

no_proxy=.internal.example.com,10.0.0.1,10.0.0.2,10.0.0.3,.cluster.local,.svc,localhost,127.0.0.1,172.30.0.1

3.6. ホスト登録

各ホストは Red Hat サブスクリプションマネージャー (RHSM) を使用して登録されており、必要なパッケージにアクセスできるようアクティブな OpenShift Container Platform サブスクリプションがアタッチされている必要があります。

  1. 各ホストで RHSM に登録します。

    # subscription-manager register --username=<user_name> --password=<password>
  2. RHSM から最新サブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 利用可能なサブスクリプションを一覧表示します。

    # subscription-manager list --available --matches '*OpenShift*'
  4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。

    # subscription-manager attach --pool=<pool_id>
  5. Yum リポジトリーをすべて無効にします。

    1. 有効にされている RHSM リポジトリーをすべて無効にします。

      # subscription-manager repos --disable="*"
    2. 残りの Yum リポジトリーを一覧表示し、repo id にあるそれらの名前をメモします (ある場合) 。

      # yum repolist
    3. yum-config-manager を使用して、残りの Yum リポジトリーを無効にします。

      # yum-config-manager --disable <repo_id>

      または、すべてのリポジトリーを無効にします。

       yum-config-manager --disable \*

      利用可能なリポジトリーが多い場合には、数分の時間がかかることがあります。

  6. OpenShift Container Platform 3.10 で必要なリポジトリーのみを有効にします。

    • x86_64 サーバーでのクラウドインストールおよびオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-server-rpms" \
          --enable="rhel-7-server-extras-rpms" \
          --enable="rhel-7-server-ose-3.10-rpms" \
          --enable="rhel-7-server-ansible-2.4-rpms"
    • IBM POWER8 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-for-power-le-rpms" \
          --enable="rhel-7-for-power-le-extras-rpms" \
          --enable="rhel-7-for-power-le-optional-rpms" \
          --enable="rhel-7-server-ansible-2.6-for-power-le-rpms" \
          --enable="rhel-7-server-for-power-le-rhscl-rpms" \
          --enable="rhel-7-for-power-le-ose-3.10-rpms"
    • IBM POWER9 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-for-power-9-rpms" \
          --enable="rhel-7-for-power-9-extras-rpms" \
          --enable="rhel-7-for-power-9-optional-rpms" \
          --enable="rhel-7-server-ansible-2.6-for-power-9-rpms" \
          --enable="rhel-7-server-for-power-le-rhscl-rpms" \
          --enable="rhel-7-for-power-le-ose-3.10-rpms"

3.7. 基本パッケージのインストール

注記

ホストで RHEL 7.5 が実行されており、OpenShift Container Platform のデフォルト docker 設定 (OverlayFS ストレージおよびすべてのデフォルトロギングオプションを使用) を受け入れる場合、「インベントリーファイルの設定」に移動し、クラスターを表すインベントリーを作成できます。インストールの実行時に使用される prerequisites.yml Playbook により、デフォルトのパッケージおよび設定が適切に適用されるようになります。

ホストで RHEL 7.4 を実行しているか、または RHEL 7.5 を実行しており、さらに docker 設定をカスタマイズする必要がある場合、このトピックの残りのセクションのガイダンスに従ってください。

RHEL 7 システムの場合:

  1. 以下の基本パッケージをインストールします。

    # yum install wget git net-tools bind-utils yum-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct
  2. システムを最新パッケージに更新します。

    # yum update
    # systemctl reboot
  3. RPM ベースのインストーラーを使用してインストールを実行することを計画している場合は、この手順を省略できます。ただし、 コンテナー化されたインストーラーの使用を計画している場合は、以下を実行します。

    1. atomic パッケージをインストールします。

      # yum install atomic
    2. Docker のインストール に進みます。
  4. RPM ベースの OpenShift Container Platform インストーラーユーティリティーを提供する以下のパッケージをインストールし、Ansible、Playbook および関連する設定ファイルなどのクラスターインストールプロセスで必要な他のパッケージをプルします。

    # yum install openshift-ansible
    注記

    以前の OpenShift Container Platform リリースでは、この手順で atomic-openshift-utils パッケージがインストールされていましたが、OpenShift Container Platform 3.10 以降ではこのパッケージが削除され、openshift-ansible パッケージが必要な内容をすべて提供しています。

RHEL Atomic Host 7 システムの場合:

  1. 最新の Atomic ツリーにアップグレードしてホストが最新の状態にあることを確認します (利用可能な場合)。

    # atomic host upgrade
  2. アップグレードが完了し、以下の起動の準備ができたら、ホストを再起動します。

    # systemctl reboot

3.8. Docker のインストール

ここで、すべてのマスターおよびノードホストで Docker をインストールする必要があります。これにより、OpenShift Container Platform をインストールする前に Docker ストレージオプション を設定することができます。

RHEL 7 システムの場合は、Docker 1.13 をインストールします。

注記

RHEL Atomic Host 7 システムには、Docker がデフォルトでインストールされ、設定され、実行されている必要があります。

# yum install docker-1.13.1

パッケージのインストールが完了したら、バージョン 1.13 がインストールされていることを確認します。

# rpm -V docker-1.13.1
# docker version
注記

クラスターインストールプロセスは、/etc/sysconfig/docker ファイルを自動的に変更します。

3.9. Docker ストレージの設定

作成元のコンテナーとイメージは Docker のストレージバックエンドに保存されます。このストレージは一時的なストレージであり、アプリケーションの必要を満たすために割り当てられる 永続ストレージ とは区別されます。一時ストレージ の場合、コンテナーに保存されるデータはコンテナーが削除されると失われます。永続ストレージ の場合、コンテナーに保存されるデータはコンテナーが削除されてもそのまま残ります。

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

注記

ホストで RHEL 7.5 が実行されており、OpenShift Container Platform のデフォルト docker 設定 (OverlayFS ストレージおよびすべてのデフォルトロギングオプションを使用) を受け入れる場合、「インベントリーファイルの設定」に移動し、クラスターを表すインベントリーを作成できます。インストールの実行時に使用される prerequisites.yml Playbook により、デフォルトのパッケージおよび設定が適切に適用されるようになります。

ホストで RHEL 7.4 を実行しているか、または RHEL 7.5 を実行しており、さらに docker 設定をカスタマイズする必要がある場合、このトピックの残りのセクションのガイダンスに従ってください。

RHEL Atomic Host の場合

RHEL Atomic Host の Docker のデフォルトストレージバックエンドはシンプール論理ボリュームで、実稼働環境でサポートされています。システム要件にある Docker ストレージ要件に対して、このボリュームに十分なスペースが割り当てられていることを確認する必要があります。

十分なスペースが割り当てられていない場合、docker-storage-setup の使用と RHEL Atomic Host におけるストレージ管理の基本手順については、「Managing Storage with Docker Formatted Containers」を参照してください。

Red Hat Enterprise Linux の場合:

RHEL 7 の Docker のデフォルトストレージバックエンドは、ループバックデバイスにあるシンプールです。これは実稼働環境でサポートされておらず、概念実証向けの環境のみに適しています。実稼働環境の場合、シンプール論理ボリュームを作成し、Docker をそのボリュームを使用するよう再設定する必要があります。

Docker はグラフドライバーにイメージとコンテナーを保存します。グラフドライバーは DeviceMapperOverlayFSBtrfs などのプラグ可能なストレージ技術です。これらにはそれぞれメリットとデメリットがあります。たとえば、OverlayFS のコンテナーを起動し、停止するスピードは DeviceMapper よりも速いですが、Overlay FS はユニオンファイルシステムのアーキテクチャー上の制限により Portable Operating System Interface for Unix (POSIX) に準拠しておらず、Red Hat Enterprise Linux 7.2 よりも前のバージョンではサポートされていません。お使いの RHEL バージョンで OverlayFS を使用する方法についての情報は Red Hat Enterprise Linux リリースノートを参照してください。

DeviceMapper と OverlayFS のメリットと制限に関する情報は、「Choosing a Graph Driver」を参照してください。

3.9.1. OverlayFS の設定

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

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

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

3.9.2. シンプールストレージの設定

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

  • オプション A: 追加のブロックデバイスを使用する。
  • オプション B: 既存の指定されたボリュームグループを使用する。
  • オプション C: root ファイルシステムが置かれている残りのボリュームグループの空きスペースを使用する。

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

  1. 以下の 3 つのオプションのいずれかを使用して docker-pool ボリュームを作成します。

    • オプション A: 追加のブロックデバイスを使用する。

      /etc/sysconfig/docker-storage-setup で、使用するブロックデバイスのパスに DEVS を設定します。作成するボリュームグループ名に VG を設定します。docker-vg は適切なオプションになります。以下は例になります。

      # cat <<EOF > /etc/sysconfig/docker-storage-setup
      DEVS=/dev/vdc
      VG=docker-vg
      EOF

      次に docker-storage-setup を実行し、出力で docker-pool ボリュームが作成されたことを確認します。

      # docker-storage-setup                                                                                                                                                                                                                                [5/1868]
      0
      Checking that no-one is using this disk right now ...
      OK
      
      Disk /dev/vdc: 31207 cylinders, 16 heads, 63 sectors/track
      sfdisk:  /dev/vdc: unrecognized partition table type
      
      Old situation:
      sfdisk: No partitions found
      
      New situation:
      Units: sectors of 512 bytes, counting from 0
      
         Device Boot    Start       End   #sectors  Id  System
      /dev/vdc1          2048  31457279   31455232  8e  Linux LVM
      /dev/vdc2             0         -          0   0  Empty
      /dev/vdc3             0         -          0   0  Empty
      /dev/vdc4             0         -          0   0  Empty
      Warning: partition 1 does not start at a cylinder boundary
      Warning: partition 1 does not end at a cylinder boundary
      Warning: no primary partition is marked bootable (active)
      This does not matter for LILO, but the DOS MBR will not boot this disk.
      Successfully wrote the new partition table
      
      Re-reading the partition table ...
      
      If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
      to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
      (See fdisk(8).)
        Physical volume "/dev/vdc1" successfully created
        Volume group "docker-vg" successfully created
        Rounding up size to full physical extent 16.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume docker-vg/docker-pool and docker-vg/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted docker-vg/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
    • オプション B: 既存の指定されたボリュームグループを使用する。

      /etc/sysconfig/docker-storage-setup で、VG を必要なボリュームグループに設定します。以下は例になります。

      # cat <<EOF > /etc/sysconfig/docker-storage-setup
      VG=docker-vg
      EOF

      次に docker-storage-setup を実行し、出力で docker-pool ボリュームが作成されたことを確認します。

      # docker-storage-setup
        Rounding up size to full physical extent 16.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume docker-vg/docker-pool and docker-vg/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted docker-vg/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
    • オプション C: root ファイルシステムが置かれているボリュームグループの残りの空きスペースを使用する。

      root ファイルシステムが置かれているボリュームグループに必要な空きスペースがあることを確認してから、docker-storage-setup を実行して、出力で docker-pool ボリュームが作成されていることを確認します。

      # docker-storage-setup
        Rounding up size to full physical extent 32.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume rhel/docker-pool and rhel/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted rhel/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
  2. 設定を確認します。/etc/sysconfig/docker-storage ファイルに dm.thinpooldev 値と docker-pool 論理ボリュームが含まれている必要があります。

    # cat /etc/sysconfig/docker-storage
    DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/rhel-docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true "
    
    # lvs
      LV          VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
      docker-pool rhel twi-a-t---  9.29g             0.00   0.12
    重要

    Docker または OpenShift Container Platform を使用する前に、docker-pool 論理ボリュームが要求を満たす程度のサイズであることを確認します。docker-pool ボリュームは利用可能なボリュームグループの 60% である必要があり、これは LVM モニタリングによって拡張し、ボリュームグループを埋めていきます。

  3. Docker がホストでまだ起動されていない場合は、サービスを有効にしてから起動し、それが実行されていることを確認します。

    # systemctl enable docker
    # systemctl start docker
    # systemctl is-active docker

    Docker がすでに実行されている場合は、Docker を再初期化します。

    警告

    これは現在ホストにあるコンテナーまたはイメージを破棄します。

    # systemctl stop docker
    # rm -rf /var/lib/docker/*
    # systemctl restart docker

    /var/lib/docker/ にコンテンツがある場合、これを削除する必要があります。OpenShift Container Platform のインストール前に Docker が使用されていた場合にはファイルが存在します。

3.9.3. Docker ストレージの再設定

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

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

3.9.4. イメージ署名サポートの有効化

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

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

注記

atomic CLI の詳細は、Atomic CLI についてのドキュメントを参照してください。

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

$ yum install atomic

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

$ atomic trust show
* (default)                         accept

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

Atomic の信頼の設定例

$ 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 を使用します。

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

  • /etc/containers/registries.d/*
  • /etc/containers/policy.json

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

3.9.5. コンテナーログの管理

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

オプション目的

--log-opt max-size

作成される新規ログファイルのサイズを設定します。

--log-opt max-file

ホストごとに保持するログファイルの最大数を設定します。

たとえば、最大ファイルサイズを 1MB に設定し、最新の 3 つのログファイルを保持するには、/etc/sysconfig/docker ファイルを編集して、max-size=1Mmax-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

3.9.6. 利用可能なコンテナーログの表示

コンテナーログは、コンテナーが実行されているノードの /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 ドキュメントを参照してください。

3.9.7. ローカルボリューム使用のブロック

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

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

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

  • --volumes-from オプション
  • VOLUME が定義されたイメージ
  • docker volume コマンドを使ってプロビジョニングされた既存ボリュームの参照

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

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

  1. docker-novolume-plugin パッケージをインストールします。

    $ yum install docker-novolume-plugin
  2. docker-novolume-plugin サービスを有効にし、起動します。

    $ systemctl enable docker-novolume-plugin
    $ systemctl start docker-novolume-plugin
  3. /etc/sysconfig/docker ファイルを編集し、以下を OPTIONS 一覧に追加します。

    --authorization-plugin=docker-novolume-plugin
  4. docker サービスを再起動します。

    $ systemctl restart docker

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

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

3.10. Red Hat Gluster Storage ソフトウェア要件

GlusterFS ボリュームにアクセスするには、すべてのスケジュール可能なノードで mount.glusterfs コマンドを利用できる必要があります。RPM ベースのシステムの場合は、glusterfs-fuse パッケージがインストールされている必要があります。

# yum install glusterfs-fuse

このパッケージはすべての RHEL システムにインストールされています。ただし、サーバーが x86_64 アーキテクチャーを使用する場合は Red Hat Gluster Storage の最新バージョンに更新することを推奨します。そのためには、以下の RPM リポジトリーを有効にする必要があります。

# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms

glusterfs-fuse がノードにすでにインストールされている場合、最新バージョンがインストールされていることを確認します。

# yum update glusterfs-fuse

3.11. 次のステップ

ホストの準備が完了したら、インベントリーファイルの設定に移行できます。

注記

スタンドアロンレジストリーをインストールする場合は、スタンドアロンレジストリーのインストールを続行します。

第4章 インベントリーファイルの設定

4.1. クラスターのインベントリーファイルのカスタマイズ

Ansible インベントリーファイルはクラスター内のホストについての詳細や OpenShift Container Platform インストールのクラスター設定の詳細を記述します。OpenShift Container Platform インストール Playbook は、ホストのセットに OpenShigt Container Platform をインストールする方法を判別するためにインベントリーファイルを読み取ります。

注記

インベントリーファイルの形式についての詳細 (YAML 構文の基本事項を含む) については、Ansible ドキュメントを参照してください。

ホストの準備」で説明されているように openshift-ansible RPM パッケージをインストールする場合、Ansible の依存関係は /etc/ansible/hosts のデフォルトの場所でファイルを作成します。ただし、ファイルは単純にデフォルトの Ansible のサンプルであり、OpenShift Container Platform 設定にとくに関連している変数はありません。OpenShift Container Platform を適切にインストールするには、ファイルのデフォルトの内容を、クラスターのトポロジーおよび要件に基づいて独自の設定に置き換える 必要があります

以下のセクションでは、クラスターのインストール時にインベントリーファイルに設定するために一般的に使用される変数について説明します。説明されている Ansible 変数の多くはオプションの変数です。開発環境の場合は、必要な変数のデフォルト値を受け入れるだけで十分ですが、実稼働環境では、利用可能な各種のオプションを理解しておくことをお勧めします。

まず、いくつかの例のインベントリーファイルのサンプルを確認し、クラスターインストールの開始時に使用します。

注記

イメージには更新を維持するためにバージョン番号ポリシーが必要です。詳細は『Architecture Guide』の「Image Version Tag Policy」のセクションを参照してください。

4.2. クラスター変数の設定

Ansible インストールの実行時に OpenShift Container Platform クラスター全体にグローバルに適用される環境変数を割り当てるには、必要な変数を /etc/ansible/hosts ファイルの [OSEv3:vars] セクションにそれぞれ単一行で指定します。以下は例になります。

[OSEv3:vars]

openshift_master_identity_providers=[{'name': 'htpasswd_auth',
'login': 'true', 'challenge': 'true',
'kind': 'HTPasswdPasswordIdentityProvider',}]

openshift_master_default_subdomain=apps.test.example.com
重要

Ansible インベントリーファイルのパラメーター値に、#, { or } などの特殊文字が含まれている場合、値をダブルエスケープ (double-escape) する必要があります (値を単一と二重引用符で囲みます)。たとえば、mypasswordwith###hashsigns を変数 openshift_cloudprovider_openstack_password の値として使用し、これを Ansible ホストインベントリーファイルで openshift_cloudprovider_openstack_password='"mypasswordwith###hashsigns"' として宣言します。

以下の表は、クラスター全体に割り当てることのできる Ansible インストーラーで使用される変数について説明しています。

表4.1 一般的なクラスター変数

変数目的

ansible_ssh_user

この変数はインストーラーで使用する SSH ユーザーを設定します。デフォルトは root です。このユーザーはパスワードを必要としない SSH ベースの認証を許可する必要があります。SSH キーベースの認証を使用する場合、そのキーは SSH エージェントで管理される必要があります。

ansible_become

ansible_ssh_userroot でない場合、この変数は true に設定する必要があり、ユーザーをパスワードレスの sudo 用に設定する必要があります。

debug_level

この変数は、 ログを systemd-journald.service に記録する INFO メッセージを設定します。以下のいずれかを設定します。

  • 0: エラーおよび警告のみをログに記録
  • 2: 通常の情報をログに記録 (これはデフォルトのレベルです)
  • 4: デバッグレベルの情報をログに記録
  • 6: API レベルのデバッグ情報 (要求/応答) をログに記録
  • 8: 本体レベルの API デバッグ情報をログに記録

デバッグログのレベルについての詳細は、「ロギングレベルの設定」を参照してください。

openshift_clock_enabled

クラスターノードでネットワークタイムプロトコル (NTP) を有効にするかどうか。デフォルトは true です。

重要

クラスター内のマスターおよびノードが同期されなくなる状態を防ぐには、このパラメーターのデフォルト値を変更しないでください。

openshift_master_admission_plugin_config

この変数は、インベントリーホストファイルの要件に基づいてパラメーターと任意の JSON 値を設定します。以下は例になります。

openshift_master_admission_plugin_config={"ClusterResourceOverride":{"configuration":{"apiVersion":"v1","kind":"ClusterResourceOverrideConfig","memoryRequestToLimitPercent":"25","cpuRequestToLimitPercent":"25","limitCPUToMemoryPercent":"200"}}}

openshift_master_audit_config

この変数は API サービスの監査を有効にします。詳細は、「監査の設定」を参照してください。

openshift_master_cluster_hostname

この変数はクラスターのホスト名を上書きします。デフォルトはマスターのホスト名です。

openshift_master_cluster_public_hostname

この変数はクラスターのパブリックホスト名を上書きします。デフォルトはマスターのホスト名です。外部ロードバランサーを使用する場合は、外部ロードバランサーのアドレスを指定します。

例:

openshift_master_cluster_public_hostname=openshift-ansible.public.example.com

openshift_master_cluster_method

オプションです。この変数は複数マスターのデプロイ時の HA メソッドを定義します。native メソッドをサポートします。詳細は、「複数マスター」を参照してください。

openshift_rolling_restart_mode

この変数は、アップグレード Playbook を直接実行する際に HA マスターのローリング再起動 (例: マスターは一度に 1 つずつ停止します) を有効にします。これはデフォルトで services となっており、マスターでのサービスのローリング再起動を許可します。また system に設定することもでき、これによりローリング、完全なシステム再起動が有効になります。

openshift_master_identity_providers

この変数は アイデンティティープロバイダーを設定します。デフォルト値は Deny Allです。サポートされているアイデンティティープロバイダーを使用する場合は OpenShift Container Platform がそれを使用するよう設定します。

openshift_master_named_certificates

これらの変数は、インストールの一部としてデプロイされるカスタム証明書を設定するために使用されます。詳細は、「カスタム証明書の設定」を参照してください。

openshift_master_overwrite_named_certificates

openshift_hosted_router_certificate

ホストされているルーターのカスタム証明書の場所を指定します。

openshift_hosted_registry_cert_expire_days

自動生成されるレジストリー証明書の有効日数。デフォルトで 730 (2 年) に設定されます。

openshift_ca_cert_expire_days

自動生成される CA 証明書の有効日数。デフォルトで 1825 (5 年) に設定されます。

openshift_node_cert_expire_days

自動生成されるノード証明書の有効日数。デフォルトで 730 (2 年) に設定されます。

openshift_master_cert_expire_days

自動生成されるマスター証明書の有効日数。デフォルトで 730 (2 年) に設定されます。

etcd_ca_default_days

自動生成される外部 etcd 証明書の有効日数。etcd CA、ピア、サーバー、クライアント証明書の有効性を管理します。デフォルトで 1825 (5 年) に設定されます。

os_firewall_use_firewalld

true に設定され、デフォルトの iptables ではなく firewalld が使用されます。RHEL Atomic Host では利用できません。詳細は「ファイアウォールの設定」のセクションを参照してください。

openshift_master_session_name

これらの変数は OAuth 設定のセッションオプションのデフォルトを上書きします。詳細は「 セッションオプションの設定」を参照してください。

openshift_master_session_max_seconds

openshift_master_session_auth_secrets

openshift_master_session_encryption_secrets

openshift_master_image_policy_config

マスター設定で imagePolicyConfig を設定します。詳細は 「イメージ設定」を参照してください。

openshift_router_selector

ルーター Pod を自動的にデプロイするためのデフォルトのノードセレクター。詳細は「ノードホストラベルの設定」を参照してください。

openshift_registry_selector

レジストリー Pod を自動的にデプロイするためのデフォルトのノードセレクター。詳細は、「ノードホストラベルの設定」を参照してください。

openshift_template_service_broker_namespaces

この変数は、ブローカーが提供するテンプレートの 1 つ以上の namespace を指定することでテンプレートサービスブローカーを有効にします。

template_service_broker_selector

テンプレートサービスブローカー Pod を自動的にデプロイするためのデフォルトのノードセレクター。デフォルトで {"node-role.kubernetes.io/infra":"true"} に設定されています。詳細は「ノードホストラベルの設定」を参照してください。

osm_default_node_selector

この変数は、Pod を配置する際にプロジェクトがデフォルトで使用するノードセレクターを上書きします。デフォルトのセレクターはマスター設定ファイルの projectConfig.defaultNodeSelector フィールドで定義されます。OpenShift Container Platform 3.9 以降では、これが定義されていない場合はデフォルトで node-role.kubernetes.io/compute=true となります。

openshift_docker_additional_registries

OpenShift Container Platform は指定された追加レジストリーを docker 設定に追加します。これらは検索対象のレジストリーです。このレジストリーへのアクセスに必要なレジストリーが 80 以外の場合は、<address>:<port> の形式でポート番号を含める必要があります。

例:

openshift_docker_additional_registries=example.com:443
注記

クラスターを別のレジストリーを使用するように設定する必要がある場合は、openshift_docker_additional_registries を使用するのではなく、oreg_url を設定します。

openshift_docker_insecure_registries

OpenShift Container Platform は指定された追加の非セキュアなレジストリーを docker 設定に追加します。それらのレジストリーの SSL (Secure Sockets Layer) は検証されません。ホスト名またはホストの IP アドレスに設定できます。0.0.0.0/0 は IP アドレスの有効な設定ではありません。

openshift_docker_blocked_registries

OpenShift Container Platform は指定されたブロック済みレジストリーを docker 設定に追加します。これは一覧表示されるレジストリーをブロックします。これを all に設定すると、他の変数で使用されていないすべてのレジストリーがブロックされます。

openshift_metrics_hawkular_hostname

この変数は、マスター設定でクラスターメトリクスの metricsPublicURL を上書きすることで、メトリクスコンソールと統合するホスト名を設定します。この変数を変更する場合は、ホスト名がルーター経由でアクセスできることを確認してください。

openshift_clusterid

この変数は AWS アベイラビリティーゾーン固有のクラスター識別子です。これを使用することで、複数のゾーンまたは複数のクラスターを持つ Amazon Web Service (AWS) での潜在的な問題を回避することができます。詳細は「AWS のクラスターへのラベル付け」を参照してください。

openshift_image_tag

この変数を使用して、インストールまたは設定するコンテナーイメージタグを指定します。

openshift_pkg_version

この変数を使用して、インストールまたは設定する RPM バージョンを指定します。

警告

クラスターのセットアップ後に openshift_image_tag または openshift_pkg_version 変数を変更する場合はアップグレードがトリガーされ、ダウンタイムが発生します。

  • openshift_image_tag が設定されている場合、この値は別のバージョンがインストールされている場合でもシステムコンテナー環境のすべてのホストに使用されます。
  • openshift_pkg_version が設定されている場合、この値は別のバージョンがインストールされている場合でも RPM ベースの環境のすべてのホストに使用されます。

表4.2 ネットワーク変数

変数目的

openshift_master_default_subdomain

この変数は、公開されるルートに使用するデフォルトのサブドメインを上書きします。

os_sdn_network_plugin_name

この変数は、どの OpenShift SDN プラグインを Pod ネットワークに使用するかを設定します。デフォルトでは標準 SDN プラグインの redhat/openshift-ovs-subnet に設定されます。変数を redhat/openshift-ovs-multitenant に設定してマルチテナント SDN プラグインを使用します。

osm_cluster_network_cidr

この変数は SDN クラスターネットワーク CIDR ブロックを上書きします。これは、Pod IP の割り当て元のネットワークです。このネットワークブロックは非公開ブロックとし、Pod、ノード、またはマスターがアクセスする必要のある可能性があるインフラストラクチャーの既存のネットワークブロックと競合しないようにする必要があります。デフォルトは 10.128.0.0/14 であり、デプロイ後は SDN マスター設定でこれに一部の変更を加えられることがありますが、任意に再設定することはできません。

openshift_portal_net

この変数は、サービスOpenShift Container Platform SDN 内で作成する際のサブネットを設定します。このネットワークブロックは非公開とし、Pod、ノード、またはマスターがアクセスする必要の可能性があるインフラストラクチャーの既存のネットワークブロックと競合しないようにする必要があります。そうでない場合、インストールは失敗します。デフォルトは 172.30.0.0/16 であり、デプロイ後はこれを再設定することはできません。デフォルトを変更する場合は、docker0 ネットワークブリッジがデフォルトで使用する 172.17.0.0/16 の使用を避けるようにするか、または docker0 ネットワークを変更します。

osm_host_subnet_length

この変数は、OpenShift Container Platform SDN により Pod IP のホストサブネットごとに割り当てられるサイズを指定します。デフォルトは 9 であり、これは各ホストにサイズが /23 のサブネットが割り当てられることを意味します。デフォルトの 10.128.0.0/14 クラスターネットワークの場合、これは 10.128.0.0/23、10.128.2.0/23、10.128.4.0/23 などを割り当てます。これはデプロイ後に再設定することはできません。

openshift_node_proxy_mode

この変数は、使用するサービスプロキシーモードを指定します。iptables (デフォルトの純粋な iptables 実装) または userspace (ユーザー空間プロキシー) のいずれかを指定します。

openshift_use_flannel

この変数は、デフォルトの SDN の代わりに flannel を代替ネットワーキングレイヤーとして有効にします。flannel を有効にする場合は、openshift_use_openshift_sdn 変数を使用してデフォルトの SDN を無効にしてください。詳細については、「Flannel の使用」を参照してください。

openshift_use_openshift_sdn

OpenShift SDN プラグインを無効にするには、false に設定します。

4.3. デプロイメントタイプの設定

Playbook 全体で使用される各種デフォルト値とインストーラーによって使用されるロールは、デプロイメントタイプの設定 (通常は Ansible インベントリーファイルで定義されます) に基づいて決定されます。

OpenShift Container Platform バリアントをインストールするには、インベントリーファイルの [OSEv3:vars] セクションにある openshift_deployment_type パラメーターが openshift-enterprise に設定されていることを確認してください。

[OSEv3:vars]
openshift_deployment_type=openshift-enterprise

4.4. ホスト変数の設定

Ansible のインストール時に環境変数をホストに割り当てるには、[masters] セクションまたは [nodes] セクションにホストを入力した後に /etc/ansible/hosts ファイルで必要な変数を指定します。以下は例を示しています。

[masters]
ec2-52-6-179-239.compute-1.amazonaws.com openshift_public_hostname=ose3-master.public.example.com

以下の表は、Ansible インストーラーで使用され、個々のホストエントリーに割り当てることができる変数を示しています。

表4.3 ホスト変数

変数目的

openshift_public_hostname

この変数は、システムのパブリックホスト名を上書きします。クラウドインストールやネットワークアドレス変換 (NAT) を使用するネットワーク上のホストに使用します。

openshift_public_ip

この変数は、システムのパブリック IP アドレスを上書きします。クラウドインストールやネットワークアドレス変換 (NAT) を使用するネットワーク上のホストに使用します。

openshift_node_labels

この変数は非推奨になっています。現在のノードラベルの設定方法については、「ノードグループおよびホストマッピングの定義」を参照してください。

openshift_node_kubelet_args

この変数は、ノードに kubeletArguments を設定するために使用します。たとえば、コンテナーとイメージのガベージコレクションに使用される引数や、ノードごとのリソースを指定するために使用される引数などがこれに該当します。kubeletArguments は、Kubelet に直接渡されるキーと値のペアで、Kubelet のコマンドライン引数に一致します。kubeletArguments は移行または検証されず、使用される場合には無効になることがあります。これらの値がノード設定の他の設定を上書きすると、無効な設定が生じる可能性があります。使用例: {'image-gc-high-threshold': ['90'],'image-gc-low-threshold': ['80']}

openshift_docker_options

この変数は、/etc/sysconfig/docker 内に追加の docker オプションを設定します。たとえば、コンテナーログの管理で使用されるオプションなどがこれに該当します。json-file を使用することを推奨します。

次に、Docker が json-file ログドライバーを使用するように設定する例を示します。この例では、Docker は 1 MB のログファイル 3 つをローテーションします。

"--log-driver json-file --log-opt max-size=1M --log-opt max-file=3"

openshift_schedulable

この変数は、ホストがスケジュール可能ノードとしてマークされているかどうか、つまり、新しい Pod を配置できるかどうかを設定します。マスターでのスケジュール可能性の設定を参照してください。

openshift_node_problem_detector_install

この変数は、Node Problem Detector をアクティブにするために使用されます。false, the default に設定される場合、Node Problem Detector はインストールされず、起動しません。

4.5. ノードグループおよびホストマッピングの定義

OpenShift Container Platform 3.10 以降では、ノードの設定はマスターからブートストラップされるようになりました。ノードおよびサービスが起動されると、ノードは、kubeconfig および他のノード設定ファイルが存在するかどうかをクラスターに参加する前に確認します。存在しない場合には、ノードはマスターから設定をプルしてから、クラスターに参加します。

このプロセスが導入されることにより、管理者はノードホストごとに一意のノード設定を手動でメンテナンスする必要がなくなり、ノードホストの /etc/origin/node/node-config.yaml ファイルの内容がマスターから取得される ConfigMaps で提供されるようになりました。

4.5.1. ノードの ConfigMap

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

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

  • node-config-master
  • node-config-infra
  • node-config-compute

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

  • node-config-all-in-one
  • node-config-master-infra
重要

ノードホストの /etc/origin/node/node-config.yaml ファイルには変更を加えないようにしてください。このファイルは、ノードが使用する ConfigMap に定義されている設定により上書きされます。

4.5.2. ノードグループの定義

最新の 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: []
1
ノードのグループ名です。
2
ノードグループに関連付けられるノードラベルの一覧です。詳細は、「ノードホストラベル」を参照してください。
3
ノードグループの設定の編集です。

インベントリーファイルの [OSEv3:vars] グループに openshift_node_groups 変数が設定されていない場合には、上記で定義したデフォルト値が使用されます。ただし、これらのデフォルト値とは違う値を使用する場合には、インベントリーファイルに (任意の全ノードグループなどを含む) openshift_node_groups の構造全体を定義する必要があります。

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

注記

設定可能なノード変数に関する情報は、「Master and Node Configuration Files」を参照してください。

たとえば、インベントリーファイルの以下のエントリーは、node-config-masternode-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 も設定できます。

  • node-config-computekubeletArguments.pods-per-core20 に設定するために変更するなど、一覧を使用できます。
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']}]}]
  • node-config-compute グループを kubelet に 2 つのパラメーターを追加するために変更するなど、複数のキーと値のペアを変更するために一覧を使用できます。
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']}]}]
  • node-config-compute グループを perFSGroup512Mi に設定するために変更するなど、ディクショナリーを値として使用することができます。
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) が更新され、最終的にホスト上のノードの設定ファイルに影響を与えます。

4.5.3. ホストとノードグループのマッピング

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

重要

ホストごとに openshift_node_group_name をノードグループに設定することは、デフォルトのノードグループ定義および ConfigMap を使用しているか、または独自の設定をカスタマイズしているかにかかわらず、すべてのクラスターインストールで必要です。

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'

4.5.4. ノードホストラベル

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

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

4.5.4.1. マスターでの Pod スケジュール可能性の設定

インストールプロセス時にマスターとして指定するすべてのホストは、マスターが OpenShift SDN の一部として設定されるようにノードとして設定される必要もあります。これらのホストのエントリーを [nodes] セクションに追加してこの設定を行う必要があります。

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

インストール後にホストのスケジュール可能性を変更したい場合は、「ノードをスケジュール対象外 (Unschedulable) またはスケジュール対象 (Schedulable) としてマークする」を参照してください。

4.5.4.2. ノードでの Pod スケジュール可能性の設定

マスターはデフォルトでスケジュール対象ノードとしてマークされるため、デフォルトノードセレクターは、クラスターのインストール時にデフォルトで設定されます。デフォルトノードセレクターは、Pod を配置する際にデフォルトでプロジェクトが使用するノードを判別するためにマスター設定ファイルの projectConfig.defaultNodeSelector フィールドに定義されます。これは、osm_default_node_selector 変数を使用して上書きされない限り、node-role.kubernetes.io/compute=true に設定されます。

重要

インストール時にデフォルトノードセレクターのnode-role.kubernetes.io/compute=true を受け入れる場合、クラスターで非マスターノードとして定義されているのが専用インフラストラクチャーノードだけでないことを確認してください。この場合、プロジェクトに対する Pod のスケジューリングの際にデフォルトノードセレクターに一致するnode-role.kubernetes.io/compute=true ラベル付きのノードが存在しないため、アプリケーション Pod はデプロイに失敗します。

インストール後に必要に応じてこの設定を調整する手順については、「クラスター全体でのデフォルトノードセレクターの設定」を参照してください。

4.5.4.3. 専用インフラストラクチャーノードの設定

実稼働環境では、レジストリー Pod とルーター Pod をユーザーアプリケーション用の Pod とは別に実行できる専用インフラストラクチャーノードを保持することを推奨します。

openshift_router_selector および openshift_registry_selector Ansible 設定は、レジストリー Pod とルーター Pod を配置する際に使用されるラベルセレクターを決定します。これらはデフォルトで node-role.kubernetes.io/infra=true に設定されます。

# 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'

レジストリーとルーターは、node-role.kubernetes.io/infra=true ラベルが付いた、専用インフラストラクチャーノードと見なされるノードホスト上でのみ実行できます。お使いの OpenShift Container Platform 環境に、node-role.kubernetes.io/infra=true ラベルが付いたノードホストが 1 つ以上存在することを確認してください。デフォルトの node-config-infra を使用してこのラベルを設定できます。

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

セレクター設定に一致するノードが [nodes] セクションにない場合、デフォルトのルーターとレジストリーはデプロイに失敗し、Pendingステータスになります。

レジストリーとルーターの管理に OpenShift Container Platform を使用しない場合は、以下のように Ansible 設定を行います。

openshift_hosted_manage_registry=false
openshift_hosted_manage_router=false

デフォルトの registry.access.redhat.com 以外のイメージレジストリーを使用する場合は、/etc/ansible/hosts ファイルで 必要なレジストリーを指定する必要があります。

マスターでのスケジュール可能性の設定で説明されているように、マスターホストはデフォルトでスケジュール可能としてマークされます。マスターホストに node-role.kubernetes.io/infra=true ラベルを付けており、他に専用インフラストラクチャーノードがない場合、マスターホストはスケジュール対象としてマークされる必要もあります。そうでない場合には、レジストリーとルーター Pod をどこにも配置することができなくなります。

これを実行するには、デフォルトの node-config-master-infra ノードグループを使用できます。

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

4.6. マスター API ポートの設定

マスター API で使用するデフォルトのポートを設定するには、/etc/ansible/hosts ファイルに以下の変数を設定します。

表4.4 マスター API ポート

変数目的

openshift_master_api_port

この変数は、OpenShift Container Platform API へのアクセスに使用するポート番号を設定します。

例:

openshift_master_api_port=3443

Web コンソールポート設定 (openshift_master_console_port) は、 API サーバーのポート (openshift_master_api_port) に一致している必要があります。

4.7. クラスターのプレインストールチェックの設定

プレインストールチェックは、openshift_health_checker Ansible ロールの一部として実行される診断タスクのセットです。OpenShift Container Platform の Ansible インストールの前に実行され、必要なインベントリー値が設定されていることを確認し、正常なインストールを妨げたり干渉したりする可能性があるホストの潜在的な問題を特定します。

以下の表は、OpenShift Container Platform のすべての Ansible インストールの前に実行される、使用可能なプレインストールチェックを示しています。

表4.5 プレインストールチェック

チェック名目的

memory_availability

このチェックでは、OpenShift Container Platform の特定のデプロイメントで推奨されるメモリー容量がホストにあることを確認します。デフォルト値は、最新のインストールドキュメントから取得されたものです。インベントリーファイルで openshift_check_min_host_memory_gb クラスター変数を設定することで、最小メモリー要件のユーザー定義値を設定できます。

disk_availability

このチェックは、etcd、マスター、およびノードホストに対してのみ実行され、OpenShift Container Platform インストールのマウントパスに十分なディスク領域が残っていることを確認します。推奨されるディスク値は、最新のインストールドキュメントから取得されたものです。インベントリーファイルで openshift_check_min_host_disk_gb クラスター変数を設定することで、最小ディスク領域のユーザー定義値を設定できます。

docker_storage

docker デーモン (ノードおよびシステムコンテナーのインストール) に依存するホストでのみ実行され、 docker の合計使用率がユーザー定義の上限を超えていないことを確認します。ユーザー定義の上限が設定されていない場合、docker の最大使用率のしきい値はデフォルトで使用可能な合計サイズの 90% になります。合計使用率のしきい値上限は、インベントリーファイルで変数を使用して設定できます。( max_thinpool_data_usage_percent=90)。最大シンプール使用率のユーザー定義の上限は、インベントリーファイルで max_thinpool_data_usage_percent クラスター変数を設定することで設定できます。

docker_storage_driver

docker デーモンが OpenShift Containe Platform でサポートされているストレージドライバーを使用していることを確認します。devicemapper ストレージドライバーが使用されている場合は、ループバックデバイスが使用されていないことも確認します。詳細については、『Docker’s Use the Device Mapper Storage Driver 』ガイドを参照してください。

docker_image_availability

OpenShift Container Platform インストールで必要なイメージがローカルで、またはホストマシン上の 1 つ以上の設定済みコンテナーイメージレジストリー で使用可能であることの確認を試行します。

package_version

yum ベースのシステムで実行され、必要な OpenShift Container Platform パッケージの複数のリリースが利用可能かどうかを確認します。OpenShift のエンタープライズインストール時にパッケージの複数のリリースが利用可能である場合は、各リリース用に複数の yum リポジトリーが有効になっていることが示され、インストールの際に問題になることがあります。このチェックは、インベントリーファイルに openshift_release 変数が定義されていない場合には省略されます。

package_availability

OpenShift Container Platform の RPM インストールの前に実行され、現在のインストールに必要な RPM パッケージが利用可能であることを確認します。

package_update

yum アップデートまたはパッケージのインストールが成功するかどうかを、実際にインストールを行ったり、ホストで yum を実行したりせずに確認します。

特定のプレインストールチェックを無効にするには、カンマ区切りのチェック名の一覧を指定した変数 openshift_disable_check をインベントリーファイルに組み込みます。以下は例になります。

openshift_disable_check=memory_availability,disk_availability
注記

既存のクラスターの診断用に実行するための類似のヘルスチェックセットが Ansible ベースのヘルスチェックに用意されています。また、「証明書の再デプロイ」には証明書の有効期限を確認するためのチェックセットもあります。

4.8. レジストリーの場所の設定

registry.access.redhat.com にあるデフォルト以外のイメージレジストリーを使用する場合は、必要なレジストリーを /etc/ansible/hosts ファイル内に指定します。

oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

表4.6 レジストリー変数

変数目的

oreg_url

別のイメージの場所に設定されます。registry.access.redhat.com でデフォルトのレジストリーを使用していない場合に必要です。デフォルトコンポーネントはイメージのプレフィックスおよびバージョンを oreg_url 値から継承します。

openshift_examples_modify_imagestreams

デフォルト以外のレジストリーを参照している場合は true に設定します。イメージストリームの場所を oreg_url の値に変更します。

例:

oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

4.9. レジストリールートの設定

ユーザーが OpenShift Container Platform クラスターの外部からイメージをプルして内部の Docker レジストリーにプッシュできるように、/etc/ansible/hosts ファイルにレジストリールートを設定します。デフォルトでは、レジストリールートは docker-registry-default.router.default.svc.cluster.local です。

表4.7 レジストリールート変数

変数目的

openshift_hosted_registry_routehost

必要なレジストリールートの値に設定します。ルートには、ルーターによって通信が管理されるインフラストラクチャーノードに解決される名前、またはデフォルトのアプリケーションサブドメインのワイルドカード値として設定したサブドメインのいずれかが含まれます。たとえば、openshift_master_default_subdomain パラメーターを apps.example.com に設定し、*.apps.example.com がインフラストラクチャーノードまたはロードバランサーに解決される場合は、registry.apps.example.com をレジストリールートとして使用できます。

openshift_hosted_registry_routecertificates

レジストリー証明書へのパスを設定します。証明書の場所の値を指定しない場合、証明書が生成されます。以下の証明書の場所を定義できます。

  • certfile
  • keyfile
  • cafile

openshift_hosted_registry_routetermination

以下のいずれかの値に設定します。

  • edge ルーターで暗号化を終了し、送信先から提供される新しい証明書で再暗号化するには、reencrypt に設定します。
  • 送信先で暗号化を終了するには、passthrough に設定します。トラフィックは送信先で復号化されます。

例:

openshift_hosted_registry_routehost=<path>
openshift_hosted_registry_routetermination=reencrypt
openshift_hosted_registry_routecertificates= "{'certfile': '<path>/org-cert.pem', 'keyfile': '<path>/org-privkey.pem', 'cafile': '<path>/org-chain.pem'}"

4.10. レジストリーコンソールの設定

デフォルト以外の Cockpit レジストリーコンソールイメージを使用する場合や、特定のバージョンのコンソールが必要な場合は、以下のように必要なレジストリーを /etc/ansible/hosts ファイル内に指定します。

openshift_cockpit_deployer_prefix=<registry_name>/<namespace>/
openshift_cockpit_deployer_version=<cockpit_image_tag>

表4.8 レジストリー変数

変数目的

openshift_cockpit_deployer_prefix

イメージが置かれるディレクトリーへの URL およびパスを指定します。パスの値は、ose- ではなく /openshift3 で終了する必要があります。これは、他のイメージの標準です。

openshift_cockpit_deployer_version

Cockpit イメージのバージョンを指定します。

例: イメージが registry.example.com/openshift3/registry-console にあり、バージョン 3.10.1 が必要な場合は、以下を入力します。

openshift_cockpit_deployer_prefix='registry.example.com/openshift3/'
openshift_cockpit_deployer_version='3.10.1'

4.11. Red Hat Gluster Storage の永続ストレージの設定

Red Hat Gluster Storage は、OpenShift Container Platform の永続ストレージと動的プロビジョニングを提供するように設定でき、OpenShift Container Platform 内のコンテナー化ストレージ (コンバージドモード) としても、独自のノード上の非コンテナー化ストレージ (インデペンデントモード) としても使用できます。

追加情報と以下を含む例については、「Red Hat Gluster Storage を使用する永続ストレージ」を参照してください。

4.11.1. コンバージドモードの設定

重要

具体的なホストの準備と前提条件については、コンバージドモードに関する考慮事項を参照してください。

  1. インベントリーファイルの [OSEv3:vars] セクションに次の変数を追加し、設定に合わせてそれらを調整します。

    [OSEv3:vars]
    ...
    openshift_storage_glusterfs_namespace=app-storage
    openshift_storage_glusterfs_storageclass=true
    openshift_storage_glusterfs_storageclass_default=false
    openshift_storage_glusterfs_block_deploy=true
    openshift_storage_glusterfs_block_host_vol_size=100
    openshift_storage_glusterfs_block_storageclass=true
    openshift_storage_glusterfs_block_storageclass_default=false
  2. [OSEv3:children] セクションに glusterfs を追加して、 [glusterfs] グループを有効にします。

    [OSEv3:children]
    masters
    nodes
    glusterfs
  3. GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs] セクションを追加します。ノードごとに、 glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスは、パーティションや LVM PV がないベアでなければなりません。変数は以下の形式で指定します。

    <hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

    例:

    [glusterfs]
    node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
  4. [glusterfs] の下に一覧表示されているホストを [nodes] グループに追加します。

    [nodes]
    ...
    node11.example.com openshift_node_group_name="node-config-compute"
    node12.example.com openshift_node_group_name="node-config-compute"
    node13.example.com openshift_node_group_name="node-config-compute"

4.11.2. インデペンデントモードの設定

  1. インベントリーファイルの [OSEv3:vars] セクションに次の変数を追加し、設定に合わせてそれらを調整します。

    [OSEv3:vars]
    ...
    openshift_storage_glusterfs_namespace=app-storage
    openshift_storage_glusterfs_storageclass=true
    openshift_storage_glusterfs_storageclass_default=false
    openshift_storage_glusterfs_block_deploy=true
    openshift_storage_glusterfs_block_host_vol_size=100
    openshift_storage_glusterfs_block_storageclass=true
    openshift_storage_glusterfs_block_storageclass_default=false
    openshift_storage_glusterfs_is_native=false
    openshift_storage_glusterfs_heketi_is_native=true
    openshift_storage_glusterfs_heketi_executor=ssh
    openshift_storage_glusterfs_heketi_ssh_port=22
    openshift_storage_glusterfs_heketi_ssh_user=root
    openshift_storage_glusterfs_heketi_ssh_sudo=false
    openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"
  2. [OSEv3:children] セクションに glusterfs を追加して、 [glusterfs] グループを有効にします。

    [OSEv3:children]
    masters
    nodes
    glusterfs
  3. GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs] セクションを追加します。ノードごとに、 glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくと も 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。また、glusterfs_ip をノードの IP アドレスに設定します。変数は以下の形式で指定します。

    <hostname_or_ip> glusterfs_ip=<ip_address> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

    例:

    [glusterfs]
    gluster1.example.com glusterfs_ip=192.168.10.11 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    gluster2.example.com glusterfs_ip=192.168.10.12 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    gluster3.example.com glusterfs_ip=192.168.10.13 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'

4.12. OpenShift Container レジストリーの設定

統合された OpenShift Container レジストリー は、インストーラーを使用してデプロイできます。

4.12.1. レジストリーストレージの設定

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

重要

テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container Registry および Quay が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

通常インストーラー (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 レジストリーのストレージを提供するように設定できます。これにより、冗長で信頼性の高いレジストリーのストレージを確保できます。

重要

具体的なホストの準備と前提条件については、コンバージドモードに関する考慮事項を参照してください。

  1. インベントリーファイルの [OSEv3:vars] セクションに次の変数を追加し、設定に合わせてそれらを調整します。

    [OSEv3:vars]
    ...
    openshift_hosted_registry_storage_kind=glusterfs 1
    openshift_hosted_registry_storage_volume_size=5Gi
    openshift_hosted_registry_selector='node-role.kubernetes.io/infra=true'
    1
    統合 OpenShift Container Registry をインフラストラクチャーノードで実行することが推奨されます。インフラストラクチャーノードは、OpenShift Container Platform クラスターのサービスを提供するために管理者がデプロイするアプリケーションを実行する専用ノードです。
  2. [OSEv3:children] セクションに glusterfs_registry を追加して、[glusterfs_registry] グループを有効にします。

    [OSEv3:children]
    masters
    nodes
    glusterfs_registry
  3. GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs_registry] セクションを追加します。ノードごとに、 glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は次の形式で指定します。

    <hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

    例:

    [glusterfs_registry]
    node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
    node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
  4. [glusterfs_registry] の下に一覧表示されているホストを [nodes] グループに追加します。

    [nodes]
    ...
    node11.example.com openshift_node_group_name="node-config-infra"
    node12.example.com openshift_node_group_name="node-config-infra"
    node13.example.com openshift_node_group_name="node-config-infra"
オプション 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

4.13. グローバルプロキシーオプションの設定

ホストが外部ホストに接続するために HTTP または HTTPS プロキシーを使用する必要がある場合は、プロキシーを使用するためにマスター、Docker、ビルドなどの多数のコンポーネントを設定する必要があります。ノードサービスは外部アクセスを必要としないマスター API にのみ接続するため、プロキシーを使用するように設定する必要はありません。

この設定を単純化するため、クラスターまたはホストレベルで次の Ansible 変数を指定し、これらの設定を環境全体に均一に適用することができます。

注記

ビルド用のプロキシー環境の定義方法の詳細については、「グローバルビルドのデフォルトとオーバーライドの設定」を参照してください。

表4.9 クラスタープロキシー変数

変数目的

openshift_http_proxy

この変数はマスターおよび Docker デーモンの HTTP_PROXY 環境変数を指定します。

openshift_https_proxy

この変数は、マスターおよび Docker デーモンの HTTPS_PROXY 環境変数を指定します。

openshift_no_proxy

この変数は、マスターおよび Docker デーモンに NO_PROXY 環境変数を設定するために使用されます。定義されたプロキシーを使用しないホスト名、ドメイン名、またはワイルドカードホスト名のカンマ区切りの一覧を提供します。デフォルトでは、この一覧は、定義済みのすべての OpenShift Container Platform ホスト名の一覧で拡張されます。

openshift_generate_no_proxy_hosts

このブール変数は、すべての定義済み OpenShift ホストの名前と *.cluster.local が自動的に NO_PROXY 一覧に追加されるかどうかを指定します。デフォルトは true です。このオプションを上書きするには false に設定します。

openshift_builddefaults_http_proxy

この変数は、BuildDefaults 受付コントローラーを使用して、ビルドに挿入される HTTP_PROXY 環境変数を定義します。このパラメーターを定義せず、openshift_http_proxy パラメーターを定義する場合、openshift_http_proxy 値が使用されます。openshift_http_proxy の値を問わず、デフォルトの http プロキシーを無効にするには、openshift_builddefaults_http_proxy 値を False に設定します。

openshift_builddefaults_https_proxy

この変数は、BuildDefaults 受付コントローラーを使用して、ビルドに挿入される HTTPS_PROXY 環境変数を定義します。このパラメーターを定義せず、openshift_http_proxy パラメーターを定義する場合、openshift_https_proxy 値が使用されます。openshift_https_proxy の値を問わず、デフォルトの http プロキシーを無効にするには、openshift_builddefaults_https_proxy 値を False に設定します。

openshift_builddefaults_no_proxy

この変数は、BuildDefaults 受付コントローラーを使用して、ビルドに挿入される NO_PROXY 環境変数を定義します。openshift_no_proxy 値の種類を問わず、ビルドのデフォルトの no proxy 設定を無効にするには、openshift_builddefaults_no_proxy 値を False に設定します。

openshift_builddefaults_git_http_proxy

この変数は、ビルド時に git clone 操作で使用される HTTP プロキシーを定義します。これは BuildDefaults 受付コントローラーを使用して定義されます。openshift_http_proxy 値の種類を問わず、ビルド時に git clone 操作のデフォルトの https プロキシーを無効にするには、openshift_builddefaults_git_http_proxy 値を False に設定します。

openshift_builddefaults_git_https_proxy

この変数は、ビルド時に git clone 操作で使用される HTTPS プロキシーを定義します。これは BuildDefaults 受付コントローラーを使用して定義されます。openshift_https_proxy 値の種類を問わず、ビルド時に git clone 操作のデフォルトの https プロキシーを無効にするには、openshift_builddefaults_git_https_proxy 値を False に設定します。

4.14. ファイアウォールの設定

重要
  • デフォルトのファイアウォールを変更する場合は、不一致を防ぐために、クラスター内の各ホストが同じファイアウォールタイプを使用していることを確認してください。
  • Atomic Host にインストールされた OpenShift Container Platform でファイアウォールを使用しないでください。ファイアウォールは Atomic Host ではサポートされていません。
注記

iptables はデフォルトのファイアウォールですが、firewalld は新規インストールで推奨されるファイアウォールです。

OpenShift Container Platform は iptables をデフォルトのファイアウォールとして使用しますが、クラスターをインストールプロセス時に firewalld を使用するように設定できます。

iptables はデフォルトのファイアウォールであるため、OpenShift Container Platform は iptables を自動的に設定するように設計されています。ただし、iptables ルールが適切に設定されていない場合、iptables ルールによって OpenShift Container Platform が中断する可能性があります。 firewalld の利点の 1 つは、複数のオブジェクトでファイアウォールルールを安全に共有できることです。

firewalld を OpenShift Container Platform インストールのファイアウォールとして使用するには、インストール時に os_firewall_use_firewalld 変数を Ansible ホストファイルの設定変数の一覧に追加します。

[OSEv3:vars]
os_firewall_use_firewalld=True 1
1
この変数を true に設定することで、必要なポートが開き、ルールがデフォルトゾーンに追加されます。これにより、firewalld が適切に設定されていることを確認できます。
注記

firewalld のデフォルトの設定オプションを使用する際には設定オプションが制限され、これらをオーバーライドすることはできません。たとえば、ストレージネットワークを複数ゾーンのインターフェースでセットアップすることができますが、ノードが通信に使用するインターフェースはデフォルトゾーンになければなりません。

4.15. セッションオプションの設定

OAuth 設定のセッションオプションはインベントリーファイルで設定できます。デフォルトで、Ansible は sessionSecretsFile を生成された認証および暗号化シークレットで設定し、1 つのマスターで生成されたセッションが他のマスターによって復号化されるようにできます。デフォルトの場所は /etc/origin/master/session-secrets.yaml であり、このファイルはすべてのマスターで削除された場合にのみ再作成されます。

openshift_master_session_name および openshift_master_session_max_seconds を使用してセッション名と最大秒数を設定できます。

openshift_master_session_name=ssn
openshift_master_session_max_seconds=3600

設定されている場合、openshift_master_session_auth_secrets および openshift_master_encryption_secrets は同じ長さでなければなりません。

HMAC を使用したセッションの認証に使用される openshift_master_session_auth_secrets の場合、32 バイトまたは 64 バイトのシークレットを使用することを推奨します。

openshift_master_session_auth_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']

セッションの暗号化に使用される openshift_master_encryption_secrets の場合、シークレットの長さは AES-128、AES-192、または AES-256 を選択するできるようにそれぞれ 16、24、または 32 文字にする必要があります。

openshift_master_session_encryption_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']

4.16. カスタム証明書の設定

OpenShift Container Platform API のパブリックホスト名と Web コンソールカスタム提供証明書は、クラスターのインストール時にデプロイでき、インベントリーファイルで設定できます。

注記

カスタム証明書は、publicMasterURL に関連付けられたホスト名にのみ設定する必要があります。これは openshift_master_cluster_public_hostname を使用して設定できます。masterURL (openshift_master_cluster_hostname) に関連付けられたホスト名のカスタム提供証明書を使用すると、インフラストラクチャーコンポーネントが内部の masterURL ホストを使用してマスター API に接続しようとするので TLS エラーが生じます。

証明書とキーファイルのパスは、openshift_master_named_certificates クラスター変数を使用して設定できます。

openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "cafile": "/path/to/custom-ca1.crt"}]

ファイルパスは、Ansible が実行されるシステムに対してローカルである必要があります。証明書はマスターホストにコピーされ、/etc/origin/master/named_certificates/ ディレクトリー内にデプロイされます。

Ansible は、証明書の Common NameSubject Alternative Names を検出します。検出された名前は、openshift_master_named_certificates の設定時に "names" キーを指定して上書きできます。

openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "names": ["public-master-host.com"], "cafile": "/path/to/custom-ca1.crt"}]

openshift_master_named_certificates を使用して設定される証明書はマスターにキャッシュされます。つまり、別の証明書セットで Ansible を実行するたびに、以前にデプロイされたすべての証明書がマスターホストとマスターの設定ファイル内に残ることになります。

openshift_master_named_certificates を指定した値 (または値なし) で上書きする場合は、openshift_master_overwrite_named_certificates クラスター変数を指定します。

openshift_master_overwrite_named_certificates=true

さらに詳細の例が必要な場合には、次のクラスター変数をインベントリーファイルに追加することを検討してください。

openshift_master_cluster_method=native
openshift_master_cluster_hostname=lb-internal.openshift.com
openshift_master_cluster_public_hostname=custom.openshift.com

後続の Ansible 実行で証明書を上書きするには、以下を設定できます。

openshift_master_named_certificates=[{"certfile": "/root/STAR.openshift.com.crt", "keyfile": "/root/STAR.openshift.com.key", "names": ["custom.openshift.com"]}]
openshift_master_overwrite_named_certificates=true

4.17. 証明書の有効性の設定

デフォルトで、etcd、マスター、kubelet の管理に使用される証明書は 2 から 5 年で有効期限切れになります。自動生成されるレジストリー、CA、ノードおよびマスター証明書の有効性 (有効期限が切れるまでの日数) は、以下の変数 (デフォルト値が表示されています) を使用してインストール時に設定できます。

[OSEv3:vars]

openshift_hosted_registry_cert_expire_days=730
openshift_ca_cert_expire_days=1825
openshift_node_cert_expire_days=730
openshift_master_cert_expire_days=730
etcd_ca_default_days=1825

これらの値は、 Ansible のインストール後での 証明書の再デプロイ時にも使用されます。

4.18. クラスターメトリクスの設定

クラスターメトリクスは、自動的にデプロイされるように設定されていません。クラスターインストール時にクラスターメトリクスを有効にするには、以下を設定します。

[OSEv3:vars]

openshift_metrics_install_metrics=true

メトリクスのパブリック URL は、クラスターのインストール時に openshift_metrics_hawkular_hostname Ansible 変数を使用して設定できます。デフォルト値は以下の通りです。

https://hawkular-metrics.{{openshift_master_default_subdomain}}/hawkular/metrics

この変数を変更する場合は、お使いのルーターからホスト名にアクセスできることを確認してください。

openshift_metrics_hawkular_hostname=hawkular-metrics.{{openshift_master_default_subdomain}}

重要

アップストリームの Kubernetes ルールに応じて、eth0 のデフォルトインターフェースでのみメトリクスを収集できます。

注記

メトリクスをデプロイするために openshift_master_default_subdomain 値を設定する必要があります。

4.18.1. メトリクスストレージの設定

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

重要

テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、メトリクスストレージの Cassandra が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。

Cassandra は複数の独立したインスタンスにより冗長性を提供することを目的として設計されています。そのため、データディレクトリーに NFS または SAN を使用することは適切ではなく、推奨されていません。

ただし、他の NFS/SAN の実装ではこのコンポーネントのサポートやこのコンポーネントへのストレージの提供に関して問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS/SAN 実装ベンダーにお問い合わせください。

クラスターインストール時にクラスターメトリクスストレージを有効にするには、次の 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

4.19. クラスターロギングの設定

クラスターロギングは、デフォルトで自動的にデプロイされるように設定されていません。クラスターインストール時にクラスターロギングを有効にするには、以下を設定します。

[OSEv3:vars]

openshift_logging_install_logging=true

4.19.1. ロギングストレージの設定

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

重要

テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、ロギングストレージの ElasticSearch が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。

ElasticSearch はカスタム deletionPolicy を実装しないため、NFS ストレージをボリュームまたは永続ボリュームとして使用することは Elasticsearch ストレージではサポートされていません。Lucene および default deletionPolicy は NFS が指定しないファイルシステムの動作に依存します。データの破損およびその他の問題が発生する可能性があります。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

クラスターインストール時にクラスターロギングストレージを有効にするには、次の 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

4.20. サービスカタログオプションのカスタマイズ

サービスカタログはインストール時にデフォルトで有効にされます。サービスブローカーを有効にすると、サービスブローカーをカタログで登録できます。サービスカタログが有効にされると、OpenShift Ansible Broker およびテンプレートサービスブローカーが共にインストールされます。詳細は、「OpenShift Ansible Broker の設定」および「テンプレートサービスブローカーの設定」を参照してください。サービスカタログを無効にする場合は、OpenShift Ansible Broker およびテンプレートサービスブローカーはインストールされません。

サービスカタログの自動デプロイメントを無効にするには、以下のクラスター変数をインベントリーファイルに設定します。

openshift_enable_service_catalog=false

独自のレジストリーを使用する場合、以下を追加する必要があります。

  • openshift_service_catalog_image_prefix: サービスカタログイメージをプルする際に、特定のプレフィックス (例: registry) の使用を強制的に実行します。(イメージ名までの) 詳細なレジストリー名を指定する必要があります。
  • openshift_service_catalog_image_version: サービスカタログイメージをプルする際に、特定のイメージバージョンの使用を強制的に実行します。

例:

openshift_service_catalog_image="docker-registry.default.example.com/openshift/ose-service-catalog:${version}"
openshift_service_catalog_image_prefix="docker-registry-default.example.com/openshift/ose-"
openshift_service_catalog_image_version="v3.9.30"
template_service_broker_selector={"role":"infra"}

4.20.1. OpenShift Ansible Broker の設定

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

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

ansible_service_broker_install=false

表4.10 サービスブローカーのカスタマイズ変数

変数目的

openshift_service_catalog_image_prefix

サービスカタログコンポートイメージのプレフィックスを指定します。

4.20.1.1. OpenShift Ansible Broker 用の永続ストレージの設定

OAB は、残りの OpenShift Container Platform クラスターが使用する etcd とは別に独自の etcd インスタンスをデプロイします。OAB の etcd インスタンスが機能するためには、永続ボリューム (PV) を使用する個別のストレージが必要です。使用可能な PV がない場合、etcd は PV の条件が満たされるまで待機します。OAB アプリケーションは、etcd インスタンスが使用可能になるまで CrashLoop 状態になります。

一部の Ansible Playbook Bundle (APB) でも、デプロイに専用の PV が必要になります。たとえば、APB の各データベースには 2 つのプランがあります。開発プランは一時的なストレージを使用し、PV を必要としませんが、実稼働プランは永続的であり、PV を必要とします。

APBPV が必要?

postgresql-apb

必要 (ただし実稼働プランの場合のみ必要)

mysql-apb

必要 (ただし実稼働プランの場合のみ必要)

mariadb-apb

必要 (ただし実稼働プランの場合のみ必要)

mediawiki-apb

必要

OAB の永続ストレージを設定するには、以下の手順を実行します。

注記

以下の例では、NFS ホストを使用して必要な PV を提供しています。ただし、他の永続ストレージプロバイダーを代わりに使用することもできます。

  1. インベントリーファイルの [OSEv3:children] セクションに nfs を追加して、 [nfs] グループを有効にします。

    [OSEv3:children]
    masters
    nodes
    nfs
  2. [nfs] グループセクションを追加し、NFS ホストになるシステムのホスト名を追加します。

    [nfs]
    master1.example.com
  3. [OSEv3:vars] セクションに以下を追加します。

    openshift_hosted_etcd_storage_kind=nfs
    openshift_hosted_etcd_storage_nfs_options="*(rw,root_squash,sync,no_wdelay)"
    openshift_hosted_etcd_storage_nfs_directory=/opt/osev3-etcd 1
    openshift_hosted_etcd_storage_volume_name=etcd-vol2 2
    openshift_hosted_etcd_storage_access_modes=["ReadWriteOnce"]
    openshift_hosted_etcd_storage_volume_size=1G
    openshift_hosted_etcd_storage_labels={'storage': 'etcd'}
    1 2
    NFS ボリュームが [nfs] グループ内のホストの <nfs_directory>/<volume_name> パスに作成されます。たとえば、これらのオプションを使用した場合、ボリュームパスは /opt/osev3-etcd/etcd-vol2 になります。

    これらの設定は、クラスターのインストール時に OAB の etcd インスタンスに割り当てられる永続ボリュームを作成します。

4.20.1.2. ローカルの APB 開発用の OpenShift Ansible Broker の設定

OpenShift Container レジストリーと OAB を組み合わせて APB 開発 を行うには、OAB がアクセスできるイメージのホワイトリストを定義する必要があります。ホワイトリストが定義されていない場合、ブローカーは APB を無視し、使用可能な APB がユーザーに表示されません。

デフォルトでは、ホワイトリストは空になっており、クラスター管理者がブローカーを設定するまでユーザーが APB イメージをブローカーに追加できないようになっています。-apb で終了するすべてのイメージをホワイトリスト化するには、以下の手順を実行します。

  1. インベントリーファイルの [OSEv3:vars] セクションに以下を追加します。

    ansible_service_broker_local_registry_whitelist=['.*-apb$']

4.20.2. テンプレートサービスブローカーの設定

テンプレートサービスブローカー (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"}

表4.11 テンプレートサービスブローカーのカスタマイズ変数

変数目的

template_service_broker_prefix

テンプレートサービスブローカーのコンポーネントイメージのプレフィックスを指定します。

ansible_service_broker_image_prefix

Ansible サービスブローカーのコンポーネントイメージのプレフィックスを指定します。

4.21. Web コンソールのカスタマイズの設定

以下の Ansible 変数は、Web コンソールをカスタマイズするためのマスター設定オプションを設定します。これらのカスタマイズオプションの詳細については、「Web コンソールのカスタマイズ」を参照してください。

表4.12 Web コンソールのカスタマイズ変数

変数目的

openshift_web_console_install

Web コンソールをインストールするかどうかを決定します。true または false に設定できます。デフォルトは true です。

openshift_web_console_prefix

Web コンソールイメージのプレフィックスを指定します。

openshift_master_logout_url

Web コンソールの設定で clusterInfo.logoutPublicURL を設定します。詳細については、「 ログアウト URL の変更」を参照してください。値の例: https://example.com/logout

openshift_web_console_extension_script_urls

Web コンソールの設定で extensions.scriptURLs を設定します。詳細については、「拡張スクリプトとスタイルシートの読み込み」を参照してください。値の例: ['https://example.com/scripts/menu-customization.js','https://example.com/scripts/nav-customization.js']

openshift_web_console_extension_stylesheet_urls

Web コンソール設定で extensions.stylesheetURLs を設定します。詳細については、「拡張スクリプトとスタイルシートの読み込み」を参照してください。値の例: ['https://example.com/styles/logo.css','https://example.com/styles/custom-styles.css']

openshift_master_oauth_template

マスター設定で OAuth テンプレートを設定します。詳細については、「ログインページのカスタマイズ」を参照してください。値の例: ['/path/to/login-template.html']

openshift_master_metrics_public_url

マスター設定で metricsPublicURL を設定します。詳細については、「メトリクスのパブリック URL の設定」を参照してください。値の例: https://hawkular-metrics.example.com/hawkular/metrics

openshift_master_logging_public_url

マスター設定で loggingPublicURL を設定します。詳細については、「Kibana」を参照してください。値の例: https://kibana.example.com

openshift_web_console_inactivity_timeout_minutes

アクティブでない状態が一定期間続いた後にユーザーを自動的にログアウトするように Web コンソールを設定します。5 以上の整数を指定する必要があります。この機能を無効にする場合は 0 を指定します。デフォルトは 0 (無効) です。

openshift_web_console_cluster_resource_overrides_enabled

クラスターがオーバーコミット対応に設定されているかどうかを示すブール値。true の場合、リソースの上限の編集時に、Web コンソールには CPU 要求、CPU 制限およびメモリー要求のフィールドは表示されません。これらの値は、クラスターリソースのオーバーライド設定で設定する必要があるためです。

第5章 インベントリーファイルの例

5.1. 概要

独自のインベントリーファイルの設定の基本を理解したら、高可用性のために複数マスターを使用することを含め、各種の環境トポロジーを記述する以下のインベントリーサンプルを確認できます。要件に一致するサンプルを選択し、これを環境に合わせて変更し、インストールの実行時にインベントリーファイルとして使用できます。

重要

以下のインベントリーのサンプルでは、[nodes] グループにホストごとに openshift_node_group_name を設定する際にノードグループのデフォルトセットを使用します。独自のカスタムノードグループの定義を定義し、使用するには、openshift_node_groups 変数も設定する必要があります。詳細は、「Defining Node Groups and Host Mappings」を参照してください。

5.2. 単一マスターの例

単一マスターと複数ノード、単一または複数の外部 etcd ホストを含む環境を設定できます。

注記

インストール後の単一マスタークラスターから複数マスターへの移行はサポートされていません。

5.2.1. 単一マスター、単一 etcd および複数ノード

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

ホスト名インストールするインフラストラクチャー/ロール

master.example.com

マスター、etcd、ノード

node1.example.com

コンピュートノード

node2.example.com

infra-node1.example.com

インフラストラクチャーノード

infra-node2.example.com

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters][etcd]、および [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]
# 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'

重要

ノードホストラベルの設定」を参照し、OpenShift Container Platform 3.9 以降のデフォルトノードセレクター要件とノードラベルに関する考慮事項を確認してください。

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

5.2.2. 単一マスター、複数 etcd、および複数ノード

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

ホスト名インストールするインフラストラクチャー/ロール

master.example.com

マスターおよびノード

etcd1.example.com

etcd

etcd2.example.com

etcd3.example.com

node1.example.com

コンピュートノード

node2.example.com

infra-node1.example.com

専用インフラストラクチャーノード

infra-node2.example.com

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

単一マスター、複数 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'

重要

ノードホストラベルの設定」を参照し、OpenShift Container Platform 3.9 以降のデフォルトノードセレクター要件とノードラベルに関する考慮事項を確認してください。

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

5.3. 複数マスターの例

複数マスター、複数 etcd ホスト、複数ノードを含む環境を設定できます。高可用性 (HA) 対応複数マスターを設定すると、クラスターに単一障害点が設定されないようにすることができます。

注記

インストール後の単一マスタークラスターから複数マスターへの移行はサポートされていません。

複数マスターを設定する際には、クラスターインストールプロセスでネイティブ高可用性 (HA) メソッドがサポートされます。この方法は、OpenShift Container Platform に組み込まれているネイティブ HA マスター機能を活用するもので、 任意のロードバランシングソリューションと組み合わせことができます。

ホストがインベントリーファイルの [lb] セクションに定義されている場合、Ansible はロードバランシングソリューションとして HAProxy を自動的にインストールし、設定します。ホストが定義されていない場合、ユーザーが選択した外部のロードバランシングソリューションを事前に定義しており、マスター API (ポート 8443) をすべてのマスターホストで分散することが想定されます。

注記

この HAProxy ロードバランサーは、API サーバーの HA モードを実証することを意図したものであり、実稼働環境での使用には推奨されません。クラウドプロバイダーにデプロイする場合は、クラウドネイティブの TCP ベースのロードバランサーをデプロイするか、または高可用性ロードバランサーを提供するための他の手順を実行することを推奨します。

外部のロードバランシングソリューションを使用する場合は、以下が必要になります。

  • SSL パススルー対応に設定された、事前に作成されたロードバランサーの仮想 IP (VIP)
  • openshift_master_api_port 値 (デフォルトは 8443) で指定されたポートでリッスンし、そのポートですべてのマスターホストにプロキシー送信する VIP。
  • DNS に登録されている VIP のドメイン名。

    • このドメイン名は、OpenShift Container Platform インストーラーで openshift_master_cluster_public_hostnameopenshift_master_cluster_hostname の両方の値になります。

詳細については、「External Load Balancer Integrations example in Github」を参照してください。高可用性マスターアーキテクチャーの詳細については、 「 Kubernetes Infrastructure」を参照してください。

注記

現時点で、クラスターインストールプロセスはアクティブ/パッシブ設定の複数の HAProxy ロードバランサーをサポートしていません。インストール後の修正については、ロードバランサー管理ドキュメントを参照してください。

複数マスターを設定するには、「複数 etcd を持つ複数マスター」を参照してください。

5.3.1. 外部のクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター

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

ホスト名インストールするインフラストラクチャー/ロール

master1.example.com

マスター (クラスター化、ネイティブ HA を使用) およびノード

master2.example.com

master3.example.com

lb.example.com

API マスターエンドポイントの負荷分散を行う HAProxy

etcd1.example.com

etcd

etcd2.example.com

etcd3.example.com

node1.example.com

コンピュートノード

node2.example.com

infra-node1.example.com

専用インフラストラクチャーノード

infra-node2.example.com

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

HAProxy インベントリーファイルを使用する複数マスター

# 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'

重要

ノードホストラベルの設定」を参照し、OpenShift Container Platform 3.9 以降のデフォルトノードセレクター要件とノードラベルに関する考慮事項を確認してください。

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

5.3.2. 同一の場所に配置されたクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター

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

ホスト名インストールするインフラストラクチャー/ロール

master1.example.com

各ホストに etcd があるマスター (ネイティブ HA を使用するクラスター化) とノード

master2.example.com

master3.example.com

lb.example.com

API マスターエンドポイントの負荷分散を行う HAProxy

node1.example.com

コンピュートノード

node2.example.com

infra-node1.example.com

専用インフラストラクチャーノード

infra-node2.example.com

これらのサンプルホストは、以下のサンプルインベントリーファイルの [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'
重要

ノードホストラベルの設定」を参照し、OpenShift Container Platform 3.9 以降のデフォルトノードセレクター要件とノードラベルに関する考慮事項を確認してください。

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

第6章 インストール Playbook の実行

6.1. インストールを開始する前に

OpenShift Container Platform をインストールする前に、以下を確認する必要があります。

  • まず「前提条件」と「ホストの準備」のトピックを参照して、ホストを準備します。この準備では、コンポーネントタイプごとにシステムおよび環境要件を確認し、docker を適切にインストールし、設定することが含まれます。さらに、インストール方法は Ansible Playbook をベースとしており、Ansible を直接起動する必要があるため、Ansible バージョン 2.4 以降をインストールすることも含まれます。
  • 環境および必要な OpenShift Container Platform クラスター設定を定義するには、「インベントリーファイルの設定」のトピックを参照してください。このインベントリーファイルはインストールを開始するために使用され、今後のクラスターアップグレード用にも保存され、維持される必要があります。

    重要

    OpenShift Container Platform 3.10 以降、ホストごとに openshift_node_group_name をノードグループに設定することは、デフォルトのノードグループ定義または ConfigMaps を使用しているか、または独自の設定をカスタマイズしているかにかかわらず、すべてのクラスターインストールで必要です。それらをまだ設定していない場合は、詳細について「ノードグループおよびホストのマッピングの定義」を参照してください。

システムコンテナー方法を使用して OpenShift Container Platform をインストールする場合 (RHEL Atomic Host システムの場合は必須です) は、「RPM およびシステムコンテナーについての考慮事項」を参照し、それらの方法の違いを理解してから、このトピックに戻って続行してください。

インストール時間の最適化の提案などの大規模インストールについては、『Scaling and Performance Guide』を参照してください。

注記

OpenShift Container Platform をスタンドアロンレジストリーとして インストールするには、「スタンドアロンレジストリーのインストール」を参照してください。

6.2. インストール Playbook の実行

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

重要

RHEL Atomic Host はコンテナー化された OpenShift Container Platform サービスを実行するためにサポートされていますが、インストール方式では RHEL Atomic Host で利用できない Ansible を使用します。そのため、RPM ベースのインストーラーは RHEL 7 システムから実行される必要があります。インストールを開始するホストは OpenShift Container Platform クラスターに組み込まれる必要はありませんが、組み込みは可能です。または、インストーラーのコンテナー化バージョンを、RHEL Atomic Host システムから実行できるシステムコンテナーとして使用することもできます。

/etc/ansible/hosts でインベントリーファイルを定義して Ansible の設定を完了した後に、RPM ベースまたはコンテナー化されたインストーラーを使用し、Ansible 経由で Playbook を実行します。

注記

既知の問題により、インストールの実行後、NFS ボリュームがいずれかのコンポーネント用にプロビジョニングされている場合、それらのコンポーネントが NFS ボリュームにデプロイされるかどうかにかかわらず、以下のディレクトリーが作成される可能性があります。

  • /exports/logging-es
  • /exports/logging-es-ops/
  • /exports/metrics/
  • /exports/prometheus
  • /exports/prometheus-alertbuffer/
  • /exports/prometheus-alertmanager/

インストール後にこれらのディレクトリーを随時削除することができます。

6.2.1. RPM ベースのインストーラーの実行

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

重要

OpenShift Ansible Playbook は nohup で実行しないでください。Playbook で nohup を使用すると、ファイル記述子が作成され、ファイルが閉じなくなります。その結果、システムでファイルをさらに開けなくなり、Playbook が失敗します。

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

  1. prerequisites.yml Playbook を実行します。この Playbook にはソフトウェアパッケージが必要であり (ある場合)、コンテナーランタイムを変更します。コンテナーランタイムを設定する必要がない限り、この Playbook はクラスターの初回のデプロイ前に 1 度のみ実行します。

    # ansible-playbook [-i /path/to/inventory] \ 1
        /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml
    1
    インベントリーファイルが /etc/ansible/hosts ディレクトリーにない場合、-i およびインベントリーファイルのパスを指定します。
  2. deploy_cluster.yml Playbook を実行してクラスターインストールを開始します。

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

何らかの理由でインストールが失敗した場合は、インストーラーを再実行する前に「既知の問題」に目を通し、特定の指示や回避策がないかどうか確認してください。

警告

インストーラーは、デフォルトで 10 分間 Playbook の設定値をキャッシュします。システム、ネットワーク、またはインベントリー設定を変更してから 10 分以内にインストーラーを再実行する場合、新規の値は使用されず、代わりに以前の値が使用されます。キャッシュのコンテンツは削除できます。これは、/etc/ansible/ansible.cfg ファイルの fact_caching_connection の値で定義されます。このファイルのサンプルは、「Recommended Installation Practices」で説明されています。

6.2.2. コンテナー化インストーラーの実行

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

6.2.2.1. インストーラーをシステムコンテナーとして実行する

インストーラーイメージは、システムコンテナーとして使用できます。システムコンテナーは、従来の docker サービスの外部に保存して実行できます。これにより、ホストでのインストールによって docker が再起動されることを心配することなく、ターゲットホストのいずれかからインストーラーイメージを実行することが可能になります。

Atomic CLI を使用してインストーラーを 1 回だけ実行されるシステムコンテナーとして実行するには、以下の手順を root ユーザーとして実行します。

  1. prerequisites.yml Playbook を実行します。

    # atomic install --system \
        --storage=ostree \
        --set INVENTORY_FILE=/path/to/inventory \ 1
        --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml \
        --set OPTS="-v" \
        registry.access.redhat.com/openshift3/ose-ansible:v3.10
    1
    ローカルホスト上にインベントリーファイルの場所を指定します。

    このコマンドは、指定されるインベントリーファイルと root ユーザーの SSH 設定を使用して一連の前提条件タスクを実行します。

  2. deploy_cluster.yml Playbook を実行します。

    # atomic install --system \
        --storage=ostree \
        --set INVENTORY_FILE=/path/to/inventory \ 1
        --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml \
        --set OPTS="-v" \
        registry.access.redhat.com/openshift3/ose-ansible:v3.10
    1
    ローカルホスト上にインベントリーファイルの場所を指定します。

    このコマンドは、指定されるインベントリーファイルと root ユーザーの SSH 設定を使用してクラスターインストールを開始します。出力のログを端末に記録し、さらに /var/log/ansible.log ファイルに保存します。このコマンドの初回実行時に、イメージは OSTree ストレージ (システムコンテナーは docker デーモンストレージではなくこのストレージを使用します) にインポートされます。後続の実行では、保存されたイメージが再利用されます。

    何らかの理由でインストールが失敗した場合は、インストーラーを再実行する前に「既知の問題」に目を通し、特定の指示や回避策がないかどうか確認してください。

6.2.2.2. その他の Playbook の実行

PLAYBOOK_FILE 環境変数を使用すると、コンテナー化インストーラーで実行するその他の Playbook を指定できます。 PLAYBOOK_FILE のデフォルト値は、メインのクラスターインストール Playbook である /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml ですが、これをコンテナー内の別の Playbook のパスに設定できます。

たとえば、インストールの前にプレインストールチェック Playbook を実行するには、以下のコマンドを使用します。

# 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
1
PLAYBOOK_FILEplaybooks/ ディレクトリーで始まる Playbook のフルパスに設定します。 Playbook は、RPM ベースのインストーラーと同じ場所にあります。
2
OPTS を設定して、コマンドラインオプションを ansible-playbook に追加します。

6.2.2.3. インストーラーを Docker コンテナーとして実行する

インストーラーイメージは、docker が実行できる任意の場所で docker コンテナーとして実行することもできます。

警告

この方法は、設定されているホストのいずれかでインストーラーを実行するために使用しないでください。インストールによってホストで docker が再起動され、インストーラーコンテナーの実行が中断する可能性があります。

注記

この方法と上記のシステムコンテナー方法は同じイメージを使用しますが、それぞれ異なるエントリーポイントとコンテキストで実行されます。そのため、ランタイムパラメーターは同じではありません。

インストーラーを docker コンテナーとして実行する場合は、少なくとも以下を指定する必要があります。

  • SSH キー (Ansible がホストにアクセスできるようにするため)。
  • Ansible インベントリーファイル。
  • そのインベントリーに対して実行する Ansible Playbook の場所。

次に、docker 経由でインストールを実行する方法の例を示します。これは、docker へのアクセス権限を持つ非 root ユーザーとして実行する必要があります。

  1. まず、prerequisites.yml Playbook を実行します。

    $ docker run -t -u `id -u` \ 1
        -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z \ 2
        -v $HOME/ansible/hosts:/tmp/inventory:Z \ 3
        -e INVENTORY_FILE=/tmp/inventory \ 4
        -e PLAYBOOK_FILE=playbooks/prerequisites.yml \ 5
        -e OPTS="-v" \ 6
        registry.access.redhat.com/openshift3/ose-ansible:v3.10
    1
    -u `id -u` は、コンテナーが現在のユーザーと同じ UID で実行されるようにします。これにより、そのユーザーがコンテナー内の SSH キーを使用できるようになります (SSH プライベートキーは所有者のみが判読できることが予想されます)。
    2
    -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z は、SSH キー ($HOME/.ssh/id_rsa) をコンテナーユーザーの $HOME/.ssh (/opt/app-root/src はコンテナー内のユーザーの $HOME です) にマウントします。SSH キーを標準以外の場所にマウントする場合は、-e ANSIBLE_PRIVATE_KEY_FILE=/the/mount/point で環境変数を追加するか、インベントリーで ansible_ssh_private_key_file=/the/mount/point を変数として設定し、Ansible がこれを参照するようにします。SSH キーは :Z フラグでマウントされることに注意してください。これは、コンテナーがその制限された SELinux コンテキストで SSH キーを読み取れるようにするために必要です。これはまた、元の SSH キーファイルのラベルが system_u:object_r:container_file_t:s0:c113,c247 のようなラベルに変更されることも意味しています。:Z の詳細については、docker-run(1) の man ページを参照してください。これらの点は、このようなボリュームマウント仕様を提供する際に留意してください。これによって予期しない結果が生じる可能性があります。たとえば、$HOME/.ssh ディレクトリー全体をマウントすると (したがってラベルを変更すると)、ホストの sshd がログイン時にパブリックキーにアクセスできなくなります。このため、元のファイルラベルを変更しなくてもすむように SSH キー (またはディレクトリー) の別のコピーを使用することをお勧めします。
    3 4
    -v $HOME/ansible/hosts:/tmp/inventory:Z-e INVENTORY_FILE=/tmp/inventory は、静的 Ansible インベントリーファイルを /tmp/inventory としてコンテナーにマウントし、これを参照する対応する環境変数を設定します。SSH キーと同様に、既存のラベルによっては、コンテナー内を読み取れるように、:Z フラグを使用してインベントリーファイルの SELinux ラベルを変更しなければならない場合があります (ユーザーの $HOME ディレクトリー内のファイルの場合、通常はラベルの変更が必要になります)。そのため、この場合もまた、マウント前にインベントリーを専用の場所にコピーすることをお勧めします。インベントリーファイルは、INVENTORY_URL 環境変数を指定した場合には、Web サーバーからダウンロードすることもできます。または DYNAMIC_SCRIPT_URL を使用して、動的なインベントリーを提供する実行可能スクリプトを指定することにより動的に生成することもできます。
    5
    -e PLAYBOOK_FILE=playbooks/prerequisites.yml は、実行する Playbook (この例では前提条件 Playbook) を、openshift-ansible コンテンツの最上位レベルのディレクトリーの相対パスとして指定します。RPM からのフルパスやコンテナー内のその他の Playbook へのパスも使用できます。
    6
    -e OPTS="-v" は、コンテナー内で実行される ansible-playbook コマンドに任意のコマンドラインオプションを提供します (この例では、-v を使用して省サイドを上げることができます)。
  2. 次に、deploy_cluster.yml playbook を実行してクラスターインストールを開始します。

    $ docker run -t -u `id -u` \
        -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z \
        -v $HOME/ansible/hosts:/tmp/inventory:Z \
        -e INVENTORY_FILE=/tmp/inventory \
        -e PLAYBOOK_FILE=playbooks/deploy_cluster.yml \
        -e OPTS="-v" \
        registry.access.redhat.com/openshift3/ose-ansible:v3.10

6.2.2.4. OpenStack インストール Playbook の実行

重要

OpenStack インストール Playbook はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

OpenShift Container Platform を既存の OpenStack インストールにインストールするには、OpenStack Playbook を使用します。詳細の前提条件を含む Playbook についての詳細は、OpenStack Provisioning readme ファイルを参照してください。

Playbook を実行するには、以下のコマンドを実行します。

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

6.2.3. 個別コンポーネント Playbook の実行

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

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

  • 残りのそれぞれのインストール Playbook を実行できます。
  • 新規環境にインストールしている場合、deploy_cluster.yml を再度実行します。

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

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

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

表6.1 個別コンポーネント Playbook の実行順序

Playbook 名ファイルの場所

Health Check

/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/pre-install.yml

Node Bootstrap

/usr/share/ansible/openshift-ansible/playbooks/openshift-node/bootstrap.yml

etcd Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/config.yml

NFS Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-nfs/config.yml

Load Balancer Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-loadbalancer/config.yml

Master Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-master/config.yml

Master Additional Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-master/additional_config.yml

Node Join

/usr/share/ansible/openshift-ansible/playbooks/openshift-node/join.yml

GlusterFS Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml

Hosted Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/config.yml

Monitoring Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-monitoring/config.yml

Web Console Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-web-console/config.yml

Metrics Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml

Logging Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

Prometheus Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-prometheus/config.yml

Availability Monitoring Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-monitor-availability/config.yml

Service Catalog Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-service-catalog/config.yml

Management Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-management/config.yml

Descheduler Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-descheduler/config.yml

Node Problem Detector Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-node-problem-detector/config.yml

Autoheal Install

/usr/share/ansible/openshift-ansible/playbooks/openshift-autoheal/config.yml

6.3. インストールの検証

インストールが完了したら、次の手順を実行します。

  1. マスターが起動しており、ノードが登録されており、Ready ステータスで報告されていることを確認します。マスターホストで 以下を root で実行します。

    # oc get nodes
    NAME                   STATUS    ROLES     AGE       VERSION
    master.example.com     Ready     master    7h        v1.9.1+a0ce1bc657
    node1.example.com      Ready     compute   7h        v1.9.1+a0ce1bc657
    node2.example.com      Ready     compute   7h        v1.9.1+a0ce1bc657
  2. Web コンソールが正常にインストールされているか確認するには、マスターホスト名と Web コンソールのポート番号を使用して Web ブラウザーで Web コンソールにアクセスします。

    たとえば、ホスト名が master.openshift.comで、デフォルトポート 8443 を使用するマスターホストの場合、Web コンソールは https://master.openshift.com:8443/console にあります。

複数 etcd ホストの確認

複数 etcd ホストをインストールした場合は、以下の手順を実行します。

  1. まず、 etcdctl コマンドを提供する etcd パッケージがインストールされていることを確認します。

    # yum install etcd
  2. マスターホストで etcd クラスターの正常性を確認します。以下で実際の etcd ホストの FQDN の置き換えを実行します。

    # etcdctl -C \
        https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \
        --ca-file=/etc/origin/master/master.etcd-ca.crt \
        --cert-file=/etc/origin/master/master.etcd-client.crt \
        --key-file=/etc/origin/master/master.etcd-client.key cluster-health
  3. メンバーリストが正しいことも確認します。

    # etcdctl -C \
        https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \
        --ca-file=/etc/origin/master/master.etcd-ca.crt \
        --cert-file=/etc/origin/master/master.etcd-client.crt \
        --key-file=/etc/origin/master/master.etcd-client.key member list
HAProxy を使用する複数マスターの確認

HAProxy を使用する複数マスターをロードバランサーとしてインストールした場合は、[lb] セクションの定義に従って次の URL に移動し、HAProxy のステータスを確認します。

http://<lb_hostname>:9000

HAProxy の設定に関するドキュメントを参照してインストールを検証できます。

6.4. ビルドのオプションでのセキュリティー保護

docker build の実行は特権付きのプロセスのため、コンテナーにはマルチテナント環境で許可される以上のノードに対するアクセスがある場合があります。ユーザーを信頼しない場合、インストール時により多くのセキュアなオプションを使用できます。クラスターで Docker ビルドを無効にし、ユーザーに対してクラスター外でイメージをビルドするように要求できます。このオプションのプロセスについての詳細は、「Securing Builds by Strategy」を参照してください。

6.5. OpenShift Container Platform のアンインストール

クラスターの OpenShift Container Platform ホストをアンインストールするには、uninstall.yml Playbook を実行します。この Playbook は、Ansible によってインストールされた OpenShift Container Platform コンテンツを削除します。これには以下が含まれます。

  • 設定
  • コンテナー
  • デフォルトのテンプレートとイメージストリーム
  • イメージ
  • RPM パッケージ

この Playbook は、Playbook の実行時に指定するインベントリーファイルで定義されているすべてのホストのコンテンツを削除します。クラスター内のすべてのホストで OpenShift Container Platform をアンインストールする場合、最初に OpenShift Container Platform をインストールした時に使用したインベントリーファイルか、または最近実行したインベントリーファイルを使用して Playbook を実行します。

# ansible-playbook [-i /path/to/file] \
    /usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml

6.5.1. ノードのアンインストール

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

警告

この方法は、特定のノードホストをアンインストールする場合にのみ使用してください。特定のマスターホストや etcd ホストのアンインストールには使用しないでください。これらのホストをアンインストールするには、クラスター内での追加の設定変更が必要になります。

  1. まず、「ノードの削除」の手順に従ってクラスターからノードオブジェクトを削除します。次に、この残りの手順を実行します。
  2. これらのホストのみを参照する別のインベントリーファイルを作成します。たとえば、1 つのノードのみからコンテンツを削除する場合は、以下を実行します。

    [OSEv3:children]
    nodes 1
    
    [OSEv3:vars]
    ansible_ssh_user=root
    openshift_deployment_type=openshift-enterprise
    
    [nodes]
    node3.example.com openshift_node_group_name='node-config-infra' 2
    1
    アンインストールするホストに関連するセクションのみを含めます。
    2
    アンインストールするホストのみを含めます。
  3. uninstall.yml Playbook の実行時に、-i オプションを使用して新規インベントリーファイルを指定します。

    # ansible-playbook -i /path/to/new/file \
        /usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml

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

6.6. 既知の問題

  • 複数マスタークラスターでフェイルオーバーが発生すると、コントローラーマネージャーの過剰修正が生じ、結果として予定よりも多くの pod がシステムで実行される可能性があります。ただし、これは一時的なイベントであり、後にシステムによって修正されます。詳細については、https://github.com/kubernetes/kubernetes/issues/10030 を参照してください。
  • Ansible インストーラーが失敗する場合でも、OpenShift Container Platform をインストールできます。

    • SDN 設定を変更しておらず、新規証明書を生成する場合は、deploy_cluster.yml Playbook を再度実行します。
    • SDN 設定を変更し、新規証明書を生成している場合、またはインストーラーが再び失敗する場合、クリーンなオペレーティングシステムインストールで起動し直すか、またはアンインストールし、再度インストールする必要があります。
    • 仮想マシンを使用する場合、新規イメージから起動するか、またはアンインストールを実行して再度インストールします。
    • ベアメタルマシンを使用する場合、再度アンインストールおよびインストールを実行します。

6.7. 次のステップ

これで OpenShift Container Platform インスタンスが機能し、以下を実行できるようになります。

第7章 非接続インストール

データセンターの一部が、プロキシーサーバー経由でもインターネットにアクセスできないことがよくあります。このような環境でも OpenShift Container Platform をインストールできますが、必要なソフトウェアおよびイメージをダウンロードし、これらを非接続環境で利用できる状態にする必要があります。

インストールコンポーネントがノードホストで利用可能な状態で、標準的なインストール手順に従って OpenShift Container Platform をインストールします。

OpenShift Container Platform をインストールしたら、プルした S2I ビルダーイメージをクラスターで利用可能にする必要があります。

7.1. 前提条件

  • OpenShift Container Platform のアーキテクチャーの概要を確認し、環境トポロジーについて計画します。
  • root アクセスが可能な、インターネットにアクセスでき、110 GB 以上のディスク領域を持つ Red Hat Enterprise Linux (RHEL) 7 サーバーを取得します。このコンピューターに必要なソフトウェアリポジトリーおよびコンテナーイメージをダウンロードします。
  • ミラーリングされたリポジトリーを提供するために Web サーバーを非接続環境で維持できるように計画します。インターネットに接続されたホストからこの Webサーバーに対して、ネットワーク経由か、または非接続デプロイメントで物理メディアを使用してリポジトリーをコピーします。
  • ソースコントロールリポジトリーを指定します。インストール後に、ノードは Git などのソースコードリポジトリーのソースコードにアクセスする必要があります。

    OpenShift Container Platform でアプリケーションをビルドする場合、ビルドに Maven リポジトリーや Ruby アプリケーション用の Gem ファイルなどの外部の依存関係が含まれる可能性があります。

  • 非接続環境内にレジストリーを指定します。オプションには以下が含まれます。

7.2. 必要なソフトウェアパッケージおよびイメージの取得

OpenShift Container Platform を非接続環境にインストールする前に、必要なイメージおよびコンポーネントを取得し、それらをリポジトリーに保存します。

重要

非接続環境のクラスターと同じアーキテクチャーを持つシステムで必要なイメージおよびソフトウェアコンポーネントを取得する必要があります。

7.2.1. OpenShift Container Platform パッケージの取得

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

  1. リポジトリーの同期後にパッケージが削除されないように GPG キーをインポートします。

    $ rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
  2. サーバーを Red Hat カスタマーポータルに登録します。OpenShift Container Platform サブスクリプションにアクセスできるアカウントに関連付けられている認証情報を使用する必要があります。

    $ subscription-manager register
  3. RHSM から最新サブスクリプションデータをプルします。

    $ subscription-manager refresh
  4. OpenShift Container Platform チャンネルを提供するサブスクリプションをアタッチします。

    1. OpenShift Container Platform チャンネルを提供する利用可能なサブスクリプションプールを検索します。

      $ subscription-manager list --available --matches '*OpenShift*'
    2. OpenShift Container Platform を提供するサブスクリプションのプール ID をアタッチします。

      $ subscription-manager attach --pool=<pool_id>
      $ subscription-manager repos --disable="*"
  5. OpenShift Container Platform 3.10 で必要なリポジトリーのみを有効にします。

    • x86_64 サーバーでのクラウドインストールおよびオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-server-rpms" \
          --enable="rhel-7-server-extras-rpms" \
          --enable="rhel-7-server-ose-3.10-rpms" \
          --enable="rhel-7-server-ansible-2.4-rpms"
    • IBM POWER8 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-for-power-le-rpms" \
          --enable="rhel-7-for-power-le-extras-rpms" \
          --enable="rhel-7-for-power-le-optional-rpms" \
          --enable="rhel-7-server-ansible-2.6-for-power-le-rpms" \
          --enable="rhel-7-server-for-power-le-rhscl-rpms" \
          --enable="rhel-7-for-power-le-ose-3.10-rpms"
    • IBM POWER9 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      # subscription-manager repos \
          --enable="rhel-7-for-power-9-rpms" \
          --enable="rhel-7-for-power-9-extras-rpms" \
          --enable="rhel-7-for-power-9-optional-rpms" \
          --enable="rhel-7-server-ansible-2.6-for-power-9-rpms" \
          --enable="rhel-7-server-for-power-le-rhscl-rpms" \
          --enable="rhel-7-for-power-le-ose-3.10-rpms"
  6. 必要なパッケージをインストールします。

    $ sudo yum -y install yum-utils createrepo docker git

    yum-utils パッケージは reposync ユーティリティーを提供します。これによって yum リポジトリーをミラーリングでき、createrepo で使用可能な yum リポジトリーをディレクトリーから作成できます。

  7. ソフトウェアを保存するディレクトリーをサーバーのストレージまたは、USB ドライブまたは他の外部デバイスに作成します。

    $ mkdir -p </path/to/repos>
    重要

    このサーバーを接続されていない LAN に再接続し、これをリポジトリーサーバーとして使用する場合、ファイルをローカルに保存します。ローカルに保存できない場合は、USB で接続されたストレージを使用し、ソフトウェアを接続されていない LAN のリポジトリーサーバーに移動できるようにします。

  8. パッケージを同期し、各パッケージのリポジトリーを作成します。

    • x86_64 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      $ for repo in \
      rhel-7-server-rpms \
      rhel-7-server-extras-rpms \
      rhel-7-server-ansible-2.4-rpms \
      rhel-7-server-ose-3.10-rpms
      do
        reposync --gpgcheck -lm --repoid=${repo} --download_path=</path/to/repos> 1
        createrepo -v </path/to/repos/>${repo} -o </path/to/repos/>${repo} 2
      done
      1 2
      作成したディレクトリーのパスを指定します。
    • IBM POWER8 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      $ for repo in \
      rhel-7-for-power-le-rpms \
      rhel-7-for-power-le-extras-rpms \
      rhel-7-for-power-le-optional-rpms \
      rhel-7-server-ansible-2.6-for-power-le-rpms \
      rhel-7-server-for-power-le-rhscl-rpms \
      rhel-7-for-power-le-ose-3.10-rpms
      do
        reposync --gpgcheck -lm --repoid=${repo} --download_path=</path/to/repos> 1
        createrepo -v </path/to/repos/>${repo} -o </path/to/repos/>${repo} 2
      done
      1 2
      作成したディレクトリーのパスを指定します。
    • IBM POWER9 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      $ for repo in \
      rhel-7-for-power-9-rpms \
      rhel-7-for-power-9-extras-rpms \
      rhel-7-for-power-9-optional-rpms \
      rhel-7-server-ansible-2.6-for-power-9-rpms \
      rhel-7-server-for-power-le-rhscl-rpms \
      rhel-7-for-power-le-ose-3.10-rpms
      do
        reposync --gpgcheck -lm --repoid=${repo} --download_path=/<path/to/repos> 1
        createrepo -v </path/to/repos/>${repo} -o </path/to/repos/>${repo} 2
      done
      1 2
      作成したディレクトリーのパスを指定します。

7.2.2. イメージの取得

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

  1. Docker デーモンを起動します。

    $ systemctl start docker
  2. 必要な OpenShift Container Platform インフラストラクチャーコンポーネントイメージすべてをプルします。<tag> をインストールするバージョンに置き換えます。たとえば、最新バージョンの v3.10.45 を指定します。別のマイナーバージョンを指定することもできます。

    $ docker pull registry.access.redhat.com/openshift3/csi-attacher:<tag>
    $ docker pull registry.access.redhat.com/openshift3/csi-driver-registrar:<tag>
    $ docker pull registry.access.redhat.com/openshift3/csi-livenessprobe:<tag>
    $ docker pull registry.access.redhat.com/openshift3/csi-provisioner:<tag>
    $ docker pull registry.access.redhat.com/openshift3/image-inspector:<tag>
    $ docker pull registry.access.redhat.com/openshift3/local-storage-provisioner:<tag>
    $ docker pull registry.access.redhat.com/openshift3/manila-provisioner:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-ansible:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-cli:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-cluster-capacity:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-deployer:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-descheduler:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-docker-builder:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-docker-registry:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-egress-dns-proxy:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-egress-http-proxy:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-egress-router:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-f5-router:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-haproxy-router:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-hyperkube:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-hypershift:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-keepalived-ipfailover:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-pod:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-node-problem-detector:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-recycler:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-web-console:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-node:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-control-plane:<tag>
    $ docker pull registry.access.redhat.com/openshift3/registry-console:<tag>
    $ docker pull registry.access.redhat.com/openshift3/snapshot-controller:<tag>
    $ docker pull registry.access.redhat.com/openshift3/snapshot-provisioner:<tag>
    $ docker pull registry.access.redhat.com/openshift3/apb-base:<tag>
    $ docker pull registry.access.redhat.com/openshift3/apb-tools:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-service-catalog:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-ansible-service-broker:<tag>
    $ docker pull registry.access.redhat.com/openshift3/mariadb-apb:<tag>
    $ docker pull registry.access.redhat.com/openshift3/mediawiki-apb:<tag>
    $ docker pull registry.access.redhat.com/openshift3/mysql-apb:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-template-service-broker:<tag>
    $ docker pull registry.access.redhat.com/openshift3/postgresql-apb:<tag>
    $ docker pull registry.access.redhat.com/rhel7/etcd:3.2.22
  3. x86_64 サーバーのオンプレミスインストールの場合、以下のイメージをプルします。<tag> をインストールするバージョンに置き換えます。たとえば、最新バージョンの v3.10.45 を指定します。別のマイナーバージョンを指定することもできます。

    $ docker pull registry.access.redhat.com/openshift3/efs-provisioner:<tag>
  4. オプションのコンポーネントに必要な OpenShift Container Platform コンポーネントイメージすべてをプルします。<tag> をインストールするバージョンに置き換えます。たとえば、最新バージョンの v3.10.45 を指定します。別のマイナーバージョンを指定することもできます。

    • x86_64 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      $ docker pull registry.access.redhat.com/openshift3/logging-auth-proxy:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-curator:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-elasticsearch:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-eventrouter:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-fluentd:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-kibana:<tag>
      $ docker pull registry.access.redhat.com/openshift3/oauth-proxy:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-cassandra:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-hawkular-metrics:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-hawkular-openshift-agent:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-heapster:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-schema-installer:<tag>
      $ docker pull registry.access.redhat.com/openshift3/prometheus:<tag>
      $ docker pull registry.access.redhat.com/openshift3/prometheus-alert-buffer:<tag>
      $ docker pull registry.access.redhat.com/openshift3/prometheus-alertmanager:<tag>
      $ docker pull registry.access.redhat.com/openshift3/prometheus-node-exporter:<tag>
      $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-postgresql
      $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-memcached
      $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-app-ui
      $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-app
      $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-embedded-ansible
      $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-httpd
      $ docker pull registry.access.redhat.com/cloudforms46/cfme-httpd-configmap-generator
      $ docker pull registry.access.redhat.com/rhgs3/rhgs-server-rhel7
      $ docker pull registry.access.redhat.com/rhgs3/rhgs-volmanager-rhel7
      $ docker pull registry.access.redhat.com/rhgs3/rhgs-gluster-block-prov-rhel7
      $ docker pull registry.access.redhat.com/rhgs3/rhgs-s3-server-rhel7
    • IBM POWER8 または IBM POWER9 サーバーでのオンプレミスインストールの場合は、以下のコマンドを実行します。

      $ docker pull registry.access.redhat.com/openshift3/logging-auth-proxy:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-curator:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-elasticsearch:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-eventrouter:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-fluentd:<tag>
      $ docker pull registry.access.redhat.com/openshift3/logging-kibana:<tag>
      $ docker pull registry.access.redhat.com/openshift3/oauth-proxy:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-cassandra:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-hawkular-metrics:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-hawkular-openshift-agent:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-heapster:<tag>
      $ docker pull registry.access.redhat.com/openshift3/metrics-schema-installer:<tag>
      $ docker pull registry.access.redhat.com/openshift3/prometheus:<tag>
      $ docker pull registry.access.redhat.com/openshift3/prometheus-alert-buffer:<tag>
      $ docker pull registry.access.redhat.com/openshift3/prometheus-alertmanager:<tag>
      $ docker pull registry.access.redhat.com/openshift3/prometheus-node-exporter:<tag>
    重要

    Red Hat サポートの場合、コンバージドモードのサブスクリプションが rhgs3/ イメージに必要です。

    重要

    OpenShift Container Platform 上での Prometheus はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

    Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

  5. OpenShift 環境で使用する Red Hat 認定の Source-to-Image (S2I) ビルダーイメージをプルします。

    バージョン番号を指定して正しいタグを使用していることを確認します。イメージバージョンの互換性についての詳細は、「OpenShift および Atomic プラットフォームのテスト済みの統合」についてのページを参照してください。

    以下のイメージをプルできます。

    $ docker pull registry.access.redhat.com/jboss-amq-6/amq63-openshift
    $ docker pull registry.access.redhat.com/jboss-datagrid-7/datagrid71-openshift
    $ docker pull registry.access.redhat.com/jboss-datagrid-7/datagrid71-client-openshift
    $ docker pull registry.access.redhat.com/jboss-datavirt-6/datavirt63-openshift
    $ docker pull registry.access.redhat.com/jboss-datavirt-6/datavirt63-driver-openshift
    $ docker pull registry.access.redhat.com/jboss-decisionserver-6/decisionserver64-openshift
    $ docker pull registry.access.redhat.com/jboss-processserver-6/processserver64-openshift
    $ docker pull registry.access.redhat.com/jboss-eap-6/eap64-openshift
    $ docker pull registry.access.redhat.com/jboss-eap-7/eap70-openshift
    $ docker pull registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat7-openshift
    $ docker pull registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat8-openshift
    $ docker pull registry.access.redhat.com/openshift3/jenkins-1-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-2-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-agent-maven-35-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-agent-nodejs-8-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-slave-base-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-slave-maven-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-slave-nodejs-rhel7
    $ docker pull registry.access.redhat.com/rhscl/mongodb-32-rhel7
    $ docker pull registry.access.redhat.com/rhscl/mysql-57-rhel7
    $ docker pull registry.access.redhat.com/rhscl/perl-524-rhel7
    $ docker pull registry.access.redhat.com/rhscl/php-56-rhel7
    $ docker pull registry.access.redhat.com/rhscl/postgresql-95-rhel7
    $ docker pull registry.access.redhat.com/rhscl/python-35-rhel7
    $ docker pull registry.access.redhat.com/redhat-sso-7/sso70-openshift
    $ docker pull registry.access.redhat.com/rhscl/ruby-24-rhel7
    $ docker pull registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift
    $ docker pull registry.access.redhat.com/redhat-sso-7/sso71-openshift
    $ docker pull registry.access.redhat.com/rhscl/nodejs-6-rhel7
    $ docker pull registry.access.redhat.com/rhscl/mariadb-101-rhel7

7.2.3. イメージのエクスポート

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

  1. 圧縮されたイメージを保存するディレクトリーを作成し、これに切り替えます。

    $ mkdir </path/to/images>
    $ cd </path/to/images>
  2. OpenShift Container Platform インフラストラクチャーコンポーネントのイメージをエクスポートします。

    $ docker save -o ose3-images.tar \
        registry.access.redhat.com/openshift3/csi-attacher \
        registry.access.redhat.com/openshift3/csi-driver-registrar \
        registry.access.redhat.com/openshift3/csi-livenessprobe \
        registry.access.redhat.com/openshift3/csi-provisioner \
        registry.access.redhat.com/openshift3/efs-provisioner \
        registry.access.redhat.com/openshift3/image-inspector \
        registry.access.redhat.com/openshift3/local-storage-provisioner \
        registry.access.redhat.com/openshift3/manila-provisioner \
        registry.access.redhat.com/openshift3/ose-ansible \
        registry.access.redhat.com/openshift3/ose-cli \
        registry.access.redhat.com/openshift3/ose-cluster-capacity \
        registry.access.redhat.com/openshift3/ose-deployer \
        registry.access.redhat.com/openshift3/ose-descheduler \
        registry.access.redhat.com/openshift3/ose-docker-builder \
        registry.access.redhat.com/openshift3/ose-docker-registry \
        registry.access.redhat.com/openshift3/ose-egress-dns-proxy \
        registry.access.redhat.com/openshift3/ose-egress-http-proxy \
        registry.access.redhat.com/openshift3/ose-egress-router \
        registry.access.redhat.com/openshift3/ose-f5-router \
        registry.access.redhat.com/openshift3/ose-haproxy-router \
        registry.access.redhat.com/openshift3/ose-hyperkube \
        registry.access.redhat.com/openshift3/ose-hypershift \
        registry.access.redhat.com/openshift3/ose-keepalived-ipfailover \
        registry.access.redhat.com/openshift3/ose-pod \
        registry.access.redhat.com/openshift3/ose-node-problem-detector \
        registry.access.redhat.com/openshift3/ose-recycler \
        registry.access.redhat.com/openshift3/ose-web-console \
        registry.access.redhat.com/openshift3/ose-node \
        registry.access.redhat.com/openshift3/ose-control-plane \
        registry.access.redhat.com/openshift3/registry-console \
        registry.access.redhat.com/openshift3/snapshot-controller \
        registry.access.redhat.com/openshift3/snapshot-provisioner \
        registry.access.redhat.com/openshift3/apb-base \
        registry.access.redhat.com/openshift3/apb-tools \
        registry.access.redhat.com/openshift3/ose-service-catalog \
        registry.access.redhat.com/openshift3/ose-ansible-service-broker \
        registry.access.redhat.com/openshift3/mariadb-apb \
        registry.access.redhat.com/openshift3/mediawiki-apb \
        registry.access.redhat.com/openshift3/mysql-apb \
        registry.access.redhat.com/openshift3/ose-template-service-broker \
        registry.access.redhat.com/openshift3/postgresql-apb \
        registry.access.redhat.com/rhel7/etcd:3.2.22
  1. オプションコンポーネントのイメージを同期している場合は、それらをエクスポートします。

    $ docker save -o ose3-optional-imags.tar \
        registry.access.redhat.com/openshift3/logging-curator5 \
        registry.access.redhat.com/openshift3/logging-elasticsearch5 \
        registry.access.redhat.com/openshift3/logging-eventrouter \
        registry.access.redhat.com/openshift3/logging-fluentd \
        registry.access.redhat.com/openshift3/logging-kibana5 \
        registry.access.redhat.com/openshift3/oauth-proxy \
        registry.access.redhat.com/openshift3/metrics-cassandra \
        registry.access.redhat.com/openshift3/metrics-hawkular-metrics \
        registry.access.redhat.com/openshift3/metrics-hawkular-openshift-agent \
        registry.access.redhat.com/openshift3/metrics-heapster \
        registry.access.redhat.com/openshift3/metrics-schema-installer \
        registry.access.redhat.com/openshift3/prometheus \
        registry.access.redhat.com/openshift3/prometheus-alert-buffer \
        registry.access.redhat.com/openshift3/prometheus-alertmanager \
        registry.access.redhat.com/openshift3/prometheus-node-exporter \
        registry.access.redhat.com/cloudforms46/cfme-openshift-postgresql \
        registry.access.redhat.com/cloudforms46/cfme-openshift-memcached \
        registry.access.redhat.com/cloudforms46/cfme-openshift-app-ui \
        registry.access.redhat.com/cloudforms46/cfme-openshift-app \
        registry.access.redhat.com/cloudforms46/cfme-openshift-embedded-ansible \
        registry.access.redhat.com/cloudforms46/cfme-openshift-httpd \
        registry.access.redhat.com/cloudforms46/cfme-httpd-configmap-generator \
        registry.access.redhat.com/rhgs3/rhgs-server-rhel7 \
        registry.access.redhat.com/rhgs3/rhgs-volmanager-rhel7 \
        registry.access.redhat.com/rhgs3/rhgs-gluster-block-prov-rhel7 \
        registry.access.redhat.com/rhgs3/rhgs-s3-server-rhel7
  2. プルした S2I ビルダーイメージをエクスポートします。たとえば、Jenkins および Tomcat イメージのみを同期している場合は、以下を実行します。

    $ docker save -o ose3-builder-images.tar \
        registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat7-openshift \
        registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat8-openshift \
        registry.access.redhat.com/openshift3/jenkins-1-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-2-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-agent-maven-35-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-agent-nodejs-8-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-slave-base-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-slave-maven-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-slave-nodejs-rhel7
  3. 圧縮されたファイルをインターネットに接続されたホストから内部ホストにコピーします。
  4. コピーしたイメージを読み込みます。

    $ docker load -i ose3-images.tar
    $ docker load -i ose3-builder-images.tar
    $ docker load -i ose3-optional-images.tar

7.3. リポジトリーサーバーの準備および設定

インストール時および追加の更新時に、ソフトウェアをホストする Web サーバーが必要になります。RHEL 7 は Apache Web サーバーを提供します。

  1. Web サーバーを準備します。

    1. 非接続環境に新規の Web サーバーをインストールする必要がある場合は、110 GB 以上の領域を持つ新規の RHEL 7 システムを LAN でインストールします。RHEL インストール時に、「Basic Web Server」オプションを選択します。
    2. OpenShift Container Platform ソフトウェアをダウンロードしており、イメージが必要なサーバーを再利用している場合、Apache をサーバーにインストールします。

      $ sudo yum install httpd
  2. リポジトリーファイルを Apache のルートフォルダーに配置します。

    • サーバーを再利用している場合は、以下を実行します。

      $ mv /path/to/repos /var/www/html/
      $ chmod -R +r /var/www/html/repos
      $ restorecon -vR /var/www/html
    • 新規サーバーをインストールしている場合、外部ストレージを割り当ててから、ファイルをコピーします。

      $ cp -a /path/to/repos /var/www/html/
      $ chmod -R +r /var/www/html/repos
      $ restorecon -vR /var/www/html
  3. ファイアウォールのルールを追加します。

    $ sudo firewall-cmd --permanent --add-service=http
    $ sudo firewall-cmd --reload
  4. 変更を有効にするには、Apache を有効にしてから起動します。

    $ systemctl enable httpd
    $ systemctl start httpd

7.4. レジストリーの設定

非接続環境でイメージにタグを付け、そのイメージを内部レジストリーにプッシュします。

重要

以下の手順では、イメージをレジストリーに読み込む方法についての概要を示します。イメージを読み込む際に、追加の、または異なるアクションを実行する必要がある可能性があります。

  1. イメージをレジストリーにプッシュする前に、それぞれのイメージに再度タグを付けます。

    • openshift3 リポジトリーのイメージについては、イメージにメジャーおよびマイナー番号の両方のタグを付けます。たとえば、OpenShift Container Platform ノードイメージにタグを付けるには、以下を実行します。

      $ docker tag registry.access.redhat.com/openshift3/ose-node:<tag> registry.example.com/openshift3/ose-node:<tag>
      $ docker tag registry.access.redhat.com/openshift3/ose-node:<tag> registry.example.com/openshift3/ose-node:{major-tag}
    • 他のイメージについては、イメージに完全に一致するバージョン番号のタグを付けます。たとえば、etcd イメージにタグを付けるには、以下を実行します。

      $ docker tag registry.access.redhat.com/rhel7/etcd:3.2.22 registry.example.com/rhel7/etcd:3.2.22
  2. 各イメージをレジストリーにプッシュします。たとえば、OpenShift Container Platform ノードイメージをプッシュするには、以下を実行します。

    $ docker push registry.example.com/openshift3/ose-node:<tag>
    $ docker push registry.example.com/openshift3/ose-node:{major-tag}

7.5. クラスターホストの準備

インストールファイルを準備したら、次にホストを準備します。

  1. OpenShift Container Platform クラスターのホストを作成します。最新バージョンの RHEL 7 を使用し、最小インストールを実行することが推奨されます。ホストがシステム要件を満たしていることを確認します。
  2. 各ノードホストで、リポジトリー定義を作成します。以下のテキストを /etc/yum.repos.d/ose.repo ファイルに配置します。

    [rhel-7-server-rpms]
    name=rhel-7-server-rpms
    baseurl=http://<server_IP>/repos/rhel-7-server-rpms 1
    enabled=1
    gpgcheck=0
    [rhel-7-server-extras-rpms]
    name=rhel-7-server-extras-rpms
    baseurl=http://<server_IP>/repos/rhel-7-server-extras-rpms 2
    enabled=1
    gpgcheck=0
    [rhel-7-server-ansible-2.4-rpms]
    name=rhel-7-server-ansible-2.4-rpms
    baseurl=http://<server_IP>/repos/rhel-7-server-ansible-2.4-rpms 3
    enabled=1
    gpgcheck=0
    [rhel-7-server-ose-3.10-rpms]
    name=rhel-7-server-ose-3.10-rpms
    baseurl=http://<server_IP>/repos/rhel-7-server-ose-3.10-rpms 4
    enabled=1
    gpgcheck=0
    1 2 3 4
    <server_IP> を IP アドレス、またはソフトウェアリポジトリーをホストする Apache サーバーの名前に置き換えます。
  3. ホストのインストールを準備します。「ホストの準備」の手順に従い、「ホスト登録」のセクションの手順は省略します。

7.6. OpenShift Container Platform のインストール

ソフトウェア、イメージおよびホストを準備したら、標準的なインストール方法を使用して OpenShift Container Platform をインストールします。

  1. 内部レジストリーを参照するようにインベントリーファイルを設定します。

    orge_url=registry.example.com/openshift3/ose-${component}:${version}
    openshift_examples_modify_imagestreams=true
  2. インストール Playbook の実行

第8章 OpenShift Container レジストリーのスタンドアロンデプロイメントのインストール

8.1. OpenShift Container レジストリーについて

OpenShift Container Platform は、OpenShift Container レジストリー (OCR) と呼ばれる統合コンテナーレジストリーを含む完全な機能を備えたエンタープライズソリューションです。また、OpenShift Container Platform を開発者向けの完全な PaaS 環境としてデプロイする代わりに、 OCR をスタンドアロンのコンテナーレジストリーとしてインストールし、オンプレミスまたはクラウドで実行することも可能です。

OCR のスタンドアロンデプロイメントをインストールすると、標準的な OpenShift Container Platform のインストールと同様にマスターとノードのクラスターも引き続きインストールされます。次に、コンテナーレジストリーはそのクラスター上で実行されるようにデプロイされます。このスタンドアロンデプロイメントのオプションは、コンテナーレジストリーは必要だが、開発者向けの Web コンソールやアプリケーションのビルドおよびデプロイツールを含む OpenShift Container Platform の完全な環境は必要ない、という管理者に役立ちます。

OCR には以下の機能があります。

管理者は、スタンドアロン OCR をデプロイすることで OpenShift Container Platform の複数のクラスターに対応しているレジストリーを個別に管理できます。また、スタンドアロン OCR を使うと、セキュリティーやコンプライアンスに関する独自の要件を満たすようにレジストリーを分離することも可能です。

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

スタンドアロン OCR をインストールするためのハードウェア要件は以下の通りです。

  • 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
  • ベース OS: RHEL 7.4、または 7.5 (RHEL 7 Extras チャンネルの「最小限の」インストールオプションおよび最新のパッケージ)、または、RHEL Atomic Host 7.4.5 以降。
  • NetworkManager 1.0 以降
  • 2 vCPU。
  • 16 GB 以上の RAM。
  • /var/ を含むファイルシステムの 15 GB 以上のハードディスク領域。
  • Docker のストレージバックエンドに使用する 15 GB 以上の追加の未割り当て領域。詳細は「Docker ストレージの設定」を参照してください。
重要

OpenShift Container Platform は x86_64 or IBM POWER アーキテクチャーを使用するサーバーをサポートします。IBM POWER サーバーを使用してクラスターホストをホストする場合は、使用できるサーバーは IBM POWER のみになります。

注記

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

8.3. サポートされているシステムトポロジー

以下のシステムトポロジーはスタンドアロン OCR でサポートされています。

オールインワン

マスター、ノード、etcd、レジストリーの各コンポーネントを含む単一ホスト。

複数マスター (高可用性)

すべてのコンポーネント (マスター、ノード、etcd、レジストリー) がそれぞれに含まれる 3 つのホスト。マスターはネイティブの高可用性を確保するように設定されます。

8.4. ホストの準備

スタンドアロン OCR をインストールする前に、完全な OpenShift Container Platform PaaS のインストールについて取り上げたホストの準備のトピックで説明している手順と同じ手順をすべて実行する必要があります。この手順には、適切なリポジトリーへのホストの登録とサブスクライブ、特定パッケージのインストールまたは更新、Docker とそのストレージ要件のセットアップなどが含まれます。

ホストの準備 の各手順を実行し、スタンドアロンレジストリーのインストール方法に進んでください。

8.5. Ansible を使用したインストール

スタンドアロン OCR をインストールする際に、「クラスターインストール」に詳細に説明されているように Ansible を使用した OpenShift Container Platform クラスターのインストールとほぼ同じ手順を使用します。大きな違いとして、ここでは Playbook がレジストリーのインストールパスをたどれるよう、インベントリーファイルの [OSEv3:vars] セクションに deployment_subtype=registry を設定する必要があります。

以下は、サポートされている複数の異なるシステムトポロジー用のインベントリーファイルの例です。

オールインワンのスタンドアロン OpenShift Container レジストリーインベントリーファイル

# Create an OSEv3 group that contains the masters and nodes 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

openshift_master_default_subdomain=apps.test.example.com

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

openshift_deployment_type=openshift-enterprise
deployment_subtype=registry 1
openshift_hosted_infra_selector="" 2

# 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]
registry.example.com

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

# host group for nodes
[nodes]
registry.example.com openshift_node_group_name='node-config-all-in-one'

1
deployment_subtype=registry を設定して、OpenShift Container Platform 環境のすべてではなく、スタンドアロン OCR がインストールされるようにします。
2
レジストリーとその Web コンソールが単一ホストでスケジュールされることを可能にします。

複数マスター (高可用性) スタンドアロン OpenShift Container レジストリーインベントリーファイル

# 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
deployment_subtype=registry 1

openshift_master_default_subdomain=apps.test.example.com

# 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

# 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-infra'
node1.example.com openshift_node_group_name='node-config-compute'
node2.example.com openshift_node_group_name='node-config-compute'

1
deployment_subtype=registry を設定して、OpenShift Container Platform 環境のすべてではなく、スタンドアロン OCR がインストールされるようにします。

/etc/ansible/hosts でインベントリーファイルを定義して Ansible を設定した後に、以下を実行します。

  1. prerequisites.yml Playbook を実行してベースパッケージと Docker を設定します。これは、新規クラスターをデプロイする前に 1 回だけ実行します。インベントリーファイルが /etc/ansible/hosts 以外の場所にある場合には、-i を指定して以下のコマンドを実行します。

    重要

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

    # ansible-playbook  [-i /path/to/inventory] \
        /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml
  2. deploy_cluster.yml Playbook を実行してインストールを開始します。

    # ansible-playbook  [-i /path/to/inventory] \
        /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml
注記

クラスターインストールプロセスに関する詳細の使用方法 (使用可能な Ansible 変数の一覧を含む) については、「インストール計画」 から本書全体に目を通してください。

法律上の通知

Copyright © 2018 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Modified versions must remove all Red Hat trademarks.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat. Licensed under the Apache License 2.0.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.