3.4. ネットワークのカスタマイズによる vSphere へのクラスターのインストール
OpenShift Container Platform バージョン 4.18 では、カスタマイズしたネットワーク設定オプションを使用して、独自にプロビジョニングする VMware vSphere インフラストラクチャーにクラスターをインストールできます。ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の MTU および VXLAN 設定と統合できます。
				大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy 設定パラメーターのみになります。
			
user-provisioned infrastructure のインストール手順は、例としてのみ提供されます。独自にプロビジョニングするインフラストラクチャーでクラスターをインストールするには、vSphere プラットフォームおよび OpenShift Container Platform のインストールプロセスを理解している必要があります。user-provisioned infrastructure のインストール手順をガイドとして使用します。他の方法で必要なリソースを作成することもできます。
3.4.1. 前提条件
- user-provisioned infrastructure を使用したクラスターのインストールの準備 のタスクを完了した。
- VMware プラットフォームのライセンスを確認した。Red Hat は VMware ライセンスに制限を設けていませんが、一部の VMware インフラストラクチャーコンポーネントにはライセンスが必要です。
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- インストールを完了するには、vSphere ホストに Red Hat Enterprise Linux CoreOS(RHCOS) OVA をアップロードする必要があります。このプロセスを完了するマシンには、vCenter および ESXi ホストのポート 443 にアクセスできる必要があります。ポート 443 にアクセスできることを確認している。
- ファイアウォールを使用する場合は、ポート 443 にアクセスできることを管理者に確認している。インストールを成功させるには、コントロールプレーンノードがポート 443 で vCenter および ESXi ホストに到達できる必要があります。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 する必要がある。
3.4.2. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.18 では、クラスターをインストールするためにインターネットアクセスが必要になります。
次のアクションを実行するには、インターネットにアクセスできる必要があります。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターがインターネットにアクセスでき、Telemetry を無効にしていない場合、そのサービスによってクラスターのサブスクリプションが自動的に有効化されます。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
3.4.3. VMware vSphere のリージョンとゾーンの有効化
OpenShift Container Platform クラスターを複数の vSphere データセンターにデプロイできます。各データセンターは、複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
VMware vSphere のリージョンおよびゾーンの有効化機能には、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーが必要です。そのため、この機能は新しくインストールされたクラスターでのみ使用できます。
以前のリリースからアップグレードされたクラスターの場合は、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。
デフォルトのインストール設定では、クラスターが単一の vSphere データセンターにデプロイされます。クラスターを複数の vSphere データセンターにデプロイする場合は、リージョンおよびゾーン機能を有効にするインストール設定ファイルを作成する必要があります。
					デフォルトの install-config.yaml ファイルには vcenters フィールドと failureDomains フィールドが含まれており、OpenShift Container Platform クラスターに複数の vSphere データセンターとクラスターを指定できます。単一のデータセンターで構成される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにすることができます。
				
次のリストでは、クラスターのゾーンとリージョンの定義に関連する用語を説明します。
- 
							障害ドメイン: リージョンとゾーン間の関係を確立します。障害ドメインは、datastoreオブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
- 
							リージョン: vCenter データセンターを指定します。リージョンを定義するには、openshift-regionタグカテゴリーのタグを使用します。
- 
							ゾーン: vCenter クラスターを指定します。ゾーンを定義するには、openshift-zoneタグカテゴリーのタグを使用します。
						install-config.yaml ファイルで複数の障害ドメインを指定する予定がある場合は、設定ファイルを作成する前に、タグカテゴリー、ゾーンタグ、およびリージョンタグを作成する必要があります。
					
リージョンを表す vCenter データセンターごとに vCenter タグを作成する必要があります。さらに、データセンターで実行されるクラスターごとに、ゾーンを表す vCenter タグを作成する必要があります。タグを作成した後、各タグをそれぞれのデータセンターとクラスターにアタッチする必要があります。
次の表は、単一の VMware vCenter で実行されている複数の vSphere データセンターを含む設定のリージョン、ゾーン、タグ間の関係の例を示しています。
| データセンター (リージョン) | クラスター (ゾーン) | タグ | 
|---|---|---|
| 米国東部 | us-east-1 | us-east-1a | 
| us-east-1b | ||
| us-east-2 | us-east-2a | |
| us-east-2b | ||
| us-west | us-west-1 | us-west-1a | 
| us-west-1b | ||
| us-west-2 | us-west-2a | |
| us-west-2b | 
3.4.4. インストール設定ファイルの手動作成
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得している。
手順
- 必要なインストールアセットを保存するためのインストールディレクトリーを作成します。 - mkdir <installation_directory> - $ mkdir <installation_directory>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 重要- このディレクトリーは必ず作成してください。ブートストラップ X.509 証明書などの一部のインストールアセットは、有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。 
- 提供されているサンプルの - install-config.yamlファイルテンプレートをカスタマイズし、ファイルを- <installation_directory>に保存します。注記- この設定ファイルの名前を - install-config.yamlと付ける必要があります。
- 多くのクラスターのインストールに使用できるように、 - install-config.yamlファイルをバックアップします。重要- インストールプロセスの次のステップで - install-config.yamlファイルを使用するため、今すぐこのファイルをバックアップしてください。
3.4.4.1. VMware vSphere のサンプル install-config.yaml ファイル
						install-config.yaml ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
					
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 4
- controlPlaneセクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、- computeセクションの最初の行はハイフン- -で始め、- controlPlaneセクションの最初の行はハイフンで始めることができません。両方のセクションで単一のマシンプールが定義されるため、使用されるコントロールプレーンは 1 つだけです。OpenShift Container Platform は、複数のコンピューティングプールの定義をサポートしていません。
- 3
- replicasパラメーターの値を- 0に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、user-provisioned infrastructure を使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。
- 5
- クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
- 6
- DNS レコードに指定したクラスター名。
- 7
- リージョンとゾーン間の関係を確立します。障害ドメインは、datastoreオブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。
- 8
- vSphere データセンター。
- 9
- 仮想マシンファイル、テンプレート、ISO イメージを保持する vSphere データストアへのパス。重要データストアクラスター内に存在する任意のデータストアのパスを指定できます。デフォルトでは、Storage vMotion はデータストアクラスターに対して自動的に有効になります。Red Hat は Storage vMotion をサポートしていないため、OpenShift Container Platform クラスターのデータ損失の問題を回避するには、Storage vMotion を無効にする必要があります。 複数のデータストアにわたって仮想マシンを指定する必要がある場合は、 datastoreオブジェクトを使用して、クラスターのinstall-config.yaml設定ファイルで障害ドメインを指定します。詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。
- 10
- オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス (例:/<data_center_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>)。値を指定しない場合、リソースはクラスターのルート/example_data_center/host/example_cluster/Resourcesにインストールされます。
- 11
- オプション: installer-provisioned infrastructure の場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例:/<data_center_name>/vm/<folder_name>/<subfolder_name>)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thinという名前のデフォルトのStorageClassオブジェクトを使用したくない場合は、install-config.yamlファイルからfolderパラメーターを省略できます。
- 12
- vSphere ユーザーに関連付けられたパスワード。
- 13
- vCenter サーバーの完全修飾ホスト名または IP アドレス。重要Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。 
- 14
- vSphere ディスクのプロビジョニング方法。
- 15
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。 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 暗号化ライブラリーを使用します。 
- 16
- OpenShift Cluster Manager から取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
- 17
- Red Hat Enterprise Linux CoreOS (RHCOS) のcoreユーザーのデフォルト SSH キーの公開部分。
3.4.4.2. インストール時のクラスター全体のプロキシーの設定
						実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
					
