第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 つのノードのサンプル環境について説明しています。

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

master.example.com

マスター、etcd、ノード

node1.example.com

ノード

node2.example.com

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

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

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

master.example.com

マスターおよびノード

etcd1.example.com

etcd

etcd2.example.com

etcd3.example.com

node1.example.com

ノード

node2.example.com

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

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

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 つのノードのサンプル環境を説明しています。

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

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 の各コンポーネントはコンテナーとして同梱され (自己完結型パッケージ)、ホストのカーネルを利用して起動と実行を行います。更新された新しいコンテナーはホストの既存のものを置き換えます。

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

Expand
表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>
Copy to Clipboard Toggle word wrap
注記

ホストの 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 ファイルシステムに十分な空き領域があることを確認してください。詳細は「システム要件」のセクションを参照してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat