This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第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 の各コンポーネントはコンテナーとして同梱され (自己完結型パッケージ)、ホストのカーネルを利用して起動と実行を行います。更新された新しいコンテナーはホストの既存のものを置き換えます。
以下の表およびセクションは、インストールタイプごとの詳細な相違点について説明しています。
RPM ベースのインストール | システムコンテナーのインストール | |
---|---|---|
配信メカニズム |
|
|
サービス管理 |
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>
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 ファイルシステムに十分な空き領域があることを確認してください。詳細は「システム要件」のセクションを参照してください。