前提条件
- 
								既存の install-config.yamlファイルがある。
- クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを - Proxyオブジェクトの- spec.noProxyフィールドに追加している。注記- Proxyオブジェクトの- status.noProxyフィールドには、インストール設定の- networking.machineNetwork[].cidr、- networking.clusterNetwork[].cidr、および- networking.serviceNetwork[]フィールドの値が設定されます。- Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、 - Proxyオブジェクトの- status.noProxyフィールドには、インスタンスメタデータのエンドポイント (- 169.254.169.254) も設定されます。
手順
- install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームはhttpである必要があります。
- 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。vCenter の IP アドレスと、そのマシンに使用する IP 範囲を含める必要があります。
- 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれるuser-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle設定マップを作成し、この設定マップはProxyオブジェクトのtrustedCAフィールドで参照されます。additionalTrustBundleフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
- 5
- オプション:trustedCAフィールドのuser-ca-bundle設定マップを参照するProxyオブジェクトの設定を決定するポリシー。許可される値はProxyonlyおよびAlwaysです。Proxyonlyを使用して、http/httpsプロキシーが設定されている場合にのみuser-ca-bundle設定マップを参照します。Alwaysを使用して、常にuser-ca-bundle設定マップを参照します。デフォルト値はProxyonlyです。
 注記- インストールプログラムは、プロキシーの - readinessEndpointsフィールドをサポートしません。注記- インストーラーがタイムアウトした場合は、インストーラーの - wait-forコマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。- ./openshift-install wait-for install-complete --log-level debug - $ ./openshift-install wait-for install-complete --log-level debug- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
						インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
					
							cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
						
3.4.4.3. VMware vCenter のリージョンとゾーンの設定
デフォルトのインストール設定ファイルを変更して、OpenShift Container Platform クラスターを複数の vSphere データセンターにデプロイできます。
						OpenShift Container Platform の以前のリリースのデフォルトの install-config.yaml ファイル設定は非推奨になりました。非推奨のデフォルト設定を引き続き使用できますが、openshift-installer により、設定ファイル内の非推奨のフィールドの使用を示す警告メッセージが表示されます。
					
前提条件
- 既存の - install-config.yamlインストール設定ファイルがある。重要- VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。 
- govcコマンドラインツールがインストールされている。重要- この例では、 - govcコマンドを使用します。- govcコマンドは、VMware から入手できるオープンソースコマンドです。Red Hat からは入手できません。Red Hat サポートチームは- govcコマンドを保守していません。- govcのダウンロードおよびインストール手順は、VMware ドキュメントの Web サイトを参照してください。
手順
- 次のコマンドを実行して、 - openshift-regionおよび- openshift-zonevCenter タグカテゴリーを作成します。重要- openshift-regionおよび- openshift-zonevCenter タグカテゴリーに異なる名前を指定すると、OpenShift Container Platform クラスターのインストールは失敗します。- govc tags.category.create -d "OpenShift region" openshift-region - $ govc tags.category.create -d "OpenShift region" openshift-region- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - govc tags.category.create -d "OpenShift zone" openshift-zone - $ govc tags.category.create -d "OpenShift zone" openshift-zone- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- クラスターをデプロイするリージョンごとに、次のコマンドを実行してリージョンタグを作成します。 - govc tags.create -c <region_tag_category> <region_tag> - $ govc tags.create -c <region_tag_category> <region_tag>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- クラスターをデプロイするゾーンごとに、次のコマンドを実行してゾーンタグを作成します。 - govc tags.create -c <zone_tag_category> <zone_tag> - $ govc tags.create -c <zone_tag_category> <zone_tag>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次のコマンドを実行して、vCenter データセンターオブジごとにリージョンタグをアタッチします。 - govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1> - $ govc tags.attach -c <region_tag_category> <region_tag_1> /<data_center_1>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次のコマンドを実行して、vCenter クラスターオブジェクトごとにゾーンタグをアタッチします。 - govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/<cluster1> - $ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<data_center_1>/host/<cluster1>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。
vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml ファイル
3.4.5. ネットワーク設定フェーズ
OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。
- フェーズ 1
- マニフェストファイルを作成する前に、 - install-config.yamlファイルで以下のネットワーク関連のフィールドをカスタマイズできます。- 
										networking.networkType
- 
										networking.clusterNetwork
- 
										networking.serviceNetwork
- 
										networking.machineNetwork
- nodeNetworking- 詳細は、「インストール設定パラメーター」を参照してください。 注記- 優先されるサブネットが配置されている Classless Inter-Domain Routing (CIDR) と一致するように - networking.machineNetworkを設定します。重要- CIDR 範囲 - 172.17.0.0/16は- libVirtによって予約されています。クラスター内のネットワークに- 172.17.0.0/16CIDR 範囲と重複する他の CIDR 範囲を使用することはできません。
 
- 
										
