4.4. 非ベアメタルエージェントマシンへの Hosted Control Plane のデプロイ
クラスターをホスティングクラスターとして機能するように設定することで、Hosted Control Plane をデプロイできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは管理クラスターとも呼ばれます。
非ベアメタルエージェントマシン上の Hosted Control Plane は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。
Hosted Control Plane 機能はデフォルトで有効になっています。
				multicluster engine Operator は、デフォルトの local-cluster マネージドハブクラスターのみをサポートしています。Red Hat Advanced Cluster Management (RHACM) 2.10 では、local-cluster マネージドハブクラスターをホスティングクラスターとして使用できます。
			
				ホステッドクラスター は、ホスティングクラスターでホストされる API エンドポイントとコントロールプレーンを含む OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。ホステッドクラスターは、multicluster engine Operator コンソールまたは hcp コマンドラインインターフェイス (CLI) を使用して作成できます。
			
ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、「multicluster engine Operator へのホステッドクラスターの自動インポートの無効化」を参照してください。
4.4.1. 非ベアメタルエージェントマシンへの Hosted Control Plane のデプロイの準備
ベアメタルに Hosted Control Plane をデプロイする準備をする際には、次の情報を考慮してください。
- Agent プラットフォームを使用すると、エージェントマシンをワーカーノードとしてホステッドクラスターに追加できます。エージェントマシンは、Discovery Image でブートされ、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。Agent プラットフォームは、Central Infrastructure Management サービスの一部です。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- ベアメタルではないすべてのホストは、Central Infrastructure Management が提供する検出イメージ ISO を使用して手動で起動する必要があります。
- ノードプールをスケールアップすると、レプリカごとにマシンが作成されます。Cluster API プロバイダーは、マシンごとに、承認済みで、検証に合格し、現在使用されておらず、ノードプール仕様で指定されている要件を満たしているエージェントを検索してインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
- ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。
- Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの「推奨される etcd プラクティス」および「論理ボリュームマネージャーストレージを使用した永続ストレージ」を参照してください。
4.4.1.1. 非ベアメタルエージェントマシンに Hosted Control Plane をデプロイするための前提条件
非ベアメタルエージェントマシンに Hosted Control Plane をデプロイする前に、次の前提条件を満たしていることを確認してください。
- OpenShift Container Platform クラスターに multicluster engine for Kubernetes Operator 2.5 以降がインストールされている。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。
- multicluster engine Operator のマネージド OpenShift Container Platform クラスターが少なくとも 1 つある。 - local-cluster管理クラスターは自動的にインポートされます。- local-clusterの詳細は、Red Hat Advanced Cluster Management ドキュメントの 詳細設定 を参照してください。次のコマンドを実行すると、管理クラスターのステータスを確認できます。- oc get managedclusters local-cluster - $ oc get managedclusters local-cluster- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Central Infrastructure Management を有効にした。詳細は、Red Hat Advanced Cluster Management ドキュメントの Central Infrastructure Management サービスの有効化 を参照してください。
- 
								hcpコマンドラインインターフェイスをインストールした。
- ホステッドクラスターの名前がクラスター全体で一意である。
- 管理クラスターとワーカーを同じインフラストラクチャー上で実行している。
4.4.1.2. 非ベアメタルエージェントマシンのファイアウォール、ポート、およびサービスの要件
管理クラスター、コントロールプレーン、ホステッドクラスター間でポートが通信できるように、ファイアウォールとポートの要件を満たす必要があります。
							サービスはデフォルトのポートで実行されます。ただし、NodePort 公開ストラテジーを使用する場合、サービスは NodePort サービスによって割り当てられたポートで実行されます。
						
ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。
Hosted Control Plane は、非ベアメタルエージェントマシン上で次のサービスを公開します。
- APIServer- 
										APIServerサービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。
- MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。
 
- 
										
- OAuthServer- 
										ルートと Ingress を使用してサービスを公開する場合、OAuthServerサービスはデフォルトでポート 443 で実行されます。
- 
										NodePort公開ストラテジーを使用する場合は、OAuthServerサービスにファイアウォールルールを使用します。
 
- 
										ルートと Ingress を使用してサービスを公開する場合、
- Konnectivity- 
										ルートと Ingress を使用してサービスを公開する場合、Konnectivityサービスはデフォルトでポート 443 で実行されます。
