15.2. クラスターの VMC へのインストール
OpenShift Container Platform バージョン 4.8 では、クラスターを VMware Cloud (VMC) on AWS にデプロイし、VMware vSphere にインストールできます。
OpenShift Container Platform デプロイメント用に VMC 環境を設定した後に、VMC 環境に併設された bastion 管理ホストの OpenShift Container Platform インストールプログラムを使用します。インストールプログラムおよびコントロールプレーンは、OpenShift Container Platform クラスターに必要なリソースのデプロイおよび管理プロセスを自動化します。
OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。
15.2.1. vSphere 用の VMC の設定
OpenShift Container Platform を VMware Cloud (VMC) on AWS でホストされた vSphere クラスターにインストールし、アプリケーションをオンプレミスおよびオンプレミスの両方でハイブリッドクラウド全体にデプロイし、管理することができます。
OpenShift Container Platform を VMware vSphere にインストールする前に、複数のオプションを VMC 環境で設定する必要があります。VMC 環境が以下の前提条件を満たしていることを確認します。
- 排他的ではない、 DHCP 対応の NSX-T ネットワークセグメントおよびサブネットを作成します。他の仮想マシン (VM) をサブネットでホストできますが、OpenShift Container Platform デプロイメントには 8 つ以上の IP アドレスが利用可能でなければなりません。
DHCP 範囲外にある 2 つの IP アドレスを割り当て、それらを逆引き DNS レコードで設定します。
-
割り当てられた IP アドレスをポイントする
api.<cluster_name>.<base_domain>
の DNS レコード。 -
割り当てられた IP アドレスをポイントする
*.apps.<cluster_name>.<base_domain>
の DNS レコード。
-
割り当てられた IP アドレスをポイントする
以下のファイアウォールルールを設定します。
- OpenShift Container Platform コンピュートネットワークとインターネット間の ANY:ANY ファイアウォールルール。これは、コンテナーイメージをダウンロードするためにノードおよびアプリケーションによって使用されます。
- ポート 443 上のインストールホストと、ソフトウェア定義データセンター (SDDC) 管理ネットワーク間の ANY:ANY ファイアウォールルール。これにより、デプロイメント時に Red Hat Enterprise Linux CoreOS (RHCOS) OVA をアップロードできます。
- OpenShift Container Platform コンピュートネットワークと vCenter 間の HTTPS ファイアウォールルール。この接続により、OpenShift Container Platform はノード、永続ボリューム要求 (PVC) および他のリソースをプロビジョニングし、管理するために vCenter と通信できます。
OpenShift Container Platform をデプロイするには、以下の情報が必要です。
-
OpenShift Container Platform クラスターの名前 (
vmc-prod-1
など)。 -
ベース DNS 名 (
companyname.com
など)。 -
デフォルトを使用しない場合、Pod ネットワーク CIDR およびサービスネットワーク CIDR を特定する必要があります。これはデフォルトで
10.128.0.0/14
および172.30.0.0/16
にそれぞれ設定されます。これらの CIDR は Pod 間および Pod とサービス間の通信に使用され、外部からアクセスすることはできません。ただし、それらは組織内の既存のサブネットと重複することができません。 以下の vCenter 情報:
- vCenter ホスト名、ユーザー名、およびパスワード
-
データセンター名 (
SDDC-Datacenter
など) -
クラスター名 (
Cluster-1
など) - ネットワーク名
データストア名 (
WorkloadDatastore
など)注記クラスターのインストールの完了後に、vSphere クラスターを VMC
Compute-ResourcePool
リソースプールに移動することが推奨されます。
-
OpenShift Container Platform クラスターの名前 (
bastion として VMC にデプロイされる Linux ベースのホスト。
- bastion ホストには Red Hat Enterprise Linux (RHEL) または他の Linux ベースのホストを使用できます。インターネット接続と OVA を ESXi ホストにアップロードする機能が必要です。
OpenShift CLI ツールをダウンロードし、 bastion ホストにインストールします。
-
openshift-install
インストールプログラム -
OpenShift CLI (
oc
) ツール
-
VMware NSX Container Plugin for Kubernetes (NCP) は使用できないため、NSX は OpenShift SDN として使用されません。VMC で現在利用できる NSX のバージョンは、OpenShift Container Platform で認定されている NCP のバージョンとは互換性がありません。
ただし、NSX DHCP サービスは、フルスタックの自動化 OpenShift Container Platform デプロイメントおよびマシン API の vSphere への統合によって手動または自動でプロビジョニングされたノードと共に仮想マシンの IP 管理に使用されます。さらに、NSX ファイアウォールルールは、OpenShift Container Platform クラスターの a アクセス、および bastion ホストと VMC vSphere ホスト間のアクセスを有効にするために作成されます。
15.2.1.1. VMC Sizer ツール
VMware Cloud on AWS は AWS ベアメタルインフラストラクチャー上に構築されます。これは、AWS ネイティブサービスを実行するベアメタルインフラストラクチャーと同じです。VMware cloud on AWSS のソフトウェア定義データセンター (SDDC) がデプロイされると、これらの物理サーバーノードを使用し、単一のテナント方式で VMware ESXi ハイパーバイザーを実行します。つまり、物理インフラストラクチャーは、 VMC を使用して他のユーザーがアクセスすることはできません。仮想インフラストラクチャーをホストするために必要な物理ホストの数を考慮することが重要です。
これを判別できるように、VMware は VMC on AWS Sizer を提供しています。このツールを使用して、VMC でホストするリソースを定義できます。
- ワークロードのタイプ
- 仮想マシンの合計数
仕様情報 (以下を含む)。
- ストレージ要件
- vCPU
- vRAM
- オーバーコミットの比率
これらの詳細情報により、Sizer ツールは VMware のベストプラクティスに基づいてレポートを生成し、クラスター設定および必要なホスト数について推奨します。
15.2.2. vSphere 要件
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 のドキュメント内容を確認している。
- ブロックレジストリーストレージ をプロビジョニングしている。永続ストレージの詳細は、永続ストレージについて を参照してください。
クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用する場合)。
注記プロキシーを設定する場合は、このサイト一覧も確認してください。
15.2.3. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.8 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
15.2.4. VMware vSphere インフラストラクチャーの要件
使用するコンポーネントの要件を満たす VMware vSphere バージョン 6 または 7 インスタンスに OpenShift Container Platform クラスターをインストールする必要があります。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 6.5 以降 (HW バージョン 13) | このバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。Red Hat Enterprise Linux 8 でサポートされるハイパーバイザーの一覧 を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 6.5 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
vSphere バージョン 6.5 インスタンスを使用している場合は、OpenShift Container Platform をインストールする前に 6.7U3 または 7.0 にアップグレードすることを検討してください。
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
15.2.5. ネットワーク接続の要件
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。
必要なネットワークポートに関する次の詳細を確認してください。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| 仮想拡張可能 LAN (VXLAN) |
| Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
15.2.6. vCenter の要件
インストーラーでプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの権限
OpenShift Container Platform クラスターを vCenter にインストールするには、インストールプログラムには、必要なリソースの読み取りおよび作成権限を持つアカウントへのアクセスが必要になります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。
グローバル管理者権限を持つアカウントを使用できない場合、OpenShift Container Platform クラスターのインストールに必要な権限を付与するためのロールを作成する必要があります。ほとんどの特権は常に必要になりますが、デフォルト動作であるインストールプログラムでの vCenter インスタンスへの OpenShift Container Platform クラスターが含まれるフォルダーのプロビジョニングを実行する場合にのみ必要となる特権もあります。必要な特権を付与するには、指定されたオブジェクトに vSphere ロールを作成するか、またはこれを修正する必要があります。
インストールプログラムが vSphere 仮想マシンフォルダーを作成するために使用される場合には、追加のロールが必要です。
例15.1 vSphere API でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な権限 |
---|---|---|
vSphere vCenter | Always |
|
vSphere vCenter Cluster | Always |
|
vSphere Datastore | Always |
|
vSphere ポートグループ | Always |
|
仮想マシンフォルダー | Always |
|
vSphere vCenter Datacenter | インストールプログラムが仮想マシンフォルダーを作成する場合 |
|
例15.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な権限 |
---|---|---|
vSphere vCenter | Always |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | Always |
|
vSphere ポートグループ | Always |
|
仮想マシンフォルダー | Always |
|
vSphere vCenter Datacenter | インストールプログラムが仮想マシンフォルダーを作成する場合 |
|
また、ユーザーには一部の ReadOnly
パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例15.3 必要なパーミッションおよび伝播の設定
vSphere オブジェクト | フォルダータイプ | 子への伝播 | パーミッションが必要 |
---|---|---|---|
vSphere vCenter | Always | False | 必要な特権が一覧表示 |
vSphere vCenter Datacenter | 既存のフォルダー | False |
|
インストールプログラムがフォルダーを作成する | True | 必要な特権が一覧表示 | |
vSphere vCenter Cluster | Always | True | 必要な特権が一覧表示 |
vSphere vCenter Datastore | Always | False | 必要な特権が一覧表示 |
vSphere Switch | Always | False |
|
vSphere ポートグループ | Always | False | 必要な特権が一覧表示 |
vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | 必要な特権が一覧表示 |
必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
OpenShift Container Platform は通常、コンピュートのみの vMotion をサポートします。Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。
コンピュートおよびコントロールプレーンノードのアップタイムを確保するには、vMotion の VMware のベストプラクティスに従うことが推奨されます。また、VMware 非アフィニティールールを使用して、メンテナンス中またはハードウェアの問題時に OpenShift Container Platform の可用性を向上させることも推奨します。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Pod で vSphere ボリュームを使用している場合、手動でまたは Storage vMotion を使用して仮想マシンをデータストア間で移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生します。これらの参照により、影響を受ける Pod が起動しなくなり、データが失われる可能性があります。
- 同様に、OpenShift Container Platform は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。
クラスターリソース
インストーラーでプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターをデプロイする場合、インストールプログラムは vCenter インスタンスに複数のリソースを作成できる必要があります。
標準的な OpenShift Container Platform インストールでは、以下の vCenter リソースを作成します。
- 1 フォルダー
- 1 タグカテゴリー
- 1 タグ
仮想マシン:
- 1 テンプレート
- 1 一時的ブートストラップノード
- 3 コントロールプレーンノード
- 3 コンピュートマシン
これらのリソースは 856 GB のストレージを使用しますが、ブートストラップノードはクラスターのインストールプロセス時に破棄されます。標準クラスターを使用するには、最低 800 GB のストレージが必要です。
追加のコンピュートマシンをデプロイする場合、OpenShift Container Platform クラスターは追加のストレージを使用します。
クラスターの制限
利用可能なリソースはクラスターによって異なります。vCenter 内の予想されるクラスター数は、主に利用可能なストレージ容量と必要なリソース数の制限によって制限されます。クラスターが作成する vCenter リソースと、IP アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに DHCP を使用し、DHCP サーバーが永続 IP アドレスをクラスターマシンに提供するように設定されていることを確認する必要があります。すべてのノードが同じ VLAN にある必要があります。2 日目の操作として 2 番目の VLAN を使用してクラスターをスケーリングすることはできません。さらに、OpenShift Container Platform クラスターをインストールする前に以下のネットワークリソースを作成する必要があります。
クラスターの各 OpenShift Container Platform ノードは、DHCP を使用して検出可能な Network Time Protocol (NTP) サーバーにアクセスできることが推奨されます。NTP サーバーなしでインストールが可能です。ただし、非同期のサーバークロックによりエラーが発生しますが、NTP サーバーはこのエラーを阻止します。
必要な IP アドレス
インストーラーでプロビジョニングされる vSphere のインストールには、2 つの静的 IP アドレスが必要です。
- API アドレスは、クラスター API にアクセスするために使用されます。
- Ingress アドレスは、クラスターの Ingress トラフィックに使用されます。
OpenShift Container Platform クラスターのインストール時にこれらの IP アドレスをインストールプログラムに指定する必要があります。
DNS レコード
OpenShift Container Platform クラスターをホストする vCenter インスタンスについて 2 つの静的 IP アドレスの DNS レコードを適切な DNS サーバーに作成する必要があります。各レコードで、 <cluster_name>
はクラスター名で、<base_domain>
は、クラスターのインストール時に指定するクラスターのベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
API VIP |
| この DNS A/AAAA または CNAME レコードは、コントロールプレーンマシンのロードバランサーを参照する必要があります。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
Ingress VIP |
| Ingress ルーター Pod を実行するマシンをターゲットにするロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
15.2.7. クラスターノードの SSH アクセス用のキーペアの生成
OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定できます。キーは、Ignition 設定ファイルを介して Red Hat Enterprise Linux CoreOS (RHCOS) ノードに渡され、ノードへの SSH アクセスを認証するために使用されます。このキーは各ノードの core
ユーザーの ~/.ssh/authorized_keys
一覧に追加され、パスワードなしの認証が可能になります。
キーがノードに渡されると、キーペアを使用して RHCOS ノードにユーザー core
として SSH を実行できます。SSH 経由でノードにアクセスするには、秘密鍵のアイデンティティーをローカルユーザーの SSH で管理する必要があります。
インストールのデバッグまたは障害復旧を実行するためにクラスターノードに対して SSH を実行する場合は、インストールプロセスの間に SSH 公開鍵を指定する必要があります。 /openshift-install gather
コマンドでは、SSH 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
- 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1
- 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
15.2.8. インストールプログラムの取得
OpenShift Container Platform をインストールする前に、インストールファイルをプロビジョニングマシンにダウンロードします。
前提条件
- Linux を実行するマシン (例: 500 MB のローカルディスク領域のある Red Hat Enterprise Linux 8) が必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使ってログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
選択するインストールタイプのページに移動し、オペレーティングシステムのインストールプログラムをダウンロードし、ファイルをインストール設定ファイルを保存するディレクトリーに配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ tar xvf openshift-install-linux.tar.gz
- Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
15.2.9. vCenter ルート CA 証明書のシステム信頼への追加
インストールプログラムは vCenter の API へのアクセスが必要であるため、OpenShift Container Platform クラスターをインストールする前に vCenter の信頼されたルート CA 証明書をシステム信頼に追加する必要があります。
手順
-
vCenter ホームページから、vCenter のルート CA 証明書をダウンロードします。vSphere Web Services SDK セクションで、Download trusted root CA certificates をクリックします。
<vCenter>/certs/download.zip
ファイルがダウンロードされます。 vCenter ルート CA 証明書が含まれる圧縮ファイルを展開します。圧縮ファイルの内容は、以下のファイル構造のようになります。
certs ├── lin │ ├── 108f4d17.0 │ ├── 108f4d17.r1 │ ├── 7e757f6a.0 │ ├── 8e4f8471.0 │ └── 8e4f8471.r0 ├── mac │ ├── 108f4d17.0 │ ├── 108f4d17.r1 │ ├── 7e757f6a.0 │ ├── 8e4f8471.0 │ └── 8e4f8471.r0 └── win ├── 108f4d17.0.crt ├── 108f4d17.r1.crl ├── 7e757f6a.0.crt ├── 8e4f8471.0.crt └── 8e4f8471.r0.crl 3 directories, 15 files
オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
# cp certs/lin/* /etc/pki/ca-trust/source/anchors
システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
# update-ca-trust extract
15.2.10. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
重要空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に値を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして vsphere を選択します。
- vCenter インスタンスの名前を指定します。
クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。
インストールプログラムは vCenter インスタンスに接続します。
- 接続する vCenter インスタンスにあるデータセンターを選択します。
使用するデフォルトの vCenter データストアを選択します。
注記データストアとクラスター名は 60 文字を超えることができません。そのため、組み合わせた文字列の長さが 60 文字の制限を超えないようにしてください。
- OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
- 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
- コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
- クラスター Ingress に設定した仮想 IP アドレスを入力します。
- ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
クラスターの記述名を入力します。クラスター名は、設定した DNS レコードで使用したものと同じである必要があります。
注記データストアとクラスター名は 60 文字を超えることができません。そのため、組み合わせた文字列の長さが 60 文字の制限を超えないようにしてください。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
重要VMC 環境でホストされる bastion からの
openshift-install
コマンドを使用します。注記ホストに設定した AWS アカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプログラムは停止し、不足しているパーミッションが表示されます。
クラスターのデプロイメントが完了すると、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報を含む、クラスターにアクセスするための指示がターミナルに表示されます。出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "4vYBz-Ee6gm-ymBZj-Wt5AL" INFO Time elapsed: 36m22s
注記クラスターアクセスおよび認証情報の情報は、インストールが正常に実行される際に
<installation_directory>/.openshift_install.log
に出力されます。重要-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
重要インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
15.2.11. バイナリーのダウンロードによる OpenShift CLI のインストール
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.8 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.8 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
$ tar xvzf <file>
oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.8 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。C:\> path
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
C:\> oc <command>
macOC への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Version ドロップダウンメニューで適切なバージョンを選択します。
- OpenShift v4.8 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。$ echo $PATH
OpenShift CLI のインストール後に、oc
コマンドを使用して利用できます。
$ oc <command>
15.2.12. CLI の使用によるクラスターへのログイン
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
kubeadmin
認証情報をエクスポートします。$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1
- 1
<installation_directory>
には、インストールファイルを保存したディレクトリーへのパスを指定します。
エクスポートされた設定を使用して、
oc
コマンドを正常に実行できることを確認します。$ oc whoami
出力例
system:admin
15.2.13. レジストリーストレージの作成
クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。
15.2.13.1. インストール時に削除されたイメージレジストリー
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift イメージレジストリー Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、イメージレジストリー Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。
Prometheus コンソールは、以下のような ImageRegistryRemoved
アラートを提供します。
"Image Registry has been removed.ImageStreamTags
, BuildConfigs
and DeploymentConfigs
which reference ImageStreamTags
may not work as expected.ストレージを設定して、configs.imageregistry.operator.openshift.io を編集して設定を Managed
状態に更新してください。
15.2.13.2. イメージレジストリーストレージの設定
イメージレジストリー Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定についての手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
15.2.13.2.1. VMware vSphere のレジストリーストレージの設定
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- VMware vSphere 上のクラスター。
Red Hat OpenShift Container Storage などのクラスターのプロビジョニングされた永続ストレージ。
重要OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの
ReadWriteOnce
アクセスをサポートします。ReadWriteOnce
アクセスでは、レジストリーがRecreate
ロールアウト戦略を使用する必要もあります。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany
アクセスが必要です。- 100Gi の容量が必要です。
テストにより、NFS サーバーを RHEL でコアサービスのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container レジストリーおよび Quay、メトリクスストレージの Prometheus、およびロギングストレージの Elasticsearch が含まれます。そのため、コアサービスで使用される PV をサポートするために RHEL NFS を使用することは推奨されていません。
他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift Container Platform コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
手順
レジストリーをストレージを使用できるように設定するには、
configs.imageregistry/cluster
リソースのspec.storage.pvc
を変更します。注記共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。
レジストリー Pod がないことを確認します。
$ oc get pod -n openshift-image-registry -l docker-registry=default
出力例
No resourses found in openshift-image-registry namespace
注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
$ oc edit configs.imageregistry.operator.openshift.io
出力例
storage: pvc: claim: 1
- 1
image-registry-storage
永続ボリューム要求 (PVC) の自動作成を許可するには、claim
フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
clusteroperator
ステータスを確認します。$ oc get clusteroperator image-registry
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
15.2.13.2.2. VMware vSphere のブロックレジストリーストレージの設定
イメージレジストリーがクラスター管理者によるアップグレード時に vSphere Virtual Machine Disk (VMDK) などのブロックストレージタイプを使用できるようにするには、Recreate
ロールアウトストラテジーを使用できます。
ブロックストレージボリュームはサポートされますが、実稼働クラスターでのイメージレジストリーと併用することは推奨されません。レジストリーに複数のレプリカを含めることができないため、ブロックストレージにレジストリーが設定されているインストールに高可用性はありません。
手順
イメージレジストリーストレージをブロックストレージタイプとして設定するには、レジストリーが
Recreate
ロールアウトストラテジーを使用し、1
レプリカのみで実行されるように、レジストリーにパッチを適用します。$ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'
ブロックストレージデバイスの PV をプロビジョニングし、そのボリュームの PVC を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。
以下の内容で
pvc.yaml
ファイルを作成して VMware vSpherePersistentVolumeClaim
オブジェクトを定義します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: image-registry-storage 1 namespace: openshift-image-registry 2 spec: accessModes: - ReadWriteOnce 3 resources: requests: storage: 100Gi 4
ファイルから
PersistentVolumeClaim
オブジェクトを作成します。$ oc create -f pvc.yaml -n openshift-image-registry
正しい PVC を参照するようにレジストリー設定を編集します。
$ oc edit config.imageregistry.operator.openshift.io -o yaml
出力例
storage: pvc: claim: 1
- 1
- カスタム PVC を作成すると、
image-registry-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにすることができます。
正しい PVC を参照するようにレジストリーストレージを設定する方法については、vSphere のレジストリーの設定 を参照してください。
15.2.14. VMware vSphere ボリュームのバックアップ
OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップしたり、スナップショットからボリュームを復元したりすることはできません。詳細は、スナップショットの制限 を参照してください。
手順
永続ボリュームのバックアップを作成すには、以下を実行します。
- 永続ボリュームを使用しているアプリケーションを停止します。
- 永続ボリュームのクローンを作成します。
- アプリケーションを再起動します。
- クローンを作成したボリュームのバックアップを作成します。
- クローンを作成したボリュームを削除します。
15.2.15. スチールクロックアカウンティング
デフォルトでは、インストールプログラムは、スチールクロックアカウンティングパラメーター (stealclock.enabled
) を有効にせずに、クラスターの仮想マシンをプロビジョニングします。スチールクロックアカウンティングを有効にすると、クラスターの問題のトラブルシューティングに役立ちます。クラスターをデプロイメントしたら、vSphere Client を使用して、各仮想マシンでこのパラメーターを有効にします。
詳細は、Red Hat ナレッジベースアーティクル libvirt-lxc を使用した Linux コンテナー (廃止) を参照してください。
15.2.16. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.8 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリングについて を参照してください。
15.2.17. 次のステップ
- クラスターをカスタマイズします。
- 必要な場合は、リモートの健全性レポートをオプトアウト することができます。
- レジストリーをセットアップし、レジストリーストレージを設定します。
- オプション: vSphere Problem Detector Operator からのイベントを表示 し、クラスターにパーミッションまたはストレージ設定の問題があるかどうかを判別します。