- フェーズ 2
- 
								openshift-install create manifestsを実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。
					フェーズ 2 では、install-config.yaml ファイルのフェーズ 1 で指定した値をオーバーライドすることはできません。ただし、フェーズ 2 でネットワークプラグインをカスタマイズできます。
				
3.4.6. 高度なネットワーク設定の指定
ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。
高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される OpenShift Container Platform マニフェストファイルを変更してネットワーク設定をカスタマイズすることは、サポートされていません。以下の手順のように、作成するマニフェストファイルを適用することがサポートされています。
前提条件
- 
							install-config.yamlファイルを作成し、これに対する変更を完了している。
手順
- インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。 - ./openshift-install create manifests --dir <installation_directory> - $ ./openshift-install create manifests --dir <installation_directory>- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <installation_directory>は、クラスターの- install-config.yamlファイルが含まれるディレクトリーの名前を指定します。
 
- cluster-network-03-config.ymlという名前の、高度なネットワーク設定用のスタブマニフェストファイルを- <installation_directory>/manifests/ディレクトリーに作成します。- apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: - apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec:- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次の例のように、 - cluster-network-03-config.ymlファイルでクラスターの高度なネットワーク設定を指定します。- OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にする - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
							オプション: manifests/cluster-network-03-config.ymlファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時にmanifests/ディレクトリーを使用します。
- コントロールプレーンマシンおよびコンピュート - MachineSetsを定義する Kubernetes マニフェストファイルを削除します。- rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml - $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。 - 
									MachineSetファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
 
- 
									
3.4.6.1. ネットワークに複数のサブネットを指定する
OpenShift Container Platform クラスターを vSphere ホストにインストールする前に、ネットワーク実装に複数のサブネットを指定して、vSphere Cloud Controller Manager (CCM) が特定のネットワーク状況に適したサブネットを選択できるようにします。vSphere は、クラスター上の Pod およびサービスを管理するサブネットを使用できます。
この設定では、vSphere CCM 設定で内部および外部の Classless Inter-Domain Routing (CIDR) 実装を指定する必要があります。各 CIDR 実装は、内部および外部ネットワークからのトラフィックと対話するサブネットを決定するために CCM が使用する IP アドレス範囲をリスト表示します。
vSphere CCM 設定で内部および外部の CIDR 実装の設定に失敗すると、vSphere CCM が誤ったサブネットを選択する可能性があります。この状況では、以下のエラーが発生します。
ERROR Bootstrap failed to complete: timed out waiting for the condition ERROR Failed to wait for bootstrapping to complete. This error usually happens when there is a problem with control plane hosts that prevents the control plane operators from creating the control plane.
ERROR Bootstrap failed to complete: timed out waiting for the condition
ERROR Failed to wait for bootstrapping to complete. This error usually happens when there is a problem with control plane hosts that prevents the control plane operators from creating the control plane.
							この設定により、新規の各ノードが node.cloudprovider.kubernetes.io/uninitialized taint を受け取ると、単一のサブネットの MachineSet オブジェクトに関連付けられた新規ノードが使用できなくなる可能性があります。このような状況では、Kubernetes API サーバーとの通信で問題が発生し、これが原因でクラスターのインストールが失敗する可能性があります。
						
前提条件
- OpenShift Container Platform クラスターの Kubernetes マニフェストファイルを作成している。
手順
- 
								OpenShift Container Platform クラスターマニフェストファイルを保存するディレクトリーから、manifests/cluster-infrastructure-02-config.ymlマニフェストファイルを開きます。
- nodeNetworkingオブジェクトをファイルに追加し、オブジェクトの内部および外部ネットワークサブネット CIDR 実装を指定します。ヒント- ほとんどのネットワークの場合は、標準のマルチサブネット構成の設定を検討してください。この構成では、 - nodeNetworking.internal.networkSubnetCidrおよび- nodeNetworking.external.networkSubnetCidrパラメーターに同じ IP アドレス範囲を設定する必要があります。- 設定された - cluster-infrastructure-02-config.ymlマニフェストファイルの例- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
3.4.7. Cluster Network Operator の設定
					クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。
				
					CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承します。
				
- clusterNetwork
- Pod IP アドレスの割り当てに使用する IP アドレスプール。
- serviceNetwork
- サービスの IP アドレスプール。
- defaultNetwork.type
- 
								クラスターネットワークプラグイン。OVNKubernetesは、インストール時にサポートされる唯一のプラグインです。
					defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
				
3.4.7.1. Cluster Network Operator 設定オブジェクト
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
| フィールド | 型 | 説明 | 
|---|---|---|
| 
										 | 
										 | 
										CNO オブジェクトの名前。この名前は常に  | 
| 
										 | 
										 | Pod IP アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 | 
| 
										 | 
										 | サービスの IP アドレスのブロック。OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。以下に例を示します。 spec: serviceNetwork: - 172.30.0.0/14 
										マニフェストを作成する前に、このフィールドを  | 
| 
										 | 
										 | クラスターネットワークのネットワークプラグインを設定します。 | 
| 
										 | 
										 | このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。 | 
							複数のネットワークにオブジェクトをデプロイする必要があるクラスターの場合は、install-config.yaml ファイルで定義されている各ネットワークタイプの clusterNetwork.hostPrefix パラメーターに、必ず同じ値を指定してください。clusterNetwork.hostPrefix パラメーターにそれぞれ異なる値を設定すると、OVN-Kubernetes ネットワークプラグインに影響が及び、異なるノード間のオブジェクトトラフィックをプラグインが効果的にルーティングできなくなる可能性があります。
						
3.4.7.1.1. defaultNetwork オブジェクト設定
							defaultNetwork オブジェクトの値は、以下の表で定義されます。
						
| フィールド | 型 | 説明 | 
|---|---|---|
| 
											 | 
											 | 
											 注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。 | 
| 
											 | 
											 | このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 | 
3.4.7.1.1.1. OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
| フィールド | 型 | 説明 | 
|---|---|---|
| 
												 | 
												 | Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。 
												クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも  | 
| 
												 | 
												 | 
												すべての Geneve パケットに使用するポート。デフォルト値は  | 
| 
												 | 
												 | IPsec 設定をカスタマイズするための設定オブジェクトを指定します。 | 
| 
												 | 
												 | IPv4 設定の設定オブジェクトを指定します。 | 
| 
												 | 
												 | IPv6 設定の設定オブジェクトを指定します。 | 
