第2章 クラスターインストール方法の選択およびそのユーザー向けの準備
OpenShift Container Platform をインストールする前に、実行するインストールプロセスを決定し、ユーザー用にクラスターを準備する際に必要なすべてのリソースがあることを確認します。
2.1. クラスターのインストールタイプの選択
OpenShift Container Platform クラスターをインストールする前に、実行する最適なインストール手順を選択する必要があります。以下の質問に回答して、最も良いオプションを選択します。
2.1.1. OpenShift Container Platform クラスターを独自にインストールし、管理しますか ?
OpenShift Container Platform を独自にインストールし、管理する必要がある場合、以下のプラットフォームにインストールすることができます。
- 64 ビット x86 インスタンスの Amazon Web Services (AWS)
- 64 ビット ARM インスタンスの Amazon Web Services (AWS)
- 64 ビット x86 インスタンスの Microsoft Azure
- 64 ビット ARM インスタンスの Microsoft Azure
- Microsoft Azure Stack Hub
- 64 ビット x86 インスタンス上の Google Cloud Platform (GCP)
- 64 ビット ARM インスタンス上の Google Cloud Platform (GCP)
- Red Hat OpenStack Platform (RHOSP)
- IBM Cloud®
- IBM Z® または IBM® LinuxONE
- IBM Z® または IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
- IBM Power®
- IBM Power® Virtual Server
- Nutanix
- VMware vSphere
- ベアメタルまたはその他のプラットフォームに依存しないインフラストラクチャー
OpenShift Container Platform 4 クラスターは、オンプレミスハードウェアとクラウドホストサービスの両方にデプロイできますが、クラスターのすべてのマシンは同じデータセンターまたはクラウドホストサービスにある必要があります。
OpenShift Container Platform を使用する必要があるが、クラスターを独自に管理する必要がない場合は、複数のマネージドサービスの選択肢から選ぶことができます。Red Hat によって完全に管理されるクラスターが必要な場合は、OpenShift Dedicated を使用できます。OpenShift を Azure、AWS、IBM Cloud®、または Google Cloud Platform でマネージドサービスとして使用することもできます。マネージドサービスの詳細は、OpenShift の製品 ページを参照してください。クラウド仮想マシンを仮想ベアメタルとして OpenShift Container Platform クラスターをインストールする場合、対応するクラウドベースのストレージはサポートされません。
2.1.2. OpenShift Container Platform 3 を使用したことがあり、その上で OpenShift Container Platform 4 を使用することを希望していますか ?
OpenShift Container Platform 3 を使用したことがあり、OpenShift Container Platform 4 を使用してみたいと思われる場合は、OpenShift Container Platform 4 がどのように異なるかを理解しておく必要があります。OpenShift Container Platform 4 では、Kubernetes アプリケーション、プラットフォームが実行されるオペレーティングシステム、Red Hat Enterprise Linux CoreOS (RHCOS) を共にシームレスにパッケージ化し、デプロイし、管理する Operator を使用します。マシンをデプロイし、それらのオペレーティングシステムを設定して OpenShift Container Platform をそれらにインストールできるようにする代わりに、RHCOS オペレーティングシステムが OpenShift Container Platform クラスターの統合された部分として使用されます。OpenShift Container Platform のインストールプロセスの一部として、クラスターマシンのオペレーティングシステムをデプロイします。OpenShift Container Platform 3 と 4 の相違点 を参照してください。
OpenShift Container Platform クラスターのインストールプロセスの一部としてマシンをプロビジョニングする必要があるため、OpenShift Container Platform 3 クラスターを OpenShift Container Platform 4 にアップグレードすることはできません。その代わりに、新規の OpenShift Container Platform 4 クラスターを作成し、OpenShift Container Platform 3 ワークロードをそれらに移行する必要があります。移行の詳細は、OpenShift Container Platform 3 から 4 への移行の概要 を参照してください。OpenShift Container Platform 4 に移行するにあたり、任意のタイプの実稼働用のクラスターのインストールプロセスを使用して新規クラスターを作成できます。
2.1.3. クラスターで既存のコンポーネントを使用する必要がありますか ?
オペレーティングシステムは OpenShift Container Platform に不可欠な要素であり、OpenShift Container Platform のインストールプログラムはすべてのインフラストラクチャーの起動を簡単に実行できます。これらは、installer provisioned infrastructure のインストールと呼ばれています。この種のインストールでは、ユーザーは既存のインフラストラクチャーをクラスターに提供できますが、インストールプログラムがクラスターを最初に必要とするすべてのマシンをデプロイします。
installer-provisioned infrastructure クラスターは、クラスターまたはその基盤となるマシンに対するカスタマイズを指定せずに、AWS、Azure、Azure Stack Hub、GCP、Nutanix にデプロイできます。
クラスターマシンのインスタンスタイプなど、installer-provisioned infrastructure クラスターの基本設定を行う必要がある場合は、AWS、Azure、GCP、Nutanix のインストールをカスタマイズできます。
installer-provisioned infrastructure のインストールの場合、AWS の既存の VPC、Azure の vNet、または GCP の VPC を使用できます。ネットワークインフラストラクチャーの一部を再利用して、AWS、Azure、または GCP のクラスターが環境内の既存の IP アドレスの割り当てと共存し、既存の MTU および VXLAN 設定と統合するようにできます。これらのクラウドに既存のアカウントおよび認証情報がある場合は、それらを再利用できますが、OpenShift Container Platform クラスターをインストールするために必要なパーミッションを持つようアカウントを変更する必要がある場合があります。
installer-provisioned infrastructure 方式を使用すると、vSphere および ベアメタル のハードウェアに適切なマシンインスタンスを作成できます。さらに、vSphere では、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。
VMware vSphere やベアメタルプラットフォームなどの一部の installer-provisioned infrastructure インストールでは、Ingress 仮想 IP (VIP) に到達する外部トラフィックがデフォルトの IngressController
レプリカ間で分散されません。ベースライン IngressController
ルーターのパフォーマンスを超えることが予想される vSphere およびベアメタル installer-provisioned infrastructure インストールでは、外部ロードバランサーを設定する必要があります。外部ロードバランサーを設定すると、複数の IngressController
レプリカのパフォーマンスが実現します。ベースライン IngressController
パフォーマンスの詳細は、ベースライン Ingress Controller (ルーター) パフォーマンス を参照してください。外部ロードバランサーの設定の詳細は、ユーザー管理ロードバランサーの設定 を参照してください。
大規模なクラウドインフラストラクチャーを再利用する必要がある場合、user-provisioned infrastructure のインストールを実行できます。これらのインストールでは、インストールプロセス時にクラスターに必要なマシンを手動でデプロイします。AWS、Azure、および Azure Stack Hub で user-provisioned infrastructure を実行する場合、提供されるテンプレートを使用して必要なすべてのコンポーネントを起動できます。共有 VPC on GCP を再利用することもできます。それ以外の場合は、プロバイダーに依存しない インストール方法を使用して、クラスターを他のクラウドにデプロイすることができます。
user-provisioned infrastructure は、既存のハードウェアで実行することもできます。RHOSP、IBM Z® または IBM® LinuxONE、RHEL KVM が搭載された IBM Z® および IBM® LinuxONE、IBM Power、または vSphere を使用する場合は、特定のインストール手順に従ってクラスターをデプロイします。サポートされる他のハードウェアを使用する場合は、ベアメタルのインストール 手順に従います。vSphere や ベアメタル などの一部のプラットフォームの場合は、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。
2.1.4. クラスターに追加のセキュリティーが必要ですか ?
user-provisioned installation 方法を使用する場合、クラスターのプロキシーを設定できます。この手順は各インストール手順に含まれています。
パブリッククラウドのクラスターがエンドポイントを外部に公開するのを防ぐ必要がある場合、AWS、Azure、または GCP の installer-provisioned infrastructure を使用してプライベートクラスターをデプロイすることができます。
非接続のクラスターまたはネットワークが制限されたクラスターなど、インターネットへのアクセスが限定されたクラスターをインストールする必要がある場合、インストールパッケージをミラーリング し、そこからクラスターをインストールできます。user-provisioned infrastructure によるインストールの詳細な手順を実行して、AWS、GCP、IBM Z® または IBM® LinuxONE、RHEL KVM が搭載された IBM Z® または IBM® LinuxONE、IBM Power®、vSphere、または ベアメタル のネットワークが制限された環境にインストールしてください。ネットワークが制限された環境へのクラスターのインストールは、installer-provisioned infrastructure を使用して、AWS、GCP、IBM Cloud®、Nutanix、RHOSP、および vSphere 用の詳細な手順に従って実行することもできます。
クラスターを AWS GovCloud リージョン、AWS China リージョン、または Azure government リージョン にデプロイする必要がある場合は、installer-provisioned infrastructure のインストール時にこれらのカスタムリージョンを設定できます。
インストール中に FIPS 140-2/140-3 検証 のために NIST に提出された RHEL 暗号化ライブラリーを使用するようにクラスターマシンを設定することもできます。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。