VMC へのインストール
VMware Cloud への OpenShift Container Platform のインストール
概要
第1章 VMC へのインストールの準備 リンクのコピーリンクがクリップボードにコピーされました!
1.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- クラスターが必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
1.2. VMC に OpenShift Container Platform をインストールする方法の選択 リンクのコピーリンクがクリップボードにコピーされました!
インストーラーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して、VMC に OpenShift Container Platform をインストールすることができます。デフォルトのインストールタイプは、インストーラーでプロビジョニングされるインフラストラクチャーを使用します。この場合、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。OpenShift Container Platform はユーザーが独自にプロビジョニングするインフラストラクチャーにインストールすることもできます。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。
installer-provisioned および user-provisioned インストールプロセスの詳細は、インストールプロセス を参照してください。
ユーザーによってプロビジョニングされるインフラストラクチャーのインストールする手順は、例としてのみ提供されます。独自に提供するインフラストラクチャーでクラスターをインストールするには、VMC プラットフォームおよび OpenShift Container Platform のインストールプロセスについて理解している必要があります。ユーザーによってプロビジョニングされるインフラストラクチャーのインストール手順をガイドとして使用します。他の方法で必要なリソースを作成することもできます。
1.2.1. インストーラーでプロビジョニングされるインフラストラクチャーでの VMC への OpenShift Container Platform のインストール リンクのコピーリンクがクリップボードにコピーされました!
インストーラーでプロビジョニングされるインフラストラクチャーにより、インストールプログラムは OpenShift Container Platform で必要なリソースのプロビジョニングを事前に設定し、自動化することができます。
- クラスターの VMC へのインストール: インストーラーでプロビジョニングされるインフラストラクチャーのインストールをカスタマイズせずに使用して、VMC に OpenShift Container Platform をインストールできます。
- カスタマイズによる VMC へのクラスターのインストール: インストーラーでプロビジョニングされるインフラストラクチャーのデフォルトのカスタマイズオプションのインストールを使用して、VMC に OpenShift Container Platform をインストールできます。
- ネットワークのカスタマイズによる VMC へのクラスターのインストール: ネットワークのカスタマイズを使用して、インストーラーでプロビジョニングされる VMC インフラストラクチャーに OpenShift Container Platform をインストールできます。インストール時に OpenShift Container Platform ネットワーク設定をカスタマイズすることで、クラスターが既存の IP アドレスの割り当てと共存でき、ネットワーク要件に準拠することができます。
- ネットワークが制限された環境での VMC へのクラスターのインストール: インストールリリースコンテンツの内部ミラーを作成して、ネットワークが制限された環境で VMC インフラストラクチャーにクラスターをインストールできます。この方法を使用して、インターネット上に表示されない内部ネットワークに OpenShift Container Platform をデプロイすることができます。
1.2.2. ユーザーによってプロビジョニングされるインフラストラクチャーでの VMC への OpenShift Container Platform のインストール リンクのコピーリンクがクリップボードにコピーされました!
ユーザーによってプロビジョニングされるインフラストラクチャーでは、ユーザーは OpenShift Container Platform に必要なすべてのリソースをプロビジョニングする必要があります。
- ユーザーによってプロビジョニングされるインフラストラクチャーでの VMC へのクラスターのインストール: 独自にプロビジョニングする VMC インフラストラクチャーに OpenShift Container Platform をインストールできます。
- カスタマイズされたネットワークを使用したユーザーによってプロビジョニングされるインフラストラクチャーでの VMC へのクラスターのインストール: カスタマイズされたネットワーク設定オプションを使用して独自にプロビジョニングする VMC インフラストラクチャーに OpenShift Container Platform をインストールできます。
- ネットワークが制限された環境でユーザーによってプロビジョニングされるインフラストラクチャーでの VMC へのクラスターのインストール: ネットワークが制限された環境で独自にプロビジョニングする VMC インフラストラクチャーに、OpenShift Container Platform をインストールできます。
1.3. VMware vSphere インフラストラクチャーの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
仮想環境製品 | 必須バージョン |
---|---|
VMware 仮想ハードウェア | 15 以降 |
vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
VMware vSphere バージョン 7.0 および 7.0 Update 1 へのクラスターのインストールは非推奨になりました。これらのバージョンは引き続き完全にサポートされていますが、vSphere 6.x のすべてのバージョンはサポートされなくなりました。OpenShift Container Platform のバージョン 4.12 には、VMware 仮想ハードウェアバージョン 15 以降が必要です。vSphere 仮想マシンのハードウェアバージョンを更新するには、クラスターの更新 セクションの "Updating hardware on nodes running in vSphere" を参照してください。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat Customer Portal の ハードウェア を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 7.0 Update 2 以降、8.0 Update 1 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
1.4. VMware vSphere CSI Driver Operator の要件 リンクのコピーリンクがクリップボードにコピーされました!
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
1.5. インストーラーでプロビジョニングされるインフラストラクチャーでの VMC への OpenShift Container Platform のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
- インストーラーでプロビジョニングされるインフラストラクチャーを使用した VMC のクラスターのアンインストール: インストーラーでプロビジョニングされるインフラストラクチャーを使用した VMC インフラストラクチャーにデプロイされたクラスターを削除できます。
第2章 クラスターの VMC へのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、クラスターを VMware Cloud (VMC) on AWS にデプロイすることで、VMware vSphere にインストールできます。
OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。
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 ホスト間のアクセスを有効にするために作成されます。
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 のベストプラクティスに基づいてレポートを生成し、クラスター設定および必要なホスト数について推奨します。
2.2. vSphere 要件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- ブロックレジストリーストレージ をプロビジョニングしている。詳細は、永続ストレージについて を参照してください。
ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
2.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
2.4. VMware vSphere インフラストラクチャーの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
仮想環境製品 | 必須バージョン |
---|---|
VMware 仮想ハードウェア | 15 以降 |
vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
VMware vSphere バージョン 7.0 および 7.0 Update 1 へのクラスターのインストールは非推奨になりました。これらのバージョンは引き続き完全にサポートされていますが、vSphere 6.x のすべてのバージョンはサポートされなくなりました。OpenShift Container Platform のバージョン 4.12 には、VMware 仮想ハードウェアバージョン 15 以降が必要です。vSphere 仮想マシンのハードウェアバージョンを更新するには、クラスターの更新 セクションの "Updating hardware on nodes running in vSphere" を参照してください。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat Customer Portal の ハードウェア を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 7.0 Update 2 以降、8.0 Update 1 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
2.5. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。
必要なネットワークポートに関する次の詳細を確認してください。
プロトコル | ポート | 説明 |
---|---|---|
VRRP | 該当なし | keepalived に必要 |
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 サーバーおよびピアポート |
2.6. VMware vSphere CSI Driver Operator の要件 リンクのコピーリンクがクリップボードにコピーされました!
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
2.7. vCenter の要件 リンクのコピーリンクがクリップボードにコピーされました!
インストーラーでプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの権限
OpenShift Container Platform クラスターを vCenter にインストールするには、インストールプログラムには、必要なリソースの読み取りおよび作成権限を持つアカウントへのアクセスが必要になります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。
グローバル管理者権限を持つアカウントを使用できない場合、OpenShift Container Platform クラスターのインストールに必要な権限を付与するためのロールを作成する必要があります。ほとんどの特権は常に必要になりますが、デフォルト動作であるインストールプログラムでの vCenter インスタンスへの OpenShift Container Platform クラスターが含まれるフォルダーのプロビジョニングを実行する場合にのみ必要となる特権もあります。必要な特権を付与するには、指定されたオブジェクトに vSphere ロールを作成するか、これを修正する必要があります。
インストールプログラムが vSphere 仮想マシンフォルダーを作成するために使用される場合には、追加のロールが必要です。
例2.1 vSphere API でのインストールに必要なロールと特権
ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な特権 |
---|---|---|
vSphere vCenter | 常時 |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常時 |
|
vSphere ポートグループ | 常時 |
|
仮想マシンフォルダー | 常時 |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
例2.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な特権 |
---|---|---|
vSphere vCenter | 常時 |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常時 |
|
vSphere ポートグループ | 常時 |
|
仮想マシンフォルダー | 常時 |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
また、ユーザーには一部の ReadOnly
パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例2.3 必要な権限と伝播設定
vSphere オブジェクト | 必要になる場合 | 子への伝播 | 必要な権限 |
---|---|---|---|
vSphere vCenter | 常時 | False | 必要な特権がリスト表示 |
vSphere vCenter Datacenter | 既存のフォルダー | False |
|
インストールプログラムがフォルダーを作成する | True | 上記の必要な特権 | |
vSphere vCenter Cluster | 既存のリソースプール | False |
|
クラスタールートの仮想マシン | True | 必要な特権がリスト表示 | |
vSphere vCenter Datastore | 常時 | False | 上記の必要な特権 |
vSphere Switch | 常時 | False |
|
vSphere ポートグループ | 常時 | False | 上記の必要な特権 |
vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | 上記の必要な特権 |
vSphere vCenter リソースプール | 既存のリソースプール | True | 上記の必要な特権 |
必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
OpenShift Container Platform は通常、コンピュート専用の vMotion をサポートします。これは、一般に、vMotion に関するすべての VMware ベストプラクティスを満たすことを意味します。
コンピュートプレーンノードとコントロールプレーンノードの稼働時間を確保するには、vMotion に関する VMware のベストプラクティスに従い、VMware のアンチアフィニティールールを使用して、メンテナンスまたはハードウェアの問題時の OpenShift Container Platform の可用性を向上させます。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。Pod で vSphere ボリュームを使用している場合、手動または Storage vMotion を介してデータストア間で VM を移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生し、データ損失が発生する可能性があります。
- OpenShift Container Platform は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。
クラスターリソース
installer-provisioned infrastructure を使用する 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 アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに Dynamic Host Configuration Protocol (DHCP) を使用して、クラスター内のマシンに永続的な IP アドレスを設定するように DHCP サーバーを設定できます。DHCP リースでは、デフォルトゲートウェイを使用するように DHCP を設定する必要があります。
静的 IP アドレスを使用してノードをプロビジョニングする場合は、ネットワークに DHCP を使用する必要はありません。
制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。
クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。
さらに、OpenShift Container Platform クラスターをインストールする前に以下のネットワークリソースを作成する必要があります。
必要な 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 レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
2.8. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
、ppc64le
、およびs390x
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
2.9. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
Linux を実行するマシン (例: 500 MB のローカルディスク領域のある Red Hat Enterprise Linux 8) が必要です。
重要macOS 上でインストールプログラムを実行しようとすると、
golang
コンパイラーに関連する既知の問題により、OpenShift Container Platform クラスターのインストールに失敗します。この問題の詳細は、OpenShift Container Platform 4.12 リリースノート の「既知の問題」セクションを参照してください。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
2.10. 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 証明書が含まれる圧縮ファイルを展開します。圧縮ファイルの内容は、以下のファイル構造のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
cp certs/lin/* /etc/pki/ca-trust/source/anchors
# cp certs/lin/* /etc/pki/ca-trust/source/anchors
Copy to Clipboard Copied! Toggle word wrap Toggle overflow システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
update-ca-trust extract
# update-ca-trust extract
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.11. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
OpenShift Container Platform デプロイメント用に VMC 環境を設定したとき、VMC 環境に併設された bastion 管理ホストの OpenShift Container Platform インストールプログラムを使用します。インストールプログラムおよびコントロールプレーンは、OpenShift Container Platform クラスターに必要なリソースのデプロイおよび管理プロセスを自動化します。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してください。
-
ディレクトリーに
プロンプト時に値を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして vsphere を選択します。
- vCenter インスタンスの名前を指定します。
クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。
インストールプログラムは vCenter インスタンスに接続します。
重要Active Directory (AD) が統合された一部の VMware vCenter Single Sign-On (SSO) 環境では、主に
<domain>\
構造を必要とする従来のログイン方法を使用する必要がある可能性があります。vCenter アカウントの権限チェックが必ず適切に完了するようにするには、
<username>@<full_qualified_domainname>
などのユーザープリンシパル名 (UPN) ログイン方法の使用を検討してください。- 接続する 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
コマンドを使用します。+
注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.log
にも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
2.12. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
C:\> oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.13. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
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
2.14. レジストリーストレージの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。
2.14.1. インストール時に削除されたイメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、Image Registry Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
2.14.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
2.14.2.1. VMware vSphere のレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- VMware vSphere 上のクラスター。
Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。
重要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
$ oc get pod -n openshift-image-registry -l docker-registry=default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resourses found in openshift-image-registry namespace
No resourses found in openshift-image-registry namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io
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
image-registry-storage
永続ボリューム要求 (PVC) の自動作成を許可するには、claim
フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
clusteroperator
ステータスを確認します。oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.14.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}}'
$ 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 vSpherePersistentVolumeClaim
オブジェクトを定義します。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-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。
2.15. VMware vSphere ボリュームのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップしたり、スナップショットからボリュームを復元したりすることはできません。詳細は、スナップショットの制限 を参照してください。
手順
永続ボリュームのバックアップを作成すには、以下を実行します。
- 永続ボリュームを使用しているアプリケーションを停止します。
- 永続ボリュームのクローンを作成します。
- アプリケーションを再起動します。
- クローンを作成したボリュームのバックアップを作成します。
- クローンを作成したボリュームを削除します。
2.16. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
2.17. 外部ロードバランサー用のサービス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。
このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。
Red Hat は、外部ロードバランサーに対して次のサービスをサポートしています。
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
外部ロードバランサーに対して、これらのサービスの 1 つまたはすべてを設定するように選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。
図2.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例
図2.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例
図2.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例
外部ロードバランサーでは、次の設定オプションがサポートされています。
- ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。
サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。
/27
や/28
などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。ヒントマシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。
OpenShift Container Platform クラスターの外部ロードバランサーを設定する前に、以下の情報を考慮してください。
- フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能については、ベンダーのドキュメントを確認してください。
バックエンド IP アドレスの場合、OpenShift Container Platform コントロールプレーンノードの IP アドレスが、外部ロードバランサーの存続期間中に変更されないようにください。次のいずれかのアクションを実行すると、これを実現できます。
- 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
- ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
- Ingress Controller バックエンドサービスの外部ロードバランサーで、Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。
2.17.1. 外部ロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーを設定する前に、「外部ロードバランサー用のサービス」セクションを必ず確認してください。
外部ロードバランサー用に設定するサービスに適用される次の前提条件を確認してください。
クラスター上で動作する MetalLB は、外部ロードバランサーとして機能します。
OpenShift API の前提条件
- フロントエンド IP アドレスを定義している。
TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。
- ポート 6443 が OpenShift API サービスにアクセスできる。
- ポート 22623 が Ignition 起動設定をノードに提供できる。
- フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
- フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
- ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。
Ingress Controller の前提条件
- フロントエンド IP アドレスを定義している。
- TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
- フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
- フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
- ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。
ヘルスチェック URL 仕様の前提条件
ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できます。OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。
次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。
Kubernetes API ヘルスチェック仕様の例
Path: HTTPS:6443/readyz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Machine Config API ヘルスチェック仕様の例
Path: HTTPS:22623/healthz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Ingress Controller のヘルスチェック仕様の例
Path: HTTP:1936/healthz/ready Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 5 Interval: 10
Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
手順
HAProxy Ingress Controller を設定して、ポート 6443、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。
HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow curl
CLI コマンドを使用して、外部ロードバランサーとそのリソースが動作していることを確認します。次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。
curl https://<loadbalancer_ip_address>:6443/version --insecure
$ curl https://<loadbalancer_ip_address>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。
curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
外部ロードバランサーのフロントエンド IP アドレスをターゲットにするように、クラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。
変更された DNS レコードの例
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。
curl
CLI コマンドを使用して、外部ロードバランサーと DNS レコード設定が動作していることを確認します。次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。
curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。
curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。
curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。
curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.18. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- レジストリーを セットアップし、レジストリーストレージを設定し ます。
- オプション: vSphere Problem Detector Operator からのイベントを表示 し、クラスターにパーミッションまたはストレージ設定の問題があるかどうかを判別します。
第3章 カスタマイズによる VMC へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、クラスターを VMware Cloud (VMC) on AWS にデプロイすることで、インストーラーでプロビジョニングされるインフラストラクチャーを使用して、VMware vSphere インスタンスにクラスターをインストールできます。
OpenShift Container Platform デプロイメント用に VMC 環境を設定した後に、VMC 環境に併設された bastion 管理ホストの OpenShift Container Platform インストールプログラムを使用します。インストールプログラムおよびコントロールプレーンは、OpenShift Container Platform クラスターに必要なリソースのデプロイおよび管理プロセスを自動化します。
OpenShift Container Platform インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。
3.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 ホスト間のアクセスを有効にするために作成されます。
3.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 のベストプラクティスに基づいてレポートを生成し、クラスター設定および必要なホスト数について推奨します。
3.2. vSphere 要件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- ブロックレジストリーストレージ をプロビジョニングしている。詳細は、永続ストレージについて を 参照 してください。
ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
3.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
3.4. VMware vSphere インフラストラクチャーの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
仮想環境製品 | 必須バージョン |
---|---|
VMware 仮想ハードウェア | 15 以降 |
vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
VMware vSphere バージョン 7.0 および 7.0 Update 1 へのクラスターのインストールは非推奨になりました。これらのバージョンは引き続き完全にサポートされていますが、vSphere 6.x のすべてのバージョンはサポートされなくなりました。OpenShift Container Platform のバージョン 4.12 には、VMware 仮想ハードウェアバージョン 15 以降が必要です。vSphere 仮想マシンのハードウェアバージョンを更新するには、クラスターの更新 セクションの "Updating hardware on nodes running in vSphere" を参照してください。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat Customer Portal の ハードウェア を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 7.0 Update 2 以降、8.0 Update 1 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
3.5. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。
必要なネットワークポートに関する次の詳細を確認してください。
プロトコル | ポート | 説明 |
---|---|---|
VRRP | 該当なし | keepalived に必要 |
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 サーバーおよびピアポート |
3.6. VMware vSphere CSI Driver Operator の要件 リンクのコピーリンクがクリップボードにコピーされました!
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
3.7. vCenter の要件 リンクのコピーリンクがクリップボードにコピーされました!
インストーラーでプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの特権
OpenShift Container Platform クラスターを vCenter にインストールするには、インストールプログラムが、必要なリソースの読み取りと作成の特権を持つアカウントにアクセスできる必要があります。グローバル管理者特権を持つアカウントを使用するのが、必要なすべての権限にアクセスする最も簡単な方法です。
グローバル管理者特権を持つアカウントを使用できない場合は、OpenShift Container Platform クラスターのインストールに必要な特権を付与するロールを作成する必要があります。ほとんどの特権は常に必要になりますが、デフォルト動作であるインストールプログラムでの vCenter インスタンスへの OpenShift Container Platform クラスターが含まれるフォルダーのプロビジョニングを実行する場合にのみ必要となる特権もあります。必要な特権を付与するには、指定されたオブジェクトに vSphere ロールを作成するか、これを修正する必要があります。
インストールプログラムが vSphere 仮想マシンフォルダーを作成するために使用される場合には、追加のロールが必要です。
例3.1 vSphere API でのインストールに必要なロールと特権
ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な特権 |
---|---|---|
vSphere vCenter | 常時 |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常時 |
|
vSphere ポートグループ | 常時 |
|
仮想マシンフォルダー | 常時 |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
例3.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な特権 |
---|---|---|
vSphere vCenter | 常時 |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常時 |
|
vSphere ポートグループ | 常時 |
|
仮想マシンフォルダー | 常時 |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
また、ユーザーには一部の ReadOnly
パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例3.3 必要な権限と伝播設定
vSphere オブジェクト | 必要になる場合 | 子への伝播 | 必要な権限 |
---|---|---|---|
vSphere vCenter | 常時 | False | 必要な特権がリスト表示 |
vSphere vCenter Datacenter | 既存のフォルダー | False |
|
インストールプログラムがフォルダーを作成する | True | リスト表示された必要な特権 | |
vSphere vCenter Cluster | 既存のリソースプール | False |
|
クラスタールートの仮想マシン | True | 必要な特権がリスト表示 | |
vSphere vCenter Datastore | 常時 | False | リスト表示された必要な特権 |
vSphere Switch | 常に | False |
|
vSphere ポートグループ | 常に | False | リスト表示された必要な特権 |
vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | リスト表示された必要な特権 |
vSphere vCenter リソースプール | 既存のリソースプール | True | リスト表示された必要な特権 |
必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
OpenShift Container Platform は通常、コンピュート専用の vMotion をサポートします。これは、一般に、vMotion に関するすべての VMware ベストプラクティスを満たすことを意味します。
コンピュートプレーンノードとコントロールプレーンノードの稼働時間を確保するには、vMotion に関する VMware のベストプラクティスに従い、VMware のアンチアフィニティールールを使用して、メンテナンスまたはハードウェアの問題時の OpenShift Container Platform の可用性を向上させます。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。Pod で vSphere ボリュームを使用している場合、手動または Storage vMotion を介してデータストア間で VM を移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生し、データ損失が発生する可能性があります。
- OpenShift Container Platform は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。
クラスターリソース
installer-provisioned infrastructure を使用する 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 アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに Dynamic Host Configuration Protocol (DHCP) を使用して、クラスター内のマシンに永続的な IP アドレスを設定するように DHCP サーバーを設定できます。DHCP リースでは、デフォルトゲートウェイを使用するように DHCP を設定する必要があります。
静的 IP アドレスを使用してノードをプロビジョニングする場合は、ネットワークに DHCP を使用する必要はありません。
制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。
クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。
さらに、OpenShift Container Platform クラスターをインストールする前に以下のネットワークリソースを作成する必要があります。
必要な 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 レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
3.8. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
、ppc64le
、およびs390x
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
3.9. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
Linux を実行するマシン (例: 500 MB のローカルディスク領域のある Red Hat Enterprise Linux 8) が必要です。
重要macOS 上でインストールプログラムを実行しようとすると、
golang
コンパイラーに関連する既知の問題により、OpenShift Container Platform クラスターのインストールに失敗します。この問題の詳細は、OpenShift Container Platform 4.12 リリースノート の「既知の問題」セクションを参照してください。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
3.10. 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 証明書が含まれる圧縮ファイルを展開します。圧縮ファイルの内容は、以下のファイル構造のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
cp certs/lin/* /etc/pki/ca-trust/source/anchors
# cp certs/lin/* /etc/pki/ca-trust/source/anchors
Copy to Clipboard Copied! Toggle word wrap Toggle overflow システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
update-ca-trust extract
# update-ca-trust extract
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.11. VMware vSphere のリージョンとゾーンの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
デフォルトのインストール設定では、クラスターが単一の 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.12. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして vsphere を選択します。
- vCenter インスタンスの名前を指定します。
クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。
インストールプログラムは vCenter インスタンスに接続します。
- 接続する vCenter インスタンスのデータセンターを選択します。
- 使用するデフォルトの vCenter データストアを選択します。
- OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
- 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
- コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
- クラスター Ingress に設定した仮想 IP アドレスを入力します。
- ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
- クラスターの記述名を入力します。入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
3.12.1. インストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
3.12.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
|
| 文字列 |
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
Kubernetes リソース | オブジェクト |
|
クラスターの名前。クラスターの DNS レコードはすべて |
小文字いちぶハイフン ( |
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
|
3.12.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
パラメーター | 説明 | 値 |
---|---|---|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
3.12.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
|
オプションの機能のセットを、 | 文字列配列 |
| コンピュートノードを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
| コントロールプレーンを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時マルチスレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
| 文字列 |
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
このパラメーターを 重要
フィールドの値が |
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
3.12.1.4. 追加の VMware vSphere 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
追加の VMware vSphere 設定パラメーターは以下の表で説明されています。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
| vCenter サーバーの完全修飾ホスト名または IP アドレス。 | String |
| vCenter インスタンスに接続するために使用するユーザー名。このユーザーには、vSphere での 静的または動的な永続ボリュームのプロビジョニング に必要なロールと特権が少なくとも必要です。 | String |
| vCenter ユーザー名のパスワード。 | String |
| vCenter インスタンスで使用するデータセンターの名前。 | String |
| ボリュームのプロビジョニングに使用するデフォルトデータストアの名前。 | String |
| オプション: インストールプログラムが仮想マシンを作成する既存のフォルダーの絶対パス。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられたフォルダーを作成します。 |
文字列 (例: |
|
オプション: インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス。値を指定しない場合、インストールプログラムは |
文字列 (例: |
| 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワーク。 | String |
| OpenShift Container Platform クラスターをインストールする vCenter クラスター。 | String |
| コントロールプレーン API のアクセス用に設定した仮想 IP (VIP) アドレス。 注記
OpenShift Container Platform 4.12 以降では、 |
IP アドレス (例: |
| クラスター Ingress に設定した仮想 IP (VIP) アドレス。 注記
OpenShift Container Platform 4.12 以降では、 |
IP アドレス (例: |
[disktype] | オプション: ディスクプロビジョニング方法。この値が設定されていない場合、デフォルトで vSphere のデフォルトのストレージポリシーに設定されます。 |
有効な値は、 |
3.12.1.5. オプションの VMware vSphere マシンプール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションの VMware vSphere マシンプール設定パラメーターは、以下の表で説明されています。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
| インストールプログラムが RHCOS イメージをダウンロードする場所。ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。 |
HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。例: |
| ディスクのサイズ (ギガバイト単位)。 | Integer |
|
仮想マシンを割り当てる仮想プロセッサーコアの合計数 | Integer |
|
仮想マシンのソケットあたりのコア数。 | Integer |
| 仮想マシンのメモリーのサイズ (メガバイト単位)。 | Integer |
3.12.1.6. リージョンおよびゾーンの有効化設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
リージョンおよびゾーンの有効化機能を使用するには、インストールファイルでリージョンおよびゾーンの有効化パラメーターを指定する必要があります。
install-config.yaml
ファイルを変更してリージョンおよびゾーンの有効化環境を設定する前に、「VMware vSphere のリージョンおよびゾーンの有効化」および「VMware vCenter のリージョンおよびゾーン」の設定セクションをお読みください。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
|
リージョンとゾーン間の関係を確立します。障害ドメインは、 | String |
| 障害ドメインの名前。マシンプールは、この名前を使用して障害ドメインを参照します。 | String |
| クライアントが障害ドメインリソースにアクセスできるように、VMware vCenter Server の完全修飾ホスト名または IP アドレスを指定します。server ロールを vSphere vCenter サーバーの場所に適用する必要があります。 | String |
|
リージョンを定義するには、 | String |
|
ゾーンを定義するには、 | String |
|
このパラメーターは、障害ドメインに関連付けられたコンピューティングクラスターを定義します。設定でこのパラメーターを定義しない場合、コンピューティングクラスターは | String |
|
インストールプログラムが仮想マシンを作成する既存のフォルダーの絶対パス。設定でこのパラメーターを定義しない場合、フォルダーは | String |
|
OpenShift Container Platform 仮想マシン (VM) が動作するデータセンターを定義します。設定でこのパラメーターを定義しない場合、データセンターはデフォルトで | String |
| 障害ドメインの仮想マシンファイルを保存する vSphere データストアへのパスを指定します。datastore ロールを vSphere vCenter データストアの場所に適用する必要があります。 | String |
|
設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリスト表示します。設定でこのパラメーターを定義しない場合、ネットワークは | String |
|
オプション: このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例: | String |
3.12.2. インストーラーでプロビジョニングされる VMware vSphere クラスターの install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 3 5
- オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
- 6
- DNS レコードに指定したクラスター名。
- 7
- オプション: マシン作成用の既存のリソースプールを提供します。値を指定しない場合、インストールプログラムは vSphere クラスターのルートリソースプールを使用します。
- 8
- vSphere ディスクのプロビジョニング方法。
- 9
- OpenShift Container Platform クラスターをインストールする vSphere クラスター。
OpenShift Container Platform 4.12 以降では、apiVIP
および ingressVIP
設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs
および ingressVIPs
設定に値を入力します。
3.12.3. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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-config
namespace に生成します。次に 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.12.4. VMware vCenter のリージョンとゾーンの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
この例では、govc
コマンドを使用します。govc
コマンドは、VMware から入手できるオープンソースコマンドです。govc
コマンドは Red Hat からは入手できません。Red Hat サポートは govc
コマンドを保守しません。govc
のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイト を参照してください。
前提条件
既存の
install-config.yaml
インストール設定ファイルがあります。重要VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
注記VMware vSphere プラットフォームに OpenShift Container Platform クラスターをインストールした後は、障害ドメインを変更できません。クラスターのインストール後に、障害ドメインを追加できます。
手順
次の
govc
コマンドラインツールコマンドを入力して、openshift-region
およびopenshift-zone
vCenter タグカテゴリーを作成します。重要openshift-region
およびopenshift-zone
vCenter タグカテゴリーに異なる名前を指定すると、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 クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。
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 クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。
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> /<datacenter_1>
$ govc tags.attach -c <region_tag_category> <region_tag_1> /<datacenter_1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。
govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
$ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。
vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml
ファイル
- 1
- VMware vSphere リージョンおよびゾーン有効化機能を使用できるように、このパラメーターの値として
TechPreviewNoUpgrade
を設定するように定義する必要があります。 - 2 3
- vCenter クラスターを指定するためのオプションのパラメーター。ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。このパラメーターを定義しない場合、ノードは定義されているすべての障害ドメインに分散されます。 - 4 5 6 7 8 9 10 11
- デフォルトの vCenter トポロジー。インストールプログラムは、このトポロジー情報を使用してブートストラップノードをデプロイメントします。さらに、トポロジーは vSphere 永続ボリュームのデフォルトデータストアを定義します。
- 12
- リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 13
- 障害ドメインの名前を定義します。各障害ドメインは
zones
パラメーターで参照され、マシンプールの範囲が障害ドメインに設定されます。 - 14
- リージョンを定義するには、
openshift-region
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 15
- ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 16
- 障害ドメインに関連付けられた vCenter リソースを指定します。
- 17
- 障害ドメインに関連付けられた vSphere データセンターを定義するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 18
- 障害ドメインに関連付けられた計算クラスターの絶対ファイルパスを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 19
- インストーラーがプロビジョニングするインフラストラクチャーのオプションのパラメーター。このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例:
/<datacenter_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>
)。値を指定しない場合、リソースはクラスターのルート/example_datacenter/host/example_cluster/Resources
にインストールされます。 - 20
- 設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリストするオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 21
- ボリュームのプロビジョニングに使用するデータストアを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
3.13. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
OpenShift Container Platform デプロイメント用に VMC 環境を設定したとき、VMC 環境に併設された bastion 管理ホストの OpenShift Container Platform インストールプログラムを使用します。インストールプログラムおよびコントロールプレーンは、OpenShift Container Platform クラスターに必要なリソースのデプロイおよび管理プロセスを自動化します。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要VMC 環境でホストされる bastion からの
openshift-install
コマンドを使用します。注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.log
にも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
3.14. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
C:\> oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.15. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
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.16. レジストリーストレージの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。
3.16.1. インストール時に削除されたイメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、Image Registry Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
3.16.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
3.16.2.1. VMware vSphere のレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- VMware vSphere 上のクラスター。
Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。
重要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
$ oc get pod -n openshift-image-registry -l docker-registry=default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resourses found in openshift-image-registry namespace
No resourses found in openshift-image-registry namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io
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
image-registry-storage
永続ボリューム要求 (PVC) の自動作成を許可するには、claim
フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
clusteroperator
ステータスを確認します。oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.16.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}}'
$ 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 vSpherePersistentVolumeClaim
オブジェクトを定義します。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-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。
3.17. VMware vSphere ボリュームのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップしたり、スナップショットからボリュームを復元したりすることはできません。詳細は、スナップショットの制限 を参照してください。
手順
永続ボリュームのバックアップを作成すには、以下を実行します。
- 永続ボリュームを使用しているアプリケーションを停止します。
- 永続ボリュームのクローンを作成します。
- アプリケーションを再起動します。
- クローンを作成したボリュームのバックアップを作成します。
- クローンを作成したボリュームを削除します。
3.18. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
3.19. 外部ロードバランサー用のサービス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。
このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。
Red Hat は、外部ロードバランサーに対して次のサービスをサポートしています。
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
外部ロードバランサーに対して、これらのサービスの 1 つまたはすべてを設定するように選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。
図3.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例
図3.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例
図3.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例
外部ロードバランサーでは、次の設定オプションがサポートされています。
- ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。
サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。
/27
や/28
などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。ヒントマシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。
OpenShift Container Platform クラスターの外部ロードバランサーを設定する前に、以下の情報を考慮してください。
- フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能については、ベンダーのドキュメントを確認してください。
バックエンド IP アドレスの場合、OpenShift Container Platform コントロールプレーンノードの IP アドレスが、外部ロードバランサーの存続期間中に変更されないようにください。次のいずれかのアクションを実行すると、これを実現できます。
- 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
- ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
- Ingress Controller バックエンドサービスの外部ロードバランサーで、Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。
3.19.1. 外部ロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーを設定する前に、「外部ロードバランサー用のサービス」セクションを必ず確認してください。
外部ロードバランサー用に設定するサービスに適用される次の前提条件を確認してください。
クラスター上で動作する MetalLB は、外部ロードバランサーとして機能します。
OpenShift API の前提条件
- フロントエンド IP アドレスを定義している。
TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。
- ポート 6443 が OpenShift API サービスにアクセスできる。
- ポート 22623 が Ignition 起動設定をノードに提供できる。
- フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
- フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
- ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。
Ingress Controller の前提条件
- フロントエンド IP アドレスを定義している。
- TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
- フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
- フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
- ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。
ヘルスチェック URL 仕様の前提条件
ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できまうs.OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。
次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。
Kubernetes API ヘルスチェック仕様の例
Path: HTTPS:6443/readyz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Machine Config API ヘルスチェック仕様の例
Path: HTTPS:22623/healthz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Ingress Controller のヘルスチェック仕様の例
Path: HTTP:1936/healthz/ready Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 5 Interval: 10
Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
手順
HAProxy Ingress Controller を設定して、ポート 6443、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。
HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow curl
CLI コマンドを使用して、外部ロードバランサーとそのリソースが動作していることを確認します。次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。
curl https://<loadbalancer_ip_address>:6443/version --insecure
$ curl https://<loadbalancer_ip_address>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。
curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
外部ロードバランサーのフロントエンド IP アドレスをターゲットにするように、クラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。
変更された DNS レコードの例
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。
curl
CLI コマンドを使用して、外部ロードバランサーと DNS レコード設定が動作していることを確認します。次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。
curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。
curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。
curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。
curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.20. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターのカスタマイズ
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- レジストリーをセットアップし、レジストリーストレージを設定 します。
- オプション: vSphere Problem Detector Operator からのイベントを表示 し、クラスターにパーミッションまたはストレージ設定の問題があるかどうかを判別します。
第4章 ネットワークのカスタマイズによる VMC へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、クラスターを VMware Cloud (VMC) on AWS にデプロイすることで、カスタマイズされるネットワーク設定オプションと共にインストーラーでプロビジョニングされるインフラストラクチャーを使用して、VMware vSphere インスタンスにクラスターをインストールできます。
OpenShift Container Platform デプロイメント用に VMC 環境を設定した後に、VMC 環境に併設された bastion 管理ホストの OpenShift Container Platform インストールプログラムを使用します。インストールプログラムおよびコントロールプレーンは、OpenShift Container Platform クラスターに必要なリソースのデプロイおよび管理プロセスを自動化します。
OpenShift Container Platform ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の VXLAN 設定と統合できます。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy
設定パラメーターのみになります。
OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。
4.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 ホスト間のアクセスを有効にするために作成されます。
4.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 のベストプラクティスに基づいてレポートを生成し、クラスター設定および必要なホスト数について推奨します。
4.2. vSphere 要件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- ブロックレジストリーストレージ をプロビジョニングしている。詳細は、永続ストレージについて を参照してください。
ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
4.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
4.4. VMware vSphere インフラストラクチャーの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
仮想環境製品 | 必須バージョン |
---|---|
VMware 仮想ハードウェア | 15 以降 |
vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
VMware vSphere バージョン 7.0 および 7.0 Update 1 へのクラスターのインストールは非推奨になりました。これらのバージョンは引き続き完全にサポートされていますが、vSphere 6.x のすべてのバージョンはサポートされなくなりました。OpenShift Container Platform のバージョン 4.12 には、VMware 仮想ハードウェアバージョン 15 以降が必要です。vSphere 仮想マシンのハードウェアバージョンを更新するには、クラスターの更新 セクションの "Updating hardware on nodes running in vSphere" を参照してください。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat Customer Portal の ハードウェア を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 7.0 Update 2 以降、8.0 Update 1 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
4.5. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。
必要なネットワークポートに関する次の詳細を確認してください。
プロトコル | ポート | 説明 |
---|---|---|
VRRP | 該当なし | keepalived に必要 |
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 サーバーおよびピアポート |
4.6. VMware vSphere CSI Driver Operator の要件 リンクのコピーリンクがクリップボードにコピーされました!
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
4.7. vCenter の要件 リンクのコピーリンクがクリップボードにコピーされました!
インストーラーでプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの権限
OpenShift Container Platform クラスターを vCenter にインストールするには、インストールプログラムには、必要なリソースの読み取りおよび作成権限を持つアカウントへのアクセスが必要になります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。
グローバル管理者権限を持つアカウントを使用できない場合、OpenShift Container Platform クラスターのインストールに必要な権限を付与するためのロールを作成する必要があります。ほとんどの特権は常に必要になりますが、デフォルト動作であるインストールプログラムでの vCenter インスタンスへの OpenShift Container Platform クラスターが含まれるフォルダーのプロビジョニングを実行する場合にのみ必要となる特権もあります。必要な特権を付与するには、指定されたオブジェクトに vSphere ロールを作成するか、これを修正する必要があります。
インストールプログラムが vSphere 仮想マシンフォルダーを作成するために使用される場合には、追加のロールが必要です。
例4.1 vSphere API でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常時 |
|
vSphere ポートグループ | 常時 |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
例4.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常時 |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
また、ユーザーには一部の ReadOnly
パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例4.3 必要なパーミッションおよび伝播の設定
vSphere オブジェクト | 必要になる場合 | 子への伝播 | パーミッションが必要 |
---|---|---|---|
vSphere vCenter | 常に | False | 必要な特権がリスト表示 |
vSphere vCenter Datacenter | 既存のフォルダー | False |
|
インストールプログラムがフォルダーを作成する | True | リスト表示された必要な特権 | |
vSphere vCenter Cluster | 既存のリソースプール | False |
|
クラスタールートの仮想マシン | True | 必要な特権がリスト表示 | |
vSphere vCenter Datastore | 常時 | False | リスト表示された必要な特権 |
vSphere Switch | 常に | False |
|
vSphere ポートグループ | 常に | False | リスト表示された必要な特権 |
vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | リスト表示された必要な特権 |
vSphere vCenter リソースプール | 既存のリソースプール | True | リスト表示された必要な特権 |
必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
OpenShift Container Platform は通常、コンピュート専用の vMotion をサポートします。これは、一般に、vMotion に関するすべての VMware ベストプラクティスを満たすことを意味します。
コンピュートプレーンノードとコントロールプレーンノードの稼働時間を確保するには、vMotion に関する VMware のベストプラクティスに従い、VMware のアンチアフィニティールールを使用して、メンテナンスまたはハードウェアの問題時の OpenShift Container Platform の可用性を向上させます。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。Pod で vSphere ボリュームを使用している場合、手動または Storage vMotion を介してデータストア間で VM を移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生し、データ損失が発生する可能性があります。
- OpenShift Container Platform は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。
クラスターリソース
installer-provisioned infrastructure を使用する 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 アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに Dynamic Host Configuration Protocol (DHCP) を使用して、クラスター内のマシンに永続的な IP アドレスを設定するように DHCP サーバーを設定できます。DHCP リースでは、デフォルトゲートウェイを使用するように DHCP を設定する必要があります。
静的 IP アドレスを使用してノードをプロビジョニングする場合は、ネットワークに DHCP を使用する必要はありません。
制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。
クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。
さらに、OpenShift Container Platform クラスターをインストールする前に以下のネットワークリソースを作成する必要があります。
必要な 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 レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
4.8. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
、ppc64le
、およびs390x
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
4.9. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
Linux を実行するマシン (例: 500 MB のローカルディスク領域のある Red Hat Enterprise Linux 8) が必要です。
重要macOS 上でインストールプログラムを実行しようとすると、
golang
コンパイラーに関連する既知の問題により、OpenShift Container Platform クラスターのインストールに失敗します。この問題の詳細は、OpenShift Container Platform 4.12 リリースノート の「既知の問題」セクションを参照してください。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
4.10. 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 証明書が含まれる圧縮ファイルを展開します。圧縮ファイルの内容は、以下のファイル構造のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
cp certs/lin/* /etc/pki/ca-trust/source/anchors
# cp certs/lin/* /etc/pki/ca-trust/source/anchors
Copy to Clipboard Copied! Toggle word wrap Toggle overflow システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
update-ca-trust extract
# update-ca-trust extract
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.11. VMware vSphere のリージョンとゾーンの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
デフォルトのインストール設定では、クラスターが単一の 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 |
4.12. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして vsphere を選択します。
- vCenter インスタンスの名前を指定します。
クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。
インストールプログラムは vCenter インスタンスに接続します。
- 接続する vCenter インスタンスのデータセンターを選択します。
- 使用するデフォルトの vCenter データストアを選択します。
- OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
- 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
- コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
- クラスター Ingress に設定した仮想 IP アドレスを入力します。
- ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
- クラスターの記述名を入力します。入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
4.12.1. インストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
4.12.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
|
| 文字列 |
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
Kubernetes リソース | オブジェクト |
|
クラスターの名前。クラスターの DNS レコードはすべて |
小文字いちぶハイフン ( |
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
|
4.12.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
パラメーター | 説明 | 値 |
---|---|---|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
4.12.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
|
オプションの機能のセットを、 | 文字列配列 |
| コンピュートノードを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
| コントロールプレーンを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
| 文字列 |
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
このパラメーターを 重要
フィールドの値が |
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
4.12.1.4. 追加の VMware vSphere 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
追加の VMware vSphere 設定パラメーターは以下の表で説明されています。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
| vCenter サーバーの完全修飾ホスト名または IP アドレス。 | String |
| vCenter インスタンスに接続するために使用するユーザー名。このユーザーには、少なくとも vSphere の 静的または動的な永続ボリュームのプロビジョニング に必要なロールおよび権限がなければなりません。 | String |
| vCenter ユーザー名のパスワード。 | String |
| vCenter インスタンスで使用するデータセンターの名前。 | String |
| ボリュームのプロビジョニングに使用するデフォルトデータストアの名前。 | String |
| オプション: インストールプログラムが仮想マシンを作成する既存のフォルダーの絶対パス。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられたフォルダーを作成します。 |
文字列 (例: |
|
オプション: インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス。値を指定しない場合、インストールプログラムは |
文字列 (例: |
| 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワーク。 | String |
| OpenShift Container Platform クラスターをインストールする vCenter クラスター。 | String |
| コントロールプレーン API のアクセス用に設定した仮想 IP (VIP) アドレス。 注記
OpenShift Container Platform 4.12 以降では、 |
IP アドレス (例: |
| クラスター Ingress に設定した仮想 IP (VIP) アドレス。 注記
OpenShift Container Platform 4.12 以降では、 |
IP アドレス (例: |
[disktype] | オプション: ディスクプロビジョニング方法。この値が設定されていない場合、デフォルトで vSphere のデフォルトのストレージポリシーに設定されます。 |
有効な値は、 |
4.12.1.5. オプションの VMware vSphere マシンプール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションの VMware vSphere マシンプール設定パラメーターは、以下の表で説明されています。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
| インストールプログラムが RHCOS イメージをダウンロードする場所。ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。 |
HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。例: |
| ディスクのサイズ (ギガバイト単位)。 | Integer |
|
仮想マシンを割り当てる仮想プロセッサーコアの合計数 | Integer |
|
仮想マシンのソケットあたりのコア数。 | Integer |
| 仮想マシンのメモリーのサイズ (メガバイト単位)。 | Integer |
4.12.1.6. リージョンおよびゾーンの有効化設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
リージョンおよびゾーンの有効化機能を使用するには、インストールファイルでリージョンおよびゾーンの有効化パラメーターを指定する必要があります。
install-config.yaml
ファイルを変更してリージョンおよびゾーンの有効化環境を設定する前に、「VMware vSphere のリージョンおよびゾーンの有効化」および「VMware vCenter のリージョンおよびゾーン」の設定セクションをお読みください。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
|
リージョンとゾーン間の関係を確立します。障害ドメインは、 | String |
| 障害ドメインの名前。マシンプールは、この名前を使用して障害ドメインを参照します。 | String |
| クライアントが障害ドメインリソースにアクセスできるように、VMware vCenter Server の完全修飾ホスト名または IP アドレスを指定します。server ロールを vSphere vCenter サーバーの場所に適用する必要があります。 | String |
|
リージョンを定義するには、 | String |
|
ゾーンを定義するには、 | String |
|
このパラメーターは、障害ドメインに関連付けられたコンピューティングクラスターを定義します。設定でこのパラメーターを定義しない場合、コンピューティングクラスターは | String |
|
インストールプログラムが仮想マシンを作成する既存のフォルダーの絶対パス。設定でこのパラメーターを定義しない場合、フォルダーは | String |
|
OpenShift Container Platform 仮想マシン (VM) が動作するデータセンターを定義します。設定でこのパラメーターを定義しない場合、データセンターはデフォルトで | String |
| 障害ドメインの仮想マシンファイルを保存する vSphere データストアへのパスを指定します。datastore ロールを vSphere vCenter データストアの場所に適用する必要があります。 | String |
|
設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリスト表示します。設定でこのパラメーターを定義しない場合、ネットワークは | String |
|
オプション: このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例: | String |
4.12.2. インストーラーでプロビジョニングされる VMware vSphere クラスターの install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 3 5
- オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
- 6
- DNS レコードに指定したクラスター名。
- 8
- オプション: マシン作成用の既存のリソースプールを提供します。値を指定しない場合、インストールプログラムは vSphere クラスターのルートリソースプールを使用します。
- 9
- vSphere ディスクのプロビジョニング方法。
- 10
- OpenShift Container Platform クラスターをインストールする vSphere クラスター。
- 7
- インストールするクラスターネットワークプラグイン。サポートされている値は
OVNKubernetes
とOpenShiftSDN
です。デフォルトの値はOVNkubernetes
です。
OpenShift Container Platform 4.12 以降では、apiVIP
および ingressVIP
設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs
および ingressVIPs
設定に値を入力します。
4.12.3. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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-config
namespace に生成します。次に 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
4.12.4. VMware vCenter のリージョンとゾーンの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
この例では、govc
コマンドを使用します。govc
コマンドは、VMware から入手できるオープンソースコマンドです。govc
コマンドは Red Hat からは入手できません。Red Hat サポートは govc
コマンドを保守しません。govc
のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイト を参照してください。
前提条件
既存の
install-config.yaml
インストール設定ファイルがあります。重要VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
注記VMware vSphere プラットフォームに OpenShift Container Platform クラスターをインストールした後は、障害ドメインを変更できません。クラスターのインストール後に、障害ドメインを追加できます。
手順
次の
govc
コマンドラインツールコマンドを入力して、openshift-region
およびopenshift-zone
vCenter タグカテゴリーを作成します。重要openshift-region
およびopenshift-zone
vCenter タグカテゴリーに異なる名前を指定すると、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 クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。
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 クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。
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> /<datacenter_1>
$ govc tags.attach -c <region_tag_category> <region_tag_1> /<datacenter_1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。
govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
$ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。
vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml
ファイル
- 1
- VMware vSphere リージョンおよびゾーン有効化機能を使用できるように、このパラメーターの値として
TechPreviewNoUpgrade
を設定するように定義する必要があります。 - 2 3
- vCenter クラスターを指定するためのオプションのパラメーター。ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。このパラメーターを定義しない場合、ノードは定義されているすべての障害ドメインに分散されます。 - 4 5 6 7 8 9 10 11
- デフォルトの vCenter トポロジー。インストールプログラムは、このトポロジー情報を使用してブートストラップノードをデプロイメントします。さらに、トポロジーは vSphere 永続ボリュームのデフォルトデータストアを定義します。
- 12
- リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 13
- 障害ドメインの名前を定義します。各障害ドメインは
zones
パラメーターで参照され、マシンプールの範囲が障害ドメインに設定されます。 - 14
- リージョンを定義するには、
openshift-region
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 15
- ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 16
- 障害ドメインに関連付けられた vCenter リソースを指定します。
- 17
- 障害ドメインに関連付けられた vSphere データセンターを定義するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 18
- 障害ドメインに関連付けられた計算クラスターの絶対ファイルパスを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 19
- インストーラーがプロビジョニングするインフラストラクチャーのオプションのパラメーター。このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例:
/<datacenter_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>
)。値を指定しない場合、リソースはクラスターのルート/example_datacenter/host/example_cluster/Resources
にインストールされます。 - 20
- 設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリストするオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 21
- ボリュームのプロビジョニングに使用するデータストアを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
4.13. ネットワーク設定フェーズ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、ネットワーク設定をカスタマイズできる 2 つのフェーズがあります。
- フェーズ 1
マニフェストファイルを作成する前に、
install-config.yaml
ファイルで以下のネットワーク関連のフィールドをカスタマイズできます。-
networking.networkType
-
networking.clusterNetwork
-
networking.serviceNetwork
networking.machineNetwork
これらのフィールドの詳細は、インストール設定パラメーター を参照してください。
注記優先される NIC が置かれている CIDR に一致する
networking.machineNetwork
を設定します。重要CIDR 範囲
172.17.0.0/16
は libVirt によって予約されています。この範囲、またはこの範囲と重複する範囲をクラスター内のネットワークに使用することはできません。
-
- フェーズ 2
-
openshift-install create manifests
を実行してマニフェストファイルを作成した後に、変更するフィールドのみでカスタマイズされた Cluster Network Operator マニフェストを定義できます。マニフェストを使用して、高度なネットワーク設定を指定できます。
フェーズ 2 で、install-config.yaml
ファイルのフェーズ 1 で指定した値を上書きすることはできません。ただし、フェーズ 2 でネットワークプラグインをさらにカスタマイズできます。
4.14. 高度なネットワーク設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される 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
ファイルで、クラスターの高度なネットワーク設定を指定します。OpenShift SDN ネットワークプロバイダーに異なる VXLAN ポートを指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時にmanifests/
ディレクトリーを使用します。
4.15. Cluster Network Operator (CNO) の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターネットワークの設定は、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
- OpenShift SDN や OVN-Kubernetes などのクラスターネットワークプラグイン。
defaultNetwork
オブジェクトのフィールドを cluster
という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
4.15.1. Cluster Network Operator 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
フィールド | タイプ | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。
マニフェストを作成する前に、このフィールドを |
|
| サービスの IP アドレスのブロック。OpenShift SDN および 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 ネットワークプラグインに影響が及ぶ可能性があり、プラグインは異なるノード間でオブジェクトトラフィックを効果的にルーティングすることはできません。
defaultNetwork オブジェクト設定
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
フィールド | タイプ | 説明 |
---|---|---|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。 |
|
| このオブジェクトは、OpenShift SDN ネットワークプラグインに対してのみ有効です。 |
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
OpenShift SDN ネットワークプラグインの設定
以下の表では、OpenShift SDN ネットワークプラグインの設定フィールドを説明します。
フィールド | タイプ | 説明 |
---|---|---|
|
|
OpenShift SDN のネットワーク分離モードを設定します。デフォルト値は
|
|
| VXLAN オーバーレイネットワークの最大転送単位 (MTU)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも クラスターインストール時またはインストール後のタスクとして値を設定できます。詳細は、OpenShift Container Platform Networking ドキュメントの "Changing the MTU for the cluster network" を参照してください。 |
|
|
すべての VXLAN パケットに使用するポート。デフォルト値は 別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。
Amazon Web Services (AWS) では、VXLAN にポート |
OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
フィールド | タイプ | 説明 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも |
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
|
| IPsec 暗号化を有効にするために空のオブジェクトを指定します。 |
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
| オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
フィールド | タイプ | 説明 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
フィールド | タイプ | 説明 |
---|---|---|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを 注記
OpenShift Container Platform 4.12 では、egress IP はプライマリーインターフェイスのみに割り当てられます。そのため、
インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
IPsec が有効な OVN-Kubernetes 設定の例
kubeProxyConfig オブジェクト設定
kubeProxyConfig
オブジェクトの値は以下の表で定義されます。
フィールド | タイプ | 説明 |
---|---|---|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s
|
4.16. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
OpenShift Container Platform デプロイメント用に VMC 環境を設定したとき、VMC 環境に併設された bastion 管理ホストの OpenShift Container Platform インストールプログラムを使用します。インストールプログラムおよびコントロールプレーンは、OpenShift Container Platform クラスターに必要なリソースのデプロイおよび管理プロセスを自動化します。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要VMC 環境でホストされる bastion からの
openshift-install
コマンドを使用します。注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.log
にも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
4.17. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
C:\> oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.18. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI がインストールされている。
手順
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
4.19. レジストリーストレージの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。
4.19.1. インストール時に削除されたイメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、Image Registry Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
4.19.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
4.19.2.1. VMware vSphere のレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- VMware vSphere 上のクラスター。
Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。
重要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
$ oc get pod -n openshift-image-registry -l docker-registry=default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resourses found in openshift-image-registry namespace
No resourses found in openshift-image-registry namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io
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
image-registry-storage
永続ボリューム要求 (PVC) の自動作成を許可するには、claim
フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
clusteroperator
ステータスを確認します。oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.19.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}}'
$ 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 vSpherePersistentVolumeClaim
オブジェクトを定義します。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-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
正しい PVC を参照するようにレジストリーストレージを設定する方法については、vSphere のレジストリーの設定 を参照 してください。
4.20. VMware vSphere ボリュームのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップしたり、スナップショットからボリュームを復元したりすることはできません。詳細は、スナップショットの制限 を参照してください。
手順
永続ボリュームのバックアップを作成すには、以下を実行します。
- 永続ボリュームを使用しているアプリケーションを停止します。
- 永続ボリュームのクローンを作成します。
- アプリケーションを再起動します。
- クローンを作成したボリュームのバックアップを作成します。
- クローンを作成したボリュームを削除します。
4.21. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
4.22. 外部ロードバランサー用のサービス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。
このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。
Red Hat は、外部ロードバランサーに対して次のサービスをサポートしています。
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
外部ロードバランサーに対して、これらのサービスの 1 つまたはすべてを設定するように選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。
図4.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例
図4.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例
図4.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例
外部ロードバランサーでは、次の設定オプションがサポートされています。
- ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。
サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。
/27
や/28
などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。ヒントマシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。
OpenShift Container Platform クラスターの外部ロードバランサーを設定する前に、以下の情報を考慮してください。
- フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能については、ベンダーのドキュメントを確認してください。
バックエンド IP アドレスの場合、OpenShift Container Platform コントロールプレーンノードの IP アドレスが、外部ロードバランサーの存続期間中に変更されないようにください。次のいずれかのアクションを実行すると、これを実現できます。
- 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
- ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
- Ingress Controller バックエンドサービスの外部ロードバランサーで、Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。
4.22.1. 外部ロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーを設定する前に、「外部ロードバランサー用のサービス」セクションを必ず確認してください。
外部ロードバランサー用に設定するサービスに適用される次の前提条件を確認してください。
クラスター上で動作する MetalLB は、外部ロードバランサーとして機能します。
OpenShift API の前提条件
- フロントエンド IP アドレスを定義している。
TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。
- ポート 6443 が OpenShift API サービスにアクセスできる。
- ポート 22623 が Ignition 起動設定をノードに提供できる。
- フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
- フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
- ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。
Ingress Controller の前提条件
- フロントエンド IP アドレスを定義している。
- TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
- フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
- フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
- ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。
ヘルスチェック URL 仕様の前提条件
ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できます。OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。
次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。
Kubernetes API ヘルスチェック仕様の例
Path: HTTPS:6443/readyz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Machine Config API ヘルスチェック仕様の例
Path: HTTPS:22623/healthz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Ingress Controller のヘルスチェック仕様の例
Path: HTTP:1936/healthz/ready Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 5 Interval: 10
Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
手順
HAProxy Ingress Controller を設定して、ポート 6443、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。
HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow curl
CLI コマンドを使用して、外部ロードバランサーとそのリソースが動作していることを確認します。次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。
curl https://<loadbalancer_ip_address>:6443/version --insecure
$ curl https://<loadbalancer_ip_address>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。
curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
外部ロードバランサーのフロントエンド IP アドレスをターゲットにするように、クラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。
変更された DNS レコードの例
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。
curl
CLI コマンドを使用して、外部ロードバランサーと DNS レコード設定が動作していることを確認します。次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。
curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。
curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。
curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。
curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.23. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- レジストリーを セットアップし、レジストリーストレージを設定し ます。
- オプション: vSphere Problem Detector Operator からのイベントを表示 し、クラスターにパーミッションまたはストレージ設定の問題があるかどうかを判別します。
第5章 ネットワークが制限された環境での VMC へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、クラスターを 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 にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。
5.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 アドレスをポイントする
以下のファイアウォールルールを設定します。
- ポート 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 ホスト間のアクセスを有効にするために作成されます。
5.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 のベストプラクティスに基づいてレポートを生成し、クラスター設定および必要なホスト数について推奨します。
5.2. vSphere 要件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
ミラーホストでレジストリーを作成 し ており、使用しているバージョンの OpenShift Container Platform の
imageContentSources
データを取得している。重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
- ブロックレジストリーストレージ をプロビジョニングしている。詳細は、永続ストレージについて を 参照 してください。
クラスターがアクセスする必要のある サイトを許可するようにファイアウォールを設定 している(ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
5.3. ネットワークが制限された環境でのインストールについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
5.3.1. その他の制限 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersion
ステータスにはUnable to retrieve available updates
エラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
5.4. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
5.5. VMware vSphere インフラストラクチャーの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
仮想環境製品 | 必須バージョン |
---|---|
VMware 仮想ハードウェア | 15 以降 |
vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
VMware vSphere バージョン 7.0 および 7.0 Update 1 へのクラスターのインストールは非推奨になりました。これらのバージョンは引き続き完全にサポートされていますが、vSphere 6.x のすべてのバージョンはサポートされなくなりました。OpenShift Container Platform のバージョン 4.12 には、VMware 仮想ハードウェアバージョン 15 以降が必要です。vSphere 仮想マシンのハードウェアバージョンを更新するには、クラスターの更新 セクションの "Updating hardware on nodes running in vSphere" を参照してください。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat Customer Portal の ハードウェア を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 7.0 Update 2 以降、8.0 Update 1 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
5.6. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。
必要なネットワークポートに関する次の詳細を確認してください。
プロトコル | ポート | 説明 |
---|---|---|
VRRP | 該当なし | keepalived に必要 |
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 サーバーおよびピアポート |
5.7. VMware vSphere CSI Driver Operator の要件 リンクのコピーリンクがクリップボードにコピーされました!
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
5.8. vCenter の要件 リンクのコピーリンクがクリップボードにコピーされました!
インストーラーでプロビジョニングされるインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの権限
OpenShift Container Platform クラスターを vCenter にインストールするには、インストールプログラムには、必要なリソースの読み取りおよび作成権限を持つアカウントへのアクセスが必要になります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。
グローバル管理者権限を持つアカウントを使用できない場合、OpenShift Container Platform クラスターのインストールに必要な権限を付与するためのロールを作成する必要があります。ほとんどの特権は常に必要になりますが、デフォルト動作であるインストールプログラムでの vCenter インスタンスへの OpenShift Container Platform クラスターが含まれるフォルダーのプロビジョニングを実行する場合にのみ必要となる特権もあります。必要な特権を付与するには、指定されたオブジェクトに vSphere ロールを作成するか、これを修正する必要があります。
インストールプログラムが vSphere 仮想マシンフォルダーを作成するために使用される場合には、追加のロールが必要です。
例5.1 vSphere API でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常に |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
例5.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常に |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
また、ユーザーには一部の ReadOnly
パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例5.3 必要なパーミッションおよび伝播の設定
vSphere オブジェクト | 必要になる場合 | 子への伝播 | パーミッションが必要 |
---|---|---|---|
vSphere vCenter | 常に | False | 必要な特権がリスト表示 |
vSphere vCenter Datacenter | 既存のフォルダー | False |
|
インストールプログラムがフォルダーを作成する | True | リスト表示された必要な特権 | |
vSphere vCenter Cluster | 既存のリソースプール | False |
|
クラスタールートの仮想マシン | True | リスト表示された必要な特権 | |
vSphere vCenter Datastore | 常に | False | リスト表示された必要な特権 |
vSphere Switch | 常に | False |
|
vSphere ポートグループ | 常に | False | リスト表示された必要な特権 |
vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | リスト表示された必要な特権 |
vSphere vCenter リソースプール | 既存のリソースプール | True | リスト表示された必要な特権 |
必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
OpenShift Container Platform は通常、コンピュート専用の vMotion をサポートします。これは、一般に、vMotion に関するすべての VMware ベストプラクティスを満たすことを意味します。
コンピュートプレーンノードとコントロールプレーンノードの稼働時間を確保するには、vMotion に関する VMware のベストプラクティスに従い、VMware のアンチアフィニティールールを使用して、メンテナンスまたはハードウェアの問題時の OpenShift Container Platform の可用性を向上させます。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。Pod で vSphere ボリュームを使用している場合、手動または Storage vMotion を介してデータストア間で VM を移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生し、データ損失が発生する可能性があります。
- OpenShift Container Platform は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。
クラスターリソース
installer-provisioned infrastructure を使用する 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 アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに Dynamic Host Configuration Protocol (DHCP) を使用して、クラスター内のマシンに永続的な IP アドレスを設定するように DHCP サーバーを設定できます。DHCP リースでは、デフォルトゲートウェイを使用するように DHCP を設定する必要があります。
静的 IP アドレスを使用してノードをプロビジョニングする場合は、ネットワークに DHCP を使用する必要はありません。
制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。
クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。
さらに、OpenShift Container Platform クラスターをインストールする前に以下のネットワークリソースを作成する必要があります。
必要な 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 レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
5.9. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
、ppc64le
、およびs390x
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
5.10. 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 証明書が含まれる圧縮ファイルを展開します。圧縮ファイルの内容は、以下のファイル構造のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オペレーティングシステム用のファイルをシステム信頼に追加します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
cp certs/lin/* /etc/pki/ca-trust/source/anchors
# cp certs/lin/* /etc/pki/ca-trust/source/anchors
Copy to Clipboard Copied! Toggle word wrap Toggle overflow システム信頼を更新します。たとえば、Fedora オペレーティングシステムで以下のコマンドを実行します。
update-ca-trust extract
# update-ca-trust extract
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.11. ネットワークが制限されたインストール用の RHCOS イメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードし、OpenShift Container Platform をネットワークが制限された VMware vSphere 環境にインストールします。
前提条件
- OpenShift Container Platform インストールプログラムを取得します。ネットワークが制限されたインストールでは、プログラムはミラーレジストリースト上に置かれます。
手順
- Red Hat カスタマーポータルの 製品ダウンロードページ にログインします。
バージョンの下で、RHEL8 用の OpenShift Container Platform 4.12 の最新リリースを選択します。
重要RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。
- Red Hat Enterprise Linux CoreOS (RHCOS) - vSphere イメージをダウンロードします。
- ダウンロードしたイメージを、bastion サーバーからアクセス可能な場所にアップロードします。
これで、イメージが制限されたインストールで利用可能になります。OpenShift Container Platform デプロイメントで使用するイメージの名前または場所をメモします。
5.12. VMware vSphere のリージョンとゾーンの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
デフォルトのインストール設定では、クラスターが単一の 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 |
5.13. インストール設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
ミラーレジストリーの作成時に生成された
imageContentSources
値を使用します。 - ミラーレジストリーの証明書の内容を取得する。
- Red Hat Enterprise Linux CoreOS (RHCOS) イメージを取得し、これをアクセス可能な場所にアップロードする。
- サブスクリプションレベルでサービスプリンシパルのパーミッションを取得する。
手順
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
./openshift-install create install-config --dir <installation_directory>
$ ./openshift-install create install-config --dir <installation_directory>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。- ターゲットに設定するプラットフォームとして vsphere を選択します。
- vCenter インスタンスの名前を指定します。
クラスターを作成するのに必要なパーミッションを持つ vCenter アカウントのユーザー名およびパスワードを指定します。
インストールプログラムは vCenter インスタンスに接続します。
- 接続する vCenter インスタンスのデータセンターを選択します。
- 使用するデフォルトの vCenter データストアを選択します。
- OpenShift Container Platform クラスターをインストールする vCenter クラスターを選択します。インストールプログラムは、vSphere クラスターの root リソースプールをデフォルトのリソースプールとして使用します。
- 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワークを選択します。
- コントロールプレーン API のアクセス用に設定した仮想 IP アドレスを入力します。
- クラスター Ingress に設定した仮想 IP アドレスを入力します。
- ベースドメインを入力します。このベースドメインは、設定した DNS レコードで使用したものと同じである必要があります。
- クラスターの記述名を入力します。入力するクラスター名は、DNS レコードの設定時に指定したクラスター名と一致する必要があります。
- Red Hat OpenShift Cluster Manager からプルシークレット を貼り付けます。
install-config.yaml
ファイルでplatform.vsphere.clusterOSImage
の値をイメージの場所または名前に設定します。以下に例を示します。platform: vsphere: clusterOSImage: http://mirror.example.com/images/rhcos-43.81.201912131630.0-vmware.x86_64.ova?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d
platform: vsphere: clusterOSImage: http://mirror.example.com/images/rhcos-43.81.201912131630.0-vmware.x86_64.ova?sha256=ffebbd68e8a1f2a245ca19522c16c86f67f9ac8e4e0c1f0a812b068b16f7265d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow install-config.yaml
ファイルを編集し、ネットワークが制限された環境でのインストールに必要な追加の情報を提供します。pullSecret
の値を更新して、レジストリーの認証情報を追加します。pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <mirror_host_name>
の場合、ミラーレジストリーの証明書で指定したレジストリードメイン名を指定し、<credentials>
の場合は、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。additionalTrustBundle
パラメーターおよび値を追加します。additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
additionalTrustBundle: | -----BEGIN CERTIFICATE----- ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ -----END CERTIFICATE-----
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この値は、ミラーレジストリーに使用した証明書ファイルの内容である必要があります。証明書ファイルは、既存の信頼できる認証局、またはミラーレジストリー用に生成した自己署名証明書のいずれかです。
次の YAML の抜粋のようなイメージコンテンツリソースを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの値には、ミラーレジストリーの作成時に記録された
imageContentSources
を使用します。
-
必要な
install-config.yaml
ファイルに他の変更を加えます。利用可能なパラメーターの詳細については、インストール設定パラメーターセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
5.13.1. インストール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターをデプロイする前に、クラスターをホストするクラウドプラットフォームでアカウントを記述し、クラスターのプラットフォームをオプションでカスタマイズするためにパラメーターの値を指定します。install-config.yaml
インストール設定ファイルを作成する際に、コマンドラインで必要なパラメーターの値を指定します。クラスターをカスタマイズする場合、install-config.yaml
ファイルを変更して、プラットフォームについての詳細情報を指定できます。
インストール後は、これらのパラメーターを install-config.yaml
ファイルで変更することはできません。
5.13.1.1. 必須設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
必須のインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
|
| 文字列 |
|
クラウドプロバイダーのベースドメイン。ベースドメインは、OpenShift Container Platform クラスターコンポーネントへのルートを作成するために使用されます。クラスターの完全な DNS 名は、 |
|
|
Kubernetes リソース | オブジェクト |
|
クラスターの名前。クラスターの DNS レコードはすべて |
小文字いちぶハイフン ( |
|
インストールを実行する特定のプラットフォームの設定: | オブジェクト |
| Red Hat OpenShift Cluster Manager からプルシークレット を取得して、Quay.io などのサービスから OpenShift Container Platform コンポーネントのコンテナーイメージをダウンロードすることを認証します。 |
|
5.13.1.2. ネットワーク設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
既存のネットワークインフラストラクチャーの要件に基づいて、インストール設定をカスタマイズできます。たとえば、クラスターネットワークの IP アドレスブロックを拡張するか、デフォルトとは異なる IP アドレスブロックを指定できます。
IPv4 アドレスのみがサポートされます。
Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーのシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。
パラメーター | 説明 | 値 |
---|---|---|
| クラスターのネットワークの設定。 | オブジェクト 注記
インストール後に |
| インストールする Red Hat OpenShift Networking ネットワークプラグイン。 |
|
| Pod の IP アドレスブロック。
デフォルト値は 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23
|
|
IPv4 ネットワーク |
CIDR (Classless Inter-Domain Routing) 表記の IP アドレスブロック。IPv4 ブロックの接頭辞長は |
|
それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、 | サブネット接頭辞。
デフォルト値は |
|
サービスの IP アドレスブロック。デフォルト値は OpenShift SDN および OVN-Kubernetes ネットワークプラグインは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。 | CIDR 形式の IP アドレスブロックを持つ配列。以下に例を示します。 networking: serviceNetwork: - 172.30.0.0/16
|
| マシンの IP アドレスブロック。 複数の IP アドレスブロックを指定する場合は、ブロックが重複しないようにしてください。 | オブジェクトの配列。以下に例を示します。 networking: machineNetwork: - cidr: 10.0.0.0/16
|
|
| CIDR 表記の IP ネットワークブロック。
例: 注記
優先される NIC が置かれている CIDR に一致する |
5.13.1.3. オプションの設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションのインストール設定パラメーターは、以下の表で説明されています。
パラメーター | 説明 | 値 |
---|---|---|
| ノードの信頼済み証明書ストアに追加される PEM でエンコードされた X.509 証明書バンドル。この信頼バンドルは、プロキシーが設定される際にも使用できます。 | 文字列 |
| オプションのコアクラスターコンポーネントのインストールを制御します。オプションのコンポーネントを無効にすることで、OpenShift Container Platform クラスターのフットプリントを削減できます。詳細は、インストール の「クラスター機能ページ」を参照してください。 | 文字列配列 |
|
有効にするオプション機能の初期セットを選択します。有効な値は | 文字列 |
|
オプションの機能のセットを、 | 文字列配列 |
| コンピュートノードを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コンピュートマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコンピュートマシン (ワーカーマシンとしても知られる) の数。 |
|
| 機能セットのクラスターを有効にします。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。インストール中に機能セットを有効にする方法の詳細は、「機能ゲートの使用による各種機能の有効化」を参照してください。 |
文字列。 |
| コントロールプレーンを設定するマシンの設定。 |
|
|
プール内のマシンの命令セットアーキテクチャーを決定します。現在、さまざまなアーキテクチャーのクラスターはサポートされていません。すべてのプールは同じアーキテクチャーを指定する必要があります。有効な値は | 文字列 |
|
コントロールプレーンマシンで同時マルチスレッドまたは 重要 同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 |
|
|
|
|
|
|
|
| プロビジョニングするコントロールプレーンマシンの数。 |
サポートされる値は |
| Cloud Credential Operator (CCO) モード。モードを指定しないと、CCO は指定された認証情報の機能を動的に判別しようとします。この場合、複数のモードがサポートされるプラットフォームで Mint モードが優先されます。 注記 すべてのクラウドプロバイダーですべての CCO モードがサポートされているわけではありません。CCO モードの詳細は、Cluster Operators リファレンス の Cloud Credential Operator を参照してください。 注記
AWS アカウントでサービスコントロールポリシー (SCP) が有効になっている場合は、 |
|
|
FIPS モードを有効または無効にします。デフォルトは 重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、 注記 Azure File ストレージを使用している場合、FIPS モードを有効にすることはできません。 |
|
| release-image コンテンツのソースおよびリポジトリー。 |
オブジェクトの配列。この表の以下の行で説明されているように、 |
|
| 文字列 |
| 同じイメージが含まれる可能性のあるリポジトリーを 1 つ以上指定します。 | 文字列の配列。 |
| Kubernetes API、OpenShift ルートなどのクラスターのユーザーに表示されるエンドポイントをパブリッシュまたは公開する方法。 |
このパラメーターを 重要
フィールドの値が |
| クラスターマシンへのアクセスを認証するための SSH キー。 注記
インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、 |
たとえば、 |
5.13.1.4. 追加の VMware vSphere 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
追加の VMware vSphere 設定パラメーターは以下の表で説明されています。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
| vCenter サーバーの完全修飾ホスト名または IP アドレス。 | String |
| vCenter インスタンスに接続するために使用するユーザー名。このユーザーには、少なくとも vSphere の 静的または動的な永続ボリュームのプロビジョニング に必要なロールおよび権限がなければなりません。 | String |
| vCenter ユーザー名のパスワード。 | String |
| vCenter インスタンスで使用するデータセンターの名前。 | String |
| ボリュームのプロビジョニングに使用するデフォルトデータストアの名前。 | String |
| オプション: インストールプログラムが仮想マシンを作成する既存のフォルダーの絶対パス。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられたフォルダーを作成します。 |
文字列 (例: |
|
オプション: インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パス。値を指定しない場合、インストールプログラムは |
文字列 (例: |
| 設定した仮想 IP アドレスおよび DNS レコードが含まれる vCenter インスタンスのネットワーク。 | String |
| OpenShift Container Platform クラスターをインストールする vCenter クラスター。 | String |
| コントロールプレーン API のアクセス用に設定した仮想 IP (VIP) アドレス。 注記
OpenShift Container Platform 4.12 以降では、 |
IP アドレス (例: |
| クラスター Ingress に設定した仮想 IP (VIP) アドレス。 注記
OpenShift Container Platform 4.12 以降では、 |
IP アドレス (例: |
[disktype] | オプション: ディスクプロビジョニング方法。この値が設定されていない場合、デフォルトで vSphere のデフォルトのストレージポリシーに設定されます。 |
有効な値は、 |
5.13.1.5. オプションの VMware vSphere マシンプール設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
オプションの VMware vSphere マシンプール設定パラメーターは、以下の表で説明されています。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
| インストールプログラムが RHCOS イメージをダウンロードする場所。ネットワークが制限された環境でインストールを実行するには、このパラメーターを設定する必要があります。 |
HTTP または HTTPS の URL (オプションで SHA-256 形式のチェックサムを使用)。例: |
| ディスクのサイズ (ギガバイト単位)。 | Integer |
|
仮想マシンを割り当てる仮想プロセッサーコアの合計数 | Integer |
|
仮想マシンのソケットあたりのコア数。 | Integer |
| 仮想マシンのメモリーのサイズ (メガバイト単位)。 | Integer |
5.13.1.6. リージョンおよびゾーンの有効化設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
リージョンおよびゾーンの有効化機能を使用するには、インストールファイルでリージョンおよびゾーンの有効化パラメーターを指定する必要があります。
install-config.yaml
ファイルを変更してリージョンおよびゾーンの有効化環境を設定する前に、「VMware vSphere のリージョンおよびゾーンの有効化」および「VMware vCenter のリージョンおよびゾーン」の設定セクションをお読みください。
platform.vsphere
パラメーターには、表に記載されている各パラメーターの接頭辞が付けられます。
パラメーター | 説明 | 値 |
---|---|---|
|
リージョンとゾーン間の関係を確立します。障害ドメインは、 | String |
| 障害ドメインの名前。マシンプールは、この名前を使用して障害ドメインを参照します。 | String |
| クライアントが障害ドメインリソースにアクセスできるように、VMware vCenter Server の完全修飾ホスト名または IP アドレスを指定します。server ロールを vSphere vCenter サーバーの場所に適用する必要があります。 | String |
|
リージョンを定義するには、 | String |
|
ゾーンを定義するには、 | String |
|
このパラメーターは、障害ドメインに関連付けられたコンピューティングクラスターを定義します。設定でこのパラメーターを定義しない場合、コンピューティングクラスターは | String |
|
インストールプログラムが仮想マシンを作成する既存のフォルダーの絶対パス。設定でこのパラメーターを定義しない場合、フォルダーは | String |
|
OpenShift Container Platform 仮想マシン (VM) が動作するデータセンターを定義します。設定でこのパラメーターを定義しない場合、データセンターはデフォルトで | String |
| 障害ドメインの仮想マシンファイルを保存する vSphere データストアへのパスを指定します。datastore ロールを vSphere vCenter データストアの場所に適用する必要があります。 | String |
|
設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリスト表示します。設定でこのパラメーターを定義しない場合、ネットワークは | String |
|
オプション: このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例: | String |
5.13.2. インストーラーでプロビジョニングされる VMware vSphere クラスターの install-config.yaml ファイルのサンプル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 4
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 3 5
- オプション: コンピュートおよびコントロールプレーンマシンのマシンプールパラメーターの追加設定を指定します。
- 6
- DNS レコードに指定したクラスター名。
- 7
- オプション: マシン作成用の既存のリソースプールを提供します。値を指定しない場合、インストールプログラムは vSphere クラスターのルートリソースプールを使用します。
- 8
- vSphere ディスクのプロビジョニング方法。
- 9
- OpenShift Container Platform クラスターをインストールする vSphere クラスター。
- 10
- bastion サーバーからアクセス可能な Red Hat Enterprise Linux CoreOS (RHCOS) イメージの場所。
- 11
<local_registry>
については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.com
またはregistry.example.com:5000
<credentials>
について、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 12
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 13
- リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSources
セクションを指定します。
OpenShift Container Platform 4.12 以降では、apiVIP
および ingressVIP
設定は非推奨です。代わりに、リスト形式を使用して、apiVIPs
および ingressVIPs
設定に値を入力します。
5.13.3. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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-config
namespace に生成します。次に 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
5.13.4. VMware vCenter のリージョンとゾーンの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
この例では、govc
コマンドを使用します。govc
コマンドは、VMware から入手できるオープンソースコマンドです。govc
コマンドは Red Hat からは入手できません。Red Hat サポートは govc
コマンドを保守しません。govc
のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイト を参照してください。
前提条件
既存の
install-config.yaml
インストール設定ファイルがあります。重要VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
注記VMware vSphere プラットフォームに OpenShift Container Platform クラスターをインストールした後は、障害ドメインを変更できません。クラスターのインストール後に、障害ドメインを追加できます。
手順
次の
govc
コマンドラインツールコマンドを入力して、openshift-region
およびopenshift-zone
vCenter タグカテゴリーを作成します。重要openshift-region
およびopenshift-zone
vCenter タグカテゴリーに異なる名前を指定すると、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 クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。
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 クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。
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> /<datacenter_1>
$ govc tags.attach -c <region_tag_category> <region_tag_1> /<datacenter_1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。
govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
$ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。
vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml
ファイル
- 1
- VMware vSphere リージョンおよびゾーン有効化機能を使用できるように、このパラメーターの値として
TechPreviewNoUpgrade
を設定するように定義する必要があります。 - 2 3
- vCenter クラスターを指定するためのオプションのパラメーター。ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。このパラメーターを定義しない場合、ノードは定義されているすべての障害ドメインに分散されます。 - 4 5 6 7 8 9 10 11
- デフォルトの vCenter トポロジー。インストールプログラムは、このトポロジー情報を使用してブートストラップノードをデプロイメントします。さらに、トポロジーは vSphere 永続ボリュームのデフォルトデータストアを定義します。
- 12
- リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 13
- 障害ドメインの名前を定義します。各障害ドメインは
zones
パラメーターで参照され、マシンプールの範囲が障害ドメインに設定されます。 - 14
- リージョンを定義するには、
openshift-region
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 15
- ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 16
- 障害ドメインに関連付けられた vCenter リソースを指定します。
- 17
- 障害ドメインに関連付けられた vSphere データセンターを定義するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 18
- 障害ドメインに関連付けられた計算クラスターの絶対ファイルパスを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 19
- インストーラーがプロビジョニングするインフラストラクチャーのオプションのパラメーター。このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例:
/<datacenter_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>
)。値を指定しない場合、リソースはクラスターのルート/example_datacenter/host/example_cluster/Resources
にインストールされます。 - 20
- 設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリストするオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 21
- ボリュームのプロビジョニングに使用するデータストアを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
5.14. クラスターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
OpenShift Container Platform デプロイメント用に VMC 環境を設定したとき、VMC 環境に併設された bastion 管理ホストの OpenShift Container Platform インストールプログラムを使用します。インストールプログラムおよびコントロールプレーンは、OpenShift Container Platform クラスターに必要なリソースのデプロイおよび管理プロセスを自動化します。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定します。
- OpenShift Container Platform インストールプログラム、およびクラスターのプルシークレットを取得する。
- ホスト上のクラウドプロバイダーアカウントに、クラスターをデプロイするための適切な権限があることを確認してください。アカウントの権限が正しくないと、インストールプロセスが失敗し、不足している権限を示すエラーメッセージが表示されます。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
./openshift-install create cluster --dir <installation_directory> \ --log-level=info
$ ./openshift-install create cluster --dir <installation_directory> \
1 --log-level=info
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要VMC 環境でホストされる bastion からの
openshift-install
コマンドを使用します。注記ホストに設定したクラウドプロバイダーアカウントにクラスターをデプロイするための十分なパーミッションがない場合、インストールプロセスは停止し、不足しているパーミッションが表示されます。
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.log
にも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
5.15. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
C:\> oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.16. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
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
5.17. デフォルトの OperatorHub カタログソースの無効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。
手順
disableAllDefaultSources: true
をOperatorHub
オブジェクトに追加して、デフォルトカタログのソースを無効にします。oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
5.18. レジストリーストレージの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストール後に、レジストリー Operator のストレージを作成する必要があります。
5.18.1. インストール時に削除されたイメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、Image Registry Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
5.18.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
5.18.2.1. VMware vSphere のレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- VMware vSphere 上のクラスター。
Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。
重要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
$ oc get pod -n openshift-image-registry -l docker-registry=default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resourses found in openshift-image-registry namespace
No resourses found in openshift-image-registry namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io
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
image-registry-storage
永続ボリューム要求 (PVC) の自動作成を許可するには、claim
フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
clusteroperator
ステータスを確認します。oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.19. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
5.20. 外部ロードバランサー用のサービス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。
このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。
Red Hat は、外部ロードバランサーに対して次のサービスをサポートしています。
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
外部ロードバランサーに対して、これらのサービスの 1 つまたはすべてを設定するように選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。
図5.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例
図5.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例
図5.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例
外部ロードバランサーでは、次の設定オプションがサポートされています。
- ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。
サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。
/27
や/28
などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。ヒントマシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。
OpenShift Container Platform クラスターの外部ロードバランサーを設定する前に、以下の情報を考慮してください。
- フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能については、ベンダーのドキュメントを確認してください。
バックエンド IP アドレスの場合、OpenShift Container Platform コントロールプレーンノードの IP アドレスが、外部ロードバランサーの存続期間中に変更されないようにください。次のいずれかのアクションを実行すると、これを実現できます。
- 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
- ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
- Ingress Controller バックエンドサービスの外部ロードバランサーで、Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。
5.20.1. 外部ロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりに外部ロードバランサーを使用することができます。
外部ロードバランサーを設定する前に、「外部ロードバランサー用のサービス」セクションを必ず確認してください。
外部ロードバランサー用に設定するサービスに適用される次の前提条件を確認してください。
クラスター上で動作する MetalLB は、外部ロードバランサーとして機能します。
OpenShift API の前提条件
- フロントエンド IP アドレスを定義している。
TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。
- ポート 6443 が OpenShift API サービスにアクセスできる。
- ポート 22623 が Ignition 起動設定をノードに提供できる。
- フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
- フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
- ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。
Ingress Controller の前提条件
- フロントエンド IP アドレスを定義している。
- TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
- フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
- フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
- ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。
ヘルスチェック URL 仕様の前提条件
ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できまうs.OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。
次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。
Kubernetes API ヘルスチェック仕様の例
Path: HTTPS:6443/readyz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Machine Config API ヘルスチェック仕様の例
Path: HTTPS:22623/healthz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Ingress Controller のヘルスチェック仕様の例
Path: HTTP:1936/healthz/ready Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 5 Interval: 10
Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
手順
HAProxy Ingress Controller を設定して、ポート 6443、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。
HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow curl
CLI コマンドを使用して、外部ロードバランサーとそのリソースが動作していることを確認します。次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。
curl https://<loadbalancer_ip_address>:6443/version --insecure
$ curl https://<loadbalancer_ip_address>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。
curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
外部ロードバランサーのフロントエンド IP アドレスをターゲットにするように、クラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。
変更された DNS レコードの例
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。
curl
CLI コマンドを使用して、外部ロードバランサーと DNS レコード設定が動作していることを確認します。次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。
curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。
curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。
curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。
curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.21. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターのカスタマイズ
-
Cluster Samples Operator および
must-gather
ツールの イメージストリームを設定 します。 - ネットワークが制限された環境での Operator Lifecycle Manager (OLM) の使用 方法について参照します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- レジストリーをセットアップし、レジストリーストレージを設定 します。
第6章 ユーザーによってプロビジョニングされるインフラストラクチャーを使用した VMC へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、クラスターを 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 にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。
6.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 アドレスが利用可能でなければなりません。
以下のファイアウォールルールを設定します。
- 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 ホスト間のアクセスを有効にするために作成されます。
6.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 のベストプラクティスに基づいてレポートを生成し、クラスター設定および必要なホスト数について推奨します。
6.2. vSphere 要件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
- ブロックレジストリーストレージ をプロビジョニングしている。詳細は、永続ストレージについて を参照してください。
ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
6.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
6.4. VMware vSphere インフラストラクチャーの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
仮想環境製品 | 必須バージョン |
---|---|
VMware 仮想ハードウェア | 15 以降 |
vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
VMware vSphere バージョン 7.0 および 7.0 Update 1 へのクラスターのインストールは非推奨になりました。これらのバージョンは引き続き完全にサポートされていますが、vSphere 6.x のすべてのバージョンはサポートされなくなりました。OpenShift Container Platform のバージョン 4.12 には、VMware 仮想ハードウェアバージョン 15 以降が必要です。vSphere 仮想マシンのハードウェアバージョンを更新するには、クラスターの更新 セクションの "Updating hardware on nodes running in vSphere" を参照してください。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat Customer Portal の ハードウェア を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 7.0 Update 2 以降、8.0 Update 1 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
6.5. VMware vSphere CSI Driver Operator の要件 リンクのコピーリンクがクリップボードにコピーされました!
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
6.6. ユーザーによってプロビジョニングされるインフラストラクチャーを使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
6.6.1. vCenter の要件 リンクのコピーリンクがクリップボードにコピーされました!
指定のインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの権限
OpenShift Container Platform クラスターを vCenter にインストールするには、vSphere アカウントに必要なリソースの読み取りと作成のための権限が含まれている必要があります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。
例6.1 vSphere API でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常に |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
例6.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常に |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
また、ユーザーには一部の ReadOnly
パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例6.3 必要なパーミッションおよび伝播の設定
vSphere オブジェクト | 必要になる場合 | 子への伝播 | 必要な権限 |
---|---|---|---|
vSphere vCenter | 常時 | False | 必要な特権がリスト表示 |
vSphere vCenter Datacenter | 既存のフォルダー | False |
|
インストールプログラムがフォルダーを作成する | True | 上記の必要な特権 | |
vSphere vCenter Cluster | 既存のリソースプール | False |
|
クラスタールートの仮想マシン | True | 必要な特権がリスト表示 | |
vSphere vCenter Datastore | 常時 | False | 上記の必要な特権 |
vSphere Switch | 常時 | False |
|
vSphere ポートグループ | 常時 | False | 上記の必要な特権 |
vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | 上記の必要な特権 |
vSphere vCenter リソースプール | 既存のリソースプール | True | 上記の必要な特権 |
必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
OpenShift Container Platform は通常、コンピュート専用の vMotion をサポートします。これは、一般に、vMotion に関するすべての VMware ベストプラクティスを満たすことを意味します。
コンピュートプレーンノードとコントロールプレーンノードの稼働時間を確保するには、vMotion に関する VMware のベストプラクティスに従い、VMware のアンチアフィニティールールを使用して、メンテナンスまたはハードウェアの問題時の OpenShift Container Platform の可用性を向上させます。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。Pod で vSphere ボリュームを使用している場合、手動または Storage vMotion を介してデータストア間で VM を移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生し、データ損失が発生する可能性があります。
- OpenShift Container Platform は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。
クラスターリソース
提供したインフラストラクチャーを使用する OpenShift Container Platform クラスターをデプロイする場合は、vCenter インスタンスに以下のリソースを作成する必要があります。
- 1 フォルダー
- 1 タグカテゴリー
- 1 タグ
仮想マシン:
- 1 テンプレート
- 1 一時的ブートストラップノード
- 3 コントロールプレーンノード
- 3 コンピュートマシン
これらのリソースは 856 GB のストレージを使用しますが、ブートストラップノードはクラスターのインストールプロセス時に破棄されます。標準クラスターを使用するには、最低 800 GB のストレージが必要です。
追加のコンピュートマシンをデプロイする場合、OpenShift Container Platform クラスターは追加のストレージを使用します。
クラスターの制限
利用可能なリソースはクラスターによって異なります。vCenter 内の予想されるクラスター数は、主に利用可能なストレージ容量と必要なリソース数の制限によって制限されます。クラスターが作成する vCenter リソースと、IP アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに Dynamic Host Configuration Protocol (DHCP) を使用して、クラスター内のマシンに永続的な IP アドレスを設定するように DHCP サーバーを設定できます。DHCP リースでは、デフォルトゲートウェイを使用するように DHCP を設定する必要があります。
静的 IP アドレスを使用してノードをプロビジョニングする場合は、ネットワークに DHCP を使用する必要はありません。
制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。
クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。
さらに、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 レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
6.6.2. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
ホスト | 説明 |
---|---|
1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を維持するには、これらのクラスターマシンに別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピュートマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 以降から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
6.6.3. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
---|---|---|---|---|---|
ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS が連動してスケーリングされるため、十分なパフォーマンスを得るには、ストレージボリュームを過剰に割り当てる必要がある場合がある点に注意してください。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
6.6.4. 証明書署名要求の管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求されるサービング証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
6.6.5. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。
クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。
DHCP サービスが user-provisioned infrastructure で利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
6.6.5.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost
または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
6.6.5.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
インターネットに接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Red Hat にテレメトリーデータを提供するために、すべてのノードがインターネットにアクセスできる必要があります。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| VXLAN |
| Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
|
UDP ポート
外部 NTP タイムサーバーが設定されている場合は、UDP ポート | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
Ethernet アダプターのハードウェアアドレス要件
クラスターの仮想マシンをプロビジョニングする場合、各仮想マシンに設定されたイーサネットインターフェイスは VMware Organizationally Unique Identifier (OUI) 割り当て範囲から MAC アドレスを使用する必要があります。
-
00:05:69:00:00:00
-00:05:69:FF:FF:FF
-
00:0c:29:00:00:00
-00:0c:29:FF:FF:FF
-
00:1c:14:00:00:00
-00:1c:14:FF:FF:FF
-
00:50:56:00:00:00
-00:50:56:FF:FF:FF
VMware OUI 外の MAC アドレスが使用される場合、クラスターのインストールは成功しません。
user-provisioned infrastructure の NTP 設定
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
6.6.6. ユーザーによってプロビジョニングされる DNS 要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。
- The Kubernetes API
- OpenShift Container Platform のアプリケーションワイルドカード
- ブートストラップ、コントロールプレーンおよびコンピュートマシン
また、Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンに逆引き DNS 解決も必要です。
DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。
各クラスターノードにホスト名を提供するために DHCP サーバーを使用することが推奨されます。詳細は、user-provisioned infrastructure に関する DHCP の推奨事項 のセクションを参照してください。
以下の DNS レコードは、user-provisioned OpenShift Container Platform クラスターに必要で、これはインストール前に設定されている必要があります。各レコードで、<cluster_name>
はクラスター名で、<base_domain>
は、install-config.yaml
ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
Kubernetes API |
| API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。 重要 API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。 | |
ルート |
| アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
ブートストラップマシン |
| ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コントロールプレーンマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコードこれらのレコードは、クラスター内のノードで解決できる必要があります。 |
コンピュートマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。
dig
コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
6.6.6.1. user-provisioned クラスターの DNS 設定の例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、クラスター名は ocp4
で、ベースドメインは example.com
です。
user-provisioned クラスターの DNS A レコードの設定例
BIND ゾーンファイルの以下の例は、user-provisioned クラスターの名前解決の A レコードの例を示しています。
例6.4 DNS ゾーンデータベースのサンプル
- 1
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
- 2
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
- 3
- ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
- 4
- ブートストラップマシンの名前解決を提供します。
- 5 6 7
- コントロールプレーンマシンの名前解決を提供します。
- 8 9
- コンピュートマシンの名前解決を提供します。
user-provisioned クラスターの DNS PTR レコードの設定例
以下の BIND ゾーンファイルの例では、user-provisioned クラスターの逆引き名前解決の PTR レコードの例を示しています。
例6.5 逆引きレコードの DNS ゾーンデータベースの例
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
6.6.7. ユーザーによってプロビジョニングされるインフラストラクチャーの負荷分散要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。
負荷分散インフラストラクチャーは以下の要件を満たす必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表6.10 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyz
エンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyz
エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz
の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとのプロービングで、2 回連続成功すると正常、3 回連続失敗すると異常と判断する設定は、十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。
以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ヒントクライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表6.11 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
6.6.7.1. ユーザーによってプロビジョニングされるクラスターのロードバランサーの設定例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、ユーザーによってプロビジョニングされるクラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg
設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
HAProxy をロードバランサーとして使用し、SELinux が enforcing
に設定されている場合は、setsebool -P haproxy_connect_any=1
を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。
例6.6 API およびアプリケーション Ingress ロードバランサーの設定例
- 1
- ポート
6443
は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。 - 2 4
- ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
- 3
- ポート
22623
はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。 - 5
- ポート
443
は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。 - 6
- ポート
80
は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe
を実行して、ポート 6443
、22623
、443
、および 80
で haproxy
プロセスがリッスンしていることを確認することができます。
6.7. user-provisioned infrastructure の準備 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。
このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続を設定し、ファイアウォール経由で必要なポートを有効にし、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。
準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。
前提条件
- OpenShift Container Platform 4.x のテスト済みインテグレーション を確認している。
- user-provisioned infrastructure を使用したクラスターの要件 で説明されているインフラストラクチャーの要件を確認している。
手順
DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。
- ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。
DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。
注記DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始 のセクションを参照してください。
DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項は、DHCP を使用したクラスターノードのホスト名の設定 参照してください。
注記DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。
- ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
重要デフォルトで、ポート
1936
は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。
クラスターに必要な DNS インフラストラクチャーを設定します。
- Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。
OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。
DNS 設定を検証します。
- インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。
DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
- 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。
6.8. user-provisioned infrastructure の DNS 解決の検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を user-provisioned infrastructure にインストールする前に、DNS 設定を検証できます。
このセクションの検証手順は、クラスターのインストール前に正常に実行される必要があります。
前提条件
- user-provisioned infrastructure に必要な DNS レコードを設定している。
手順
インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答に含まれる IP アドレスが正しいコンポーネントに対応することを確認します。
Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nameserver_ip>
をネームサーバーの IP アドレスに、<cluster_name>
をクラスター名に、<base_domain>
をベースドメイン名に置き換えます。
出力例
api.ocp4.example.com. 604800 IN A 192.168.1.5
api.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow *.apps.<cluster_name>.<base_domain>
DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
random
は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答に含まれるレコード名が正しいコンポーネントに対応することを確認します。
API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.5
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com. 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com.
1 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。
ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.96
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。
6.9. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
、ppc64le
、およびs390x
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。クラスターを独自にプロビジョニングするインフラストラクチャーにインストールする場合は、キーをインストールプログラムに指定する必要があります。
6.10. VMware vSphere のリージョンとゾーンの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
デフォルトのインストール設定では、クラスターが単一の 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 |
6.11. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
6.12. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための 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
ファイルを使用するため、今すぐこのファイルをバックアップしてください。
6.12.1. VMware vSphere のサンプル install-config.yaml ファイル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 4
controlPlane
セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン (-
) で始まり、controlPlane
セクションの最初の行はハイフン以外で始まる必要があります。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。- 3
replicas
パラメーターの値を0
に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、user-provisioned infrastructure を使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。- 5
- クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
- 6
- DNS レコードに指定したクラスター名。
- 7
- vCenter サーバーの完全修飾ホスト名または IP アドレス。重要
Cluster Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。
- 8
- サーバーにアクセスするユーザーの名前。
- 9
- vSphere ユーザーに関連付けられたパスワード。
- 10
- vSphere データセンター。
- 11
- 使用するデフォルトの vSphere データストア。
- 12
- オプションのパラメーター: インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例:
/<datacenter_name>/vm/<folder_name>/<subfolder_name>
)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thin
という名前のデフォルトのStorageClass
オブジェクトを使用したくない場合は、install-config.yaml
ファイルからfolder
パラメーターを省略できます。 - 13
- オプションのパラメーター: インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例:
/<datacenter_name>/vm/<folder_name>/<subfolder_name>
)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供する場合は、このパラメーターを省略します。 - 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 モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、
x86_64
、ppc64le
、およびs390x
アーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。 - 16
- OpenShift Cluster Manager Hybrid Cloud Console から取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
- 17
- Red Hat Enterprise Linux CoreOS (RHCOS) の
core
ユーザーのデフォルト SSH キーの公開部分。
6.12.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-config
namespace に生成します。次に 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
6.12.3. VMware vCenter のリージョンとゾーンの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
この例では、govc
コマンドを使用します。govc
コマンドは、VMware から入手できるオープンソースコマンドです。govc
コマンドは Red Hat からは入手できません。Red Hat サポートは govc
コマンドを保守しません。govc
のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイト を参照してください。
前提条件
既存の
install-config.yaml
インストール設定ファイルがあります。重要VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
注記VMware vSphere プラットフォームに OpenShift Container Platform クラスターをインストールした後は、障害ドメインを変更できません。クラスターのインストール後に、障害ドメインを追加できます。
手順
次の
govc
コマンドラインツールコマンドを入力して、openshift-region
およびopenshift-zone
vCenter タグカテゴリーを作成します。重要openshift-region
およびopenshift-zone
vCenter タグカテゴリーに異なる名前を指定すると、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 クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。
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 クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。
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> /<datacenter_1>
$ govc tags.attach -c <region_tag_category> <region_tag_1> /<datacenter_1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。
govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
$ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。
vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml
ファイル
- 1
- VMware vSphere リージョンおよびゾーン有効化機能を使用できるように、このパラメーターの値として
TechPreviewNoUpgrade
を設定するように定義する必要があります。 - 2 3
- vCenter クラスターを指定するためのオプションのパラメーター。ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。このパラメーターを定義しない場合、ノードは定義されているすべての障害ドメインに分散されます。 - 4 5 6 7 8 9 10 11
- デフォルトの vCenter トポロジー。インストールプログラムは、このトポロジー情報を使用してブートストラップノードをデプロイメントします。さらに、トポロジーは vSphere 永続ボリュームのデフォルトデータストアを定義します。
- 12
- リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 13
- 障害ドメインの名前を定義します。各障害ドメインは
zones
パラメーターで参照され、マシンプールの範囲が障害ドメインに設定されます。 - 14
- リージョンを定義するには、
openshift-region
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 15
- ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 16
- 障害ドメインに関連付けられた vCenter リソースを指定します。
- 17
- 障害ドメインに関連付けられた vSphere データセンターを定義するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 18
- 障害ドメインに関連付けられた計算クラスターの絶対ファイルパスを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 19
- インストーラーがプロビジョニングするインフラストラクチャーのオプションのパラメーター。このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例:
/<datacenter_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>
)。値を指定しない場合、リソースはクラスターのルート/example_datacenter/host/example_cluster/Resources
にインストールされます。 - 20
- 設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリストするオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 21
- ボリュームのプロビジョニングに使用するデータストアを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
6.13. Kubernetes マニフェストおよび Ignition 設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。
-
install-config.yaml
インストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
./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
ファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンおよびコンピュートマシンセットを定義する 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 これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。
- コンピュートマシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
<installation_directory>/manifests/cluster-scheduler-02-config.yml
Kubernetes マニフェストファイルのmastersSchedulable
パラメーターがfalse
に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルを開きます。 -
mastersSchedulable
パラメーターを見つけ、これがfalse
に設定されていることを確認します。 - ファイルを保存し、終了します。
-
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>
については、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-password
およびkubeconfig
ファイルが./<installation_directory>/auth
ディレクトリーに作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.14. インフラストラクチャー名の抽出 リンクのコピーリンクがクリップボードにコピーされました!
Ignition 設定ファイルには、VMware Cloud on AWS でクラスターを一意に識別するために使用できる一意のクラスター 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
- このコマンドの出力はクラスター名とランダムな文字列です。
6.15. 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
ファイルで指定したデータストアを選択します。
- 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
次のステップ
各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。
6.16. 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 をクリックします。
Edit Configuration をクリックし、Configuration Parameters ウィンドウで Add Configuration Params をクリックします。以下のパラメーター名および値を定義します。
-
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 を選択します。
次のステップ
- 継続してクラスター用の追加のコンピュートマシンを作成します。
6.17. ディスクパーティション設定 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの場合、データパーティションは、最初に別のオペレーティングシステムをインストールするのではなく、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
へのブート引数とオプションの両方があります。
個別の /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 インストール手順への入力として使用できます。
6.18. バイナリーのダウンロードによる OpenShift CLI のインストール リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインインターフェイスを使用して OpenShift Container Platform と対話するために CLI (oc
) をインストールすることができます。oc
は Linux、Windows、または macOS にインストールできます。
以前のバージョンの oc
をインストールしている場合、これを使用して OpenShift Container Platform 4.12 のすべてのコマンドを実行することはできません。新規バージョンの oc
をダウンロードし、インストールします。
Linux への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Linux にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- Product Variant ドロップダウンリストからアーキテクチャーを選択します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
アーカイブを展開します。
tar xvf <file>
$ tar xvf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc
バイナリーを、PATH
にあるディレクトリーに配置します。PATH
を確認するには、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Windows への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを Windows にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
- OpenShift v4.12 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
- ZIP プログラムでアーカイブを解凍します。
oc
バイナリーを、PATH
にあるディレクトリーに移動します。PATH
を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
C:\> oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
macOS への OpenShift CLI のインストール
以下の手順を使用して、OpenShift CLI (oc
) バイナリーを macOS にインストールできます。
手順
- Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
- バージョン ドロップダウンリストから適切なバージョンを選択します。
OpenShift v4.12 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
注記macOS arm64 の場合は、OpenShift v4.12 macOS arm64 Client エントリーを選択します。
- アーカイブを展開し、解凍します。
oc
バイナリーをパスにあるディレクトリーに移動します。PATH
を確認するには、ターミナルを開き、以下のコマンドを実行します。echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
OpenShift CLI のインストール後に、
oc
コマンドを使用して利用できます。oc <command>
$ oc <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.19. ブートストラッププロセスの完了まで待機する リンクのコピーリンクがクリップボードにコピーされました!
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.25.0 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.25.0 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 サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。
ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。
重要この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。
6.20. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI がインストールされている。
手順
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
6.21. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンに対して 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.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
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
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
6.22. 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 を設定します。
6.22.1. インストール時に削除されたイメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、Image Registry Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
6.22.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
6.22.2.1. VMware vSphere のレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- VMware vSphere 上のクラスター。
Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。
重要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
$ oc get pod -n openshift-image-registry -l docker-registry=default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resourses found in openshift-image-registry namespace
No resourses found in openshift-image-registry namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io
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
image-registry-storage
永続ボリューム要求 (PVC) の自動作成を許可するには、claim
フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
clusteroperator
ステータスを確認します。oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.22.2.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。
手順
イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。
oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告実稼働用以外のクラスターにのみこのオプションを設定します。
Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、
oc patch
コマンドは以下のエラーを出して失敗します。Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 数分待機した後に、このコマンドを再び実行します。
6.22.2.3. 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 vSpherePersistentVolumeClaim
オブジェクトを定義します。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-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
正しい PVC を参照するようにレジストリーストレージを設定する方法については、vSphere のレジストリーの設定 を参照 してください。
6.23. 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 への追加 に従い、クラスターのインストールの完了後に追加のコンピュートマシンを 追加できます。
6.24. VMware vSphere ボリュームのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップしたり、スナップショットからボリュームを復元したりすることはできません。詳細は、スナップショットの制限 を参照してください。
手順
永続ボリュームのバックアップを作成すには、以下を実行します。
- 永続ボリュームを使用しているアプリケーションを停止します。
- 永続ボリュームのクローンを作成します。
- アプリケーションを再起動します。
- クローンを作成したボリュームのバックアップを作成します。
- クローンを作成したボリュームを削除します。
6.25. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
6.26. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターをカスタマイズします。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- レジストリーを セットアップし、レジストリーストレージを設定し ます。
- オプション: vSphere Problem Detector Operator からのイベントを表示 し、クラスターにパーミッションまたはストレージ設定の問題があるかどうかを判別します。
第7章 ユーザーによってプロビジョニングされるインフラストラクチャーおよびネットワークのカスタマイズを使用した VMC へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、クラスターを VMware Cloud (VMC) on AWS にデプロイすることで、カスタマイズされるネットワーク設定オプションでプロビジョニングされるインフラストラクチャーを使用して VMware vSphere インスタンスにクラスターをインストールできます。
OpenShift Container Platform デプロイメント用に VMC 環境を設定した後に、VMC 環境に併設された bastion 管理ホストの OpenShift Container Platform インストールプログラムを使用します。インストールプログラムおよびコントロールプレーンは、OpenShift Container Platform クラスターに必要なリソースのデプロイおよび管理プロセスを自動化します。
ネットワーク設定をカスタマイズすることにより、クラスターは環境内の既存の IP アドレスの割り当てと共存でき、既存の VXLAN 設定と統合できます。大半のネットワーク設定パラメーターはインストール時に設定する必要があり、実行中のクラスターで変更できるのは kubeProxy
設定パラメーターのみになります。
OpenShift Container Platform は、単一の VMware vCenter へのクラスターのデプロイのみをサポートします。複数の vCenter にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。
7.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 アドレスが利用可能でなければなりません。
以下のファイアウォールルールを設定します。
- 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 ホスト間のアクセスを有効にするために作成されます。
7.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 のベストプラクティスに基づいてレポートを生成し、クラスター設定および必要なホスト数について推奨します。
7.2. vSphere 要件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認している。
- ブロックレジストリーストレージ をプロビジョニングしている。詳細は、永続ストレージについて を 参照 してください。
- ファイアウォールを使用する場合は、クラスターがアクセスを必要とするサイトを許可するようにファイアウォールを設定する必要がある。
7.3. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターをインストールするためにインターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプに応じて、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
7.4. VMware vSphere インフラストラクチャーの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
仮想環境製品 | 必須バージョン |
---|---|
VMware 仮想ハードウェア | 15 以降 |
vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
VMware vSphere バージョン 7.0 および 7.0 Update 1 へのクラスターのインストールは非推奨になりました。これらのバージョンは引き続き完全にサポートされていますが、vSphere 6.x のすべてのバージョンはサポートされなくなりました。OpenShift Container Platform のバージョン 4.12 には、VMware 仮想ハードウェアバージョン 15 以降が必要です。vSphere 仮想マシンのハードウェアバージョンを更新するには、クラスターの更新 セクションの "Updating hardware on nodes running in vSphere" を参照してください。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat Customer Portal の ハードウェア を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 7.0 Update 2 以降、8.0 Update 1 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
7.5. VMware vSphere CSI Driver Operator の要件 リンクのコピーリンクがクリップボードにコピーされました!
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
7.6. ユーザーによってプロビジョニングされるインフラストラクチャーを使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
7.6.1. vCenter の要件 リンクのコピーリンクがクリップボードにコピーされました!
指定のインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの権限
OpenShift Container Platform クラスターを vCenter にインストールするには、vSphere アカウントに必要なリソースの読み取りと作成のための権限が含まれている必要があります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。
例7.1 vSphere API でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常に |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
例7.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常に |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
また、ユーザーには一部の ReadOnly
パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例7.3 必要なパーミッションおよび伝播の設定
vSphere オブジェクト | 必要になる場合 | 子への伝播 | パーミッションが必要 |
---|---|---|---|
vSphere vCenter | 常に | False | 必要な特権がリスト表示 |
vSphere vCenter Datacenter | 既存のフォルダー | False |
|
インストールプログラムがフォルダーを作成する | True | リスト表示された必要な特権 | |
vSphere vCenter Cluster | 既存のリソースプール | False |
|
クラスタールートの仮想マシン | True | 必要な特権がリスト表示 | |
vSphere vCenter Datastore | 常に | False | 必要な特権がリスト表示 |
vSphere Switch | 常に | False |
|
vSphere ポートグループ | 常に | False | リスト表示された必要な特権 |
vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | リスト表示された必要な特権 |
vSphere vCenter リソースプール | 既存のリソースプール | True | リスト表示された必要な特権 |
必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
OpenShift Container Platform は通常、コンピュート専用の vMotion をサポートします。これは、一般に、vMotion に関するすべての VMware ベストプラクティスを満たすことを意味します。
コンピュートプレーンノードとコントロールプレーンノードの稼働時間を確保するには、vMotion に関する VMware のベストプラクティスに従い、VMware のアンチアフィニティールールを使用して、メンテナンスまたはハードウェアの問題時の OpenShift Container Platform の可用性を向上させます。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。Pod で vSphere ボリュームを使用している場合、手動または Storage vMotion を介してデータストア間で VM を移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生し、データ損失が発生する可能性があります。
- OpenShift Container Platform は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。
クラスターリソース
提供したインフラストラクチャーを使用する OpenShift Container Platform クラスターをデプロイする場合は、vCenter インスタンスに以下のリソースを作成する必要があります。
- 1 フォルダー
- 1 タグカテゴリー
- 1 タグ
仮想マシン:
- 1 テンプレート
- 1 一時的ブートストラップノード
- 3 コントロールプレーンノード
- 3 コンピュートマシン
これらのリソースは 856 GB のストレージを使用しますが、ブートストラップノードはクラスターのインストールプロセス時に破棄されます。標準クラスターを使用するには、最低 800 GB のストレージが必要です。
追加のコンピュートマシンをデプロイする場合、OpenShift Container Platform クラスターは追加のストレージを使用します。
クラスターの制限
利用可能なリソースはクラスターによって異なります。vCenter 内の予想されるクラスター数は、主に利用可能なストレージ容量と必要なリソース数の制限によって制限されます。クラスターが作成する vCenter リソースと、IP アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに Dynamic Host Configuration Protocol (DHCP) を使用して、クラスター内のマシンに永続的な IP アドレスを設定するように DHCP サーバーを設定できます。DHCP リースでは、デフォルトゲートウェイを使用するように DHCP を設定する必要があります。
静的 IP アドレスを使用してノードをプロビジョニングする場合は、ネットワークに DHCP を使用する必要はありません。
制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。
クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。
さらに、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 レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
7.6.2. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
ホスト | 説明 |
---|---|
1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を維持するには、これらのクラスターマシンについて別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピューティングマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
7.6.3. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
---|---|---|---|---|---|
ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
7.6.4. 証明書署名要求の管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
7.6.5. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。
クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。
DHCP サービスが user-provisioned infrastructure で利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
7.6.5.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost
または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
7.6.5.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するために、すべてのノードにインターネットへのアクセスが必要です。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリック |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| VXLAN |
| Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
|
UDP ポート
外部 NTP タイムサーバーが設定されている場合は、UDP ポート | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
Ethernet アダプターのハードウェアアドレス要件
クラスターの仮想マシンをプロビジョニングする場合、各仮想マシンに設定されたイーサネットインターフェイスは VMware Organizationally Unique Identifier (OUI) 割り当て範囲から MAC アドレスを使用する必要があります。
-
00:05:69:00:00:00
-00:05:69:FF:FF:FF
-
00:0c:29:00:00:00
-00:0c:29:FF:FF:FF
-
00:1c:14:00:00:00
-00:1c:14:FF:FF:FF
-
00:50:56:00:00:00
-00:50:56:FF:FF:FF
VMware OUI 外の MAC アドレスが使用される場合、クラスターのインストールは成功しません。
user-provisioned infrastructure の NTP 設定
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
7.6.6. ユーザーによってプロビジョニングされる DNS 要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。
- The Kubernetes API
- OpenShift Container Platform のアプリケーションワイルドカード
- ブートストラップ、コントロールプレーンおよびコンピュートマシン
また、Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンに逆引き DNS 解決も必要です。
DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。
各クラスターノードにホスト名を提供するために DHCP サーバーを使用することが推奨されます。詳細は、user-provisioned infrastructure に関する DHCP の推奨事項 のセクションを参照してください。
以下の DNS レコードは、user-provisioned OpenShift Container Platform クラスターに必要で、これはインストール前に設定されている必要があります。各レコードで、<cluster_name>
はクラスター名で、<base_domain>
は、install-config.yaml
ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
Kubernetes API |
| API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。 重要 API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。 | |
ルート |
| アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
ブートストラップマシン |
| ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コントロールプレーンマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコードこれらのレコードは、クラスター内のノードで解決できる必要があります。 |
コンピュートマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。
dig
コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
7.6.6.1. user-provisioned クラスターの DNS 設定の例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、クラスター名は ocp4
で、ベースドメインは example.com
です。
user-provisioned クラスターの DNS A レコードの設定例
BIND ゾーンファイルの以下の例は、user-provisioned クラスターの名前解決の A レコードの例を示しています。
例7.4 DNS ゾーンデータベースのサンプル
- 1
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
- 2
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
- 3
- ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
- 4
- ブートストラップマシンの名前解決を提供します。
- 5 6 7
- コントロールプレーンマシンの名前解決を提供します。
- 8 9
- コンピュートマシンの名前解決を提供します。
user-provisioned クラスターの DNS PTR レコードの設定例
以下の BIND ゾーンファイルの例では、user-provisioned クラスターの逆引き名前解決の PTR レコードの例を示しています。
例7.5 逆引きレコードの DNS ゾーンデータベースの例
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
7.6.7. ユーザーによってプロビジョニングされるインフラストラクチャーの負荷分散要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。
負荷分散インフラストラクチャーは以下の要件を満たす必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表7.10 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyz
エンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyz
エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz
の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が正常な状態になり、3 つの要求が正常な状態になりません。これらは十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。
以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ヒントクライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表7.11 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
7.6.7.1. ユーザーによってプロビジョニングされるクラスターのロードバランサーの設定例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、ユーザーによってプロビジョニングされるクラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg
設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
HAProxy をロードバランサーとして使用し、SELinux が enforcing
に設定されている場合は、setsebool -P haproxy_connect_any=1
を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。
例7.6 API およびアプリケーション Ingress ロードバランサーの設定例
- 1
- ポート
6443
は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。 - 2 4
- ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
- 3
- ポート
22623
はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。 - 5
- ポート
443
は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。 - 6
- ポート
80
は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe
を実行して、ポート 6443
、22623
、443
、および 80
で haproxy
プロセスがリッスンしていることを確認することができます。
7.7. user-provisioned infrastructure の準備 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。
このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続を設定し、ファイアウォール経由で必要なポートを有効にし、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。
準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。
前提条件
- OpenShift Container Platform 4.x のテスト済みインテグレーション を確認している。
- user-provisioned infrastructure を使用したクラスターの要件で説明されているインフラストラクチャーの要件を確認している。
手順
DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。
- ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。
DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。
注記DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。
DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項については、DHCP を使用したクラスターノードのホスト名の設定 参照してください。
注記DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。
- ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
重要デフォルトで、ポート
1936
は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。
クラスターに必要な DNS インフラストラクチャーを設定します。
- Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。
OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。
DNS 設定を検証します。
- インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。
DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
- 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。
7.8. user-provisioned infrastructure の DNS 解決の検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を user-provisioned infrastructure にインストールする前に、DNS 設定を検証できます。
このセクションの検証手順は、クラスターのインストール前に正常に実行される必要があります。
前提条件
- user-provisioned infrastructure に必要な DNS レコードを設定している。
手順
インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答に含まれる IP アドレスが正しいコンポーネントに対応することを確認します。
Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nameserver_ip>
をネームサーバーの IP アドレスに、<cluster_name>
をクラスター名に、<base_domain>
をベースドメイン名に置き換えます。
出力例
api.ocp4.example.com. 604800 IN A 192.168.1.5
api.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow *.apps.<cluster_name>.<base_domain>
DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
random
は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答に含まれるレコード名が正しいコンポーネントに対応することを確認します。
API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.5
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com. 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com.
1 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。
ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.96
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。
7.9. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
、ppc64le
、およびs390x
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
7.10. VMware vSphere のリージョンとゾーンの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
デフォルトのインストール設定では、クラスターが単一の 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 |
7.11. インストールプログラムの取得 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、インストールに使用しているホストにインストールファイルをダウンロードします。
前提条件
- 500 MB のローカルディスク領域がある Linux または macOS を実行するコンピューターが必要です。
手順
- OpenShift Cluster Manager サイトの インフラストラクチャープロバイダー ページにアクセスします。Red Hat アカウントがある場合は、認証情報を使用してログインします。アカウントがない場合はこれを作成します。
- インフラストラクチャープロバイダーを選択します。
インストールタイプのページに移動し、ホストオペレーティングシステムとアーキテクチャーに対応するインストールプログラムをダウンロードして、インストール設定ファイルを保存するディレクトリーにファイルを配置します。
重要インストールプログラムは、クラスターのインストールに使用するコンピューターにいくつかのファイルを作成します。クラスターのインストール完了後は、インストールプログラムおよびインストールプログラムが作成するファイルを保持する必要があります。ファイルはいずれもクラスターを削除するために必要になります。
重要インストールプログラムで作成されたファイルを削除しても、クラスターがインストール時に失敗した場合でもクラスターは削除されません。クラスターを削除するには、特定のクラウドプロバイダー用の OpenShift Container Platform のアンインストール手順を実行します。
インストールプログラムを展開します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
tar -xvf openshift-install-linux.tar.gz
$ tar -xvf openshift-install-linux.tar.gz
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Cluster Manager からインストールプルシークレット をダウンロードします。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
7.12. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための 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
ファイルを使用するため、今すぐこのファイルをバックアップしてください。
7.12.1. VMware vSphere のサンプル install-config.yaml ファイル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 4
controlPlane
セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン (-
) で始まり、controlPlane
セクションの最初の行はハイフン以外で始まる必要があります。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。- 3
replicas
パラメーターの値を0
に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、user-provisioned infrastructure を使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。- 5
- クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
- 6
- DNS レコードに指定したクラスター名。
- 7
- vCenter サーバーの完全修飾ホスト名または IP アドレス。重要
Cluster Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。
- 8
- サーバーにアクセスするユーザーの名前。
- 9
- vSphere ユーザーに関連付けられたパスワード。
- 10
- vSphere データセンター。
- 11
- 使用するデフォルトの vSphere データストア。
- 12
- オプションのパラメーター: インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例:
/<datacenter_name>/vm/<folder_name>/<subfolder_name>
)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thin
という名前のデフォルトのStorageClass
オブジェクトを使用したくない場合は、install-config.yaml
ファイルからfolder
パラメーターを省略できます。 - 13
- オプションのパラメーター: インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例:
/<datacenter_name>/vm/<folder_name>/<subfolder_name>
)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供する場合は、このパラメーターを省略します。 - 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 モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、
x86_64
、ppc64le
、およびs390x
アーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。 - 16
- OpenShift Cluster Manager Hybrid Cloud Console から取得したプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
- 17
- Red Hat Enterprise Linux CoreOS (RHCOS) の
core
ユーザーのデフォルト SSH キーの公開部分。
7.12.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-config
namespace に生成します。次に 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
7.12.3. VMware vCenter のリージョンとゾーンの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
この例では、govc
コマンドを使用します。govc
コマンドは、VMware から入手できるオープンソースコマンドです。govc
コマンドは Red Hat からは入手できません。Red Hat サポートは govc
コマンドを保守しません。govc
のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイト を参照してください。
前提条件
既存の
install-config.yaml
インストール設定ファイルがあります。重要VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
注記VMware vSphere プラットフォームに OpenShift Container Platform クラスターをインストールした後は、障害ドメインを変更できません。クラスターのインストール後に、障害ドメインを追加できます。
手順
次の
govc
コマンドラインツールコマンドを入力して、openshift-region
およびopenshift-zone
vCenter タグカテゴリーを作成します。重要openshift-region
およびopenshift-zone
vCenter タグカテゴリーに異なる名前を指定すると、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 クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。
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 クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。
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> /<datacenter_1>
$ govc tags.attach -c <region_tag_category> <region_tag_1> /<datacenter_1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。
govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
$ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。
vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml
ファイル
- 1
- VMware vSphere リージョンおよびゾーン有効化機能を使用できるように、このパラメーターの値として
TechPreviewNoUpgrade
を設定するように定義する必要があります。 - 2 3
- vCenter クラスターを指定するためのオプションのパラメーター。ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。このパラメーターを定義しない場合、ノードは定義されているすべての障害ドメインに分散されます。 - 4 5 6 7 8 9 10 11
- デフォルトの vCenter トポロジー。インストールプログラムは、このトポロジー情報を使用してブートストラップノードをデプロイメントします。さらに、トポロジーは vSphere 永続ボリュームのデフォルトデータストアを定義します。
- 12
- リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 13
- 障害ドメインの名前を定義します。各障害ドメインは
zones
パラメーターで参照され、マシンプールの範囲が障害ドメインに設定されます。 - 14
- リージョンを定義するには、
openshift-region
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 15
- ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 16
- 障害ドメインに関連付けられた vCenter リソースを指定します。
- 17
- 障害ドメインに関連付けられた vSphere データセンターを定義するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 18
- 障害ドメインに関連付けられた計算クラスターの絶対ファイルパスを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 19
- インストーラーがプロビジョニングするインフラストラクチャーのオプションのパラメーター。このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例:
/<datacenter_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>
)。値を指定しない場合、リソースはクラスターのルート/example_datacenter/host/example_cluster/Resources
にインストールされます。 - 20
- 設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリストするオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 21
- ボリュームのプロビジョニングに使用するデータストアを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
7.13. 高度なネットワーク設定の指定 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークプラグインに高度なネットワーク設定を使用し、クラスターを既存のネットワーク環境に統合することができます。高度なネットワーク設定は、クラスターのインストール前にのみ指定することができます。
インストールプロブラムで作成される 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
ファイルで、クラスターの高度なネットワーク設定を指定します。OpenShift SDN ネットワークプロバイダーに異なる VXLAN ポートを指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OVN-Kubernetes ネットワークプロバイダーの IPsec を有効にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション:
manifests/cluster-network-03-config.yml
ファイルをバックアップします。インストールプログラムは、Ignition 設定ファイルの作成時にmanifests/
ディレクトリーを使用します。 コントロールプレーンマシンおよび compute 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 を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
7.14. Cluster Network Operator (CNO) の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターネットワークの設定は、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
- OpenShift SDN や OVN-Kubernetes などのクラスターネットワークプラグイン。
defaultNetwork
オブジェクトのフィールドを cluster
という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
7.14.1. Cluster Network Operator 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
フィールド | タイプ | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。
マニフェストを作成する前に、このフィールドを |
|
| サービスの IP アドレスのブロック。OpenShift SDN および 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 ネットワークプラグインに影響が及ぶ可能性があり、プラグインは異なるノード間でオブジェクトトラフィックを効果的にルーティングすることはできません。
defaultNetwork オブジェクト設定
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
フィールド | タイプ | 説明 |
---|---|---|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。 |
|
| このオブジェクトは、OpenShift SDN ネットワークプラグインに対してのみ有効です。 |
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
OpenShift SDN ネットワークプラグインの設定
以下の表では、OpenShift SDN ネットワークプラグインの設定フィールドを説明します。
フィールド | タイプ | 説明 |
---|---|---|
|
|
OpenShift SDN のネットワーク分離モードを設定します。デフォルト値は
|
|
| VXLAN オーバーレイネットワークの最大転送単位 (MTU)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも クラスターインストール時またはインストール後のタスクとして値を設定できます。詳細は、OpenShift Container Platform Networking ドキュメントの "Changing the MTU for the cluster network" を参照してください。 |
|
|
すべての VXLAN パケットに使用するポート。デフォルト値は 別の VXLAN ネットワークの一部である既存ノードと共に仮想化環境で実行している場合は、これを変更する必要がある可能性があります。たとえば、OpenShift SDN オーバーレイを VMware NSX-T 上で実行する場合は、両方の SDN が同じデフォルトの VXLAN ポート番号を使用するため、VXLAN の別のポートを選択する必要があります。
Amazon Web Services (AWS) では、VXLAN にポート |
OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
フィールド | タイプ | 説明 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。これは、プライマリーネットワークインターフェイスの MTU に基づいて自動的に検出されます。通常、検出された MTU を上書きする必要はありません。 自動検出した値が予想される値ではない場合は、ノード上のプライマリーネットワークインターフェイスの MTU が正しいことを確認します。このオプションを使用して、ノード上のプライマリーネットワークインターフェイスの MTU 値を変更することはできません。
クラスターで異なるノードに異なる MTU 値が必要な場合、この値をクラスター内の最小の MTU 値よりも |
|
|
すべての Geneve パケットに使用するポート。デフォルト値は |
|
| IPsec 暗号化を有効にするために空のオブジェクトを指定します。 |
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
| オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
|
既存のネットワークインフラストラクチャーが このフィールドは、インストール後に変更できません。 |
デフォルト値は |
フィールド | タイプ | 説明 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
フィールド | タイプ | 説明 |
---|---|---|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを 注記
OpenShift Container Platform 4.12 では、egress IP はプライマリーインターフェイスのみに割り当てられます。そのため、
インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
IPsec が有効な OVN-Kubernetes 設定の例
kubeProxyConfig オブジェクト設定
kubeProxyConfig
オブジェクトの値は以下の表で定義されます。
フィールド | タイプ | 説明 |
---|---|---|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s
|
7.15. 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
7.16. インフラストラクチャー名の抽出 リンクのコピーリンクがクリップボードにコピーされました!
Ignition 設定ファイルには、VMware Cloud on AWS でクラスターを一意に識別するために使用できる一意のクラスター 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
- このコマンドの出力はクラスター名とランダムな文字列です。
7.17. 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
ファイルで指定したデータストアを選択します。
- 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
次のステップ
各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。
7.18. 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 をクリックします。
Edit Configuration をクリックし、Configuration Parameters ウィンドウで Add Configuration Params をクリックします。以下のパラメーター名および値を定義します。
-
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 を選択します。
次のステップ
- 継続してクラスター用の追加のコンピュートマシンを作成します。
7.19. ディスクパーティション設定 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの場合、データパーティションは、最初に別のオペレーティングシステムをインストールするのではなく、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
へのブート引数とオプションの両方があります。
個別の /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 インストール手順への入力として使用できます。
7.20. ブートストラッププロセスの完了まで待機する リンクのコピーリンクがクリップボードにコピーされました!
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.25.0 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.25.0 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 サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。
ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。
重要この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。
7.21. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
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
7.22. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 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.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
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
サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。それらを個別に承認するには、それぞれの有効な 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
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
7.23. 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 を設定します。
7.23.1. インストール時に削除されたイメージレジストリー リンクのコピーリンクがクリップボードにコピーされました!
共有可能なオブジェクトストレージを提供しないプラットフォームでは、OpenShift Image Registry Operator 自体が Removed
としてブートストラップされます。これにより、openshift-installer
がそれらのプラットフォームタイプでのインストールを完了できます。
インストール後に、Image Registry Operator 設定を編集して managementState
を Removed
から Managed
に切り替える必要があります。これが完了したら、ストレージを設定する必要があります。
7.23.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
7.23.2.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 vSpherePersistentVolumeClaim
オブジェクトを定義します。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-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
正しい PVC を参照するようにレジストリーストレージを設定する手順は、vSphere のレジストリーの設定 を参照してください。
7.24. 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 への追加 に従って、コンピュートマシンをさらに追加できます。
7.25. VMware vSphere ボリュームのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップしたり、スナップショットからボリュームを復元したりすることはできません。詳細は、スナップショットの制限 を参照してください。
手順
永続ボリュームのバックアップを作成すには、以下を実行します。
- 永続ボリュームを使用しているアプリケーションを停止します。
- 永続ボリュームのクローンを作成します。
- アプリケーションを再起動します。
- クローンを作成したボリュームのバックアップを作成します。
- クローンを作成したボリュームを削除します。
7.26. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
7.27. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターのカスタマイズ
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- レジストリーをセットアップし、レジストリーストレージを設定 します。
- オプション: vSphere Problem Detector Operator からのイベントを表示 し、クラスターにパーミッションまたはストレージ設定の問題があるかどうかを判別します。
第8章 ユーザーによってプロビジョニングされるインフラストラクチャーのネットワークが制限された環境での VMC へのクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform バージョン 4.12 では、クラスターを 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 にマシン/マシンセットを含むクラスターをデプロイすることはサポートされていません。
8.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 アドレスが利用可能でなければなりません。
以下のファイアウォールルールを設定します。
- ポート 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 ホスト間のアクセスを有効にするために作成されます。
8.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 のベストプラクティスに基づいてレポートを生成し、クラスター設定および必要なホスト数について推奨します。
8.2. vSphere 要件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認した。
- クラスターインストール方法の選択およびそのユーザー向けの準備 を確認した。
ミラーホストでレジストリーを作成 しており、使用しているバージョンの OpenShift Container Platform の
imageContentSources
データを取得している。重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
- ブロックレジストリーストレージ をプロビジョニングしている。詳細は、永続ストレージについて を参照してください。
クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
注記プロキシーを設定する場合は、このサイトリストも確認してください。
8.3. ネットワークが制限された環境でのインストールについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェア、Nutanix、または VMware vSphere へのインストールに必要なインターネットアクセスが少なくて済む場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift イメージレジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
user-provisioned installation の設定は複雑であるため、user-provisioned infrastructure を使用してネットワークが制限されたインストールを試行する前に、標準的な user-provisioned infrastructure を実行することを検討してください。このテストが完了すると、ネットワークが制限されたインストール時に発生する可能性のある問題の切り分けやトラブルシューティングがより容易になります。
8.3.1. その他の制限 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersion
ステータスにはUnable to retrieve available updates
エラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
8.4. OpenShift Container Platform のインターネットアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターのインストールに必要なイメージを取得するために、インターネットにアクセスする必要があります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager Hybrid Cloud Console にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにインストールパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
8.5. VMware vSphere インフラストラクチャーの要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、使用するコンポーネントの要件に合わせて、以下に示す VMware vSphere インスタンスのいずれかのバージョンにインストールする必要があります。
- バージョン 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降
- バージョン 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
VMware vSphere インフラストラクチャーは、オンプレミスまたは次の表に示す要件を満たす VMware Cloud Verified プロバイダー でホストできます。
仮想環境製品 | 必須バージョン |
---|---|
VMware 仮想ハードウェア | 15 以降 |
vSphere ESXi ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
vCenter ホスト | 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 |
VMware vSphere バージョン 7.0 および 7.0 Update 1 へのクラスターのインストールは非推奨になりました。これらのバージョンは引き続き完全にサポートされていますが、vSphere 6.x のすべてのバージョンはサポートされなくなりました。OpenShift Container Platform のバージョン 4.12 には、VMware 仮想ハードウェアバージョン 15 以降が必要です。vSphere 仮想マシンのハードウェアバージョンを更新するには、クラスターの更新 セクションの "Updating hardware on nodes running in vSphere" を参照してください。
コンポーネント | サポートされる最小バージョン | 説明 |
---|---|---|
ハイパーバイザー | vSphere 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、vSphere 8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降 (仮想ハードウェアバージョン 15) | このハイパーバイザーのバージョンは、Red Hat Enterprise Linux CoreOS (RHCOS) がサポートする最小バージョンです。RHCOS と互換性のある Red Hat Enterprise Linux (RHEL) の最新バージョンでサポートされているハードウェアの詳細は、Red Hat Customer Portal の ハードウェア を参照してください。 |
ストレージおよび In-tree ドライバー | vSphere 7.0 Update 2 以降、8.0 Update 1 以降 | このプラグインは、OpenShift Container Platform に含まれる vSphere の In-tree ストレージドライバーを使用して vSphere ストレージを作成します。 |
OpenShift Container Platform をインストールする前に、ESXi ホストの時間が同期されていることを確認する必要があります。VMware ドキュメントの Edit Time Configuration for a Host を参照してください。
8.6. VMware vSphere CSI Driver Operator の要件 リンクのコピーリンクがクリップボードにコピーされました!
vSphere CSI Driver Operator をインストールするには、次の要件を満たす必要があります。
- VMware vSphere バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- vCenter バージョン: 7.0 Update 2 以降、または VMware Cloud Foundation 4.3 以降、8.0 Update 1 以降、または VMware Cloud Foundation 5.0 以降
- ハードウェアバージョン 15 以降の仮想マシン
- クラスターにサードパーティーの vSphere CSI ドライバーがインストールされていない
サードパーティーの vSphere CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの vSphere CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。
VMware vSphere CSI Driver Operator は、インストールマニフェストの platform: vsphere
でデプロイされたクラスターでのみサポートされます。
8.7. ユーザーによってプロビジョニングされるインフラストラクチャーを使用したクラスターの要件 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure を含むクラスターの場合、必要なマシンすべてをデプロイする必要があります。
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイする要件を説明します。
8.7.1. vCenter の要件 リンクのコピーリンクがクリップボードにコピーされました!
指定のインフラストラクチャーを使用する OpenShift Container Platform クラスターを vCenter にインストールする前に、環境を準備する必要があります。
必要な vCenter アカウントの権限
OpenShift Container Platform クラスターを vCenter にインストールするには、vSphere アカウントに必要なリソースの読み取りと作成のための権限が含まれている必要があります。グローバル管理者権限のあるアカウントを使用すること方法が、必要なすべてのパーミッションにアクセスするための最も簡単な方法です。
例8.1 vSphere API でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vSphere API で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常に |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
例8.2 vCenter グラフィカルユーザーインターフェイス (GUI) でのインストールに必要なロールと権限
ロールの vSphere オブジェクト | 必要になる場合 | vCenter GUI で必要な権限 |
---|---|---|
vSphere vCenter | 常に |
|
vSphere vCenter Cluster | 仮想マシンがクラスタールートに作成される場合 |
|
vSphere vCenter リソースプール | 既存のリソースプールが提供されている場合 |
|
vSphere Datastore | 常に |
|
vSphere ポートグループ | 常に |
|
仮想マシンフォルダー | 常に |
|
vSphere vCenter Datacenter |
インストールプログラムが仮想マシンフォルダーを作成する場合。UPI の場合、クラスターが Machine API を使用しないのであれば |
|
また、ユーザーには一部の ReadOnly
パーミッションが必要であり、一部のロールでは、パーミッションを子オブジェクトに伝播するパーミッションが必要です。これらの設定は、クラスターを既存のフォルダーにインストールするかどうかによって異なります。
例8.3 必要なパーミッションおよび伝播の設定
vSphere オブジェクト | 必要になる場合 | 子への伝播 | パーミッションが必要 |
---|---|---|---|
vSphere vCenter | 常に | False | 必要な特権がリスト表示 |
vSphere vCenter Datacenter | 既存のフォルダー | False |
|
インストールプログラムがフォルダーを作成する | True | リスト表示された必要な特権 | |
vSphere vCenter Cluster | 既存のリソースプール | False |
|
クラスタールートの仮想マシン | True | リスト表示された必要な特権 | |
vSphere vCenter Datastore | 常に | False | リスト表示された必要な特権 |
vSphere Switch | 常に | False |
|
vSphere ポートグループ | 常に | False | リスト表示された必要な特権 |
vSphere vCenter 仮想マシンフォルダー | 既存のフォルダー | True | リスト表示された必要な特権 |
vSphere vCenter リソースプール | 既存のリソースプール | True | リスト表示された必要な特権 |
必要な権限のみを持つアカウントの作成に関する詳細は、vSphere ドキュメントの vSphere Permissions and User Management Tasks を参照してください。
OpenShift Container Platform と vMotion の使用
vSphere 環境で vMotion を使用する場合は、OpenShift Container Platform クラスターをインストールする前に以下を考慮してください。
OpenShift Container Platform は通常、コンピュート専用の vMotion をサポートします。これは、一般に、vMotion に関するすべての VMware ベストプラクティスを満たすことを意味します。
コンピュートプレーンノードとコントロールプレーンノードの稼働時間を確保するには、vMotion に関する VMware のベストプラクティスに従い、VMware のアンチアフィニティールールを使用して、メンテナンスまたはハードウェアの問題時の OpenShift Container Platform の可用性を向上させます。
vMotion および anti-affinity ルールの詳細は、vMotion ネットワーク要件 および VM の非アフィニティールール に関する VMware vSphere のドキュメントを参照してください。
- Storage vMotion を使用すると問題が発生する可能性があるため、これはサポートされていません。Pod で vSphere ボリュームを使用している場合、手動または Storage vMotion を介してデータストア間で VM を移行すると、OpenShift Container Platform 永続ボリューム (PV) オブジェクト内で無効な参照が発生し、データ損失が発生する可能性があります。
- OpenShift Container Platform は、仮想マシンのプロビジョニング用にデータストアクラスターを、または PV の動的または静的プロビジョニング用にデータストアクラスターを使用するか、PV の動的または静的プロビジョニング用にデータストアクラスターの一部であるデータストアを使用した VMDK のデータストア間での選択的な移行をサポートしません。
クラスターリソース
提供したインフラストラクチャーを使用する OpenShift Container Platform クラスターをデプロイする場合は、vCenter インスタンスに以下のリソースを作成する必要があります。
- 1 フォルダー
- 1 タグカテゴリー
- 1 タグ
仮想マシン:
- 1 テンプレート
- 1 一時的ブートストラップノード
- 3 コントロールプレーンノード
- 3 コンピュートマシン
これらのリソースは 856 GB のストレージを使用しますが、ブートストラップノードはクラスターのインストールプロセス時に破棄されます。標準クラスターを使用するには、最低 800 GB のストレージが必要です。
追加のコンピュートマシンをデプロイする場合、OpenShift Container Platform クラスターは追加のストレージを使用します。
クラスターの制限
利用可能なリソースはクラスターによって異なります。vCenter 内の予想されるクラスター数は、主に利用可能なストレージ容量と必要なリソース数の制限によって制限されます。クラスターが作成する vCenter リソースと、IP アドレスやネットワークなどのクラスターのデプロイに必要なリソースの両方の制限を考慮してください。
ネットワーク要件
ネットワークに Dynamic Host Configuration Protocol (DHCP) を使用して、クラスター内のマシンに永続的な IP アドレスを設定するように DHCP サーバーを設定できます。DHCP リースでは、デフォルトゲートウェイを使用するように DHCP を設定する必要があります。
静的 IP アドレスを使用してノードをプロビジョニングする場合は、ネットワークに DHCP を使用する必要はありません。
制限された環境にインストールする場合、制限されたネットワーク内の仮想マシンは、ノード、永続ボリュームクレーム (PVC)、およびその他のリソースをプロビジョニングおよび管理するために、vCenter にアクセスできる必要があります。
クラスター内の各 OpenShift Container Platform ノードが、DHCP によって検出可能な Network Time Protocol (NTP) サーバーにアクセスできることを確認してください。NTP サーバーがなくてもインストールは可能です。ただし、非同期のサーバークロックにより、エラーが発生する可能性があります。NTP サーバーがあれば、このエラーは防止されます。
さらに、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 レコードです。このレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
8.7.2. クラスターのインストールに必要なマシン リンクのコピーリンクがクリップボードにコピーされました!
最小の OpenShift Container Platform クラスターでは以下のホストが必要です。
ホスト | 説明 |
---|---|
1 つの一時的なブートストラップマシン | クラスターでは、ブートストラップマシンが OpenShift Container Platform クラスターを 3 つのコントロールプレーンマシンにデプロイする必要があります。クラスターのインストール後にブートストラップマシンを削除できます。 |
3 つのコントロールプレーンマシン | コントロールプレーンマシンは、コントロールプレーンを設定する Kubernetes および OpenShift Container Platform サービスを実行します。 |
少なくとも 2 つのコンピュートマシン (ワーカーマシンとしても知られる)。 | OpenShift Container Platform ユーザーが要求するワークロードは、コンピュートマシンで実行されます。 |
クラスターの高可用性を維持するには、これらのクラスターマシンについて別の物理ホストを使用します。
ブートストラップおよびコントロールプレーンマシンでは、Red Hat Enterprise Linux CoreOS (RHCOS) をオペレーティングシステムとして使用する必要があります。ただし、コンピューティングマシンは、Red Hat Enterprise Linux CoreOS (RHCOS)、Red Hat Enterprise Linux (RHEL) 8.6 から選択できます。
RHCOS は Red Hat Enterprise Linux (RHEL) 8 をベースとしており、そのハードウェア認定および要件が継承されることに注意してください。Red Hat Enterprise Linux テクノロジーの機能と制限 を参照してください。
8.7.3. クラスターインストールの最小リソース要件 リンクのコピーリンクがクリップボードにコピーされました!
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | vCPU [1] | 仮想 RAM | ストレージ | 1 秒あたりの入出力 (IOPS) [2] |
---|---|---|---|---|---|
ブートストラップ | RHCOS | 4 | 16 GB | 100 GB | 300 |
コントロールプレーン | RHCOS | 4 | 16 GB | 100 GB | 300 |
Compute | RHCOS、RHEL 8.6 以降 [3] | 2 | 8 GB | 100 GB | 300 |
- 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = vCPU
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd については、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
8.7.4. 証明書署名要求の管理 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーがプロビジョニングするインフラストラクチャーを使用する場合、クラスターの自動マシン管理へのアクセスは制限されるため、インストール後にクラスターの証明書署名要求 (CSR) のメカニズムを提供する必要があります。kube-controller-manager
は kubelet クライアント CSR のみを承認します。machine-approver
は、kubelet 認証情報を使用して要求される提供証明書の有効性を保証できません。適切なマシンがこの要求を発行したかどうかを確認できないためです。kubelet 提供証明書の要求の有効性を検証し、それらを承認する方法を判別し、実装する必要があります。
8.7.5. user-provisioned infrastructure のネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
初回の起動時に、マシンには DHCP サーバーを使用して設定される IP アドレス設定、または必要な起動オプションを指定して静的に設定される IP アドレス設定が必要です。ネットワーク設定の確立後に、マシンは HTTP または HTTPS サーバーから Ignition 設定ファイルをダウンロードします。その後、Ignition 設定ファイルは各マシンの正確な状態を設定するために使用されます。Machine Config Operator はインストール後に、新しい証明書やキーの適用など、マシンへの追加の変更を完了します。
クラスターマシンの長期管理に DHCP サーバーを使用することが推奨されます。DHCP サーバーが永続 IP アドレス、DNS サーバー情報、およびホスト名をクラスターマシンに提供するように設定されていることを確認します。
DHCP サービスが user-provisioned infrastructure で利用できない場合は、IP ネットワーク設定および DNS サーバーのアドレスを RHCOS のインストール時にノードに提供することができます。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
8.7.5.1. DHCP を使用したクラスターノードのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、ホスト名は NetworkManager 経由で設定されます。デフォルトでは、マシンは DHCP 経由でホスト名を取得します。ホスト名が DHCP によって提供されない場合、カーネル引数を介して静的に設定される場合、または別の方法でホスト名が取得される場合は、逆引き DNS ルックアップによって取得されます。逆引き DNS ルックアップは、ネットワークがノードで初期化された後に発生し、解決に時間がかかる場合があります。その他のシステムサービスは、これより前に起動し、ホスト名を localhost
または同様のものとして検出できます。これを回避するには、DHCP を使用して各クラスターノードのホスト名を指定できます。
また、DHCP を介してホスト名を設定すると、DNS スプリットホライズンが実装されている環境での手動の DNS レコード名設定エラーを回避できます。
8.7.5.2. ネットワーク接続の要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
このセクションでは、必要なポートの詳細を説明します。
接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するために、すべてのノードにインターネットへのアクセスが必要です。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリック |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| VXLAN |
| Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
|
UDP ポート
外部 NTP タイムサーバーが設定されている場合は、UDP ポート | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
Ethernet アダプターのハードウェアアドレス要件
クラスターの仮想マシンをプロビジョニングする場合、各仮想マシンに設定されたイーサネットインターフェイスは VMware Organizationally Unique Identifier (OUI) 割り当て範囲から MAC アドレスを使用する必要があります。
-
00:05:69:00:00:00
-00:05:69:FF:FF:FF
-
00:0c:29:00:00:00
-00:0c:29:FF:FF:FF
-
00:1c:14:00:00:00
-00:1c:14:FF:FF:FF
-
00:50:56:00:00:00
-00:50:56:FF:FF:FF
VMware OUI 外の MAC アドレスが使用される場合、クラスターのインストールは成功しません。
user-provisioned infrastructure の NTP 設定
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、クラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
DHCP サーバーが NTP サーバー情報を提供する場合、Red Hat Enterprise Linux CoreOS (RHCOS) マシンの chrony タイムサービスは情報を読み取り、NTP サーバーとクロックを同期できます。
8.7.6. ユーザーによってプロビジョニングされる DNS 要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。
- The Kubernetes API
- OpenShift Container Platform のアプリケーションワイルドカード
- ブートストラップ、コントロールプレーンおよびコンピュートマシン
また、Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンに逆引き DNS 解決も必要です。
DNS A/AAAA または CNAME レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。ホスト名が DHCP によって提供されていない場合は、Red Hat Enterprise Linux CoreOS (RHCOS) は逆引きレコードを使用してすべてのノードのホスト名を設定するため、逆引きレコードは重要です。さらに、逆引きレコードは、OpenShift Container Platform が動作するために必要な証明書署名要求 (CSR) を生成するために使用されます。
各クラスターノードにホスト名を提供するために DHCP サーバーを使用することが推奨されます。詳細は、user-provisioned infrastructure に関する DHCP の推奨事項 のセクションを参照してください。
以下の DNS レコードは、user-provisioned OpenShift Container Platform クラスターに必要で、これはインストール前に設定されている必要があります。各レコードで、<cluster_name>
はクラスター名で、<base_domain>
は、install-config.yaml
ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
Kubernetes API |
| API ロードバランサーを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| API ロードバランサーを内部的に識別するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のすべてのノードで解決できる必要があります。 重要 API サーバーは、Kubernetes に記録されるホスト名でワーカーノードを解決できる必要があります。API サーバーがノード名を解決できない場合、プロキシーされる API 呼び出しが失敗し、Pod からログを取得できなくなる可能性があります。 | |
ルート |
| アプリケーション Ingress ロードバランサーを参照するワイルドカード DNS A/AAAA または CNAME レコード。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
ブートストラップマシン |
| ブートストラップマシンを識別するための DNS A / AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
コントロールプレーンマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコードおよび DNS PTR レコードこれらのレコードは、クラスター内のノードで解決できる必要があります。 |
コンピュートマシン |
| ワーカーノードの各マシンを特定するための DNS A/AAAA または CNAME レコード、および DNS PTR レコード。これらのレコードは、クラスター内のノードで解決できる必要があります。 |
OpenShift Container Platform 4.4 以降では、DNS 設定で etcd ホストおよび SRV レコードを指定する必要はありません。
dig
コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
8.7.6.1. user-provisioned クラスターの DNS 設定の例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、user-provisioned infrastructure に OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、クラスター名は ocp4
で、ベースドメインは example.com
です。
user-provisioned クラスターの DNS A レコードの設定例
BIND ゾーンファイルの以下の例は、user-provisioned クラスターの名前解決の A レコードの例を示しています。
例8.4 DNS ゾーンデータベースのサンプル
- 1
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照します。
- 2
- Kubernetes API の名前解決を提供します。レコードは API ロードバランサーの IP アドレスを参照し、内部クラスター通信に使用されます。
- 3
- ワイルドカードルートの名前解決を提供します。レコードは、アプリケーション Ingress ロードバランサーの IP アドレスを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するマシンをターゲットにします。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
- 4
- ブートストラップマシンの名前解決を提供します。
- 5 6 7
- コントロールプレーンマシンの名前解決を提供します。
- 8 9
- コンピュートマシンの名前解決を提供します。
user-provisioned クラスターの DNS PTR レコードの設定例
以下の BIND ゾーンファイルの例では、user-provisioned クラスターの逆引き名前解決の PTR レコードの例を示しています。
例8.5 逆引きレコードの DNS ゾーンデータベースの例
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
8.7.7. ユーザーによってプロビジョニングされるインフラストラクチャーの負荷分散要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。
負荷分散インフラストラクチャーは以下の要件を満たす必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
重要API ロードバランサーのセッションの永続性は設定しないでください。Kubernetes API サーバーのセッション永続性を設定すると、OpenShift Container Platform クラスターとクラスター内で実行される Kubernetes API の過剰なアプリケーショントラフィックによりパフォーマンスの問題が発生する可能性があります。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表8.10 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyz
エンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyz
エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz
の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとのプロービングで、2 回連続成功すると正常、3 回連続失敗すると異常と判断する設定は、十分にテストされた値です。Application Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。
以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP または SSL パススルーモードと呼ばれます。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ヒントクライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
Expand 表8.11 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
8.7.7.1. ユーザーによってプロビジョニングされるクラスターのロードバランサーの設定例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、ユーザーによってプロビジョニングされるクラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg
設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
HAProxy をロードバランサーとして使用し、SELinux が enforcing
に設定されている場合は、setsebool -P haproxy_connect_any=1
を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。
例8.6 API およびアプリケーション Ingress ロードバランサーの設定例
- 1
- ポート
6443
は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。 - 2 4
- ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
- 3
- ポート
22623
はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。 - 5
- ポート
443
は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。 - 6
- ポート
80
は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe
を実行して、ポート 6443
、22623
、443
、および 80
で haproxy
プロセスがリッスンしていることを確認することができます。
8.8. user-provisioned infrastructure の準備 リンクのコピーリンクがクリップボードにコピーされました!
user-provisioned infrastructure に OpenShift Container Platform をインストールする前に、基礎となるインフラストラクチャーを準備する必要があります。
このセクションでは、OpenShift Container Platform インストールの準備としてクラスターインフラストラクチャーを設定するために必要な手順の概要を説明します。これには、クラスターノード用の IP ネットワークおよびネットワーク接続を設定し、ファイアウォール経由で必要なポートを有効にし、必要な DNS および負荷分散インフラストラクチャーの設定が含まれます。
準備後、クラスターインフラストラクチャーは、user-provisioned infrastructure を使用したクラスターの要件 セクションで説明されている要件を満たす必要があります。
前提条件
- OpenShift Container Platform 4.x のテスト済みインテグレーション を確認している。
- user-provisioned infrastructure を使用したクラスターの要件 で説明されているインフラストラクチャーの要件を確認している。
手順
DHCP を使用して IP ネットワーク設定をクラスターノードに提供する場合は、DHCP サービスを設定します。
- ノードの永続 IP アドレスを DHCP サーバー設定に追加します。設定で、関連するネットワークインターフェイスの MAC アドレスを、各ノードの目的の IP アドレスと一致させます。
DHCP を使用してクラスターマシンの IP アドレスを設定する場合、マシンは DHCP を介して DNS サーバー情報も取得します。DHCP サーバー設定を介してクラスターノードが使用する永続 DNS サーバーアドレスを定義します。
注記DHCP サービスを使用しない場合、IP ネットワーク設定と DNS サーバーのアドレスを RHCOS インストール時にノードに指定する必要があります。ISO イメージからインストールしている場合は、ブート引数として渡すことができます。静的 IP プロビジョニングと高度なネットワークオプションの詳細は、RHCOS のインストールと OpenShift Container Platform ブートストラッププロセスの開始のセクションを参照してください。
DHCP サーバー設定でクラスターノードのホスト名を定義します。ホスト名に関する考慮事項については、DHCP を使用したクラスターノードのホスト名の設定 参照してください。
注記DHCP サービスを使用しない場合、クラスターノードは逆引き DNS ルックアップを介してホスト名を取得します。
- ネットワークインフラストラクチャーがクラスターコンポーネント間の必要なネットワーク接続を提供することを確認します。要件に関する詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
OpenShift Container Platform クラスターコンポーネントで通信するために必要なポートを有効にするようにファイアウォールを設定します。必要なポートの詳細は、user-provisioned infrastructure のネットワーク要件 のセクションを参照してください。
重要デフォルトで、ポート
1936
は OpenShift Container Platform クラスターにアクセスできます。これは、各コントロールプレーンノードがこのポートへのアクセスを必要とするためです。Ingress ロードバランサーを使用してこのポートを公開しないでください。これを実行すると、Ingress コントローラーに関連する統計やメトリクスなどの機密情報が公開される可能性があるためです。
クラスターに必要な DNS インフラストラクチャーを設定します。
- Kubernetes API、アプリケーションワイルドカード、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの DNS 名前解決を設定します。
Kubernetes API、ブートストラップマシン、コントロールプレーンマシン、およびコンピュートマシンの逆引き DNS 解決を設定します。
OpenShift Container Platform DNS 要件の詳細は、user-provisioned DNS 要件 のセクションを参照してください。
DNS 設定を検証します。
- インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答の IP アドレスが正しいコンポーネントに対応することを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答のレコード名が正しいコンポーネントに対応することを確認します。
DNS 検証手順の詳細は、user-provisioned infrastructure の DNS 解決の検証 のセクションを参照してください。
- 必要な API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングします。要件に関する詳細は、user-provisioned infrastructure の負荷分散要件 のセクションを参照してください。
一部の負荷分散ソリューションでは、負荷分散を初期化する前に、クラスターノードの DNS 名前解決を有効化する必要があります。
8.9. user-provisioned infrastructure の DNS 解決の検証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform を user-provisioned infrastructure にインストールする前に、DNS 設定を検証できます。
このセクションの検証手順は、クラスターのインストール前に正常に実行される必要があります。
前提条件
- user-provisioned infrastructure に必要な DNS レコードを設定している。
手順
インストールノードから、Kubernetes API、ワイルドカードルート、およびクラスターノードのレコード名に対して DNS ルックアップを実行します。応答に含まれる IP アドレスが正しいコンポーネントに対応することを確認します。
Kubernetes API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api.<cluster_name>.<base_domain>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nameserver_ip>
をネームサーバーの IP アドレスに、<cluster_name>
をクラスター名に、<base_domain>
をベースドメイン名に置き換えます。
出力例
api.ocp4.example.com. 604800 IN A 192.168.1.5
api.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes 内部 API レコード名に対してルックアップを実行します。結果が API ロードバランサーの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> api-int.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
api-int.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow *.apps.<cluster_name>.<base_domain>
DNS ワイルドカードルックアップの例をテストします。すべてのアプリケーションのワイルドカードルックアップは、アプリケーション Ingress ロードバランサーの IP アドレスに解決する必要があります。dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> random.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
random.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
random
は、別のワイルドカード値に置き換えることができます。たとえば、OpenShift Container Platform コンソールへのルートをクエリーできます。dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> console-openshift-console.apps.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
console-openshift-console.apps.ocp4.example.com. 604800 IN A 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブートストラップ DNS レコード名に対してルックアップを実行します。結果がブートストラップノードの IP アドレスを参照することを確認します。
dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
$ dig +noall +answer @<nameserver_ip> bootstrap.<cluster_name>.<base_domain>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
bootstrap.ocp4.example.com. 604800 IN A 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの DNS レコード名に対してルックアップを実行します。結果が各ノードの IP アドレスに対応していることを確認します。
インストールノードから、ロードバランサーとクラスターノードの IP アドレスに対して逆引き DNS ルックアップを実行します。応答に含まれるレコード名が正しいコンポーネントに対応することを確認します。
API ロードバランサーの IP アドレスに対して逆引き参照を実行します。応答に、Kubernetes API および Kubernetes 内部 API のレコード名が含まれていることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.5
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com. 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
5.1.168.192.in-addr.arpa. 604800 IN PTR api-int.ocp4.example.com.
1 5.1.168.192.in-addr.arpa. 604800 IN PTR api.ocp4.example.com.
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。アプリケーション Ingress ロードバランサーの IP アドレスに対する逆引き DNS 解決の検証手順は必要ありません。
ブートストラップノードの IP アドレスに対して逆引き参照を実行します。結果がブートストラップノードの DNS レコード名を参照していることを確認します。
dig +noall +answer @<nameserver_ip> -x 192.168.1.96
$ dig +noall +answer @<nameserver_ip> -x 192.168.1.96
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
96.1.168.192.in-addr.arpa. 604800 IN PTR bootstrap.ocp4.example.com.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - この方法を使用して、コントロールプレーンおよびコンピュートノードの IP アドレスに対して逆引きルックアップを実行します。結果が各ノードの DNS レコード名に対応していることを確認します。
8.10. クラスターノードの 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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
AWS キーペア などのプラットフォームに固有の方法で設定したキーではなく、ローカルキーを使用する必要があります。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済みまたは進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
、ppc64le
、およびs390x
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
cat <path>/<file_name>.pub
$ cat <path>/<file_name>.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。cat ~/.ssh/id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。eval "$(ssh-agent -s)"
$ eval "$(ssh-agent -s)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Agent pid 31874
Agent pid 31874
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。ssh-add <path>/<file_name>
$ ssh-add <path>/<file_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。クラスターを独自にプロビジョニングするインフラストラクチャーにインストールする場合は、キーをインストールプログラムに指定する必要があります。
8.11. VMware vSphere のリージョンとゾーンの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターを、単一の VMware vCenter で実行される複数の vSphere データセンターにデプロイできます。各データセンターは複数のクラスターを実行できます。この設定により、クラスターの障害を引き起こす可能性のあるハードウェア障害やネットワーク停止のリスクが軽減されます。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
デフォルトのインストール設定では、クラスターが単一の 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 |
8.12. インストール設定ファイルの手動作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインストールするには、インストール設定ファイルを手動で作成する必要があります。
前提条件
- インストールプログラムで使用するための SSH 公開鍵がローカルマシン上に存在する。この鍵は、デバッグや障害復旧のために、クラスターノードへの SSH 認証に使用できます。
- OpenShift Container Platform インストールプログラムとクラスターのプルシークレットを取得した。
-
リポジトリーのミラーリングに使用するコマンドの出力で
imageContentSources
セクションを取得します。 - ミラーレジストリーの証明書の内容を取得する。
手順
必要なインストールアセットを保存するためのインストールディレクトリーを作成します。
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
と付ける必要があります。-
docker.io
などの、RHCOS がデフォルトで信頼するレジストリーを使用しない限り、additionalTrustBundle
セクションにミラーリポジトリーの証明書の内容を指定する必要があります。ほとんどの場合、ミラーの証明書を指定する必要があります。 -
リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSources
セクションを組み込む必要があります。
-
多くのクラスターのインストールに使用できるように、
install-config.yaml
ファイルをバックアップします。重要インストールプロセスの次のステップで
install-config.yaml
ファイルを使用するため、今すぐこのファイルをバックアップしてください。
8.12.1. VMware vSphere のサンプル install-config.yaml ファイル リンクのコピーリンクがクリップボードにコピーされました!
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 4
controlPlane
セクションは単一マッピングですが、コンピュートセクションはマッピングのシーケンスになります。異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン (-
) で始まり、controlPlane
セクションの最初の行はハイフン以外で始まる必要があります。どちらのセクションも、現時点では単一のマシンプールを定義しますが、OpenShift Container Platform の今後のバージョンでは、インストール時の複数のコンピュートプールの定義をサポートする可能性があります。1 つのコントロールプレーンプールのみが使用されます。- 3
replicas
パラメーターの値を0
に設定する必要があります。このパラメーターはクラスターが作成し、管理するワーカーの数を制御します。これは、user-provisioned infrastructure を使用する場合にクラスターが実行しない機能です。OpenShift Container Platform のインストールが終了する前に、クラスターが使用するワーカーマシンを手動でデプロイする必要があります。- 5
- クラスターに追加するコントロールプレーンマシンの数。クラスターをこの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
- 6
- DNS レコードに指定したクラスター名。
- 7
- vCenter サーバーの完全修飾ホスト名または IP アドレス。重要
Cluster Cloud Controller Manager Operator は、指定されたホスト名または IP アドレスに対して接続チェックを行います。到達可能な vCenter サーバーに対して、ホスト名または IP アドレスを指定していることを確認してください。存在しない vCenter サーバーにメタデータを提供すると、クラスターのインストールはブートストラップ段階で失敗します。
- 8
- サーバーにアクセスするユーザーの名前。
- 9
- vSphere ユーザーに関連付けられたパスワード。
- 10
- vSphere データセンター。
- 11
- 使用するデフォルトの vSphere データストア。
- 12
- オプションのパラメーター: インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例:
/<datacenter_name>/vm/<folder_name>/<subfolder_name>
)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供していて、thin
という名前のデフォルトのStorageClass
オブジェクトを使用したくない場合は、install-config.yaml
ファイルからfolder
パラメーターを省略できます。 - 13
- オプションのパラメーター: インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストールプログラムが仮想マシンを作成する既存フォルダーの絶対パス (例:
/<datacenter_name>/vm/<folder_name>/<subfolder_name>
)。この値を指定しない場合、インストールプログラムは、データセンターの仮想マシンフォルダーにインフラストラクチャー ID を使用して名前が付けられる上位レベルのフォルダーを作成します。クラスターのインフラストラクチャーを提供する場合は、このパラメーターを省略します。 - 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 モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。FIPS 検証済み/Modules In Process 暗号ライブラリーの使用は、
x86_64
、ppc64le
、およびs390x
アーキテクチャー上の OpenShift Container Platform デプロイメントでのみサポートされます。 - 16
<local_registry>
については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例:registry.example.com
またはregistry.example.com:5000
<credentials>
に、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。- 17
- Red Hat Enterprise Linux CoreOS (RHCOS) の
core
ユーザーのデフォルト SSH キーの公開部分。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。 - 18
- ミラーレジストリーに使用した証明書ファイルの内容を指定します。
- 19
- リポジトリーのミラーリングに使用するコマンドの出力の
imageContentSources
セクションを指定します。
8.12.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-config
namespace に生成します。次に 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
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
8.12.3. VMware vCenter のリージョンとゾーンの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのインストール設定ファイルを変更して、単一の VMware vCenter で実行される複数の vSphere データセンターに OpenShift Container Platform クラスターをデプロイできるようにします。
VMware vSphere のリージョンとゾーンの有効化は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
この例では、govc
コマンドを使用します。govc
コマンドは、VMware から入手できるオープンソースコマンドです。govc
コマンドは Red Hat からは入手できません。Red Hat サポートは govc
コマンドを保守しません。govc
のダウンロードおよびインストール手順は、VMware ドキュメントの Web サイト を参照してください。
前提条件
既存の
install-config.yaml
インストール設定ファイルがあります。重要VMware vCenter Server のデータセンターオブジェクトをプロビジョニングできるように、OpenShift Container Platform クラスターに少なくとも 1 つの障害ドメインを指定する必要があります。異なるデータセンター、クラスター、データストア、その他のコンポーネントに仮想マシンノードをプロビジョニングする必要がある場合は、複数の障害ドメインを指定することを検討してください。リージョンとゾーンを有効にするには、OpenShift Container Platform クラスターに複数の障害ドメインを定義する必要があります。
注記VMware vSphere プラットフォームに OpenShift Container Platform クラスターをインストールした後は、障害ドメインを変更できません。クラスターのインストール後に、障害ドメインを追加できます。
手順
次の
govc
コマンドラインツールコマンドを入力して、openshift-region
およびopenshift-zone
vCenter タグカテゴリーを作成します。重要openshift-region
およびopenshift-zone
vCenter タグカテゴリーに異なる名前を指定すると、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 クラスターをデプロイする各リージョン vSphere データセンターのリージョンタグを作成するには、ターミナルで次のコマンドを入力します。
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 クラスターをデプロイする vSphere クラスターごとにゾーンタグを作成するには、次のコマンドを入力します。
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> /<datacenter_1>
$ govc tags.attach -c <region_tag_category> <region_tag_1> /<datacenter_1>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、各 vCenter データセンターオブジェクトにゾーンタグをアタッチします。
govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
$ govc tags.attach -c <zone_tag_category> <zone_tag_1> /<datacenter_1>/host/vcs-mdcnc-workload-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - インストールプログラムが含まれるディレクトリーに移動し、選択したインストール要件に従ってクラスターデプロイメントを初期化します。
vSphere センターで定義された複数のデータセンターを含むサンプル install-config.yaml
ファイル
- 1
- VMware vSphere リージョンおよびゾーン有効化機能を使用できるように、このパラメーターの値として
TechPreviewNoUpgrade
を設定するように定義する必要があります。 - 2 3
- vCenter クラスターを指定するためのオプションのパラメーター。ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。このパラメーターを定義しない場合、ノードは定義されているすべての障害ドメインに分散されます。 - 4 5 6 7 8 9 10 11
- デフォルトの vCenter トポロジー。インストールプログラムは、このトポロジー情報を使用してブートストラップノードをデプロイメントします。さらに、トポロジーは vSphere 永続ボリュームのデフォルトデータストアを定義します。
- 12
- リージョンとゾーン間の関係を確立します。障害ドメインは、datastore オブジェクトなどの vCenter オブジェクトを使用して定義します。障害ドメインは、OpenShift Container Platform クラスターノードの vCenter の場所を定義します。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 13
- 障害ドメインの名前を定義します。各障害ドメインは
zones
パラメーターで参照され、マシンプールの範囲が障害ドメインに設定されます。 - 14
- リージョンを定義するには、
openshift-region
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 15
- ゾーンを定義するには、
openshift-zone
タグカテゴリーのタグを使用します。タグは vCenter データセンターに添付する必要があります。 - 16
- 障害ドメインに関連付けられた vCenter リソースを指定します。
- 17
- 障害ドメインに関連付けられた vSphere データセンターを定義するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 18
- 障害ドメインに関連付けられた計算クラスターの絶対ファイルパスを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 19
- インストーラーがプロビジョニングするインフラストラクチャーのオプションのパラメーター。このパラメーターは、インストールプログラムが仮想マシンを作成する既存のリソースプールの絶対パスを設定します (例:
/<datacenter_name>/host/<cluster_name>/Resources/<resource_pool_name>/<optional_nested_resource_pool_name>
)。値を指定しない場合、リソースはクラスターのルート/example_datacenter/host/example_cluster/Resources
にインストールされます。 - 20
- 設定した仮想 IP アドレスと DNS レコードを含む vCenter インスタンス内のネットワークをリストするオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
- 21
- ボリュームのプロビジョニングに使用するデータストアを指定するためのオプションのパラメーター。このパラメーターを定義しない場合、インストールプログラムはデフォルトの vCenter トポロジーを使用します。
8.13. Kubernetes マニフェストおよび Ignition 設定ファイルの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のクラスター定義ファイルを変更し、クラスターマシンを手動で起動する必要があるため、クラスターがマシンを設定するために必要な Kubernetes マニフェストと Ignition 設定ファイルを生成する必要があります。
インストール設定ファイルは Kubernetes マニフェストに変換されます。マニフェストは Ignition 設定ファイルにラップされます。これはクラスターマシンを設定するために後で使用されます。
-
OpenShift Container Platform のインストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
前提条件
- OpenShift Container Platform インストールプログラムを取得していること。ネットワークが制限されたインストールでは、これらのファイルがミラーホスト上に置かれます。
-
install-config.yaml
インストール設定ファイルを作成していること。
手順
OpenShift Container Platform のインストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。
./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
ファイルが含まれるインストールディレクトリーを指定します。
コントロールプレーンマシンおよびコンピュートマシンセットを定義する 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 これらのリソースを独自に作成および管理するため、それらを初期化する必要はありません。
- コンピュートマシンセットファイルを保存して、マシン API を使用してコンピュートマシンを作成することができますが、環境に合わせてそれらへの参照を更新する必要があります。
<installation_directory>/manifests/cluster-scheduler-02-config.yml
Kubernetes マニフェストファイルのmastersSchedulable
パラメーターがfalse
に設定されていることを確認します。この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。-
<installation_directory>/manifests/cluster-scheduler-02-config.yml
ファイルを開きます。 -
mastersSchedulable
パラメーターを見つけ、これがfalse
に設定されていることを確認します。 - ファイルを保存し、終了します。
-
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>
には、同じインストールディレクトリーを指定します。
Ignition 設定ファイルは、インストールディレクトリー内のブートストラップ、コントロールプレーン、およびコンピュートノード用に作成されます。
kubeadmin-password
およびkubeconfig
ファイルが./<installation_directory>/auth
ディレクトリーに作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.14. インフラストラクチャー名の抽出 リンクのコピーリンクがクリップボードにコピーされました!
Ignition 設定ファイルには、VMware Cloud on AWS でクラスターを一意に識別するために使用できる一意のクラスター 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
- このコマンドの出力はクラスター名とランダムな文字列です。
8.15. 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
ファイルで指定したデータストアを選択します。
- 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
次のステップ
各マシンごとに先の手順に従って、クラスターの残りのマシンを作成します。
重要この時点でブートストラップおよびコントロールプレーンマシンを作成する必要があります。一部の Pod はデフォルトでコンピュートマシンにデプロイされるため、クラスターのインストール前に、2 つ以上のコンピュートマシンを作成します。
8.16. 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 をクリックします。
Edit Configuration をクリックし、Configuration Parameters ウィンドウで Add Configuration Params をクリックします。以下のパラメーター名および値を定義します。
-
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 を選択します。
次のステップ
- 継続してクラスター用の追加のコンピュートマシンを作成します。
8.17. ディスクパーティション設定 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの場合、データパーティションは、最初に別のオペレーティングシステムをインストールするのではなく、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
へのブート引数とオプションの両方があります。
個別の /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 インストール手順への入力として使用できます。
8.18. ブートストラッププロセスの完了まで待機する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform ブートストラッププロセスは、初回のクラスターノードのディスクにインストールされている永続的な RHCOS 環境での起動後に開始します。Ignition 設定ファイルで指定される設定情報は、ブートストラッププロセスを初期化し、マシンに OpenShift Container Platform をインストールするために使用されます。ブートストラッププロセスが完了するまで待機する必要があります。
前提条件
- クラスターの Ignition 設定ファイルを作成している。
- 適切なネットワーク、DNS および負荷分散インフラストラクチャーを設定している。
- インストールプログラムを取得し、クラスターの Ignition 設定ファイルを生成している。
- RHCOS をクラスターマシンにインストールし、OpenShift Container Platform インストールプログラムで生成される Ignition 設定ファイルを指定している。
手順
ブートストラッププロセスをモニターします。
./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.25.0 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.25.0 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 サーバーでこれがコントロールプレーンマシンにブートストラップされていることを示すシグナルが出されるとコマンドは成功します。
ブートストラッププロセスが完了したら、ブートストラップマシンをロードバランサーから削除します。
重要この時点で、ブートストラップマシンをロードバランサーから削除する必要があります。さらに、ブートストラップマシン自体を削除し、再フォーマットすることができます。
8.19. CLI の使用によるクラスターへのログイン リンクのコピーリンクがクリップボードにコピーされました!
クラスター kubeconfig
ファイルをエクスポートし、デフォルトシステムユーザーとしてクラスターにログインできます。kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターに関する情報が含まれます。このファイルはクラスターに固有のファイルであり、OpenShift Container Platform のインストール時に作成されます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
CLI をインストールしていること。
手順
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
8.20. マシンの証明書署名要求の承認 リンクのコピーリンクがクリップボードにコピーされました!
マシンをクラスターに追加する際に、追加したそれぞれのマシンについて 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.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.25.0 master-1 Ready master 63m v1.25.0 master-2 Ready master 64m v1.25.0
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
サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。それらを個別に承認するには、それぞれの有効な 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
ステータスに移行するまでに数分の時間がかかる場合があります。
関連情報
- CSR の詳細は、Certificate Signing Requests を参照してください。
8.21. 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 を設定します。
8.21.1. デフォルトの OperatorHub カタログソースの無効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。
手順
disableAllDefaultSources: true
をOperatorHub
オブジェクトに追加して、デフォルトカタログのソースを無効にします。oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
8.21.2. イメージレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator は、デフォルトストレージを提供しないプラットフォームでは最初は利用できません。インストール後に、レジストリー Operator を使用できるようにレジストリーをストレージを使用するように設定する必要があります。
実稼働クラスターに必要な永続ボリュームの設定に関する手順が示されます。該当する場合、空のディレクトリーをストレージの場所として設定する方法が表示されます。これは、実稼働以外のクラスターでのみ利用できます。
アップグレード時に Recreate
ロールアウトストラテジーを使用して、イメージレジストリーがブロックストレージタイプを使用することを許可するための追加の手順が提供されます。
8.21.2.1. VMware vSphere のレジストリーストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- VMware vSphere 上のクラスター。
Red Hat OpenShift Data Foundation など、クラスターのプロビジョニングされた永続ストレージ。
重要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
$ oc get pod -n openshift-image-registry -l docker-registry=default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resourses found in openshift-image-registry namespace
No resourses found in openshift-image-registry namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.io
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
image-registry-storage
永続ボリューム要求 (PVC) の自動作成を許可するには、claim
フィールドを空白のままにします。PVC は、デフォルトのストレージクラスに基づいて生成されます。ただし、デフォルトのストレージクラスは、RADOS ブロックデバイス (RBD) などの ReadWriteOnce (RWO) ボリュームを提供する可能性があることに注意してください。これは、複数のレプリカに複製するときに問題を引き起こす可能性があります。
clusteroperator
ステータスを確認します。oc get clusteroperator image-registry
$ oc get clusteroperator image-registry
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.21.2.2. 実稼働以外のクラスターでのイメージレジストリーのストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Registry Operator のストレージを設定する必要があります。実稼働用以外のクラスターの場合、イメージレジストリーは空のディレクトリーに設定することができます。これを実行する場合、レジストリーを再起動するとすべてのイメージが失われます。
手順
イメージレジストリーストレージを空のディレクトリーに設定するには、以下を実行します。
oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告実稼働用以外のクラスターにのみこのオプションを設定します。
Image Registry Operator がそのコンポーネントを初期化する前にこのコマンドを実行する場合、
oc patch
コマンドは以下のエラーを出して失敗します。Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 数分待機した後に、このコマンドを再び実行します。
8.21.2.3. 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 vSpherePersistentVolumeClaim
オブジェクトを定義します。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-storage
PVC のデフォルトの自動作成のclaim
フィールドを空のままにできます。
正しい PVC を参照するようにレジストリーストレージを設定する方法については、VMware vSphere のレジストリーの設定 を参照してください。
8.22. ユーザーによってプロビジョニングされるインフラストラクチャーでのインストールの完了 リンクのコピーリンクがクリップボードにコピーされました!
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 でのカーネル引数を使用したマルチパスの有効化を参照してください。
- Cluster registration ページでクラスターを登録します。
クラスターのインストールが完了したら、コンピュートマシンの vSphere への追加 に従って、コンピュートマシンをさらに追加できます。
8.23. VMware vSphere ボリュームのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、個別の永続ディスクとして新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップしたり、スナップショットからボリュームを復元したりすることはできません。詳細は、スナップショットの制限 を参照してください。
手順
永続ボリュームのバックアップを作成すには、以下を実行します。
- 永続ボリュームを使用しているアプリケーションを停止します。
- 永続ボリュームのクローンを作成します。
- アプリケーションを再起動します。
- クローンを作成したボリュームのバックアップを作成します。
- クローンを作成したボリュームを削除します。
8.24. OpenShift Container Platform の Telemetry アクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.12 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager Hybrid Cloud Console に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager Hybrid Cloud Console を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
8.25. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- クラスターのカスタマイズ
-
Cluster Samples Operator および
must-gather
ツールの イメージストリームを設定 します。 - ネットワークが制限された環境での Operator Lifecycle Manager (OLM) の使用 方法について参照します。
- クラスターのインストールに使用したミラーレジストリーに信頼された CA がある場合は、追加のトラストストアを設定 してクラスターに追加します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。
- オプション: vSphere Problem Detector Operator からのイベントを表示 し、クラスターにパーミッションまたはストレージ設定の問題があるかどうかを判別します。
第9章 VMC のクラスターのアンインストール リンクのコピーリンクがクリップボードにコピーされました!
インストーラーでプロビジョニングされるインフラストラクチャーを使用して、VMware Cloud (VMC) on AWS にデプロイし、VMware vSphere インフラストラクチャーにインストールされたクラスターを削除できます。
9.1. インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターの削除 リンクのコピーリンクがクリップボードにコピーされました!
インストーラーでプロビジョニングされるインフラストラクチャーを使用するクラスターは、クラウドから削除できます。
アンインストール後に、とくにユーザーによってプロビジョニングされるインフラストラクチャー (UPI) クラスターで適切に削除されていないリソースがあるかどうかについて、クラウドプロバイダーを確認します。インストールプログラムが作成しなかったリソース、またはインストールプログラムがアクセスできないリソースが存在する可能性があります。
前提条件
- クラスターをデプロイするために使用したインストールプログラムのコピーがあります。
- クラスター作成時にインストールプログラムが生成したファイルがあります。
手順
クラスターのインストールに使用したコンピューターで、インストールプログラムを含むディレクトリーに移動し、次のコマンドを実行します。
./openshift-install destroy cluster \ --dir <installation_directory> --log-level info
$ ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info
1 2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記クラスターのクラスター定義ファイルが含まれるディレクトリーを指定する必要があります。クラスターを削除するには、インストールプログラムでこのディレクトリーにある
metadata.json
ファイルが必要になります。-
オプション:
<installation_directory>
ディレクトリーおよび OpenShift Container Platform インストールプログラムを削除します。
Legal Notice
リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.