4.2. ベアメタルへの Hosted Control Plane のデプロイ
クラスターを管理クラスターとして機能するように設定することで、Hosted Control Plane をデプロイできます。管理クラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。場合によっては、管理クラスターは ホスティング クラスターとも呼ばれます。
管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。
Hosted Control Plane 機能はデフォルトで有効になっています。
multicluster engine Operator は、マネージドのハブクラスターであるデフォルトの local-cluster
と、管理クラスターとしてのハブクラスターのみをサポートしています。Red Hat Advanced Cluster Management がインストールされている場合は、マネージドハブクラスター (local-cluster
) を管理クラスターとして使用できます。
ホステッドクラスター は、API エンドポイントとコントロールプレーンが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。ホステッドクラスターは、multicluster engine Operator のコンソールか、Hosted Control Plane のコマンドラインインターフェイス (CLI) である hcp
を使用して作成できます。
ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、multicluster engine Operator へのホステッドクラスターの自動インポートの無効化 を参照してください。
4.2.1. ベアメタルへの Hosted Control Plane のデプロイの準備
ベアメタルに Hosted Control Plane をデプロイする準備をする際には、次の情報を考慮してください。
- Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
-
すべてのベアメタルホストは、Central Infrastructure Management が提供する Discovery Image ISO を使用して手動で起動する必要があります。ホストは手動で起動することも、
Cluster-Baremetal-Operator
を使用して自動化することもできます。各ホストが起動すると、エージェントプロセスが実行され、ホストの詳細が検出され、インストールが完了します。Agent
カスタムリソースは、各ホストを表します。 - Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。
4.2.1.1. 管理クラスターを設定するための前提条件
- OpenShift Container Platform クラスターに multicluster engine for Kubernetes Operator 2.2 以降がインストールされている必要があります。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。
multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。multicluster engine Operator バージョン 2.2 以降では、
local-cluster
が自動的にインポートされます。local-cluster
の詳細は、Red Hat Advanced Cluster Management ドキュメントの 詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。$ oc get managedclusters local-cluster
-
管理クラスター上のベアメタルホストに
topology.kubernetes.io/zone
ラベルを追加する必要があります。そうしないと、すべての Hosted Control Plane Pod が単一ノードでスケジュールされ、単一障害点が発生します。 - エージェントプラットフォームを使用して、Hosted Control Plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
- Hosted Control Plane コマンドラインインターフェイスをインストールする必要があります。
4.2.1.2. ベアメタルファイアウォール、ポート、およびサービスの要件
管理クラスター、コントロールプレーン、ホストされたクラスター間でポートの通信ができるように、ファイアウォール、ポート、およびサービスの要件を満たす必要があります。
サービスはデフォルトのポートで実行されます。ただし、NodePort
公開ストラテジーを使用する場合、サービスは NodePort
サービスによって割り当てられたポートで実行されます。
ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。
ハブクラスターにプロキシー設定がある場合は、すべてのホステッドクラスター API エンドポイントを Proxy
オブジェクトの noProxy
フィールドに追加して、ハブクラスターがホステッドクラスターの API エンドポイントにアクセスできようにします。詳細は、「クラスター全体のプロキシーの設定」を参照してください。
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.2.1.3. ベアメタルのインフラストラクチャー要件
エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーに関して次の要件があります。
- Agent: Agent は、Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。
- DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。
4.2.2. ベアメタルでの DNS 設定
ホステッドクラスターの API サーバーは、NodePort
サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain>
の DNS エントリーが存在する必要があります。
DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。
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 を設定する場合、設定は次の例のようになります。
IPv6 ネットワークの 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.2.3. ベアメタルでのホステッドクラスターの作成
Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。ベアメタルでホステッドクラスターを作成するか、インポートできます。
ホステッドクラスターを作成するときは、次のガイドラインに留意してください。
- 各ホステッドクラスターに、クラスター全体で一意の名前が必要です。multicluster engine Operator によってホステッドクラスターを管理するには、ホステッドクラスター名を既存のマネージドクラスターと同じにすることはできません。
-
ホステッドクラスター名として
clusters
を使用しないでください。 - ホステッドクラスターは、multicluster engine Operator のマネージドクラスターの namespace には作成できません。
手順
次のコマンドを入力して、Hosted Control Plane namespace を作成します。
$ oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>
<hosted_cluster_namespace>
を、ホストされたクラスターの namespace 名 (例:clusters
) に置き換えます。<hosted_cluster_name>
は、ホステッドクラスターの名前に置き換えます。クラスターにデフォルトのストレージクラスが設定されていることを確認します。そうしないと、保留中の PVC が表示される場合があります。以下のコマンドを実行します。
$ 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_public_key> \7 --namespace <hosted_cluster_namespace> \8 --control-plane-availability-policy HighlyAvailable \9 --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 10
- 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
- etcd ストレージクラス名を指定します (例:
lvm-storageclass
)。 - 7
- SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは
~/.ssh/id_rsa.pub
です。 - 8
- ホストされたクラスターの namespace を指定します。
- 9
- コントロールプレーンの可用性ポリシーのデフォルト値は、
HighlyAvailable
です。 - 10
- 使用するサポート対象の OpenShift Container Platform バージョンを指定します (例:
4.17.0-multi
)。非接続環境を使用している場合は、<ocp_release_image>
をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。
$ oc -n <hosted_control_plane_namespace> get pods
出力例
NAME READY STATUS RESTARTS AGE capi-provider-7dcf5fc4c4-nr9sq 1/1 Running 0 4m32s catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s certified-operators-catalog-884c756c4-zdt64 1/1 Running 0 2m51s cluster-api-f75d86f8c-56wfz 1/1 Running 0 4m32s
関連情報
4.2.3.1. コンソールを使用してベアメタル上にホストされたクラスターを作成する
コンソールを使用してホステッドクラスターを作成するには、次の手順を実行します。
手順
- OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順は、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>.<base_domain>
設定の DNS エントリーが存在する必要があります。このエントリーとして、管理クラスター内のノードの 1 つを指すレコード、または受信トラフィックを Ingress Pod にリダイレクトするロードバランサーを指すレコードを指定できます。
エントリーを確認し、Create をクリックします。
Hosted cluster ビューが表示されます。
- Hosted cluster ビューでホストされたクラスターのデプロイメントを監視します。
- ホストされたクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。
- コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
- ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホストされたクラスターに参加したかどうかを確認することもできます。
次のステップ
- Web コンソールにアクセスするには、Web コンソールへのアクセス を参照してください。
4.2.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.2.4. ホステッドクラスター作成の確認
デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。
手順
次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。
$ oc extract -n <hosted-control-plane-namespace> secret/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 dns 4.10.26 True False False 2m52s image-registry 4.10.26 True False False 2m8s ingress 4.10.26 True False False 22m
次のコマンドを入力して、ホストされたクラスター上で実行中の 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-node-tuning-operator tuned-dhw5p 1/1 Running 0 109s openshift-cluster-storage-operator cluster-storage-operator-5f784969f5-vwzgz 1/1 Running 1 (113s ago) 20m openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-7nrfw 1/1 Running 0 3m8s openshift-console console-5cbf6c7969-6gk6z 1/1 Running 0 119s openshift-console downloads-7bcd756565-6wj5j 1/1 Running 0 4m3s openshift-dns-operator dns-operator-77d755cd8c-xjfbn 2/2 Running 0 21m openshift-dns dns-default-kfqnh 2/2 Running 0 113s