| 
												 | 
												 | ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 | 
| 
												 | 
												 | 
												オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。有効な値は  注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 | 
| フィールド | 型 | 説明 | 
|---|---|---|
| 
												 | string | 
												既存のネットワークインフラストラクチャーが  
												デフォルト値は  | 
| 
												 | string | 
												既存のネットワークインフラストラクチャーが  
												デフォルト値は  | 
| フィールド | 型 | 説明 | 
|---|---|---|
| 
												 | string | 
												既存のネットワークインフラストラクチャーが  
												デフォルト値は  | 
| 
												 | string | 
												既存のネットワークインフラストラクチャーが  
												デフォルト値は  | 
| フィールド | 型 | 説明 | 
|---|---|---|
| 
												 | integer | 
												ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり  | 
| 
												 | integer | 
												監査ログの最大サイズ (バイト単位)。デフォルト値は  | 
| 
												 | integer | 保持されるログファイルの最大数。 | 
| 
												 | string | 以下の追加の監査ログターゲットのいずれかになります。 
 | 
| 
												 | string | 
												RFC5424 で定義される  | 
| フィールド | 型 | 説明 | 
|---|---|---|
| 
												 | 
												 | 
												Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを  
												このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを  | 
| 
												 | 
												 | 
												 注記 
													デフォルト値の  | 
| 
												 | 
												 | オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 | 
| 
												 | 
												 | オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 | 
| フィールド | 型 | 説明 | 
|---|---|---|
| 
												 | 
												 | 
												ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は  重要 
													OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして  | 
| フィールド | 型 | 説明 | 
|---|---|---|
| 
												 | 
												 | 
												ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は  重要 
													OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして  | 
| フィールド | 型 | 説明 | 
|---|---|---|
| 
												 | 
												 | IPsec 実装の動作を指定します。次の値のいずれかである必要があります。 
 | 
IPSec が有効な OVN-Kubernetes 設定の例
3.4.8. Ignition 設定ファイルの作成
クラスターマシンは手動で起動する必要があるため、クラスターがマシンを作成するために必要な Ignition 設定ファイルを生成する必要があります。
- 
								インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
- 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
手順
- Ignition 設定ファイルを取得します。 - ./openshift-install create ignition-configs --dir <installation_directory> - $ ./openshift-install create ignition-configs --dir <installation_directory>- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <installation_directory>の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
 重要- install-config.yamlファイルを作成している場合、それが含まれるディレクトリーを指定します。または、空のディレクトリーを指定します。ブートストラップ X.509 証明書などの一部のインストールアセットの有効期限は短く設定されているため、インストールディレクトリーを再利用することができません。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。- 以下のファイルはディレクトリーに生成されます。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
3.4.9. インフラストラクチャー名の抽出
Ignition 設定ファイルには、VMware vSphere でクラスターを一意に識別するために使用できる一意のクラスター ID が含まれます。クラスター ID を仮想マシンフォルダーの名前として使用する予定がある場合、これを抽出する必要があります。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得している。
- クラスターの Ignition 設定ファイルを生成している。
- 
							jqパッケージをインストールしている。
手順
- Ignition 設定ファイルメタデータからインフラストラクチャー名を抽出し、表示するには、以下のコマンドを実行します。 - jq -r .infraID <installation_directory>/metadata.json - $ jq -r .infraID <installation_directory>/metadata.json- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
 - 出力例 - openshift-vw9j6 - openshift-vw9j6- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- このコマンドの出力はクラスター名とランダムな文字列です。
 
3.4.10. RHCOS のインストールおよび OpenShift Container Platform ブートストラッププロセスの開始
OpenShift Container Platform を VMware vSphere の user-provisioned infrastructure にインストールするには、Red Hat Enterprise Linux CoreOS (RHCOS) を vSphere ホストにインストールする必要があります。RHCOS のインストール時に、インストールするマシンのタイプに、OpenShift Container Platform インストールプログラムによって生成された Ignition 設定ファイルを指定する必要があります。適切なネットワーク、DNS、および負荷分散インフラストラクチャーが設定されている場合、OpenShift Container Platform ブートストラッププロセスは RHCOS マシンの再起動後に自動的に開始されます。
前提条件
- クラスターの Ignition 設定ファイルを取得している。
- お使いのコンピューターからアクセスでき、作成するマシンがアクセスできる HTTP サーバーへのアクセス権がある。
- vSphere クラスター を作成している。
手順
- 
							<installation_directory>/bootstrap.ignという名前のインストールプログラムが作成したブートストラップ Ignition 設定ファイルを HTTP サーバーにアップロードします。このファイルの URL をメモします。
- ブートストラップノードの以下の二次的な Ignition 設定ファイルを、 - <installation_directory>/merge-bootstrap.ignとしてコンピューターに保存します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- ホストしているブートストラップの Ignition 設定ファイルの URL を指定します。
 - ブートストラップマシンの仮想マシン (VM) を作成する場合に、この Ignition 設定ファイルを使用します。 
- インストールプログラムにより作成された次の Ignition 設定ファイルを見つけます。 - 
									<installation_directory>/master.ign
- 
									<installation_directory>/worker.ign
- 
									<installation_directory>/merge-bootstrap.ign
 
- 
									
- Ignition 設定ファイルを Base64 エンコーディングに変換します。この手順の後半で、これらのファイルを VM の追加の設定パラメーター - guestinfo.ignition.config.dataに追加する必要があります。- たとえば、Linux オペレーティングシステムを使用する場合、 - base64コマンドを使用してファイルをエンコードできます。- base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64 - $ base64 -w0 <installation_directory>/master.ign > <installation_directory>/master.64- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64 - $ base64 -w0 <installation_directory>/worker.ign > <installation_directory>/worker.64- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64 - $ base64 -w0 <installation_directory>/merge-bootstrap.ign > <installation_directory>/merge-bootstrap.64- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 重要- インストールの完了後にコンピュートマシンをさらにクラスターに追加する予定の場合には、これらのファイルを削除しないでください。 
- RHCOS OVA イメージを取得します。イメージは、RHCOS イメージミラー ページから入手できます。 重要- RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。 - ファイル名には、 - rhcos-vmware.<architecture>.ova形式の OpenShift Container Platform のバージョン番号が含まれます。
- vSphere クライアントで、仮想マシンを保管するフォルダーをデータセンターに作成します。 - VMs and Templates ビューをクリックします。
- データセンターの名前を右クリックします。
- 
									New Folder New VM and Template Folder をクリックします。 
