第2章 クラスターインストール方法の選択およびそのユーザー向けの準備
OpenShift Container Platform をインストールする前に、実行するインストールプロセスを決定し、ユーザー用にクラスターを準備する際に必要なすべてのリソースがあることを確認します。
2.1. クラスターのインストールタイプの選択
OpenShift Container Platform クラスターをインストールする前に、実行する最適なインストール手順を選択する必要があります。以下の質問に回答して、最も良いオプションを選択します。
2.1.1. OpenShift Container Platform クラスターを独自にインストールし、管理しますか ?
OpenShift Container Platform を独自にインストールし、管理する必要がある場合、以下のプラットフォームにインストールすることができます。
- Alibaba Cloud
- 64 ビット x86 インスタンスの Amazon Web Services (AWS)
- 64 ビット ARM インスタンスの Amazon Web Services (AWS)
- 64 ビット x86 インスタンスの Microsoft Azure
- 64 ビット ARM インスタンスの Microsoft Azure
- Microsoft Azure Stack Hub
- Google Cloud Platform (GCP)
- Red Hat OpenStack Platform (RHOSP)
- Red Hat Virtualization (RHV)
- IBM Cloud VPC
- IBM Z または IBM® LinuxONE
- IBM Z または IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
- IBM Power
- IBM Power Virtual Server
- Nutanix
- VMware vSphere
- VMware Cloud (VMC) on AWS
- ベアメタルまたはその他のプラットフォームに依存しないインフラストラクチャー
OpenShift Container Platform 4 クラスターは、オンプレミスハードウェアとクラウドホストサービスの両方にデプロイできますが、クラスターのすべてのマシンは同じデータセンターまたはクラウドホストサービスにある必要があります。
OpenShift Container Platform を使用する必要があるが、クラスターを独自に管理することを望まない場合は、複数のマネージドサービスオプションを使用できます。Red Hat によって完全に管理されるクラスターが必要な場合は、OpenShift Dedicated または OpenShift Online を使用することができます。OpenShift を Azure、AWS、IBM Cloud、または Google Cloud VPC でマネージドサービスとして使用することもできます。マネージドサービスの詳細は、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 のインストールと呼ばれています。この種のインストールでは、ユーザーは既存のインフラストラクチャーをクラスターに提供できますが、インストールプログラムがクラスターを最初に必要とするすべてのマシンをデプロイします。
クラスターまたはその基盤となるマシンの Alibaba Cloud、AWS、Azure、Azure Stack Hub、GCP、Nutanix、または VMC on AWS へのカスタマイズを指定することなく、インストーラーでプロビジョニングされたインフラストラクチャークラスターをデプロイできます。これらのインストール方法は、実稼働対応の OpenShift Container Platform クラスターをデプロイする最も高速な方法です。
インストーラーでプロビジョニングされたインフラストラクチャークラスターの基本設定 (クラスターマシンのインスタンスタイプなど) を実行する必要がある場合は、Alibaba Cloud、AWS、Azure、GCP、Nutanix、または VMC on AWS のインストールをカスタマイズできます。
installer-provisioned infrastructure のインストールの場合、AWS の既存の VPC、Azure の vNet、または GCP の VPC を使用できます。ネットワークインフラストラクチャーの一部を再利用して、AWS、Azure、GCP、または VMC on AWS のクラスターが環境内の既存の IP アドレスの割り当てと共存し、既存の MTU および VXLAN 設定と統合できるようにします。これらのクラウドに既存のアカウントおよび認証情報がある場合は、それらを再利用できますが、OpenShift Container Platform クラスターをインストールするために必要なパーミッションを持つようアカウントを変更する必要がある場合があります。
インストーラーでプロビジョニングされるインフラストラクチャー方法を使用して、RHOSP、Kuryr を使用した RHOSP、RHV、vSphere、および ベアメタル のハードウェアに適切なマシンインスタンスを作成できます。さらに、vSphere、VMC on AWS では、インストール時に追加のネットワークパラメーターをカスタマイズすることもできます。
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、GCP、または VMC on AWS でユーザーによってプロビジョニングされるインフラストラクチャーを実行する場合、提供されるテンプレートを使用して必要なすべてのコンポーネントを起動できます。共有 VPC on GCP を再利用することもできます。それ以外の場合は、プロバイダーに依存しない インストール方法を使用して、クラスターを他のクラウドにデプロイすることができます。
ユーザーによってプロビジョニングされるインフラストラクチャーは、既存のハードウェアで実行することもできます。RHOSP、RHV、IBM Z または IBM® LinuxONE、RHEL KVM を使用した IBM Z または IBM® LinuxONE、IBM Power、または vSphere を使用する場合は、特定のインストール手順を使用してクラスターをデプロイします。サポートされる他のハードウェアを使用する場合は、ベアメタルのインストール 手順に従います。RHOSP、vSphere、VMC on AWS、および ベアメタル などの一部のプラットフラォームの場合は、インストール時に追加のネットワークパメーターをカスタマイズすることもできます。
2.1.4. クラスターに追加のセキュリティーが必要ですか ?
user-provisioned installation 方法を使用する場合、クラスターのプロキシーを設定できます。この手順は各インストール手順に含まれています。
パブリッククラウドのクラスターがエンドポイントを外部に公開するのを防ぐ必要がある場合、AWS、Azure、または GCP の installer-provisioned infrastructure を使用してプライベートクラスターをデプロイすることができます。
非接続のクラスターまたはネットワークが制限されたクラスターなど、インターネットへのアクセスが限定されたクラスターをインストールする必要がある場合、インストールパッケージをミラーリング し、そこからクラスターをインストールできます。AWS、GCP、IBM Z または IBM® LinuxONE、RHEL KVM を使用した IBM Z または IBM® LinuxONE、IBM Power、vSphere、VMC on AWS、または ベアメタル のネットワークが制限された環境へのユーザーによってプロビジョニングされるインフラストラクチャーのインストールの詳細な手順を実行します。AWS、GCP、Nutanix、VMC on AWS、RHOSP、RHV、および vSphere の詳細な手順に従って、インストーラーによってプロビジョニングされたインフラストラクチャーを使用して、ネットワークが制限された環境にクラスターをインストールすることもできます。
クラスターを AWS GovCloud リージョン、AWS China リージョン、または Azure government リージョン にデプロイする必要がある場合は、installer-provisioned infrastructure のインストール時にこれらのカスタムリージョンを設定できます。