3.6. Azure のクラスターの既存 VNet へのインストール
OpenShift Container Platform バージョン 4.17 では、Microsoft Azure 上の既存の Azure Virtual Network (VNet) にクラスターをインストールできます。インストールプログラムは、カスタマイズ可能な残りの必要なインフラストラクチャーをプロビジョニングします。インストールをカスタマイズするには、クラスターをインストールする前に、install-config.yaml
ファイルでパラメーターを変更します。
3.6.1. OpenShift Container Platform クラスターでの VNet の再利用について
OpenShift Container Platform 4.17 では、クラスターを Microsoft Azure の既存の Azure Virtual Network (VNet) にデプロイできます。これを実行する場合、VNet 内の既存のサブネットおよびルーティングルールも使用する必要があります。
OpenShift Container Platform を既存の Azure VNet にデプロイすることで、新規アカウントでのサービス制限の制約を回避したり、会社のガイドラインによる運用上の制約をより容易に遵守することが可能になる場合があります。VNet の作成に必要なインフラストラクチャーの作成パーミッションを取得できない場合には、このオプションを使用できます。
3.6.1.1. VNet を使用するための要件
既存の VNet を使用してクラスターをデプロイする場合、クラスターをインストールする前に追加のネットワーク設定を実行する必要があります。installer-provisioned infrastructure クラスターでは、インストーラーは通常以下のコンポーネントを作成しますが、既存の VNet にインストールする場合にはこれらを作成しません。
- サブネット
- ルートテーブル
- VNets
- ネットワークセキュリティーグループ
インストールプログラムでは、クラウド提供の DNS サーバーを使用する必要があります。カスタム DNS サーバーの使用はサポートされていないため、インストールが失敗します。
カスタム VNet を使用する場合、インストールプログラムおよびクラスターで使用できるようにカスタム VNet およびそのサブネットを適切に設定する必要があります。インストールプログラムは、使用するクラスターのネットワーク範囲を細分化できず、サブネットのルートテーブルを設定するか、DHCP などの VNet オプションを設定します。これは、クラスターのインストール前に設定する必要があります。
クラスターは、既存の VNet およびサブネットを含むリソースグループにアクセスできる必要があります。クラスターが作成するすべてのリソースは、作成される別個のリソースグループに配置され、一部のネットワークリソースが別個のグループから使用されます。一部のクラスター Operator は両方のリソースグループのリソースにアクセスできる必要があります。たとえばマシン API コントローラーは、ネットワークリソースグループから、作成される仮想マシンの NIC をサブネットに割り当てます。
VNet には以下の特徴が確認される必要があります。
-
VNet の CIDR ブロックには、クラスターマシンの IP アドレスプールである
Networking.MachineCIDR
範囲が含まれる必要があります。 - VNet およびそのサブネットは同じリソースグループに属する必要があり、サブネットは静的 IP アドレスではなく、Azure で割り当てられた DHCP IP アドレスを使用するように設定される必要があります。
コントロールプレーンマシンのサブネットおよびコンピュートマシン用のサブネットの 2 つのサブネットを VNet 内に指定する必要があります。Azure はマシンを指定するリージョン内の複数の異なるアベイラビリティーゾーンに分散するため、デフォルトのクラスターには高可用性があります。
デフォルトでは、install-config.yaml
ファイルでアベイラビリティゾーンを指定すると、インストールプログラムはコントロールプレーンマシンとコンピューティングマシンを リージョン 内の これらのアベイラビリティゾーン に分散します。クラスターの高可用性を確保するには、少なくとも 3 つ以上のアベイラビリティーゾーンのあるリージョンを選択します。リージョンに含まれるアベイラビリティーゾーンが 3 つ未満の場合、インストールプログラムは複数のコントロールプレーンマシンを利用可能なゾーンに配置します。
指定するサブネットが適切であることを確認するには、インストールプログラムが以下のデータを確認します。
- 指定されたサブネットがすべて存在します。
- コントロールプレーンマシンのサブネットおよびコンピュートマシンのサブネットの 2 つのサブネットがあります
- サブネットの CIDR は指定されたマシン CIDR に属します。マシンは、プライベートサブネットを指定しないアベイラビリティーゾーンにはプロビジョニングされません。必要な場合に、インストールプログラムはコントロールプレーンおよびワーカーノードを管理するパブリックロードバランサーを作成し、Azure はパブリック IP アドレスをそれらに割り当てます。
既存の VNet を使用するクラスターを破棄しても、VNet は削除されません。
3.6.1.1.1. ネットワークセキュリティーグループの要件
コンピュートマシンおよびコントロールプレーンマシンをホストするサブネットのネットワークセキュリティーグループには、クラスターの通信が正しいことを確認するための特定のアクセスが必要です。必要なクラスター通信ポートへのアクセスを許可するルールを作成する必要があります。
ネットワークセキュリティーグループルールは、クラスターのインストール前に有効にされている必要があります。必要なアクセスなしにクラスターのインストールを試行しても、インストールプログラムは Azure API に到達できず、インストールに失敗します。
ポート | 説明 | コントロールプレーン | Compute |
---|---|---|---|
| HTTP トラフィックを許可します。 | x | |
| HTTPS トラフィックを許可します | x | |
| コントロールプレーンマシンとの通信を許可します。 | x | |
| マシンをプロビジョニングするためのマシン設定サーバーへの内部通信を許可します。 | x |
- Azure Firewall を使用してインターネットアクセスを制限している場合は、Azure API を許可するように Azure Firewall を設定できます。ネットワークセキュリティーグループルールは必要ありません。詳細は、関連情報の「ファイアウォールの設定」を参照してください。
現在、マシン設定サーバーエンドポイントをブロックまたは制限する方法はサポートされていません。マシン設定サーバーは、既存の設定または状態を持たない新しくプロビジョニングされたマシンが設定を取得できるように、ネットワークに公開する必要があります。このモデルでは、信頼のルートは証明書署名要求 (CSR) エンドポイントであり、kubelet がクラスターに参加するための承認のために証明書署名要求を送信する場所です。このため、シークレットや証明書などの機密情報を配布するためにマシン設定を使用しないでください。
マシン設定サーバーエンドポイント、ポート 22623 および 22624 がベアメタルシナリオで確実に保護されるようにするには、顧客は適切なネットワークポリシーを設定する必要があります。
クラスターコンポーネントは、Kubernetes コントローラーが更新する、ユーザーによって提供されるネットワークセキュリティーグループを変更しないため、擬似セキュリティーグループが環境の残りの部分に影響を及ぼさずに Kubernetes コントローラー用に作成されます。
プロトコル | ポート | 説明 |
---|---|---|
ICMP | 該当なし | ネットワーク到達性のテスト |
TCP |
| メトリック |
|
ホストレベルのサービス。 ポート | |
| Kubernetes が予約するデフォルトポート | |
UDP |
| VXLAN |
| Geneve | |
|
ポート | |
| IPsec IKE パケット | |
| IPsec NAT-T パケット | |
|
UDP ポート
外部 NTP タイムサーバーを設定する場合は、UDP ポート | |
TCP/UDP |
| Kubernetes ノードポート |
ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
プロトコル | ポート | 説明 |
---|---|---|
TCP |
| etcd サーバーおよびピアポート |
3.6.1.2. パーミッションの区分
OpenShift Container Platform 4.3 以降、クラスターのデプロイに、インストールプログラムがプロビジョニングするインフラストラクチャークラスターに必要なすべてのパーミッションを必要としなくなりました。この変更は、ある会社で個人がクラウドで他とは異なるリソースを作成できるようにパーミッションが区分された状態に類似するものです。たとえば、インスタンス、ストレージ、ロードバランサーなどのアプリケーション固有のアイテムを作成することはできますが、VNet、サブネット、または Ingress ルールなどのネットワーク関連のコンポーネントは作成できない可能性があります。
クラスターの作成時に使用する Azure の認証情報には、VNet、およびサブネット、ルーティングテーブル、インターネットゲートウェイ、NAT、VPN などの VNet 内のコアとなるネットワークコンポーネントの作成に必要なネットワークのパーミッションは必要ありません。ロードバランサー、セキュリティーグループ、ストレージアカウントおよびノードなどの、クラスター内でマシンに必要なアプリケーションリソースを作成するパーミッションは依然として必要になります。
3.6.1.3. クラスター間の分離
クラスターは既存のサブネットのネットワークセキュリティーグループを変更できないため、VNet でクラスターを相互に分離する方法はありません。
3.6.2. インストール設定ファイルの作成
Microsoft Azure にインストールする OpenShift Container Platform クラスターをカスタマイズできます。
前提条件
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- Azure サブスクリプション ID とテナント ID がある。
- サービスプリンシパルを使用してクラスターをインストールしている場合は、そのアプリケーション ID とパスワードが必要です。
- システムが割り当てたマネージド ID を使用してクラスターをインストールしている場合は、インストールプログラムを実行する仮想マシン上でそれが有効になっています。
ユーザーが割り当てたマネージド ID を使用してクラスターをインストールしている場合は、次の前提条件を満たしている必要があります。
- そのクライアント ID がある。
- これは、インストールプログラムを実行する仮想マシンに割り当てられている。
手順
オプション: 以前にこのコンピューターでインストールプログラムを実行したことがあり、代替のサービスプリンシパルまたはマネージド ID を使用する場合は、
~/.azure/
ディレクトリーに移動して、osServicePrincipal.json
設定ファイルを削除します。このファイルを削除すると、インストールプログラムが以前のインストールのサブスクリプション値と認証値を自動的に再利用できなくなります。
install-config.yaml
ファイルを作成します。インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。
$ ./openshift-install create install-config --dir <installation_directory> 1
- 1
<installation_directory>
の場合、インストールプログラムが作成するファイルを保存するためにディレクトリー名を指定します。
ディレクトリーを指定する場合:
-
ディレクトリーに
execute
権限があることを確認します。この権限は、インストールディレクトリーで Terraform バイナリーを実行するために必要です。 - 空のディレクトリーを使用します。ブートストラップ X.509 証明書などの一部のインストールアセットは有効期限が短いため、インストールディレクトリーを再利用しないでください。別のクラスターインストールの個別のファイルを再利用する必要がある場合は、それらをディレクトリーにコピーすることができます。ただし、インストールアセットのファイル名はリリース間で変更される可能性があります。インストールファイルを以前のバージョンの OpenShift Container Platform からコピーする場合は注意してコピーを行ってください。
プロンプト時に、クラウドの設定の詳細情報を指定します。
オプション: クラスターマシンにアクセスするために使用する SSH キーを選択します。
注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。ターゲットに設定するプラットフォームとして azure を選択します。
インストールプログラムが以前のインストールの
osServicePrincipal.json
設定ファイルを見つけることができない場合は、Azure サブスクリプションと認証の値の入力を求められます。サブスクリプションの次の Azure パラメーター値を入力します。
- azure subscription id: クラスターに使用するサブスクリプション ID を入力します。
- azure tenant id: テナント ID を入力します。
クラスターのデプロイに使用している Azure ID に応じて、azure サービスプリンシパルのクライアント ID の入力を求められたら、次のいずれかを行います。
- サービスプリンシパルを使用している場合は、そのアプリケーション ID を入力します。
- システム割り当てのマネージド ID を使用している場合は、この値を空白のままにします。
- ユーザー割り当てのマネージド ID を使用している場合は、そのクライアント ID を指定します。
クラスターのデプロイに使用している Azure ID に応じて、azure サービスプリンシパルのクライアントシークレット の入力を求められたら、次のいずれかを実行します。
- サービスプリンシパルを使用している場合は、そのパスワードを入力します。
- システム割り当てのマネージド ID を使用している場合は、この値を空白のままにします。
- ユーザー割り当てのマネージド ID を使用している場合は、この値を空白のままにします。
- クラスターをデプロイするリージョンを選択します。
- クラスターをデプロイするベースドメインを選択します。ベースドメインは、クラスターに作成した Azure DNS ゾーンに対応します。
クラスターの記述名を入力します。
重要パブリックエンドポイントで利用可能なすべての Azure リソースはリソース名の制限を受けるため、特定の用語を使用するリソースを作成することはできません。Azure が制限する用語のリストは、Azure ドキュメントの 予約されたリソース名のエラーを解決する を参照してください。
-
install-config.yaml
ファイルを変更します。利用可能なパラメーターの詳細は、「インストール設定パラメーター」のセクションを参照してください。 install-config.yaml
ファイルをバックアップし、複数のクラスターをインストールするのに使用できるようにします。重要install-config.yaml
ファイルはインストールプロセス時に使用されます。このファイルを再利用する必要がある場合は、この段階でこれをバックアップしてください。
以前に検出されなかった場合は、インストールプログラムが osServicePrincipal.json
設定ファイルを作成し、このファイルをコンピューターの ~/.azure/
ディレクトリーに保存します。これにより、インストールプログラムがターゲットプラットフォーム上で OpenShift Container Platform クラスターを作成するときにプロファイルをロードできるようになります。
3.6.2.1. クラスターインストールの最小リソース要件
それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。
マシン | オペレーティングシステム | 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 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。
- OpenShift Container Platform および Kubernetes はディスクのパフォーマンスに敏感であり、特に 10 ms p99 fsync 期間を必要とするコントロールプレーンノード上の etcd には、高速ストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
- すべての user-provisioned installation と同様に、クラスターで RHEL コンピュートマシンの使用を選択する場合は、システム更新の実行、パッチの適用、その他すべての必要なタスクの完了など、オペレーティングシステムのライフサイクルの管理と保守をすべて担当します。RHEL 7 コンピューティングマシンの使用は推奨されておらず、OpenShift Container Platform 4.10 以降では削除されています。
OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。
- x86-64 アーキテクチャーには x86-64-v2 ISA が必要
- ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
- IBM Power アーキテクチャーには Power 9 ISA が必要
- s390x アーキテクチャーには z14 ISA が必要
詳細は、RHEL アーキテクチャー を参照してください。
premiumIO
パラメーターが true
に設定されている Azure 仮想マシンを使用する必要があります。
プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。
関連情報
3.6.2.2. Azure のテスト済みインスタンスタイプ
以下の Microsoft Azure インスタンスタイプは OpenShift Container Platform でテストされています。
例3.10 64 ビット x86 アーキテクチャーに基づくマシンタイプ
-
standardBasv2Family
-
standardBSFamily
-
standardBsv2Family
-
standardDADSv5Family
-
standardDASv4Family
-
standardDASv5Family
-
standardDCACCV5Family
-
standardDCADCCV5Family
-
standardDCADSv5Family
-
standardDCASv5Family
-
standardDCSv3Family
-
standardDCSv2Family
-
standardDDCSv3Family
-
standardDDSv4Family
-
standardDDSv5Family
-
standardDLDSv5Family
-
standardDLSv5Family
-
standardDSFamily
-
standardDSv2Family
-
standardDSv2PromoFamily
-
standardDSv3Family
-
standardDSv4Family
-
standardDSv5Family
-
standardEADSv5Family
-
standardEASv4Family
-
standardEASv5Family
-
standardEBDSv5Family
-
standardEBSv5Family
-
standardECACCV5Family
-
standardECADCCV5Family
-
standardECADSv5Family
-
standardECASv5Family
-
standardEDSv4Family
-
standardEDSv5Family
-
standardEIADSv5Family
-
standardEIASv4Family
-
standardEIASv5Family
-
standardEIBDSv5Family
-
standardEIBSv5Family
-
standardEIDSv5Family
-
standardEISv3Family
-
standardEISv5Family
-
standardESv3Family
-
standardESv4Family
-
standardESv5Family
-
standardFXMDVSFamily
-
standardFSFamily
-
standardFSv2Family
-
standardGSFamily
-
standardHBrsv2Family
-
standardHBSFamily
-
standardHBv4Family
-
standardHCSFamily
-
standardHXFamily
-
standardLASv3Family
-
standardLSFamily
-
standardLSv2Family
-
standardLSv3Family
-
standardMDSHighMemoryv3Family
-
standardMDSMediumMemoryv2Family
-
standardMDSMediumMemoryv3Family
-
standardMIDSHighMemoryv3Family
-
standardMIDSMediumMemoryv2Family
-
standardMISHighMemoryv3Family
-
standardMISMediumMemoryv2Family
-
standardMSFamily
-
standardMSHighMemoryv3Family
-
standardMSMediumMemoryv2Family
-
standardMSMediumMemoryv3Family
-
StandardNCADSA100v4Family
-
Standard NCASv3_T4 Family
-
standardNCSv3Family
-
standardNDSv2Family
-
StandardNGADSV620v1Family
-
standardNPSFamily
-
StandardNVADSA10v5Family
-
standardNVSv3Family
-
standardXEISv4Family
3.6.2.3. 64 ビット ARM インフラストラクチャー上の Azure のテスト済みインスタンスタイプ
以下の Microsoft Azure Azure64 インスタンスタイプは OpenShift Container Platform でテストされています。
例3.11 64 ビット ARM アーキテクチャーに基づくマシンタイプ
-
standardBpsv2Family
-
standardDPSv5Family
-
standardDPDSv5Family
-
standardDPLDSv5Family
-
standardDPLSv5Family
-
standardEPSv5Family
-
standardEPDSv5Family
3.6.2.4. Azure VM の信頼された起動の有効化
Azure にクラスターをインストールするときに、セキュアブート と 仮想化された信頼できるプラットフォームモジュール という 2 つの信頼された起動機能を有効にできます。
信頼できる起動機能をサポートする仮想マシンのサイズの詳細は、仮想マシンのサイズ を参照してください。
信頼できる起動はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
-
install-config.yaml
ファイルを作成しました。
手順
クラスターをデプロイする前に、
install-config.yaml
ファイルを編集します。次のスタンザを追加して、コントロールプレーンでのみ信頼できる起動を有効にします。
controlPlane: platform: azure: settings: securityType: TrustedLaunch trustedLaunch: uefiSettings: secureBoot: Enabled virtualizedTrustedPlatformModule: Enabled
次のスタンザを追加して、コンピュートノードでのみ信頼できる起動を有効にします。
compute: platform: azure: settings: securityType: TrustedLaunch trustedLaunch: uefiSettings: secureBoot: Enabled virtualizedTrustedPlatformModule: Enabled
次のスタンザを追加して、すべてのノードで信頼できる起動を有効にします。
platform: azure: settings: securityType: TrustedLaunch trustedLaunch: uefiSettings: secureBoot: Enabled virtualizedTrustedPlatformModule: Enabled
3.6.2.5. Confidential VM の有効化
クラスターをインストールするときに、Confidential VM を有効にできます。コンピューティングノード、コンピュートノード、またはすべてのノードに対して Confidential VM を有効にできます。
Confidential VM の使用はテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
次の仮想マシンサイズの Confidential VM を使用できます。
- DCasv5 シリーズ
- DCadsv5 シリーズ
- ECasv5 シリーズ
- ECadsv5 シリーズ
現在、Confidential VM は 64 ビット ARM アーキテクチャーではサポートされていません。
前提条件
-
install-config.yaml
ファイルを作成しました。
手順
クラスターをデプロイする前に、
install-config.yaml
ファイルを編集します。次のスタンザを追加して、コントロールプレーンでのみ機密仮想マシンを有効にします。
controlPlane: platform: azure: settings: securityType: ConfidentialVM confidentialVM: uefiSettings: secureBoot: Enabled virtualizedTrustedPlatformModule: Enabled osDisk: securityProfile: securityEncryptionType: VMGuestStateOnly
次のスタンザを追加して、コンピュートノード上でのみ機密仮想マシンを有効にします。
compute: platform: azure: settings: securityType: ConfidentialVM confidentialVM: uefiSettings: secureBoot: Enabled virtualizedTrustedPlatformModule: Enabled osDisk: securityProfile: securityEncryptionType: VMGuestStateOnly
次のスタンザを追加して、すべてのノードで機密仮想マシンを有効にします。
platform: azure: settings: securityType: ConfidentialVM confidentialVM: uefiSettings: secureBoot: Enabled virtualizedTrustedPlatformModule: Enabled osDisk: securityProfile: securityEncryptionType: VMGuestStateOnly
3.6.2.6. Azure のカスタマイズされた install-config.yaml ファイルのサンプル
install-config.yaml
ファイルをカスタマイズして、OpenShift Container Platform クラスターのプラットフォームに関する詳細を指定するか、必要なパラメーターの値を変更することができます。
このサンプルの YAML ファイルは参照用にのみ提供されます。インストールプログラムを使用して install-config.yaml
ファイルを取得し、これを変更する必要があります。
apiVersion: v1 baseDomain: example.com 1 controlPlane: 2 hyperthreading: Enabled 3 4 name: master platform: azure: encryptionAtHost: true ultraSSDCapability: Enabled osDisk: diskSizeGB: 1024 5 diskType: Premium_LRS diskEncryptionSet: resourceGroup: disk_encryption_set_resource_group name: disk_encryption_set_name subscriptionId: secondary_subscription_id osImage: publisher: example_publisher_name offer: example_image_offer sku: example_offer_sku version: example_image_version type: Standard_D8s_v3 replicas: 3 compute: 6 - hyperthreading: Enabled 7 8 name: worker platform: azure: ultraSSDCapability: Enabled type: Standard_D2s_v3 encryptionAtHost: true osDisk: diskSizeGB: 512 9 diskType: Standard_LRS diskEncryptionSet: resourceGroup: disk_encryption_set_resource_group name: disk_encryption_set_name subscriptionId: secondary_subscription_id osImage: publisher: example_publisher_name offer: example_image_offer sku: example_offer_sku version: example_image_version zones: 10 - "1" - "2" - "3" replicas: 5 metadata: name: test-cluster 11 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes 12 serviceNetwork: - 172.30.0.0/16 platform: azure: defaultMachinePlatform: osImage: 13 publisher: example_publisher_name offer: example_image_offer sku: example_offer_sku version: example_image_version ultraSSDCapability: Enabled baseDomainResourceGroupName: resource_group 14 region: centralus 15 resourceGroupName: existing_resource_group 16 networkResourceGroupName: vnet_resource_group 17 virtualNetwork: vnet 18 controlPlaneSubnet: control_plane_subnet 19 computeSubnet: compute_subnet 20 outboundType: Loadbalancer cloudName: AzurePublicCloud pullSecret: '{"auths": ...}' 21 fips: false 22 sshKey: ssh-ed25519 AAAA... 23
- 1 11 15 21
- 必須。インストールプログラムはこの値の入力を求めるプロンプトを出します。
- 2 6
- これらのパラメーターおよび値を指定しない場合、インストールプログラムはデフォルトの値を指定します。
- 3 7
controlPlane
セクションは単一マッピングですが、compute
セクションはマッピングのシーケンスになります。複数の異なるデータ構造の要件を満たすには、compute
セクションの最初の行はハイフン-
で始め、controlPlane
セクションの最初の行はハイフンで始めることができません。1 つのコントロールプレーンプールのみが使用されます。- 4 8
- 同時マルチスレッドまたは
hyperthreading
を有効/無効にするかどうか。デフォルトでは、同時スレッドはマシンのコアのパフォーマンスを上げるために有効にされます。パラメーター値をDisabled
に設定するとこれを無効にすることができます。一部のクラスターマシンで同時マルチスレッドを無効にする場合は、これをすべてのクラスターマシンで無効にする必要があります。重要同時スレッドを無効にする場合は、容量計画においてマシンパフォーマンスの大幅な低下が考慮に入れられていることを確認します。同時マルチスレッドを無効にする場合は、マシンに対して
Standard_D8s_v3
などの大規模な仮想マシンタイプを使用します。 - 5 9
- 使用するディスクのサイズは、GB 単位で指定できます。コントロールプレーンノードの最小推奨値は 1024 GB です。
- 10
- マシンをデプロイするゾーンのリストを指定します。高可用性を確保するには、少なくとも 2 つのゾーンを指定します。
- 12
- インストールするクラスターネットワークプラグイン。サポートされる値はデフォルト値の
OVNKubernetes
のみです。 - 13
- オプション: コントロールプレーンとコンピュートマシンを起動するために使用するカスタム Red Hat Enterprise Linux CoreOS (RHCOS) イメージ。
platform.azure.defaultMachinePlatform.osImage
の下のpublisher
、offer
、sku
、およびversion
パラメーターは、コントロールプレーンとコンピュートマシンの両方に適用されます。controlPlane.platform.azure.osImage
またはcompute.platform.azure.osImage
の下のパラメーターが設定されている場合、それらはplatform.azure.defaultMachinePlatform.osImage
パラメーターをオーバーライドします。 - 14
- ベースドメインの DNS ゾーンが含まれるリソースグループの名前を指定します。
- 16
- クラスターをインストールする既存のリソースグループの名前を指定します。定義されていない場合は、クラスターに新しいリソースグループが作成されます。
- 17
- 既存の VNet を使用する場合は、それが含まれるリソースグループの名前を指定します。
- 18
- 既存の VNet を使用する場合は、その名前を指定します。
- 19
- 既存の VNet を使用する場合は、コントロールプレーンマシンをホストするサブネットの名前を指定します。
- 20
- 既存の VNet を使用する場合は、コンピュートマシンをホストするサブネットの名前を指定します。
- 22
- FIPS モードを有効または無効にするかどうか。デフォルトでは、FIPS モードは有効にされません。FIPS モードが有効にされている場合、OpenShift Container Platform が実行される Red Hat Enterprise Linux CoreOS (RHCOS) マシンがデフォルトの Kubernetes 暗号スイートをバイパスし、代わりに RHCOS で提供される暗号モジュールを使用します。重要
クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
- 23
- クラスター内のマシンにアクセスするために使用する
sshKey
値をオプションで指定できます。注記インストールのデバッグまたは障害復旧を実行する必要のある実稼働用の OpenShift Container Platform クラスターでは、
ssh-agent
プロセスが使用する SSH キーを指定します。
3.6.2.7. インストール時のクラスター全体のプロキシーの設定
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに 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----- additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 5
- 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
http
である必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。 - 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 Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml
ファイルのプロキシー設定を使用する cluster
という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster
Proxy
オブジェクトが依然として作成されますが、これには spec
がありません。
cluster
という名前の Proxy
オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
関連情報
- 高速ネットワークの詳細は、Accelerated Networking for Microsoft Azure VMs を参照してください。
3.6.3. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
デフォルトでは、管理者のシークレットは kube-system
プロジェクトに保存されます。install-config.yaml
ファイルの credentialsMode
パラメーターを Manual
に設定した場合は、次のいずれかの代替手段を使用する必要があります。
- 長期クラウド認証情報を手動で管理するには、長期認証情報を手動で作成する の手順に従ってください。
- クラスターの外部で管理される短期認証情報を個々のコンポーネントに対して実装するには、短期認証情報を使用するように Azure クラスターを設定する の手順に従ってください。
3.6.3.1. 長期認証情報を手動で作成する
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
apiVersion: v1 baseDomain: example.com credentialsMode: Manual # ...
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
カスタムリソース (CR) のリストを抽出します。$ oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \1 --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2 --to=<path_to_directory_for_credentials_requests> 3
このコマンドにより、それぞれの
CredentialsRequest
オブジェクトに YAML ファイルが作成されます。サンプル
CredentialsRequest
オブジェクトapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <component_credentials_request> namespace: openshift-cloud-credential-operator ... spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AzureProviderSpec roleBindings: - role: Contributor ...
以前に生成した
openshift-install
マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれのCredentialsRequest
オブジェクトにspec.secretRef
に定義される namespace およびシークレット名を使用して保存する必要があります。シークレットを含む
CredentialsRequest
オブジェクトのサンプルapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <component_credentials_request> namespace: openshift-cloud-credential-operator ... spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AzureProviderSpec roleBindings: - role: Contributor ... secretRef: name: <component_secret> namespace: <component_namespace> ...
サンプル
Secret
オブジェクトapiVersion: v1 kind: Secret metadata: name: <component_secret> namespace: <component_namespace> data: azure_subscription_id: <base64_encoded_azure_subscription_id> azure_client_id: <base64_encoded_azure_client_id> azure_client_secret: <base64_encoded_azure_client_secret> azure_tenant_id: <base64_encoded_azure_tenant_id> azure_resource_prefix: <base64_encoded_azure_resource_prefix> azure_resourcegroup: <base64_encoded_azure_resourcegroup> azure_region: <base64_encoded_azure_region>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。
3.6.3.2. 短期認証情報を使用するように Azure クラスターを設定する
Microsoft Entra Workload ID を使用するクラスターをインストールするには、Cloud Credential Operator ユーティリティーを設定し、クラスターに必要な Azure リソースを作成する必要があります。
3.6.3.2.1. Cloud Credential Operator ユーティリティーの設定
Cloud Credential Operator (CCO) が手動モードで動作しているときにクラスターの外部からクラウドクレデンシャルを作成および管理するには、CCO ユーティリティー (ccoctl
) バイナリーを抽出して準備します。
ccoctl
ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) がインストールされている。
次の権限で使用する
ccoctl
ユーティリティー用のグローバル Microsoft Azure アカウントが作成されました。例3.12 必要な Azure 権限
- Microsoft.Resources/subscriptions/resourceGroups/read
- Microsoft.Resources/subscriptions/resourceGroups/write
- Microsoft.Resources/subscriptions/resourceGroups/delete
- Microsoft.Authorization/roleAssignments/read
- Microsoft.Authorization/roleAssignments/delete
- Microsoft.Authorization/roleAssignments/write
- Microsoft.Authorization/roleDefinitions/read
- Microsoft.Authorization/roleDefinitions/write
- Microsoft.Authorization/roleDefinitions/delete
- Microsoft.Storage/storageAccounts/listkeys/action
- Microsoft.Storage/storageAccounts/delete
- Microsoft.Storage/storageAccounts/read
- Microsoft.Storage/storageAccounts/write
- Microsoft.Storage/storageAccounts/blobServices/containers/write
- Microsoft.Storage/storageAccounts/blobServices/containers/delete
- Microsoft.Storage/storageAccounts/blobServices/containers/read
- Microsoft.ManagedIdentity/userAssignedIdentities/delete
- Microsoft.ManagedIdentity/userAssignedIdentities/read
- Microsoft.ManagedIdentity/userAssignedIdentities/write
- Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/read
- Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write
- Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/delete
- Microsoft.Storage/register/action
- Microsoft.ManagedIdentity/register/action
手順
次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
$ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
注記$RELEASE_IMAGE
のアーキテクチャーが、ccoctl
ツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctl
バイナリーを抽出します。$ oc image extract $CCO_IMAGE \ --file="/usr/bin/ccoctl.<rhel_version>" \1 -a ~/.pull-secret
- 1
<rhel_version>
には、ホストが使用する Red Hat Enterprise Linux (RHEL) のバージョンに対応する値を指定します。値が指定されていない場合は、デフォルトでccoctl.rhel8
が使用されます。次の値が有効です。-
rhel8
: RHEL 8 を使用するホストの場合はこの値を指定します。 -
rhel9
: RHEL 9 を使用するホストの場合はこの値を指定します。
-
次のコマンドを実行して、権限を変更して
ccoctl
を実行可能にします。$ chmod 775 ccoctl.<rhel_version>
検証
ccoctl
が使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。$ ./ccoctl.rhel9
出力例
OpenShift credentials provisioning tool Usage: ccoctl [command] Available Commands: aws Manage credentials objects for AWS cloud azure Manage credentials objects for Azure gcp Manage credentials objects for Google cloud help Help about any command ibmcloud Manage credentials objects for {ibm-cloud-title} nutanix Manage credentials objects for Nutanix Flags: -h, --help help for ccoctl Use "ccoctl [command] --help" for more information about a command.
3.6.3.2.2. Cloud Credential Operator ユーティリティーを使用した Azure リソースの作成
ccoctl azure create-all
コマンドを使用して、Azure リソースの作成を自動化できます。
デフォルトで、ccoctl
はコマンドが実行されるディレクトリーにオブジェクトを作成します。オブジェクトを別のディレクトリーに作成するには、--output-dir
フラグを使用します。この手順では、<path_to_ccoctl_output_dir>
を使用してこの場所を参照します。
前提条件
以下が必要になります。
-
ccoctl
バイナリーを抽出して準備している。 - Azure CLI を使用して Microsoft Azure アカウントにアクセスします。
手順
次のコマンドを実行して、インストールファイルのリリースイメージを
$RELEASE_IMAGE
変数に設定します。$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequest
オブジェクトのリストを抽出します。$ oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \1 --install-config=<path_to_directory_with_installation_configuration>/install-config.yaml \2 --to=<path_to_directory_for_credentials_requests> 3
注記このコマンドの実行には少し時間がかかる場合があります。
ccoctl
ユーティリティーが Azure 認証情報を自動的に検出できるようにするには、次のコマンドを実行して Azure CLI にログインします。$ az login
次のコマンドを実行し、
ccoctl
ツールを使用してCredentialsRequest
オブジェクトをすべて処理します。$ ccoctl azure create-all \ --name=<azure_infra_name> \1 --output-dir=<ccoctl_output_dir> \2 --region=<azure_region> \3 --subscription-id=<azure_subscription_id> \4 --credentials-requests-dir=<path_to_credentials_requests_directory> \5 --dnszone-resource-group-name=<azure_dns_zone_resource_group_name> \6 --tenant-id=<azure_tenant_id> 7
- 1
- トラッキングに使用される、作成されたすべての Azure リソースのユーザー定義名を指定します。
- 2
- オプション:
ccoctl
ユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 3
- クラウドリソースが作成される Azure リージョンです。
- 4
- 使用する Azure サブスクリプション ID を指定します。
- 5
- コンポーネント
CredentialsRequest
オブジェクトのファイルを含むディレクトリーを指定します。 - 6
- クラスターのベースドメイン Azure DNS ゾーンを含むリソースグループの名前を指定します。
- 7
- 使用する Azure テナント ID を指定します。
注記クラスターで
TechPreviewNoUpgrade
機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview
パラメーターを含める必要があります。追加のオプションパラメーターとその使用方法の説明を表示するには、
azure create-all --help
コマンドを実行します。
検証
OpenShift Container Platform シークレットが作成されることを確認するには、
<path_to_ccoctl_output_dir>/manifests
ディレクトリーのファイルを一覧表示します。$ ls <path_to_ccoctl_output_dir>/manifests
出力例
azure-ad-pod-identity-webhook-config.yaml cluster-authentication-02-config.yaml openshift-cloud-controller-manager-azure-cloud-credentials-credentials.yaml openshift-cloud-network-config-controller-cloud-credentials-credentials.yaml openshift-cluster-api-capz-manager-bootstrap-credentials-credentials.yaml openshift-cluster-csi-drivers-azure-disk-credentials-credentials.yaml openshift-cluster-csi-drivers-azure-file-credentials-credentials.yaml openshift-image-registry-installer-cloud-credentials-credentials.yaml openshift-ingress-operator-cloud-credentials-credentials.yaml openshift-machine-api-azure-cloud-credentials-credentials.yaml
Azure をクエリーすることで、Microsoft Entra ID サービスアカウントが作成されていることを確認できます。詳細は、Entra ID サービスアカウントのリストに関する Azure ドキュメントを参照してください。
3.6.3.2.3. Cloud Credential Operator ユーティリティーマニフェストの組み込み
個々のコンポーネントに対してクラスターの外部で管理される短期セキュリティー認証情報を実装するには、Cloud Credential Operator ユーティリティー (ccoctl
) が作成したマニフェストファイルを、インストールプログラムの正しいディレクトリーに移動する必要があります。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) が設定されている。 -
ccoctl
ユーティリティーを使用して、クラスターに必要なクラウドプロバイダーリソースを作成している。
手順
install-config.yaml
設定ファイルのcredentialsMode
パラメーターをManual
に設定しなかった場合は、次のように値を変更します。設定ファイルのサンプルスニペット
apiVersion: v1 baseDomain: example.com credentialsMode: Manual # ...
既存のリソースグループを使用する代わりに、
ccoctl
ユーティリティーを使用して新しい Azure リソースグループを作成した場合は、次のようにinstall-config.yaml
のresourceGroupName
パラメーターを変更します。設定ファイルのサンプルスニペット
apiVersion: v1 baseDomain: example.com # ... platform: azure: resourceGroupName: <azure_infra_name> 1 # ...
- 1
- この値は、
ccoctl azure create-all
コマンドの--name
引数で指定された Azure リソースのユーザー定義名と一致する必要があります。
インストールマニフェストファイルをまだ作成していない場合は、次のコマンドを実行して作成します。
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。次のコマンドを実行して、
ccoctl
ユーティリティーが生成したマニフェストを、インストールプログラムが作成したmanifests
ディレクトリーにコピーします。$ cp /<path_to_ccoctl_output_dir>/manifests/* ./manifests/
秘密鍵を含む
tls
ディレクトリーをインストールディレクトリーにコピーします。$ cp -a /<path_to_ccoctl_output_dir>/tls .
3.6.4. クラスターのデプロイ
互換性のあるクラウドプラットフォームに OpenShift Container Platform をインストールできます。
インストールプログラムの create cluster
コマンドは、初期インストール時に 1 回だけ実行できます。
前提条件
- クラスターをホストするクラウドプラットフォームでアカウントを設定しました。
- OpenShift Container Platform インストールプログラムおよびクラスターのプルシークレットがある。
- Azure サブスクリプション ID とテナント ID がある。
手順
インストールプログラムが含まれるディレクトリーに切り替え、クラスターのデプロイメントを初期化します。
$ ./openshift-install create cluster --dir <installation_directory> \ 1 --log-level=info 2
検証
クラスターのデプロイが正常に完了すると、次のようになります。
-
ターミナルには、Web コンソールへのリンクや
kubeadmin
ユーザーの認証情報など、クラスターにアクセスするための指示が表示されます。 -
認証情報は
<installation_directory>/.openshift_install.log
にも出力されます。
インストールプログラム、またはインストールプログラムが作成するファイルを削除することはできません。これらはいずれもクラスターを削除するために必要になります。
出力例
... INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com INFO Login to the console with user: "kubeadmin", and password: "password" INFO Time elapsed: 36m22s
-
インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の
node-bootstrapper
証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー に関するドキュメントを参照してください。 - 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することを推奨します。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。
関連情報
- OpenShift Container Platform Web コンソールへのアクセスと理解に関する詳細は、Web コンソールへのアクセス を参照してください。
3.6.5. 次のステップ
- クラスターをカスタマイズ します。
- 必要に応じて、リモートヘルスレポートをオプトアウト できます。