13.5. ネットワークが制限された環境での RHV へのクラスターのインストール
OpenShift Container Platform バージョン 4.8 では、インストールリリースコンテンツの内部ミラーを作成して、カスタマイズされた OpenShift Container Platform クラスターをネットワークが制限された環境で Red Hat Virtualization (RHV) にインストールできます。
13.5.1. 前提条件
OpenShift Container Platform クラスターを RHV 環境にインストールするには、以下の要件を満たしている必要があります。
- OpenShift Container Platform のインストールおよび更新 プロセスの詳細を確認している。
- クラスターインストール方法の選択およびそのユーザー向けの準備 のドキュメント内容を確認している。
- Support Matrix for OpenShift Container Platform on RHV に記載のサポートされるバージョンの組み合わせを使用できる。
ミラーホストでレジストリーを作成 しており、使用しているバージョンの OpenShift Container Platform の
imageContentSources
データを取得している。重要インストールメディアはミラーホストにあるため、そのコンピューターを使用してすべてのインストール手順を完了することができます。
- クラスターの 永続ストレージ をプロビジョニングしている。プライベートイメージレジストリーをデプロイするには、ストレージで ReadWriteMany アクセスモードを指定する必要があります。
クラスターがアクセスを必要とする サイトを許可するようにファイアウォールを設定 している (ファイアウォールを使用し、Telemetry サービスを使用する予定の場合)。
注記プロキシーを設定する場合は、このサイト一覧も確認してください。
13.5.2. ネットワークが制限された環境でのインストールについて
OpenShift Container Platform 4.8 では、ソフトウェアコンポーネントを取得するためにインターネットへのアクティブな接続を必要としないインストールを実行できます。ネットワークが制限された環境のインストールは、クラスターのインストール先となるクラウドプラットフォームに応じて、インストーラーでプロビジョニングされるインフラストラクチャーまたはユーザーによってプロビジョニングされるインフラストラクチャーを使用して実行できます。
クラウドプラットフォーム上でネットワークが制限されたインストールの実行を選択した場合でも、そのクラウド API へのアクセスが必要になります。Amazon Web Service の Route 53 DNS や IAM サービスなどの一部のクラウド機能には、インターネットアクセスが必要です。ネットワークによっては、ベアメタルハードウェアまたは VMware vSphere へのインストールには、インターネットアクセスが必要になる場合があります。
ネットワークが制限されたインストールを完了するには、OpenShift Container Platform レジストリーのコンテンツをミラーリングし、インストールメディアを含むレジストリーを作成する必要があります。このミラーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホストで、または制限に対応する他の方法を使用して作成できます。
13.5.2.1. その他の制限
ネットワークが制限された環境のクラスターには、以下の追加の制限および制約があります。
-
ClusterVersion
ステータスにはUnable to retrieve available updates
エラーが含まれます。 - デフォルトで、開発者カタログのコンテンツは、必要とされるイメージストリームタグにアクセスできないために使用できません。
13.5.3. OpenShift Container Platform のインターネットアクセス
OpenShift Container Platform 4.8 では、クラスターをインストールするために必要なイメージを取得するために、インターネットアクセスが必要になります。
インターネットへのアクセスは以下を実行するために必要です。
- OpenShift Cluster Manager にアクセスし、インストールプログラムをダウンロードし、サブスクリプション管理を実行します。クラスターにインターネットアクセスがあり、Telemetry を無効にしない場合、そのサービスは有効なサブスクリプションでクラスターを自動的に使用します。
- クラスターのインストールに必要なパッケージを取得するために Quay.io にアクセスします。
- クラスターの更新を実行するために必要なパッケージを取得します。
クラスターでインターネットに直接アクセスできない場合、プロビジョニングする一部のタイプのインフラストラクチャーでネットワークが制限されたインストールを実行できます。このプロセスで、必要なコンテンツをダウンロードし、これを使用してミラーレジストリーにクラスターのインストールおよびインストールプログラムの生成に必要なパッケージを設定します。インストールタイプによっては、クラスターのインストール環境でインターネットアクセスが不要となる場合があります。クラスターを更新する前に、ミラーレジストリーのコンテンツを更新します。
13.5.4. RHV 環境の要件
OpenShift Container Platform バージョン 4.8 クラスターをインストールし、実行するには、RHV 環境が以下の要件を満たしている必要があります。
これらの要件を満たさないと、インストールまたはプロセスが失敗する可能性があります。さらに、これらの要件を満たしていないと、OpenShift Container Platform クラスターはインストールしてから数日または数週間後に失敗する可能性があります。
CPU、メモリー、ストレージリソースについての以下の要件は、インストールプログラムが作成する仮想マシンのデフォルト数で乗算した デフォルト 値に基づいています。これらのリソースは、RHV 環境が OpenShift Container Platform 以外の操作に使用するものに 加え、利用可能でなければなりません。
デフォルトでは、インストールプログラムは 7 つの仮想マシンをインストールプロセスで作成します。まず、ブートストラップ仮想マシンを作成し、OpenShift Container Platform クラスターの残りの部分を作成する間に一時サービスとコントロールプレーンを提供します。インストールプログラムがクラスターの作成を終了すると、ブートストラップマシンが削除され、そのリソースが解放されます。
RHV 環境の仮想マシン数を増やす場合は、リソースを適宜増やす必要があります。
要件
- RHV のバージョンは 4.4 である。
- RHV 環境に Up 状態のデータセンターが 1 つあること。
- RHV データセンターに RHV クラスターが含まれていること。
RHV クラスターに OpenShift Container Platform クラスター専用の以下のリソースがあること。
- 最小 28 vCPU: インストール時に作成される 7 仮想マシンのそれぞれに 4 vCPU。
以下を含む 112 GiB 以上の RAM。
- 一時的なコントロールプレーンを提供するブートストラップマシン用に 16 GiB 以上。
- コントロールプレーンを提供する 3 つのコントロールプレーンマシンのそれぞれに 16 GiB 以上。
- アプリケーションワークロードを実行する 3 つのコンピュートマシンのそれぞれに 16 GiB 以上。
- RHV ストレージドメインは、これらの etcd バックエンドのパフォーマンス要件 を満たす必要があります。
- 実稼働環境では、各仮想マシンに 120 GiB 以上が必要です。そのため、ストレージドメインはデフォルトの OpenShift Container Platform クラスターに 840 GiB 以上を提供する必要があります。リソースに制約のある環境または非実稼働環境では、各仮想マシンに 32 GiB 以上を指定する必要があるため、ストレージドメインにはデフォルトの OpenShift Container Platform クラスター用に 230 GiB 以上が必要になります。
- インストールおよび更新中に Red Hat Ecosystem Catalog からイメージをダウンロードするには、RHV クラスターがインターネット接続にアクセスできる必要があります。また、サブスクリプションおよびエンタイトルメントプロセスを単純化するために Telemetry サービスにもインターネット接続が必要です。
- RHV クラスターには、RHV Manager の REST API にアクセスできる仮想ネットワークが必要です。インストーラーが作成する仮想マシンが DHCP を使用して IP アドレスを取得するため、DHCP がこのネットワークで有効にされていることを確認します。
ターゲット RHV クラスターに OpenShift Container Platform クラスターをインストールし、管理するための以下の最小限の権限を持つユーザーアカウントおよびグループ。
-
DiskOperator
-
DiskCreator
-
UserTemplateBasedVm
-
TemplateOwner
-
TemplateCreator
-
ターゲットクラスターの
ClusterAdmin
-
最小権限の原則を適用します。インストールプロセスで RHV で SuperUser
権限を持つ管理者アカウントを使用することを避けます。インストールプログラムは、ユーザーが指定する認証情報を、危険にさらされる可能性のある一時的な ovirt-config.yaml
ファイルに保存します。
13.5.5. RHV 環境の要件の確認
RHV 環境が OpenShift Container Platform クラスターをインストールし、実行するための要件を満たしていることを確認します。これらの要件を満たさないと、エラーが発生する可能性があります。
これらの要件は、インストールプログラムがコントロールプレーンおよびコンピュートマシンの作成に使用するデフォルトのリソースに基づいています。これらのリソースには、vCPU、メモリー、およびストレージが含まれます。これらのリソースを変更するか、または OpenShift Container Platform マシンの数を増やす場合は、これらの要件を適宜調整します。
手順
RHV のバージョンが OpenShift Container Platform バージョン 4.8 のインストールをサポートすることを確認します。
- RHV Administration Portal の右上にある ? ヘルプアイコンをクリックし、About を選択します。
- 開かれるウィンドウで、RHV ソフトウェアのバージョン をメモします。
- RHV のバージョンが 4.4 であることを確認します。サポートされるバージョンの組み合わせについての詳細は、Support Matrix for OpenShift Container Platform on RHV を参照してください。
データセンター、クラスター、およびストレージを検査します。
-
RHV 管理ポータルで、Compute
Data Centers をクリックします。 - OpenShift Container Platform をインストールする予定のデータセンターにアクセスできることを確認します。
- そのデータセンターの名前をクリックします。
- データセンターの詳細の Storage タブで、OpenShift Container Platform をインストールする予定のストレージドメインが Active であることを確認します。
- 後で使用できるように ドメイン名 を記録します。
- 空き領域 に 230 GiB 以上あることを確認します。
- ストレージドメインが これらの etcd バックエンドのパフォーマンス要件 を満たしていることを確認します。これは、fio パフォーマンスベンチマークツールを使用して測定できます。
- データセンターの詳細で、Clusters タブをクリックします。
- OpenShift Container Platform をインストールする予定の RHV クラスターを見つけます。後で使用できるようにクラスター名を記録します。
-
RHV 管理ポータルで、Compute
RHV ホストリソースを確認します。
- RHV 管理ポータルで、Compute > Clusters をクリックします。
- OpenShift Container Platform をインストールする予定のクラスターをクリックします。
- クラスターの詳細で、Hosts タブをクリックします。
- ホストを検査し、それらに OpenShift Container Platform クラスター 専用 として利用可能な 論理 CPU コア の合計が 28 つ以上であることを確認します。
- 後で使用できるように、利用可能な 論理 CPU コア の数を記録します。
- これらの CPU コアが分散され、インストール時に作成された 7 つの仮想マシンのそれぞれに 4 つのコアを持たせることができることを確認します。
ホストには、以下の OpenShift Container Platform マシンのそれぞれの要件を満たすように 新規仮想マシンをスケジュールするための最大空きメモリー として 112 GiB があることを確認します。
- ブートストラップマシンに 16 GiB が必要です。
- 3 つのコントロールプレーンマシンのそれぞれに 16 GiB が必要です。
- 3 つのコンピュートマシンのそれぞれに 16 GiB が必要です。
- 後で使用できるように 新規仮想マシンをスケジュールするための最大空きメモリー の量を記録します。
OpenShift Container Platform をインストールするための仮想ネットワークが RHV Manager の REST API にアクセスできることを確認します。このネットワーク上の仮想マシンから、RHV Manager の REST API に到達するために curl を使用します。
$ curl -k -u <username>@<profile>:<password> \ 1 https://<engine-fqdn>/ovirt-engine/api 2
以下に例を示します。
$ curl -k -u ocpadmin@internal:pw123 \ https://rhv-env.virtlab.example.com/ovirt-engine/api
13.5.6. ユーザーによってプロビジョニングされるインフラストラクチャーのネットワーク要件
すべての Red Hat Enterprise Linux CoreOS (RHCOS) マシンでは、起動時に initramfs
でネットワークを設定し、Ignition 設定ファイルをフェッチする必要があります。
初回の起動時に、Ignition 設定ファイルをダウンロードできるようネットワーク接続を確立するために、マシンには HTTP または HTTPS サーバーが必要になります。
マシンは静的 IP アドレスで設定されます。DHCP サーバーは必要ありません。マシンに永続 IP アドレスおよびホスト名があることを確認します。
Kubernetes API サーバーはクラスターマシンのノード名を解決できる必要があります。API サーバーおよびワーカーノードが異なるゾーンに置かれている場合、デフォルトの DNS 検索ゾーンを、API サーバーでノード名を解決できるように設定することができます。もう 1 つの実行可能な方法として、ノードオブジェクトとすべての DNS 要求の両方において、ホストを完全修飾ドメイン名で常に参照します。
ファイアウォール
クラスターが必要なサイトにアクセスできるようにファイアウォールを設定します。
以下も参照してください。
DNS
インフラストラクチャーで提供される DNS を設定して、主要なコンポーネントとサービスの正しい解決を許可します。1 つのロードバランサーのみを使用する場合、これらの DNS レコードは同じ IP アドレスを参照できます。
-
api.<cluster_name>.<base_domain>
(内部および外部解決) と、コントロールプレーンマシンのロードバランサーを参照するapi-int.<cluster_name>.<base_domain>
(内部解決) の DNS レコードを作成します。 -
Ingress ルーターのロードバランサーを参照する
*.apps.<cluster_name>.<base_domain>
の DNS レコードを作成します。たとえば、コンピュートマシンのポート443
および80
などが含まれます。
13.5.6.1. ネットワーク接続の要件
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
本セクションでは、必要なポートの詳細を説明します。
接続された OpenShift Container Platform 環境では、プラットフォームコンテナーのイメージをプルし、Telemetry データを Red Hat に提供するために、すべてのノードにインターネットへのアクセスが必要です。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリクス |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
| openshift-sdn | |
UDP |
| VXLAN および Geneve |
| VXLAN および Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| Kubernetes API |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
ユーザーによってプロビジョニングされるインフラストラクチャーの NTP 設定
OpenShift Container Platform クラスターは、デフォルトでパブリック Network Time Protocol (NTP) サーバーを使用するように設定されます。ローカルのエンタープライズ NTP サーバーを使用する必要があるか、またはクラスターが切断されたネットワークにデプロイされている場合は、特定のタイムサーバーを使用するようにクラスターを設定できます。詳細は、chrony タイムサービスの設定 のドキュメントを参照してください。
13.5.7. ユーザーによってプロビジョニングされる 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) を生成するために使用されます。
以下の DNS レコードは、ユーザーによってプロビジョニングされる 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
コマンドを使用して、名前および逆引き名前解決を確認することができます。検証手順の詳細は、ユーザーによってプロビジョニングされるインフラストラクチャーの DNS 解決の検証のセクションを参照してください。
13.5.7.1. ユーザーによってプロビジョニングされるクラスターの DNS 設定の例
このセクションでは、ユーザーによってプロビジョニングされるインフラストラクチャーに OpenShift Container Platform をデプロイするための DNS 要件を満たす A および PTR レコード設定サンプルを提供します。サンプルは、特定の DNS ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、クラスター名は ocp4
で、ベースドメインは example.com
です。
ユーザーによってプロビジョニングされるクラスターの DNS A レコードの設定例
BIND ゾーンファイルの以下の例は、ユーザーによってプロビジョニングされるクラスターの名前解決の A レコードの例を示しています。
例13.1 DNS ゾーンデータベースのサンプル
$TTL 1W @ IN SOA ns1.example.com. root ( 2019070700 ; serial 3H ; refresh (3 hours) 30M ; retry (30 minutes) 2W ; expiry (2 weeks) 1W ) ; minimum (1 week) IN NS ns1.example.com. IN MX 10 smtp.example.com. ; ; ns1.example.com. IN A 192.168.1.5 smtp.example.com. IN A 192.168.1.5 ; helper.example.com. IN A 192.168.1.5 helper.ocp4.example.com. IN A 192.168.1.5 ; api.ocp4.example.com. IN A 192.168.1.5 1 api-int.ocp4.example.com. IN A 192.168.1.5 2 ; *.apps.ocp4.example.com. IN A 192.168.1.5 3 ; bootstrap.ocp4.example.com. IN A 192.168.1.96 4 ; master0.ocp4.example.com. IN A 192.168.1.97 5 master1.ocp4.example.com. IN A 192.168.1.98 6 master2.ocp4.example.com. IN A 192.168.1.99 7 ; worker0.ocp4.example.com. IN A 192.168.1.11 8 worker1.ocp4.example.com. IN A 192.168.1.7 9 ; ;EOF
- 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
- コンピュートマシンの名前解決を提供します。
ユーザーによってプロビジョニングされるクラスターの DNS PTR レコードの設定例
以下の BIND ゾーンファイルの例では、ユーザーによってプロビジョニングされるクラスターの逆引き名前解決の PTR レコードの例を示しています。
例13.2 逆引きレコードの DNS ゾーンデータベースの例
$TTL 1W @ IN SOA ns1.example.com. root ( 2019070700 ; serial 3H ; refresh (3 hours) 30M ; retry (30 minutes) 2W ; expiry (2 weeks) 1W ) ; minimum (1 week) IN NS ns1.example.com. ; 5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com. 1 5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com. 2 ; 96.1.168.192.in-addr.arpa. IN PTR bootstrap.ocp4.example.com. 3 ; 97.1.168.192.in-addr.arpa. IN PTR master0.ocp4.example.com. 4 98.1.168.192.in-addr.arpa. IN PTR master1.ocp4.example.com. 5 99.1.168.192.in-addr.arpa. IN PTR master2.ocp4.example.com. 6 ; 11.1.168.192.in-addr.arpa. IN PTR worker0.ocp4.example.com. 7 7.1.168.192.in-addr.arpa. IN PTR worker1.ocp4.example.com. 8 ; ;EOF
PTR レコードは、OpenShift Container Platform アプリケーションのワイルドカードには必要ありません。
13.5.7.2. ユーザーによってプロビジョニングされるインフラストラクチャーの負荷分散要件
OpenShift Container Platform をインストールする前に、API およびアプリケーションの Ingress 負荷分散インフラストラクチャーをプロビジョニングする必要があります。実稼働のシナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイし、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
Red Hat Enterprise Linux (RHEL) インスタンスを使用して API およびアプリケーションイングレスロードバランサーをデプロイする場合は、RHEL サブスクリプションを別途購入する必要があります。
負荷分散インフラストラクチャーは以下の要件を満たす必要があります。
API ロードバランサー: プラットフォームと対話およびプラットフォームを設定するためのユーザー向けの共通のエンドポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、API ルートの Server Name Indication (SNI) を有効にする必要があります。
- ステートレス負荷分散アルゴリズム。オプションは、ロードバランサーの実装によって異なります。
注記API ロードバランサーが適切に機能するには、セッション永続性は必要ありません。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
表13.13 API ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 6443
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。API サーバーのヘルスチェックプローブの
/readyz
エンドポイントを設定する必要があります。X
X
Kubernetes API サーバー
22623
ブートストラップおよびコントロールプレーン。ブートストラップマシンがクラスターのコントロールプレーンを初期化した後に、ブートストラップマシンをロードバランサーから削除します。
X
マシン設定サーバー
注記ロードバランサーは、API サーバーが
/readyz
エンドポイントをオフにしてからプールから API サーバーインスタンスを削除するまで最大 30 秒かかるように設定する必要があります。/readyz
の後の時間枠内でエラーが返されたり、正常になったりする場合は、エンドポイントが削除または追加されているはずです。5 秒または 10 秒ごとにプローブし、2 つの正常な要求が健全な状態になり、3 つの要求が不健全な状態になります。これらは十分にテストされた値になります。アプリケーション Ingress ロードバランサー: クラスター外から送られるアプリケーショントラフィックの Ingress ポイントを提供します。以下の条件を設定します。
- Layer 4 の負荷分散のみ。これは、Raw TCP、SSL パススルー、または SSL ブリッジモードと呼ばれます。SSL ブリッジモードを使用する場合は、Ingress ルートの Server Name Indication (SNI) を有効にする必要があります。
- 選択可能なオプションやプラットフォーム上でホストされるアプリケーションの種類に基づいて、接続ベースの永続化またはセッションベースの永続化が推奨されます。
ヒントクライアントの実際の IP アドレスがアプリケーション Ingress ロードバランサーによって確認できる場合、ソースの IP ベースのセッション永続化を有効にすると、エンドツーエンドの TLS 暗号化を使用するアプリケーションのパフォーマンスを強化できます。
ロードバランサーのフロントとバックの両方で以下のポートを設定します。
表13.14 アプリケーション Ingress ロードバランサー ポート バックエンドマシン (プールメンバー) 内部 外部 説明 443
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTPS トラフィック
80
デフォルトで Ingress コントローラー Pod、コンピュート、またはワーカーを実行するマシン。
X
X
HTTP トラフィック
1936
デフォルトでは、Ingress コントローラー Pod を実行するワーカーノード。入力ヘルスチェックプローブの
/healthz/ready
エンドポイントを設定する必要があります。X
X
HTTP トラフィック
ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
Ingress ルーターの作業用の設定が OpenShift Container Platform クラスターに必要です。コントロールプレーンの初期化後に Ingress ルーターを設定する必要があります。
13.5.7.2.1. ユーザーによってプロビジョニングされるクラスターのロードバランサーの設定例
このセクションでは、ユーザーによってプロビジョニングされるクラスターの負荷分散要件を満たす API およびアプリケーション Ingress ロードバランサーの設定例を説明します。この例は、HAProxy ロードバランサーの /etc/haproxy/haproxy.cfg
設定です。この例では、特定の負荷分散ソリューションを選択するためのアドバイスを提供することを目的としていません。
この例では、同じロードバランサーが Kubernetes API およびアプリケーションの Ingress トラフィックに使用されます。実稼働シナリオでは、API およびアプリケーション Ingress ロードバランサーを個別にデプロイできるため、それぞれのロードバランサーインフラストラクチャーを分離してスケーリングすることができます。
例13.3 API およびアプリケーション Ingress ロードバランサーの設定例
global log 127.0.0.1 local2 pidfile /var/run/haproxy.pid maxconn 4000 daemon defaults mode http log global option dontlognull option http-server-close option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 frontend stats bind *:1936 mode http log global maxconn 10 stats enable stats hide-version stats refresh 30s stats show-node stats show-desc Stats for ocp4 cluster 1 stats auth admin:ocp4 stats uri /stats listen api-server-6443 2 bind *:6443 mode tcp server bootstrap bootstrap.ocp4.example.com:6443 check inter 1s backup 3 server master0 master0.ocp4.example.com:6443 check inter 1s server master1 master1.ocp4.example.com:6443 check inter 1s server master2 master2.ocp4.example.com:6443 check inter 1s listen machine-config-server-22623 4 bind *:22623 mode tcp server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup 5 server master0 master0.ocp4.example.com:22623 check inter 1s server master1 master1.ocp4.example.com:22623 check inter 1s server master2 master2.ocp4.example.com:22623 check inter 1s listen ingress-router-443 6 bind *:443 mode tcp balance source server worker0 worker0.ocp4.example.com:443 check inter 1s server worker1 worker1.ocp4.example.com:443 check inter 1s listen ingress-router-80 7 bind *:80 mode tcp balance source server worker0 worker0.ocp4.example.com:80 check inter 1s server worker1 worker1.ocp4.example.com:80 check inter 1s
- 1
- この例では、クラスター名は
ocp4
です。 - 2
- ポート
6443
は Kubernetes API トラフィックを処理し、コントロールプレーンマシンを参照します。 - 3 5
- ブートストラップエントリーは、OpenShift Container Platform クラスターのインストール前に有効にし、ブートストラッププロセスの完了後にそれらを削除する必要があります。
- 4
- ポート
22623
はマシン設定サーバートラフィックを処理し、コントロールプレーンマシンを参照します。 - 6
- ポート
443
は HTTPS トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。 - 7
- ポート
80
は HTTP トラフィックを処理し、Ingress コントローラー Pod を実行するマシンを参照します。Ingress コントローラー Pod はデフォルトでコンピュートマシンで実行されます。注記ゼロ (0) コンピュートノードで 3 ノードクラスターをデプロイする場合、Ingress コントローラー Pod はコントロールプレーンノードで実行されます。3 ノードクラスターデプロイメントでは、HTTP および HTTPS トラフィックをコントロールプレーンノードにルーティングするようにアプリケーション Ingress ロードバランサーを設定する必要があります。
HAProxy をロードバランサーとして使用する場合は、HAProxy ノードで netstat -nltupe
を実行して、ポート 6443
、22623
、443
、および 80
で haproxy
プロセスがリッスンしていることを確認することができます。
HAProxy をロードバランサーとして使用し、SELinux が enforcing
に設定されている場合は、setsebool -P haproxy_connect_any=1
を実行して、HAProxy サービスが設定済みの TCP ポートにバインドできることを確認する必要があります。
13.5.8. インストールマシンの設定
バイナリー openshift-install
インストールプログラムおよび Ansible スクリプトを実行するには、Manager 上の RHV 環境および REST API にネットワークでアクセスできるように、RHV Manager または Red Hat Enterprise Linux (RHEL) を設定します。
手順
Python3 および Ansible を更新またはインストールします。以下に例を示します。
# dnf update python3 ansible
-
python3-ovirt-engine-sdk4
パッケージをインストール して、Python Software Development Kit を取得します。 ovirt.image-template
Ansible ロールをインストールします。RHV Manager およびその他の Red Hat Enterprise Linux (RHEL) マシンでは、このロールはovirt-ansible-image-template
パッケージとして提供されます。たとえば、 以下を入力します。# dnf install ovirt-ansible-image-template
ovirt.vm-infra
Ansible ロールをインストールします。RHV Manager およびその他の RHEL マシンでは、このロールはovirt-ansible-vm-infra
パッケージとして提供されます。# dnf install ovirt-ansible-vm-infra
環境変数を作成し、その環境変数に絶対パスまたは相対パスを割り当てます。たとえば、 以下を入力します。
$ export ASSETS_DIR=./wrk
注記インストールプログラムはこの変数を使用して、重要なインストール関連のファイルを保存するディレクトリーを作成します。その後、インストールプロセスはこの変数を再利用して、これらのアセットファイルを見つけます。このアセットディレクトリーを削除しないでください。これは、クラスターのアンインストールに必要になります。
13.5.9. RHV 用の CA 証明書の設定
Red Hat Virtualization (RHV) Manager から CA 証明書をダウンロードし、インストールマシンにこれを設定します。
RHV Manager からの Web サイトまたは curl
コマンドを使用して、証明書をダウンロードできます。
その後、インストールプログラムに証明書を提供します。
手順
以下の 2 つの方法のいずれかを使用して CA 証明書をダウンロードします。
-
Manager の Web ページ (
https://<engine-fqdn>/ovirt-engine/
) に移動します。次に、Downloads で CA Certificate のリンクをクリックします。 以下のコマンドを実行します。
$ curl -k 'https://<engine-fqdn>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA' -o /tmp/ca.pem 1
- 1
<engine-fqdn>
には、RHV Manager の完全修飾ドメイン名 (例:rhv-env.virtlab.example.com
) を指定します。
-
Manager の Web ページ (
ルートレスユーザーに Manager へのアクセスを付与するように CA ファイルを設定します。CA ファイルのパーミッションを 8 進数の
0644
に設定します (シンボリック値:-rw-r—r--
):$ sudo chmod 0644 /tmp/ca.pem
Linux の場合は、サーバー証明書のディレクトリーに CA 証明書をコピーします。
-p
を使用してパーミッションを保存します。$ sudo cp -p /tmp/ca.pem /etc/pki/ca-trust/source/anchors/ca.pem
オペレーティングシステム用の証明書マネージャーに証明書を追加します。
- MacOS の場合は、証明書ファイルをダブルクリックして、Keychain Access ユーティリティーを使用してファイルを System キーチェーンに追加します。
Linux の場合は、CA 信頼を更新します。
$ sudo update-ca-trust
注記独自の認証局を使用する場合は、システムがこれを信頼することを確認します。
関連情報
- 詳細は、RHV ドキュメントの Authentication and Security を参照してください。
13.5.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 公開鍵がクラスターノードに配置されている必要もあります。
障害復旧およびデバッグが必要な実稼働環境では、この手順を省略しないでください。
手順
クラスターノードへの認証に使用するローカルマシンに既存の SSH キーペアがない場合は、これを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 1
- 1
- 新しい SSH キーのパスとファイル名 (
~/.ssh/id_ed25519
など) を指定します。既存のキーペアがある場合は、公開鍵が~/.ssh
ディレクトリーにあることを確認します。
注記FIPS で検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーを使用する OpenShift Container Platform クラスターを
x86_64
アーキテクチャーにインストールする予定の場合は、ed25519
アルゴリズムを使用するキーは作成しないでください。代わりに、rsa
アルゴリズムまたはecdsa
アルゴリズムを使用するキーを作成します。公開 SSH キーを表示します。
$ cat <path>/<file_name>.pub
たとえば、次のコマンドを実行して
~/.ssh/id_ed25519.pub
公開鍵を表示します。$ cat ~/.ssh/id_ed25519.pub
ローカルユーザーの SSH エージェントに SSH 秘密鍵 ID が追加されていない場合は、それを追加します。キーの SSH エージェント管理は、クラスターノードへのパスワードなしの SSH 認証、または
./openshift-install gather
コマンドを使用する場合は必要になります。注記一部のディストリビューションでは、
~/.ssh/id_rsa
および~/.ssh/id_dsa
などのデフォルトの SSH 秘密鍵のアイデンティティーは自動的に管理されます。ssh-agent
プロセスがローカルユーザーに対して実行されていない場合は、バックグラウンドタスクとして開始します。$ eval "$(ssh-agent -s)"
出力例
Agent pid 31874
注記クラスターが FIPS モードにある場合は、FIPS 準拠のアルゴリズムのみを使用して SSH キーを生成します。鍵は RSA または ECDSA のいずれかである必要があります。
SSH プライベートキーを
ssh-agent
に追加します。$ ssh-add <path>/<file_name> 1
- 1
~/.ssh/id_ed25519
などの、SSH プライベートキーのパスおよびファイル名を指定します。
出力例
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
次のステップ
- OpenShift Container Platform をインストールする際に、SSH パブリックキーをインストールプログラムに指定します。
13.5.11. Ansible Playbook のダウンロード
RHV に OpenShift Container Platform バージョン 4.8 をインストールするために Ansible Playbook をダウンロードします。
手順
インストールマシンで、以下のコマンドを実行します。
$ mkdir playbooks
$ cd playbooks
$ curl -s -L -X GET https://api.github.com/repos/openshift/installer/contents/upi/ovirt?ref=release-4.8 | grep 'download_url.*\.yml' | awk '{ print $2 }' | sed -r 's/("|",)//g' | xargs -n 1 curl -O
次のステップ
-
これらの Ansible Playbook をダウンロードしたら、インストールプログラムを実行してインストール設定ファイルを作成する前に、アセットディレクトリーの環境変数を作成し、
inventory.yml
ファイルをカスタマイズする必要もあります。
13.5.12. inventory.yml ファイル
inventory.yml
ファイルを使用して、インストールする OpenShift Container Platform クラスターの各種の要素を定義し、作成します。これには、Red Hat Enterprise Linux CoreOS(RHCOS) イメージ、仮想マシンテンプレート、ブートストラップマシン、コントロールプレーンノード、ワーカーノードなどの要素が含まれます。また、inventory.yml
を使用してクラスターを破棄します。
以下の inventory.yml
の例は、パラメーターとそれらのデフォルト値を示しています。これらのデフォルト値の量と数は、RHV 環境で実稼働用の OpenShift Container Platform クラスターを実行するための要件を満たしています。
inventory.yml
ファイルの例
--- all: vars: ovirt_cluster: "Default" ocp: assets_dir: "{{ lookup('env', 'ASSETS_DIR') }}" ovirt_config_path: "{{ lookup('env', 'HOME') }}/.ovirt/ovirt-config.yaml" # --- # {op-system} section # --- rhcos: image_url: "https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.8/latest/rhcos-openstack.x86_64.qcow2.gz" local_cmp_image_path: "/tmp/rhcos.qcow2.gz" local_image_path: "/tmp/rhcos.qcow2" # --- # Profiles section # --- control_plane: cluster: "{{ ovirt_cluster }}" memory: 16GiB sockets: 4 cores: 1 template: rhcos_tpl operating_system: "rhcos_x64" type: high_performance graphical_console: headless_mode: false protocol: - spice - vnc disks: - size: 120GiB name: os interface: virtio_scsi storage_domain: depot_nvme nics: - name: nic1 network: lab profile: lab compute: cluster: "{{ ovirt_cluster }}" memory: 16GiB sockets: 4 cores: 1 template: worker_rhcos_tpl operating_system: "rhcos_x64" type: high_performance graphical_console: headless_mode: false protocol: - spice - vnc disks: - size: 120GiB name: os interface: virtio_scsi storage_domain: depot_nvme nics: - name: nic1 network: lab profile: lab # --- # Virtual machines section # --- vms: - name: "{{ metadata.infraID }}-bootstrap" ocp_type: bootstrap profile: "{{ control_plane }}" type: server - name: "{{ metadata.infraID }}-master0" ocp_type: master profile: "{{ control_plane }}" - name: "{{ metadata.infraID }}-master1" ocp_type: master profile: "{{ control_plane }}" - name: "{{ metadata.infraID }}-master2" ocp_type: master profile: "{{ control_plane }}" - name: "{{ metadata.infraID }}-worker0" ocp_type: worker profile: "{{ compute }}" - name: "{{ metadata.infraID }}-worker1" ocp_type: worker profile: "{{ compute }}" - name: "{{ metadata.infraID }}-worker2" ocp_type: worker profile: "{{ compute }}"
Enter から始まる説明のあるパラメーターの値を入力します。 それ以外の場合は、デフォルト値を使用するか、またはこえを新しい値に置き換えることができます。
General セクション
-
ovirt_cluster
: OpenShift Container Platform クラスターをインストールする既存の RHV クラスターの名前を入力します。 -
ocp.assets_dir
:openshift-install
インストールプログラムが生成するファイルを保存するために作成するディレクトリーのパス。 -
ocp.ovirt_config_path
: インストールプログラムが生成するovirt-config.yaml
ファイルのパス (./wrk/install-config.yaml
など)。このファイルには、Manager の REST API との対話に必要な認証情報が含まれます。
Red Hat Enterprise Linux CoreOS (RHCOS) セクション
-
image_url
: ダウンロード用に指定した RHCOS イメージの URL を入力します。 -
local_cmp_image_path
: 圧縮された RHCOS イメージのローカルダウンロードディレクトリーのパス。 -
local_image_path
: 展開した RHCOS イメージのローカルディレクトリーのパス。
Profiles セクション
このセクションは、2 つのプロファイルで設定されます。
-
control_plane
: ブートストラップおよびコントロールプレーンノードのプロファイル。 -
compute
: コンピュートプレーン内のワーカーノードのプロファイル。
これらのプロファイルには以下のパラメーターが含まれます。パラメーターのデフォルト値は、実稼働クラスターを実行するために必要な最小要件を満たします。これらの値は、ワークロードの要件に応じて増減したり、カスタマイズしたりできます。
-
cluster
: 値は、General セクションのovirt_cluster
からクラスター名を取得します。 -
memory
: 仮想マシンに必要なメモリーの量 (GB)。 -
sockets
: 仮想マシンのソケット数。 -
cores
: 仮想マシンのコア数。 -
template
: 仮想マシンテンプレートの名前。複数のクラスターをインストールする計画があり、これらのクラスターが異なる仕様が含まれるテンプレートを使用する場合には、テンプレート名の先頭にクラスターの ID を付けます。 -
operating_system
: 仮想マシンのゲストオペレーティングシステムのタイプ。oVirt/RHV バージョン 4.4 では、Ignition script
の値を仮想マシンに渡すことができるようにするために、この値をrhcos_x64
にする必要があります。 type
: 仮想マシンのタイプとしてserver
を入力します。重要type
パラメーターの値をhigh_performance
からserver
に変更する必要があります。-
disks
: ディスクの仕様。control_plane
とcompute
ノードには、異なるストレージドメインを設定できます。 -
size
: ディスクの最小サイズ。 -
name
: RHV のターゲットクラスターに接続されたディスクの名前を入力します。 -
interface
: 指定したディスクのインターフェイスタイプを入力します。 -
storage_domain
: 指定したディスクのストレージドメインを入力します。 -
nics
: 仮想マシンが使用するname
およびnetwork
を入力します。仮想ネットワークインターフェイスプロファイルを指定することもできます。デフォルトでは、NIC は oVirt/RHV MAC プールから MAC アドレスを取得します。
仮想マシンセクション
この最後のセクション vms
は、クラスターで作成およびデプロイする予定の仮想マシンを定義します。デフォルトで、実稼働環境用の最小数のコントロールプレーンおよびワーカーノードが提供されます。
vms
には 3 つの必須要素が含まれます。
-
name
: 仮想マシンの名前。この場合、metadata.infraID
は、仮想マシン名の先頭にmetadata.yml
ファイルのインフラストラクチャー ID を付けます。 -
ocp_type
: OpenShift Container Platform クラスター内の仮想マシンのロール。使用できる値はbootstrap
、master
、worker
です。 profile
: それぞれの仮想マシンが仕様を継承するプロファイルの名前。この例で使用可能な値はcontrol_plane
またはcompute
です。仮想マシンがプロファイルから継承する値を上書きできます。これを実行するには、
inventory.yml
の仮想マシンに profile 属性の名前を追加し、これに上書きする値を割り当てます。この例を確認するには、直前のinventory.yml
の例のname: "{{ metadata.infraID }}-bootstrap"
仮想マシンを検査します。これには値がserver
のtype
属性があり、この仮想マシンがそれ以外の場合にcontrol_plane
プロファイルから継承するtype
属性の値を上書きします。
メタデータ変数
仮想マシンの場合、metadata.infraID
は、仮想マシンの名前の先頭に、Ignition ファイルのビルド時に作成する metadata.json
ファイルのインフラストラクチャー ID を付けます。
Playbook は以下のコードを使用して、ocp.assets_dir
にある特定のファイルから infraID
を読み取ります。
--- - name: include metadata.json vars include_vars: file: "{{ ocp.assets_dir }}/metadata.json" name: metadata ...
13.5.13. RHCOS イメージ設定の指定
inventory.yml
ファイルの Red Hat Enterprise Linux CoreOS (RHCOS) イメージ設定を更新します。後にこのファイルを Playbook のいずれかとして実行すると、圧縮された Red Hat Enterprise Linux CoreOS (RHCOS) イメージが image_url
URL から local_cmp_image_path
ディレクトリーにダウンロードされます。次に Playbook はイメージを local_image_path
ディレクトリーに展開し、これを使用して oVirt/RHV テンプレートを作成します。
手順
- インストールする OpenShift Container Platform バージョンの RHCOS イメージダウンロードページを見つけます (例: /pub/openshift-v4/dependencies/rhcos/latest/latest のインデックス)。
-
そのダウンロードページから、
https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.8/latest/rhcos-openstack.x86_64.qcow2.gz
などの OpenStackqcow2
イメージの URL をコピーします。 先のステップでダウンロードした
inventory.yml
Playbook を編集します。この中で、URL をimage_url
の値として貼り付けます。以下に例を示します。rhcos: "https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.8/latest/rhcos-openstack.x86_64.qcow2.gz"
13.5.14. インストール設定ファイルの作成
インストールプログラム openshift-install
を実行し、先に指定または収集した情報でプロンプトに応答し、インストール設定ファイルを作成します。
プロンプトに応答すると、インストールプログラムは、以前に指定したアセットディレクトリーの install-config.yaml
ファイルの初期バージョンを作成します (例: ./wrk/install-config.yaml
)。
インストールプログラムは、Manager に到達して REST API を使用するために必要なすべての接続パラメーターが含まれる $HOME/.ovirt/ovirt-config.yaml
ファイルも作成します。
注: インストールプロセスでは、Internal API virtual IP
および Ingress virtual IP
などの一部のパラメーターに指定する値を使用しません。それらの値はインフラストラクチャー DNS にすでに設定されているためです。
また、oVirt cluster
、 oVirt storage
、および oVirt network
などの値のような inventory.yml
のパラメーターに指定する値を使用します。また、スクリプトを使用して install-config.yaml
の同じ値を削除するか、またはこれを前述の virtual IPs
に置き換えます。
手順
インストールプログラムを実行します。
$ openshift-install create install-config --dir $ASSETS_DIR
インストールプログラムのプロンプトに応答し、システムに関する情報を提供します。
出力例
? SSH Public Key /home/user/.ssh/id_dsa.pub ? Platform <ovirt> ? Engine FQDN[:PORT] [? for help] <engine.fqdn> ? Enter ovirt-engine username <ocpadmin@internal> ? Enter password <******> ? oVirt cluster <cluster> ? oVirt storage <storage> ? oVirt network <net> ? Internal API virtual IP <172.16.0.252> ? Ingress virtual IP <172.16.0.251> ? Base Domain <example.org> ? Cluster Name <ocp4> ? Pull Secret [? for help] <********>
? SSH Public Key /home/user/.ssh/id_dsa.pub ? Platform <ovirt> ? Engine FQDN[:PORT] [? for help] <engine.fqdn> ? Enter ovirt-engine username <ocpadmin@internal> ? Enter password <******> ? oVirt cluster <cluster> ? oVirt storage <storage> ? oVirt network <net> ? Internal API virtual IP <172.16.0.252> ? Ingress virtual IP <172.16.0.251> ? Base Domain <example.org> ? Cluster Name <ocp4> ? Pull Secret [? for help] <********>
Internal API virtual IP
および Ingress virtual IP
について、DNS サービスの設定時に指定した IP アドレスを指定します。
さらに、oVirt cluster
および Base Domain
プロンプトに対して入力する値は REST API および作成するアプリケーションの URL の一部を設定します (例: https://api.ocp4.example.org:6443/
and https://console-openshift-console.apps.ocp4.example.org
)。
13.5.15. IBM Z のサンプル install-config.yaml ファイル
13.5.16. RHV のサンプル install-config.yaml ファイル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームについての詳細を指定するか、または必要なパラメーターの値を変更することができます。
apiVersion: v1 baseDomain: example.com 1 compute: 2 - hyperthreading: Enabled 3 name: worker replicas: 0 4 controlPlane: 5 hyperthreading: Enabled 6 name: master replicas: 3 7 metadata: name: test 8 networking: clusterNetwork: - cidr: 10.128.0.0/14 9 hostPrefix: 23 10 networkType: OpenShiftSDN serviceNetwork: 11 - 172.30.0.0/16 platform: none: {} 12 fips: false 13 pullSecret: '{"auths": ...}' 14 sshKey: 'ssh-ed25519 AAAA...' 15
- 1
- クラスターのベースドメイン。すべての DNS レコードはこのベースのサブドメインである必要があり、クラスター名が含まれる必要があります。
- 2 5
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 3 6
- 同時マルチスレッド (SMT) またはハイパースレッディングを有効/無効にするかどうかを指定します。デフォルトでは、SMT はマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値を
Disabled
に設定するとこれを無効にすることができます。SMT を無効にする場合、これをすべてのクラスターマシンで無効にする必要があります。これにはコントロールプレーンとコンピュートマシンの両方が含まれます。注記同時マルチスレッド (SMT) はデフォルトで有効になっています。SMT が BIOS 設定で有効になっていない場合は、
hyperthreading
パラメーターは効果がありません。重要BIOS または
install-config.yaml
であるかに関係なくhyperthreading
を無効にする場合、容量計画においてマシンのパフォーマンスの大幅な低下が考慮に入れられていることを確認します。 - 4
- OpenShift Container Platform をユーザーによってプロビジョニングされるインフラストラクチャーにインストールする場合は、この値を
0
に設定する必要があります。インストーラーでプロビジョニングされるインストールでは、パラメーターはクラスターが作成し、管理するコンピュートマシンの数を制御します。ユーザーによってプロビジョニングされるインストールでは、クラスターのインストールの終了前にコンピュートマシンを手動でデプロイする必要があります。注記3 ノードクラスターをインストールする場合は、Red Hat Enterprise Linux CoreOS (RHCOS) マシンをインストールする際にコンピュートマシンをデプロイしないでください。
- 7
- クラスターに追加するコントロールプレーンマシンの数。クラスターをこれらの値をクラスターの etcd エンドポイント数として使用するため、値はデプロイするコントロールプレーンマシンの数に一致する必要があります。
- 8
- DNS レコードに指定したクラスター名。
- 9
- Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定する必要があります。注記
クラス E の CIDR 範囲は、将来の使用のために予約されています。クラス E CIDR 範囲を使用するには、ネットワーク環境がクラス E CIDR 範囲内の IP アドレスを受け入れるようにする必要があります。
- 10
- それぞれの個別ノードに割り当てるサブネット接頭辞長。たとえば、
hostPrefix
が23
に設定されている場合、各ノードに指定のcidr
から/23
サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。 - 11
- サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみを入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネットワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。
- 12
- プラットフォームを
none
に設定する必要があります。IBM Z インフラストラクチャー用に追加のプラットフォーム設定変数を指定できません。RHV インフラストラクチャー。警告Red Hat Virtualization は現在、oVirt プラットフォーム上にあるユーザーによってプロビジョニングされるインフラストラクチャーでのインストールをサポートしていません。そのため、プラットフォームを
none
に設定し、OpenShift Container Platform が各ノードをベアメタルノードとして、およびクラスターをベアメタルクラスターとして識別できるようにします。これは、任意のプラットフォームにクラスターをインストールする のと同じであり、次の制限があります。- クラスタープロバイダーがないため、各マシンを手動で追加する必要があり、ノードスケーリング機能はありません。
- oVirt CSI ドライバーはインストールされず、CSI 機能はありません。
- 13
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、
x86_64
アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。 - 14
- Red Hat OpenShift Cluster Manager からのプルシークレット。このプルシークレットを使用し、OpenShift Container Platform コンポーネントのコンテナーイメージを提供する Quay.io など、組み込まれた各種の認証局によって提供されるサービスで認証できます。
- 15
- Red Hat Enterprise Linux CoreOS (RHCOS) の
core
ユーザーの SSH 公開鍵。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
13.5.16.1. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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
ファイルを編集し、プロキシー設定を追加します。以下に例を示します。apiVersion: v1 baseDomain: my.domain.com proxy: httpProxy: http://<username>:<pswd>@<ip>:<port> 1 httpsProxy: https://<username>:<pswd>@<ip>:<port> 2 noProxy: example.com 3 additionalTrustBundle: | 4 -----BEGIN CERTIFICATE----- <MY_TRUSTED_CA_CERT> -----END CERTIFICATE----- ...
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 4
- 指定されている場合には、インストールプログラムは、
openshift-config
namespace にuser-ca-bundle
という名前の設定魔府を生成して、追加の CA 証明書を保存します。additionalTrustBundle
と少なくとも 1 つのプロキシー設定を指定した場合には、Proxy
オブジェクトはtrusted CA
フィールドでuser-ca-bundle
設定マップを参照するように設定されます。その後、Cluster Network Operator は、trustedCA
パラメーターに指定されたコンテンツを RHCOS トラストバンドルにマージするtrusted-ca-bundle
設定マップを作成します。additionalTrustBundle
フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
注記インストールプログラムは、プロキシーの
readinessEndpoints
フィールドをサポートしません。- ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
13.5.17. install-config.yaml のカスタマイズ
ここでは、3 つの python スクリプトを使用して、インストールプログラムのデフォルト動作の一部を上書きします。
- デフォルトでは、インストールプログラムはマシン API を使用してノードを作成します。このデフォルトの動作を上書きするには、コンピュートノードの数をゼロ (0) レプリカに設定します。後に Ansible Playbook を使用してコンピュートノードを作成します。
- デフォルトでは、インストールプログラムはノードのマシンネットワークの IP 範囲を設定します。このデフォルトの動作を上書きするには、インフラストラクチャーに一致するように IP 範囲を設定します。
-
デフォルトでは、インストールプログラムはプラットフォームを
ovirt
に設定します。ただし、ユーザーによってプロビジョニングされるインフラストラクチャーにクラスターをインストールすることは、ベアメタルにクラスターをインストールすることに似ています。したがって、ovirt プラットフォームセクションをinstall-config.yaml
から削除し、プラットフォームをnone
に変更します。代わりに、inventory.yml
を使用して、必要な設定をすべて指定します。
これらのスニペットは Python 3 および Python 2 で動作します。
手順
コンピュートノードの数をゼロ (0) レプリカに設定します。
$ python3 -c 'import os, yaml path = "%s/install-config.yaml" % os.environ["ASSETS_DIR"] conf = yaml.safe_load(open(path)) conf["compute"][0]["replicas"] = 0 open(path, "w").write(yaml.dump(conf, default_flow_style=False))'
マシンネットワークの IP 範囲を設定します。たとえば、範囲を
172.16.0.0/16
に設定するには、以下を実行します。$ python3 -c 'import os, yaml path = "%s/install-config.yaml" % os.environ["ASSETS_DIR"] conf = yaml.safe_load(open(path)) conf["networking"]["machineNetwork"][0]["cidr"] = "172.16.0.0/16" open(path, "w").write(yaml.dump(conf, default_flow_style=False))'
ovirt
セクションを削除し、プラットフォームをnone
に変更します。$ python3 -c 'import os, yaml path = "%s/install-config.yaml" % os.environ["ASSETS_DIR"] conf = yaml.safe_load(open(path)) platform = conf["platform"] del platform["ovirt"] platform["none"] = {} open(path, "w").write(yaml.dump(conf, default_flow_style=False))'
警告Red Hat Virtualization は現在、oVirt プラットフォーム上にあるユーザーによってプロビジョニングされるインフラストラクチャーでのインストールをサポートしていません。そのため、プラットフォームを
none
に設定し、OpenShift Container Platform が各ノードをベアメタルノードとして、およびクラスターをベアメタルクラスターとして識別できるようにします。これは、任意のプラットフォームにクラスターをインストールする のと同じであり、次の制限があります。- クラスタープロバイダーがないため、各マシンを手動で追加する必要があり、ノードスケーリング機能はありません。
- oVirt CSI ドライバーはインストールされず、CSI 機能はありません。
13.5.18. マニフェストファイルの生成
インストールプログラムを使用して、アセットディレクトリーにマニフェストファイルのセットを生成します。
マニフェストファイルを生成するコマンドにより、install-config.yaml
ファイルを使用する前に警告メッセージが表示されます。
install-config.yaml
ファイルを再利用する予定の場合には、マニフェストファイルを生成する前にバックアップしてからバックアップコピーを作成してください。
手順
オプション:
install-config.yaml
ファイルのバックアップコピーを作成します。$ cp install-config.yaml install-config.yaml.backup
アセットディレクトリーにマニフェストのセットを生成します。
$ openshift-install create manifests --dir $ASSETS_DIR
このコマンドにより、以下の情報が表示されます。
出力例
INFO Consuming Install Config from target directory WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings
このコマンドにより、以下のマニフェストファイルが生成されます。
出力例
$ tree . └── wrk ├── manifests │ ├── 04-openshift-machine-config-operator.yaml │ ├── cluster-config.yaml │ ├── cluster-dns-02-config.yml │ ├── cluster-infrastructure-02-config.yml │ ├── cluster-ingress-02-config.yml │ ├── cluster-network-01-crd.yml │ ├── cluster-network-02-config.yml │ ├── cluster-proxy-01-config.yaml │ ├── cluster-scheduler-02-config.yml │ ├── cvo-overrides.yaml │ ├── etcd-ca-bundle-configmap.yaml │ ├── etcd-client-secret.yaml │ ├── etcd-host-service-endpoints.yaml │ ├── etcd-host-service.yaml │ ├── etcd-metric-client-secret.yaml │ ├── etcd-metric-serving-ca-configmap.yaml │ ├── etcd-metric-signer-secret.yaml │ ├── etcd-namespace.yaml │ ├── etcd-service.yaml │ ├── etcd-serving-ca-configmap.yaml │ ├── etcd-signer-secret.yaml │ ├── kube-cloud-config.yaml │ ├── kube-system-configmap-root-ca.yaml │ ├── machine-config-server-tls-secret.yaml │ └── openshift-config-secret-pull-secret.yaml └── openshift ├── 99_kubeadmin-password-secret.yaml ├── 99_openshift-cluster-api_master-user-data-secret.yaml ├── 99_openshift-cluster-api_worker-user-data-secret.yaml ├── 99_openshift-machineconfig_99-master-ssh.yaml ├── 99_openshift-machineconfig_99-worker-ssh.yaml └── openshift-install-manifests.yaml
次のステップ
- コントロールプレーンノードをスケジュール対象外にします。
13.5.19. コントロールプレーンノードのスケジュール対象外の設定
コントロールプレーンマシンを手動で作成し、デプロイしているので、コントロールプレーンノードをスケジュール対象外にするようにマニフェストファイルを設定する必要があります。
手順
コントロールプレーンノードをスケジュール対象外にするには、以下を入力します。
$ python3 -c 'import os, yaml path = "%s/manifests/cluster-scheduler-02-config.yml" % os.environ["ASSETS_DIR"] data = yaml.safe_load(open(path)) data["spec"]["mastersSchedulable"] = False open(path, "w").write(yaml.dump(data, default_flow_style=False))'
13.5.20. Ignition ファイルのビルド
生成および変更したマニフェストファイルから Ignition ファイルを作成するには、インストールプログラムを実行します。このアクションにより、Ignition ファイルをフェッチし、ノードを作成するために必要な設定を実行する Red Hat Enterprise Linux CoreOS (RHCOS) マシン initramfs
が作成されます。
Ignition ファイルのほかに、インストールプログラムは以下を生成します。
-
oc
およびkubectl
ユーティリティーを使用してクラスターに接続するための管理者認証情報が含まれるauth
ディレクトリー。 -
OpenShift Container Platform クラスター名、クラスター ID、および現行インストールのインフラストラクチャー ID などの情報を含む
metadata.json
ファイル。
このインストールプロセスの Ansible Playbook は、infraID
の値を、作成する仮想マシンの接頭辞として使用します。これにより、同じ oVirt/RHV クラスターに複数のインストールがある場合の命名の競合が回避されます。
Ignition 設定ファイルの証明書は 24 時間後に有効期限が切れます。最初の証明書のローテーションが終了するように、クラスターのインストールを完了し、クラスターを動作が低下していない状態で 24 時間実行し続ける必要があります。
手順
Ignition ファイルをビルドするには、以下を入力します。
$ openshift-install create ignition-configs --dir $ASSETS_DIR
出力例
$ tree . └── wrk ├── auth │ ├── kubeadmin-password │ └── kubeconfig ├── bootstrap.ign ├── master.ign ├── metadata.json └── worker.ign
13.5.21. テンプレートおよび仮想マシンの作成
inventory.yml
の変数を確認した後に、最初の Ansible プロビジョニング Playbook create-templates-and-vms.yml
を実行します。
この Playbook は、$HOME/.ovirt/ovirt-config.yaml
から RHV Manager の接続パラメーターを使用し、アセットディレクトリーで metadata.json
を読み取ります。
ローカルの Red Hat Enterprise Linux CoreOS (RHCOS) イメージが存在しない場合、Playbook は inventory.yml
の image_url
に指定した URL からダウンロードします。これはイメージを展開し、これを RHV にアップロードしてテンプレートを作成します。
Playbook は、inventory.yml
ファイルの control_plane
と compute
プロファイルに基づいてテンプレートを作成します。これらのプロファイルの名前が異なる場合、2 つのテンプレートが作成されます。
Playbook が完了すると、作成される仮想マシンは停止します。他のインフラストラクチャー要素の設定に役立つ情報を取得できます。たとえば、仮想マシンの MAC アドレスを取得して、仮想マシンに永続的な IP アドレスを割り当てるように DHCP を設定できます。
手順
-
inventory.yml
のcontrol_plane
およびcompute
変数で、type: high_performance
の 両方のインスタンスをtype: server
に変更します。 オプション: 同じクラスターに複数のインストールを実行する予定の場合には、OpenShift Container Platform インストールごとに異なるテンプレートを作成します。
inventory.yml
ファイルで、template
の値の先頭にinfraID
を付けます。以下に例を示します。control_plane: cluster: "{{ ovirt_cluster }}" memory: 16GiB sockets: 4 cores: 1 template: "{{ metadata.infraID }}-rhcos_tpl" operating_system: "rhcos_x64" ...
テンプレートおよび仮想マシンを作成します。
$ ansible-playbook -i inventory.yml create-templates-and-vms.yml
13.5.22. ブートストラップマシンの作成
bootstrap.yml
Playbook を実行してブートストラップマシンを作成します。この Playbook はブートストラップ仮想マシンを起動し、これをアセットディレクトリーから bootstrap.ign
Ignition ファイルに渡します。ブートストラップノードは、Ignition ファイルをコントロールプレーンノードに送信できるように設定します。
ブートストラッププロセスをモニターするには、RHV 管理ポータルでコンソールを使用するか、SSH を使用して仮想マシンに接続します。
手順
ブートストラップマシンを作成します。
$ ansible-playbook -i inventory.yml bootstrap.yml
管理ポータルまたは SSH のコンソールを使用してブートストラップマシンに接続します。
<bootstrap_ip>
をブートストラップノードの IP アドレスに置き換えます。SSH を使用するには、以下を入力します。$ ssh core@<boostrap.ip>
ブートストラップノードからリリースイメージサービスについての
bootkube.service
journald ユニットログを収集します。[core@ocp4-lk6b4-bootstrap ~]$ journalctl -b -f -u release-image.service -u bootkube.service
注記ブートストラップノードの
bootkube.service
ログは、etcd のconnection refused
エラーを出力し、ブートストラップサーバーがコントロールプレーンノード (別名マスターノード) の etcd に接続できないことを示します。etcd が各コントロールプレーンノードで起動し、ノードがクラスターに参加した後には、エラーは発生しなくなるはずです。
13.5.23. コントロールプレーンノードの作成
masters.yml
Playbook を実行してコントロールプレーンノードを作成します。この Playbook は master.ign
Ignition ファイルをそれぞれの仮想マシンに渡します。Ignition ファイルには、https://api-int.ocp4.example.org:22623/config/master
などの URL から Ignition を取得するためのコントロールプレーンノードのディレクティブが含まれます。この URL のポート番号はロードバランサーによって管理され、クラスター内でのみアクセスできます。
手順
コントロールプレーンノードを作成します。
$ ansible-playbook -i inventory.yml masters.yml
Playbook がコントロールプレーンを作成する間に、ブートストラッププロセスをモニターします。
$ openshift-install wait-for bootstrap-complete --dir $ASSETS_DIR
出力例
INFO API v1.18.3+b74c5ed up INFO Waiting up to 40m0s for bootstrapping to complete...
コントロールプレーンノードおよび etcd のすべての Pod が実行されている場合、インストールプログラムは以下の出力を表示します。
出力例
INFO It is now safe to remove the bootstrap resources
13.5.24. クラスターステータスの確認
インストール時またはインストール後に OpenShift Container Platform クラスターのステータスを確認することができます。
手順
クラスター環境で、管理者の kubeconfig ファイルをエクスポートします。
$ export KUBECONFIG=$ASSETS_DIR/auth/kubeconfig
kubeconfig
ファイルには、クライアントを正しいクラスターおよび API サーバーに接続するために CLI で使用されるクラスターについての情報が含まれます。デプロイメント後に作成されたコントロールプレーンおよびコンピュートマシンを表示します。
$ oc get nodes
クラスターのバージョンを表示します。
$ oc get clusterversion
Operator のステータスを表示します。
$ oc get clusteroperator
クラスター内のすべての実行中の Pod を表示します。
$ oc get pods -A
13.5.25. ブートストラップマシンの削除
wait-for
コマンドがブートストラッププロセスが完了したことを示していることを確認したら、ブートストラップ仮想マシンを削除してコンピュート、メモリー、およびストレージリソースを解放する必要があります。また、ロードバランサーディレクティブからブートストラップマシンの設定を削除します。
手順
クラスターからブートストラップマシンを削除するには、以下を実行します。
$ ansible-playbook -i inventory.yml retire-bootstrap.yml
- ロードバランサーディレクティブからブートストラップマシンの設定を削除します。
13.5.26. ワーカーノードの作成およびインストールの完了
ワーカーノードの作成は、コントロールプレーンノードの作成と同様です。ただし、ワーカーノードはクラスターに自動的に参加しません。これらをクラスターに追加するには、ワーカーの保留状態の CSR(証明書署名要求) を確認し、承認します。
最初の要求の承認後に、ワーカーノードがすべて承認されるまで CSR の承認を継続します。このプロセスが完了すると、ワーカーノードは Ready
になり、Pod がそれらで実行されるようにスケジュールできます。
最後に、コマンドラインを監視し、インストールプロセスが完了するタイミングを確認します。
手順
ワーカーノードを作成します。
$ ansible-playbook -i inventory.yml workers.yml
すべての CSR を一覧表示するには、以下を入力します。
$ oc get csr -A
最終的に、このコマンドはノードごとに 1 つの CSR を表示します。以下に例を示します。
出力例
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-2lnxd 63m kubernetes.io/kubelet-serving system:node:ocp4-lk6b4-master0.ocp4.example.org Approved,Issued csr-hff4q 64m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-hsn96 60m kubernetes.io/kubelet-serving system:node:ocp4-lk6b4-master2.ocp4.example.org Approved,Issued csr-m724n 6m2s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-p4dz2 60m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-t9vfj 60m kubernetes.io/kubelet-serving system:node:ocp4-lk6b4-master1.ocp4.example.org Approved,Issued csr-tggtr 61m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Approved,Issued csr-wcbrf 7m6s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
一覧をフィルターし、保留中の CSR のみを表示するには、以下を実行します。
$ watch "oc get csr -A | grep pending -i"
このコマンドは 2 秒ごとに出力を更新し、保留中の CSR のみを表示します。以下に例を示します。
出力例
Every 2.0s: oc get csr -A | grep pending -i csr-m724n 10m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending csr-wcbrf 11m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending
保留中のそれぞれの要求を検査します。以下に例を示します。
出力例
$ oc describe csr csr-m724n
出力例
Name: csr-m724n Labels: <none> Annotations: <none> CreationTimestamp: Sun, 19 Jul 2020 15:59:37 +0200 Requesting User: system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Signer: kubernetes.io/kube-apiserver-client-kubelet Status: Pending Subject: Common Name: system:node:ocp4-lk6b4-worker1.ocp4.example.org Serial Number: Organization: system:nodes Events: <none>
CSR 情報が正しい場合は、要求を承認します。
$ oc adm certificate approve csr-m724n
インストールプロセスが完了するまで待機します。
$ openshift-install wait-for install-complete --dir $ASSETS_DIR --log-level debug
インストールが完了すると、コマンドラインには OpenShift Container Platform Web コンソールの URL と、管理者のユーザー名およびパスワードが表示されます。
13.5.27. OpenShift Container Platform の Telemetry アクセス
OpenShift Container Platform 4.8 では、クラスターの健全性および正常に実行された更新についてのメトリクスを提供するためにデフォルトで実行される Telemetry サービスにもインターネットアクセスが必要です。クラスターがインターネットに接続されている場合、Telemetry は自動的に実行され、クラスターは OpenShift Cluster Manager に登録されます。
OpenShift Cluster Manager インベントリーが正常である (Telemetry によって自動的に維持、または OpenShift Cluster Manager を使用して手動で維持) ことを確認した後に、subscription watch を使用 して、アカウントまたはマルチクラスターレベルで OpenShift Container Platform サブスクリプションを追跡します。
関連情報
- Telemetry サービスの詳細は、リモートヘルスモニターリングについて を参照してください。
13.5.28. デフォルトの 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}]'
または、Web コンソールを使用してカタログソースを管理できます。Administration