- 
										Konnectivityエージェントはリバーストンネルを確立し、コントロールプレーンがホステッドクラスターのネットワークにアクセスできるようにします。エージェントは egress を使用してKonnectivityサーバーに接続します。サーバーは、ポート 443 のルートまたは手動で割り当てられたNodePortを使用して公開されます。
- クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
- アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。
 
- 
										ルートと Ingress を使用してサービスを公開する場合、
- Ignition- 
										ルートと Ingress を使用してサービスを公開する場合、Ignitionサービスはデフォルトでポート 443 で実行されます。
- 
										NodePort公開ストラテジーを使用する場合は、Ignitionサービスにファイアウォールルールを使用します。
 
- 
										ルートと Ingress を使用してサービスを公開する場合、
非ベアメタルエージェントマシンでは、次のサービスは必要ありません。
- 
								OVNSbDb
- 
								OIDC
4.4.1.3. 非ベアメタルエージェントマシンのインフラストラクチャー要件
Agent プラットフォームはインフラストラクチャーを作成しませんが、次のインフラストラクチャー要件があります。
- Agent: Agent は、Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。
- DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。
4.4.2. 非ベアメタルエージェントマシンでの DNS の設定
					ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<basedomain> の DNS エントリーが存在する必要があります。
				
DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。
- IPv4 ネットワークで接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- IPv6 ネットワークで非接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- デュアルスタックネットワークの非接続環境で DNS を設定する場合は、IPv4 と IPv6 の両方の DNS エントリーを含めるようにしてください。次の DNS 設定の例を参照してください。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
4.4.2.1. カスタム DNS 名の定義
クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。
- 内部ルート CA にバインドされているコントロールプレーン機能を損なうことなく、ユーザー向けの TLS 証明書をパブリック CA が発行したものに置き換えるため。
- スプリットホライズン DNS および NAT のシナリオをサポートするため。
- 
								スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保し、正しい kubeconfigと DNS 設定を使用して、Show Login Commandなどの機能を使用可能にするため。
						HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。
					
前提条件
- 
								kubeAPIServerDNSNameパラメーターで設定する DNS 名が、有効な TLS 証明書の対象に含まれている。
- 正しいアドレスに到達し、それを指し示す解決可能な DNS 名 URI がある。
手順
- HostedClusterオブジェクトの仕様で、- kubeAPIServerDNSNameパラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- kubeAPIServerDNSNameパラメーターの値は、有効でアドレス指定可能なドメインである必要があります。
 
						kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。
					
						Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。
					
						カスタム kubeconfig ファイルへの参照情報は、HostedCluster オブジェクトの status パラメーター内に CustomKubeconfig という名前で存在しています。CustomKubeConfig パラメーターは任意であり、kubeAPIServerDNSName パラメーターが空でない場合にのみ追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster namespace で <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作時に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。
					
							カスタム DNS 名の定義はデータプレーンに直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane namespace は、HyperShift Operator から変更を受け取り、対応するパラメーターを削除します。
						
						HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと、CustomKubeconfig 参照がクラスターと status パラメーターから削除されます。
					
4.4.3. CLI を使用した非ベアメタルエージェントマシンでのホステッドクラスターの作成
Agent プラットフォームを使用してホステッドクラスターを作成すると、HyperShift Operator によって Agent Cluster API プロバイダーが Hosted Control Plane の namespace にインストールされます。ベアメタルでホステッドクラスターを作成するか、インポートできます。
ホステッドクラスターを作成するときは、次のガイドラインを確認してください。
- 各ホステッドクラスターの名前がクラスター全体で一意である。multicluster engine Operator によってホステッドクラスターを管理するには、ホステッドクラスター名を既存のマネージドクラスターと同じにすることはできません。
- 
							ホステッドクラスター名として clustersを使用しない。
- ホステッドクラスターは、multicluster engine Operator のマネージドクラスターの namespace には作成できない。
手順
- 次のコマンドを入力して、Hosted Control Plane namespace を作成します。 - oc create ns <hosted_cluster_namespace>-<hosted_cluster_name> - $ oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <hosted_cluster_namespace>を、ホステッドクラスターの namespace 名 (例:- clusters) に置き換えます。- <hosted_cluster_name>は、ホステッドクラスターの名前に置き換えます。
 
- 次のコマンドを入力して、ホステッドクラスターを作成します。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- ホステッドクラスターの名前を指定します (例:example)。
- 2
- プルシークレットへのパスを指定します (例:/user/name/pullsecret)。
- 3
- Hosted Control Plane namespace を指定します (例:clusters-example)。oc get agent -n <hosted-control-plane-namespace>コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
- 4
- ベースドメインを指定します (例:krnl.es)。
- 5
- --api-server-addressフラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。- --api-server-addressフラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
- 6
- クラスターにデフォルトのストレージクラスが設定されていることを確認する。設定されていない場合は、PVC が保留になる可能性があります。etcd ストレージクラス名を指定します (例:lvm-storageclass)。
- 7
- SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは~/.ssh/id_rsa.pubです。
- 8
- ホステッドクラスターの namespace を指定します。
- 9
- Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションはSingleReplicaとHighlyAvailableです。デフォルト値はHighlyAvailableです。
- 10
- 使用するサポート対象の OpenShift Container Platform バージョンを指定します (例:4.19.0-multi)。
- 11
- ノードプールのレプリカ数を指定します (例:3)。レプリカ数は0以上で指定する必要があります。指定したとおりの数のノードが作成されます。それ以外の場合、ノードプールは作成されません。
 
検証
- しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。 - oc -n <hosted_cluster_namespace>-<hosted_cluster_name> get pods - $ oc -n <hosted_cluster_namespace>-<hosted_cluster_name> get pods- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME READY STATUS RESTARTS AGE catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32s - NAME READY STATUS RESTARTS AGE catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32s- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
4.4.3.1. Web コンソールを使用した非ベアメタルエージェントマシンでのホステッドクラスターの作成
OpenShift Container Platform Web コンソールを使用して、非ベアメタルエージェントマシン上にホステッドクラスターを作成できます。
前提条件
- 
								cluster-admin権限でクラスターにアクセスできる。
- OpenShift Container Platform Web コンソールにアクセスできる。
手順
- OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。
- コンソールのヘッダーで、All Clusters を選択します。
- 
								Infrastructure Clusters をクリックします。 
- Create cluster Host inventory - Hosted control plane をクリックします。 - Create cluster ページが表示されます。 
- Create cluster ページでプロンプトに従い、クラスター、ノードプール、ネットワーク、および自動化に関する詳細を入力します。
クラスターの詳細を入力する際には、次のヒントが役立つ場合があります。
- 事前定義された値を使用してコンソールのフィールドに自動的に値を入力する場合は、ホストインベントリーの認証情報を作成できます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
- Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。ホストインベントリー認証情報を選択した場合は、プルシークレットが自動的に入力されます。
- Node pools ページでは、namespace にノードプールのホストが含まれます。コンソールを使用してホストインベントリーを作成した場合、コンソールは専用の namespace を作成します。
- Networking ページで、API サーバー公開ストラテジーを選択します。ホステッドクラスターの API サーバーは、既存のロードバランサーを使用するか、 - NodePortタイプのサービスとして公開できます。API サーバーに到達できる宛先を指す- api.<hosted_cluster_name>.<basedomain>設定の DNS エントリーが存在する必要があります。このエントリーとして、管理クラスター内のノードの 1 つを指すレコード、または受信トラフィックを Ingress Pod にリダイレクトするロードバランサーを指すレコードを指定できます。- エントリーを確認し、Create をクリックします。
 - Hosted cluster ビューが表示されます。 - Hosted cluster ビューでホステッドクラスターのデプロイメントを監視します。ホステッドクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
- ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホステッドクラスターに参加したかどうかを確認することもできます。
 
次のステップ
- Web コンソールにアクセスするには、Web コンソールへのアクセス を参照してください。
4.4.3.2. ミラーレジストリーを使用した非ベアメタルエージェントマシンでのホステッドクラスターの作成
						hcp create cluster コマンドで --image-content-sources フラグを指定することで、ミラーレジストリーを使用して、非ベアメタルエージェントマシン上にホステッドクラスターを作成できます。
					
手順
- YAML ファイルを作成して、イメージコンテンツソースポリシー (ICSP) を定義します。以下の例を参照してください。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
								ファイルを icsp.yamlとして保存します。このファイルにはミラーレジストリーが含まれます。
- ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- ホステッドクラスターの名前を指定します (例:example)。
- 2
- プルシークレットへのパスを指定します (例:/user/name/pullsecret)。
- 3
- Hosted Control Plane namespace を指定します (例:clusters-example)。oc get agent -n <hosted-control-plane-namespace>コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
- 4
- ベースドメインを指定します (例:krnl.es)。
- 5
- --api-server-addressフラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。- --api-server-addressフラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
- 6
- ICSP およびミラーレジストリーを定義するicsp.yamlファイルを指定します。
- 7
- SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは~/.ssh/id_rsa.pubです。
- 8
- ホステッドクラスターの namespace を指定します。
- 9
- 使用するサポート対象の OpenShift Container Platform バージョンを指定します (例:4.19.0-multi)。非接続環境を使用している場合は、<ocp_release_image>をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
 
次のステップ
- コンソールでホステッドクラスターを作成するときに再利用できる認証情報を作成するには、オンプレミス環境の認証情報の作成 を参照してください。
- ホステッドクラスターにアクセスするには、ホステッドクラスターへのアクセス を参照してください。
- Discovery Image を使用してホストインベントリーにホストを追加するには、Discovery Image を使用したホストインベントリーへのホストの追加 を参照してください。
- OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
4.4.4. 非ベアメタルエージェントマシンでのホステッドクラスターの作成を検証する
デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。
手順
- 次のコマンドを入力して、新しいホステッドクラスターの - kubeconfigファイルを取得します。- oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig --to=- \ > kubeconfig-<hosted_cluster_name> - $ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig --to=- \ > kubeconfig-<hosted_cluster_name>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- kubeconfigファイルを使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。- oc get co --kubeconfig=kubeconfig-<hosted_cluster_name> - $ oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52s - NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52s- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示します。 - oc get pods -A --kubeconfig=kubeconfig-<hosted_cluster_name> - $ oc get pods -A --kubeconfig=kubeconfig-<hosted_cluster_name>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104s - NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104s- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
4.4.5. ホステッドクラスターでカスタム API サーバー証明書を設定する
					API サーバーのカスタム証明書を設定するには、HostedCluster 設定の spec.configuration.apiServer セクションで証明書の詳細を指定します。
				
カスタム証明書は、Day 1 操作または Day 2 操作の中で設定できます。ただし、サービス公開ストラテジーはホステッドクラスターの作成中に設定した後は変更できないため、設定する予定の Kubernetes API サーバーのホスト名を知っておく必要があります。
前提条件
- 管理クラスターにカスタム証明書が含まれる Kubernetes シークレットを作成しました。シークレットには次の鍵が含まれています。 - 
									tls.crt: 証明書
- 
									tls.key: 秘密鍵
 
- 
									
- 
							HostedCluster設定にロードバランサーを使用するサービス公開ストラテジーが含まれている場合は、証明書のサブジェクト代替名 (SAN) が内部 API エンドポイント (api-int) と競合しないことを確認してください。内部 API エンドポイントは、プラットフォームによって自動的に作成および管理されます。カスタム証明書と内部 API エンドポイントの両方で同じホスト名を使用すると、ルーティングの競合が発生する可能性があります。このルールの唯一の例外は、PrivateまたはPublicAndPrivate設定で AWS をプロバイダーとして使用する場合です。このような場合、SAN の競合はプラットフォームによって管理されます。
- 証明書は外部 API エンドポイントに対して有効である必要があります。
- 証明書の有効期間は、クラスターの予想されるライフサイクルと一致します。
手順
- 次のコマンドを入力して、カスタム証明書を使用してシークレットを作成します。 - oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace> - $ oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次の例に示すように、カスタム証明書の詳細を使用して - HostedCluster設定を更新します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次のコマンドを入力して、 - HostedCluster設定に変更を適用します。- oc apply -f <hosted_cluster_config>.yaml - $ oc apply -f <hosted_cluster_config>.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
検証
- API サーバー Pod をチェックして、新しい証明書がマウントされていることを確認します。
- カスタムドメイン名を使用して API サーバーへの接続をテストします。
- 
							ブラウザーで、または opensslなどのツールを使用して、証明書の詳細を確認します。