- 
									表示されるウィンドウで、フォルダー名を入力します。install-config.yamlファイルに既存のフォルダーを指定していない場合には、インフラストラクチャー ID と同じ名前を持つフォルダーを作成します。このフォルダー名を使用すると、vCenter はその Workspace 設定に適した場所にあるストレージを動的にプロビジョニングします。
 
- vSphere クライアントで、OVA イメージのテンプレートを作成してから、必要に応じてテンプレートのクローンを作成します。 注記- 以下の手順では、テンプレートを作成してから、すべてのクラスターマシンのテンプレートのクローンを作成します。次に、仮想マシンのプロビジョニング時にクローン作成されたマシンタイプの Ignition 設定ファイルの場所を指定します。 - Hosts and Clusters タブで、クラスターの名前を右クリックし、Deploy OVF Template を選択します。
- Select an OVF タブで、ダウンロードした RHCOS OVA ファイルの名前を指定します。
- 
									Select a name and folder タブで、Template-RHCOSなどの Virtual machine name をテンプレートに設定します。vSphere クラスターの名前をクリックし、直前の手順で作成したフォルダーを選択します。
- Select a compute resource タブで、vSphere クラスターの名前をクリックします。
- Select storage タブで、仮想マシンのストレージオプションを設定します。 - ストレージ設定に応じて、Thin Provision または Thick Provision を選択します。
- 
											install-config.yamlファイルで指定したデータストアを選択します。
- 仮想マシンを暗号化する場合は、Encrypt this virtual machine を選択します。詳細は、「仮想マシンを暗号化するための要件」セクションを参照してください。
 
- Select network タブで、クラスターに設定したネットワークを指定します (ある場合)。
- OVF テンプレートの作成時には、Customize template タブで値を指定したり、テンプレートに追加の設定をしないようにしてください。 重要- 元の仮想マシンテンプレートは開始しないでください。仮想マシンテンプレートは停止した状態でなければなりません。また、新規 RHCOS マシン用にクローン作成する必要があります。仮想マシンテンプレートを起動すると、仮想マシンテンプレートがプラットフォームの仮想マシンとして設定されるので、これをコンピュートマシンセットで設定を適用できるテンプレートとして使用できなくなります。 
 
- 必要に応じて、仮想マシンテンプレートで設定された仮想ハードウェアバージョンを更新します。詳細は、VMware ドキュメントの Upgrading a virtual machine to the latest hardware version を参照してください。 重要- 必要に応じて、仮想マシンを作成する前に、仮想マシンテンプレートのハードウェアバージョンをバージョン 15 に更新することが推奨されます。vSphere で実行しているクラスターノード用にハードウェアバージョン 13 を使用することは非推奨となりました。インポートしたテンプレートがハードウェアバージョン 13 にデフォルト設定されている場合は、仮想マシンテンプレートをハードウェアバージョン 15 にアップグレードする前に、ESXi ホストが 6.7U3 以降を使用していることを確認する必要があります。vSphere のバージョンが 6.7U3 未満の場合は、このアップグレード手順を省略できます。ただし、OpenShift Container Platform の今後のバージョンでは、ハードウェアバージョン 13 および vSphere バージョンのサポートが 6.7U3 未満になる予定です。 
- テンプレートがデプロイされた後に、マシンの仮想マシンをクラスターにデプロイします。 - 
									テンプレートの名前を右クリックし、Clone Clone to Virtual Machine をクリックします。 
- Select a name and folder タブで、仮想マシンの名前を指定します。 - control-plane-0または- compute-1などのように、マシンタイプを名前に含めることができるかもしれません。注記- vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。 
- Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
- Select a compute resource タブで、データセンター内のホストの名前を選択します。
- Select clone options で、Customize this virtual machine's hardware を選択します。
- Customize hardware タブで、Advanced Parameters をクリックします。 重要- 次の設定の提案は、例としてのみ使用されます。クラスター管理者は、クラスターに課せられるリソース需要に従ってリソースを設定する必要があります。クラスターリソースを最適に管理するには、クラスターのルートリソースプールからリソースプールを作成することを検討してください。 - オプション: vSphere でデフォルトの DHCP ネットワークを上書きします。静的 IP ネットワークを有効にするには、以下を実行します。 - 静的 IP 設定を行います。 - コマンドの例 - export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]" - $ export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]"- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - コマンドの例 - export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8" - $ export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8"- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- vSphere で OVA から仮想マシンを起動する前に、 - guestinfo.afterburn.initrd.network-kargsプロパティーを設定します。- コマンドの例 - govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"- $ govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。 - 
													guestinfo.ignition.config.data: この手順で先程作成した、base-64 でエンコードされたファイルを見つけて、このマシンタイプに関する base-64 でエンコードされた Ignition 設定ファイルの内容を貼り付けます。
- 
													guestinfo.ignition.config.data.encoding:base64を指定します。
- 
													disk.EnableUUID:TRUEを指定します。
- 
													stealclock.enable: このパラメーターが定義されていない場合は、追加してTRUEを指定します。
- クラスターの root リソースプールから子リソースプールを作成します。この子リソースプールでリソースの割り当てを実行します。
 
- 
													
 
- Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。
- 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
- 
									Virtual Machines タブで仮想マシンを右クリックし、Power Power On を選択します。 
- コンソール出力をチェックして、Ignition が実行されたことを確認します。 - コマンドの例 - Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied - Ignition: ran on 2022/03/14 14:48:33 UTC (this boot) Ignition: user-provided config was applied- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- 
									テンプレートの名前を右クリックし、Clone 
次のステップ
- 各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。 重要- この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。 
3.4.11. vSphere でのコンピュートマシンのクラスターへの追加
コンピュートマシンを VMware vSphere の user-provisioned OpenShift Container Platform クラスターに追加することができます。
vSphere テンプレートを OpenShift Container Platform クラスターにデプロイした後に、そのクラスター内のマシンの仮想マシン (VM) をデプロイできます。
前提条件
- コンピュートマシンの base64 でエンコードされた Ignition ファイルを取得します。
- クラスター用に作成した vSphere テンプレートにアクセスできる必要があります。
手順
- 
							テンプレートの名前を右クリックし、Clone Clone to Virtual Machine をクリックします。 
