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 をデプロイする準備をする際には、次の情報を考慮してください。
- エージェントプラットフォームを使用して、エージェントマシンをワーカーノードとしてホステッドクラスターに追加できます。エージェントマシンは、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
- 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 は、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 設定の例を参照してください。
api.example.krnl.es. IN A 192.168.122.20 api.example.krnl.es. IN A 192.168.122.21 api.example.krnl.es. IN A 192.168.122.22 api-int.example.krnl.es. IN A 192.168.122.20 api-int.example.krnl.es. IN A 192.168.122.21 api-int.example.krnl.es. IN A 192.168.122.22 `*`.apps.example.krnl.es. IN A 192.168.122.23
IPv6 ネットワークで非接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。
api.example.krnl.es. IN A 2620:52:0:1306::5 api.example.krnl.es. IN A 2620:52:0:1306::6 api.example.krnl.es. IN A 2620:52:0:1306::7 api-int.example.krnl.es. IN A 2620:52:0:1306::5 api-int.example.krnl.es. IN A 2620:52:0:1306::6 api-int.example.krnl.es. IN A 2620:52:0:1306::7 `*`.apps.example.krnl.es. IN A 2620:52:0:1306::10
デュアルスタックネットワークの非接続環境で DNS を設定する場合は、IPv4 と IPv6 の両方の DNS エントリーを含めるようにしてください。次の DNS 設定の例を参照してください。
host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10 host-record=api.hub-dual.dns.base.domain.name,192.168.126.10 address=/apps.hub-dual.dns.base.domain.name/192.168.126.11 dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20 dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21 dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22 dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25 dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26 host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2 host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2 address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3 dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5] dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6] dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7] dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8] dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]
4.4.3. CLI を使用した非ベアメタルエージェントマシンでのホステッドクラスターの作成
エージェントプラットフォームでホステッドクラスターを作成すると、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> 1
- 1
<hosted_cluster_namespace>
を、ホストされたクラスターの namespace 名 (例:clusters
) に置き換えます。<hosted_cluster_name>
は、ホステッドクラスターの名前に置き換えます。
次のコマンドを入力して、ホステッドクラスターを作成します。
$ hcp create cluster agent \ --name=<hosted_cluster_name> \1 --pull-secret=<path_to_pull_secret> \2 --agent-namespace=<hosted_control_plane_namespace> \3 --base-domain=<basedomain> \4 --api-server-address=api.<hosted_cluster_name>.<basedomain> \5 --etcd-storage-class=<etcd_storage_class> \6 --ssh-key <path_to_ssh_key> \7 --namespace <hosted_cluster_namespace> \8 --control-plane-availability-policy HighlyAvailable \9 --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release> \10 --node-pool-replicas <node_pool_replica_count> 11
- 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.17.0-multi
)。 - 11
- ノードプールのレプリカ数を指定します (例:
3
)。同じ数のレプリカを作成するには、レプリカ数を0
以上に指定する必要があります。それ以外の場合、ノードプールは作成されません。
検証
しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。
$ oc -n <hosted_control_plane_namespace> get pods
出力例
NAME READY STATUS RESTARTS AGE catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32s
関連情報
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) を定義します。以下の例を参照してください。
- mirrors: - brew.registry.redhat.io source: registry.redhat.io - mirrors: - brew.registry.redhat.io source: registry.stage.redhat.io - mirrors: - brew.registry.redhat.io source: registry-proxy.engineering.redhat.com
-
ファイルを
icsp.yaml
として保存します。このファイルにはミラーレジストリーが含まれます。 ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。
$ hcp create cluster agent \ --name=<hosted_cluster_name> \1 --pull-secret=<path_to_pull_secret> \2 --agent-namespace=<hosted_control_plane_namespace> \3 --base-domain=<basedomain> \4 --api-server-address=api.<hosted_cluster_name>.<basedomain> \5 --image-content-sources icsp.yaml \6 --ssh-key <path_to_ssh_key> \7 --namespace <hosted_cluster_namespace> \8 --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 9
- 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.17.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>
kubeconfig
ファイルを使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。$ oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>
出力例
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
次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示します。
$ oc get pods -A --kubeconfig=kubeconfig-<hosted_cluster_name>
出力例
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