- Select a name and folder タブで、仮想マシンの名前を指定します。 - compute-1などのように、マシンタイプを名前に含めることができるかもしれません。注記- vSphere インストール全体のすべての仮想マシン名が一意であることを確認してください。 
- Select a name and folder タブで、クラスターに作成したフォルダーの名前を選択します。
- Select a compute resource タブで、データセンター内のホストの名前を選択します。
- Select storage タブで、設定ファイルとディスクファイル用のストレージを選択します。
- Select clone options で、Customize this virtual machine's hardware を選択します。
- Customize hardware タブで、Advanced Parameters をクリックします。 - Attribute フィールドおよび Values フィールドにデータを指定して、以下の設定パラメーター名と値を追加します。作成するパラメーターごとに Add ボタンを選択してください。 - 
											guestinfo.ignition.config.data: このマシンファイルの base64 でエンコードしたコンピュート Ignition 設定ファイルの内容を貼り付けます。
- 
											guestinfo.ignition.config.data.encoding:base64を指定します。
- 
											disk.EnableUUID:TRUEを指定します。
 
- 
											
 
- Customize hardware タブの Virtual Hardware パネルで、必要に応じて指定した値を変更します。RAM、CPU、およびディスクストレージの量がマシンタイプの最小要件を満たすことを確認してください。多くのネットワークが存在する場合は、Add New Device > Network Adapter を選択し、New Network メニュー項目に表示されるフィールドにネットワーク情報を入力します。
- 残りの設定手順を完了します。Finish ボタンをクリックして、クローン作成操作を完了します。
- 
							Virtual Machines タブで仮想マシンを右クリックし、Power Power On を選択します。 
次のステップ
- 継続してクラスター用の追加のコンピュートマシンを作成します。
3.4.12. ディスクパーティション設定
ほとんどの場合、データパーティションは、最初に別のオペレーティングシステムをインストールするのではなく、RHCOS をインストールして作成されます。この場合、OpenShift Container Platform インストーラーでは、ディスクパーティションの設定が許可されます。
ただし、以下は、OpenShift Container Platform ノードのインストール時に、デフォルトのパーティション設定を上書きするために介入が必要と思われる 2 つのケースになります。
- 別個のパーティションの作成: 空のディスクへのグリーンフィールドインストールの場合は、別のストレージをパーティションに追加する必要がある場合があります。これは、 - /varまたは- /var/lib/etcdなどの- /varのサブディレクトリー (両方ではない) を個別のパーティションとして作成する場合にのみ正式にサポートされます。重要- ディスクサイズが 100 GB を超える場合、特にディスクサイズが 1 TB を超える場合は、別の - /varパーティションを作成します。詳細は、「個別の- /varパーティションの作成」およびこちらの Red Hat ナレッジベースの記事 を参照してください。重要- Kubernetes は 2 つのファイルシステムパーティションのみをサポートします。元の設定に複数のパーティションを追加すると、Kubernetes はそれらをすべて監視できません。 
- 
							既存のパーティションの保持: ブラウンフィールドインストールで、既存のノードに OpenShift Container Platform を再インストールし、以前のオペレーティングシステムからのデータパーティションを維持する必要がある場合、既存のデータパーティションを保持できる coreos-installerへのブート引数とオプションの両方があります。
3.4.13. 個別の /var パーティションの作成
一般的に、OpenShift Container Platform のディスクパーティション設定は、インストーラーに任せる必要があります。ただし、拡張予定のファイルシステムの一部に個別のパーティションの作成が必要となる場合もあります。
					OpenShift Container Platform は、ストレージを /var パーティションまたは /var のサブディレクトリーのいずれかに割り当てる単一のパーティションの追加をサポートします。以下に例を示します。
				
- 
							/var/lib/containers: イメージやコンテナーがシステムにさらに追加されると拡張するコンテナー関連のコンテンツを保持します。
- 
							/var/lib/etcd: etcd ストレージのパフォーマンスの最適化などの目的で分離する必要のあるデータを保持します。
- /var: 監査などの目的に合わせて分離させる必要のあるデータを保持します。重要- ディスクサイズが 100 GB を超える場合、特に 1 TB を超える場合は、別の - /varパーティションを作成します。
					/var ディレクトリーのコンテンツを個別に保存すると、必要に応じてこれらの領域のストレージの拡大を容易にし、後で OpenShift Container Platform を再インストールして、そのデータをそのまま保持することができます。この方法では、すべてのコンテナーを再度プルする必要はありません。また、システムの更新時に大きなログファイルをコピーする必要もありません。
				
					/var は、Red Hat Enterprise Linux CoreOS (RHCOS) の新規インストール前に有効にする必要があるため、以下の手順では OpenShift Container Platform インストールの openshift-install の準備フェーズで挿入されるマシン設定マニフェストを作成して、別の /var パーティションを設定します。
				
手順
- OpenShift Container Platform インストールファイルを保存するディレクトリーを作成します。 - mkdir $HOME/clusterconfig - $ mkdir $HOME/clusterconfig- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- openshift-installを実行して、- manifestおよび- openshiftのサブディレクトリーにファイルのセットを作成します。プロンプトが表示されたら、システムの質問に回答します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 追加のパーティションを設定する Butane 設定を作成します。たとえば、 - $HOME/clusterconfig/98-var-partition.buファイルに名前を付け、ディスクのデバイス名を- workerシステムのストレージデバイスの名前に変更し、必要に応じてストレージサイズを設定します。以下の例では、- /varディレクトリーを別のパーティションにマウントします。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- パーティションを設定する必要のあるディスクのストレージデバイス名。
- 2
- データパーティションをブートディスクに追加する場合は、25000 のメビバイトの最小値が推奨されます。ルートファイルシステムは、指定したオフセットまでの利用可能な領域をすべて埋めるためにサイズを自動的に変更します。値の指定がない場合や、指定した値が推奨される最小値よりも小さい場合、生成されるルートファイルシステムのサイズは小さ過ぎるため、RHCOS の再インストールでデータパーティションの最初の部分が上書きされる可能性があります。
- 3
- データパーティションのサイズ (メビバイト単位)。
- 4
- コンテナーストレージに使用されるファイルシステムでは、prjquotaマウントオプションを有効にする必要があります。
 注記- 個別の - /varパーティションを作成する場合、異なるインスタンスタイプに同じデバイス名がない場合は、ワーカーノードに異なるインスタンスタイプを使用することはできません。
- Butane config からマニフェストを作成し、 - clusterconfig/openshiftディレクトリーに保存します。たとえば、以下のコマンドを実行します。- butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml - $ butane $HOME/clusterconfig/98-var-partition.bu -o $HOME/clusterconfig/openshift/98-var-partition.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- openshift-installを再度実行し、- manifestおよび- openshiftのサブディレクトリー内のファイルセットから、Ignition 設定を作成します。- openshift-install create ignition-configs --dir $HOME/clusterconfig ls $HOME/clusterconfig/ - $ openshift-install create ignition-configs --dir $HOME/clusterconfig $ ls $HOME/clusterconfig/ auth bootstrap.ign master.ign metadata.json worker.ign- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
Ignition 設定ファイルを Red Hat Enterprise Linux CoreOS (RHCOS) システムをインストールために vSphere インストール手順への入力として使用できます。
3.4.14. ブートストラッププロセスの完了まで待機する
OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
- RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
- お使いのマシンでインターネットに直接アクセスできるか、HTTP または HTTPS プロキシーが利用できる。
手順
- ブートストラッププロセスをモニターします。 - ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ --log-level=info- $ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \- 1 - --log-level=info- 2 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.31.3 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources - INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443... INFO API v1.31.3 up INFO Waiting up to 30m0s for bootstrapping to complete... INFO It is now safe to remove the bootstrap resources- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Kubernetes API サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。 
- ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。 重要- この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。 
3.4.15. CLI の使用によるクラスターへのログイン
					クラスター kubeconfig ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
				
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
- 
							OpenShift CLI (oc) がインストールされている。
手順
- 次のコマンドを実行して、 - kubeadmin認証情報をエクスポートします。- export KUBECONFIG=<installation_directory>/auth/kubeconfig - $ export KUBECONFIG=<installation_directory>/auth/kubeconfig- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
 
- 次のコマンドを実行し、エクスポートされた設定を使用して - ocコマンドを正常に実行できることを確認します。- oc whoami - $ oc whoami- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - system:admin - system:admin- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
3.4.16. マシンの証明書署名要求の承認
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 2 つの保留状態の証明書署名要求 (CSR) が生成されます。これらの CSR が承認されていることを確認するか、必要な場合はそれらを承認してください。最初にクライアント要求を承認し、次にサーバー要求を承認する必要があります。
前提条件
- マシンがクラスターに追加されています。
手順
- クラスターがマシンを認識していることを確認します。 - oc get nodes - $ oc get nodes- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.31.3 master-1 Ready master 63m v1.31.3 master-2 Ready master 64m v1.31.3 - NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.31.3 master-1 Ready master 63m v1.31.3 master-2 Ready master 64m v1.31.3- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力には作成したすべてのマシンがリスト表示されます。 注記- 上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。 
- 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に - Pendingまたは- Approvedステータスが表示されていることを確認します。- oc get csr - $ oc get csr- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ... - NAME AGE REQUESTOR CONDITION csr-8b2br 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-8vnps 15m system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - この例では、2 つのマシンがクラスターに参加しています。このリストにはさらに多くの承認された CSR が表示される可能性があります。 
- 追加したマシンの保留中の CSR すべてが - Pendingステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。注記- CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に - machine-approverによって自動的に承認されます。注記- ベアメタルおよび他の user-provisioned infrastructure などのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、 - oc exec、- oc rsh、および- oc logsコマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が- system:nodeまたは- system:adminグループの- node-bootstrapperサービスアカウントによって提出されていることを確認し、ノードの ID を確認します。- それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。 - oc adm certificate approve <csr_name> - $ oc adm certificate approve <csr_name>- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <csr_name>は、現行の CSR のリストからの CSR の名前です。
 
- すべての保留中の CSR を承認するには、以下のコマンドを実行します。 - oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve- $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 注記- 一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。 
 
- クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。 - oc get csr - $ oc get csr- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ... - NAME AGE REQUESTOR CONDITION csr-bfd72 5m26s system:node:ip-10-0-50-126.us-east-2.compute.internal Pending csr-c57lv 5m26s system:node:ip-10-0-95-157.us-east-2.compute.internal Pending ...- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 残りの CSR が承認されず、それらが - Pendingステータスにある場合、クラスターマシンの CSR を承認します。- それらを個別に承認するには、それぞれの有効な CSR に以下のコマンドを実行します。 - oc adm certificate approve <csr_name> - $ oc adm certificate approve <csr_name>- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <csr_name>は、現行の CSR のリストからの CSR の名前です。
 
- すべての保留中の CSR を承認するには、以下のコマンドを実行します。 - oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve- $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが - Readyになります。以下のコマンドを実行して、これを確認します。- oc get nodes - $ oc get nodes- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 注記- サーバー CSR の承認後にマシンが - Readyステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
3.4.16.1. Operator の初期設定
コントロールプレーンの初期化後に、一部の Operator を利用可能にするためにそれらをすぐに設定する必要があります。
前提条件
- コントロールプレーンが初期化されています。
手順
- クラスターコンポーネントがオンラインになることを確認します。 - watch -n5 oc get clusteroperators - $ watch -n5 oc get clusteroperators- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 利用不可の Operator を設定します。
3.4.16.2. インストール時に削除されたイメージレジストリー
						共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed としてブートストラップされます。これにより、openshift-installer がそれらのプラットフォームタイプでのインストールを完了できます。
					
						インストール後に、Image Registry Operator 設定を編集して managementState を Removed から Managed に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
					
3.4.16.3. イメージレジストリーストレージの設定
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
						アップグレード時に Recreate ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
					
3.4.16.3.1. 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}}'- $ oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ブロックストレージデバイスの永続ボリューム (PV) をプロビジョニングし、そのボリュームの永続ボリューム要求 (PVC) を作成します。要求されたブロックボリュームは ReadWriteOnce (RWO) アクセスモードを使用します。 - 以下の内容で - pvc.yamlファイルを作成して VMware vSphere- PersistentVolumeClaimオブジェクトを定義します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次のコマンドを入力して、ファイルから - PersistentVolumeClaimオブジェクトを作成します。- oc create -f pvc.yaml -n openshift-image-registry - $ oc create -f pvc.yaml -n openshift-image-registry- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- 次のコマンドを入力して、正しい PVC を参照するようにレジストリー設定を編集します。 - oc edit config.imageregistry.operator.openshift.io -o yaml - $ oc edit config.imageregistry.operator.openshift.io -o yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - storage: pvc: claim:- storage: pvc: claim:- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- カスタム PVC を作成することにより、image-registry-storagePVC のデフォルトの自動作成のclaimフィールドを空のままにできます。
 
正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。
3.4.17. user-provisioned infrastructure でのインストールの完了
Operator の設定が完了したら、独自に提供するインフラストラクチャーへのクラスターのインストールを完了できます。
前提条件
- コントロールプレーンが初期化されています。
- Operator の初期設定を完了済みです。
手順
- 以下のコマンドを使用して、すべてのクラスターコンポーネントがオンラインであることを確認します。 - watch -n5 oc get clusteroperators - $ watch -n5 oc get clusteroperators- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - あるいは、以下のコマンドを使用すると、すべてのクラスターが利用可能な場合に通知されます。また、このコマンドは認証情報を取得して表示します。 - ./openshift-install --dir <installation_directory> wait-for install-complete - $ ./openshift-install --dir <installation_directory> wait-for install-complete- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <installation_directory>には、インストールファイルを保存したディレクトリーへのパスを指定します。
 - 出力例 - INFO Waiting up to 30m0s for the cluster to initialize... - INFO Waiting up to 30m0s for the cluster to initialize...- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Cluster Version Operator が Kubernetes API サーバーから OpenShift Container Platform クラスターのデプロイを終了するとコマンドは成功します。 重要- 
										インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。
- 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
 
- Kubernetes API サーバーが Pod と通信していることを確認します。 - すべての Pod のリストを表示するには、以下のコマンドを使用します。 - oc get pods --all-namespaces - $ oc get pods --all-namespaces- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 以下のコマンドを使用して、直前のコマンドの出力にリスト表示される Pod のログを表示します。 - oc logs <pod_name> -n <namespace> - $ oc logs <pod_name> -n <namespace>- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- 直前のコマンドの出力にあるように、Pod 名および namespace を指定します。
 - Pod のログが表示される場合、Kubernetes API サーバーはクラスターマシンと通信できます。 
 
- FCP (Fibre Channel Protocol) を使用したインストールでは、マルチパスを有効にするために追加の手順が必要です。インストール時にマルチパスを有効にしないでください。 - 詳細は、インストール後のマシン設定タスク ドキュメントで、「RHCOS でのカーネル引数を使用したマルチパスの有効化」を参照してください。 
クラスターのインストールが完了したら、コンピュートマシンの vSphere への追加 に従って、コンピュートマシンをさらに追加できます。
3.4.18. コントロールプレーンノードの vSphere DRS 非アフィニティールールの設定
vSphere Distributed Resource Scheduler (DRS) 非アフィニティールールを設定して、OpenShift Container Platform コントロールプレーンノードでより高い可用性をサポートできます。非アフィニティールールにより、OpenShift Container Platform コントロールプレーンノードの vSphere 仮想マシンが同じ vSphere ノードにスケジュールされないようにします。
- 以下の情報はコンピュート DRS にのみ適用され、ストレージ DRS には適用されません。
- 
								govcコマンドは、VMware で利用可能なオープンソースのコマンドであり、Red Hat からは利用できません。govcコマンドは、Red Hat サポートではサポートされません。
- 
								govcのダウンロードおよびインストール手順は、VMware ドキュメントの Web サイトを参照してください。
以下のコマンドを実行して anti-affinity ルールを作成します。
コマンドの例
govc cluster.rule.create \ -name openshift4-control-plane-group \ -dc MyDatacenter -cluster MyCluster \ -enable \ -anti-affinity master-0 master-1 master-2
$ govc cluster.rule.create \
  -name openshift4-control-plane-group \
  -dc MyDatacenter -cluster MyCluster \
  -enable \
  -anti-affinity master-0 master-1 master-2ルールを作成すると、コントロールプレーンノードは vSphere によって自動的に移行されるため、同じホストで実行されることはありません。vSphere が新しいルールを調整するまで、しばらく時間がかかる場合があります。コマンドを正しく補完する方法は、以下の手順に示します。
移行は自動的に行われ、移行が完了するまで短い OpenShift API 停止またはレイテンシーが発生する可能性があります。
vSphere DRS の非アフィニティールールは、コントロールプレーンの仮想マシン名が変更された場合や、新しい vSphere クラスターへの移行時に手動で更新する必要があります。
手順
- 以下のコマンドを実行して、既存の DRS 非アフィニティールールを削除します。 - govc cluster.rule.remove \ -name openshift4-control-plane-group \ -dc MyDatacenter -cluster MyCluster - $ govc cluster.rule.remove \ -name openshift4-control-plane-group \ -dc MyDatacenter -cluster MyCluster- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - [13-10-22 09:33:24] Reconfigure /MyDatacenter/host/MyCluster...OK - [13-10-22 09:33:24] Reconfigure /MyDatacenter/host/MyCluster...OK- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 以下のコマンドを実行して、更新された名前でルールを再度作成します。 - govc cluster.rule.create \ -name openshift4-control-plane-group \ -dc MyDatacenter -cluster MyOtherCluster \ -enable \ -anti-affinity master-0 master-1 master-2 - $ govc cluster.rule.create \ -name openshift4-control-plane-group \ -dc MyDatacenter -cluster MyOtherCluster \ -enable \ -anti-affinity master-0 master-1 master-2- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
3.4.19. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.18 では、Telemetry サービスにもインターネットアクセスが必要です。Telemetry サービスは、クラスターの健全性と更新の成功に関するメトリクスを提供するためにデフォルトで実行されます。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
3.4.20. 次のステップ
- クラスターのカスタマイズ
- 必要に応じて、リモートヘルスレポート を作成できます。
- レジストリーをセットアップし、レジストリーストレージを設定 します。
- オプション: vSphere Problem Detector Operator からのイベントを表示 し、クラスターに権限またはストレージ設定の問題があるかどうかを判別します。
- オプション: 暗号化された仮想マシンを作成した場合は、暗号化されたストレージクラスを作成 します。