サポートコンソール開発者トライアルの開始お問い合わせ

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 は、Red Hat Advanced Cluster Management (RHACM) をインストールすると、自動的にインストールされます。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator として RHACM なしでインストールすることもできます。

  • multicluster engine Operator のマネージド OpenShift Container Platform クラスターが少なくとも 1 つある。local-cluster マネージドハブクラスターは自動的にインポートされます。local-cluster の詳細は、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。 

    $ oc get managedclusters local-cluster
  • Central Infrastructure Management を有効にした。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • hcp コマンドラインインターフェイスをインストールした。
  • ホステッドクラスターの名前がクラスター全体で一意である。multicluster engine Operator によってホステッドクラスターを管理するには、ホステッドクラスター名を既存のマネージドクラスターと同じにすることはできません。
  • Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行している。

関連情報

4.4.1.2. 非ベアメタルエージェントマシンのファイアウォール、ポート、およびサービスの要件

管理クラスター、コントロールプレーン、ホステッドクラスター間でポートが通信できるように、ファイアウォールとポートの要件を満たす必要があります。

注記

サービスはデフォルトのポートで実行されます。ただし、NodePort 公開ストラテジーを使用する場合、サービスは NodePort サービスによって割り当てられたポートで実行されます。

ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。

Hosted Control Plane は、非ベアメタルエージェントマシン上で次のサービスを公開します。

  • APIServer

    • APIServer サービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。
    • MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。

  • OAuthServer

    • ルートと Ingress を使用してサービスを公開する場合、OAuthServer サービスはデフォルトでポート 443 で実行されます。
    • NodePort 公開ストラテジーを使用する場合は、OAuthServer サービスにファイアウォールルールを使用します。

  • Konnectivity

    • ルートと Ingress を使用してサービスを公開する場合、Konnectivity サービスはデフォルトでポート 443 で実行されます。
    • Konnectivity エージェントはリバーストンネルを確立し、コントロールプレーンがホストされたクラスターのネットワークにアクセスできるようにします。エージェントは egress を使用して Konnectivity サーバーに接続します。サーバーは、ポート 443 のルートまたは手動で割り当てられた NodePort を使用して公開されます。
    • クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
    • アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。

  • Ignition

    • ルートと Ingress を使用してサービスを公開する場合、Ignition サービスはデフォルトでポート 443 で実行されます。
    • NodePort 公開ストラテジーを使用する場合は、Ignition サービスにファイアウォールルールを使用します。

非ベアメタルエージェントマシンでは、次のサービスは必要ありません。

  • 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-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es.   IN A 192.168.122.23

  • IPv6 ネットワークで非接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。 

    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,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]

4.4.3. CLI を使用した非ベアメタルエージェントマシンでのホステッドクラスターの作成

エージェントプラットフォームでホステッドクラスターを作成すると、HyperShift Operator が Agent Cluster API プロバイダーを Hosted Control Plane の namespace にインストールします。ベアメタルでホステッドクラスターを作成するか、インポートできます。

ホステッドクラスターを作成するときは、次のガイドラインを確認してください。

  • 各ホステッドクラスターに、クラスター全体で一意の名前が必要です。multicluster engine Operator によってホステッドクラスターを管理するには、ホステッドクラスター名を既存のマネージドクラスターと同じにすることはできません。
  • ホステッドクラスター名として clusters を使用しないでください。
  • ホステッドクラスターは、multicluster engine Operator のマネージドクラスターの namespace には作成できません。

手順

  1. 次のコマンドを入力して、Hosted Control Plane namespace を作成します。 

    $ oc create ns <hosted_cluster_namespace>-<hosted_cluster_name> 1
    1
    <hosted_cluster_namespace> を、ホストされたクラスターの namespace 名 (例: clusters) に置き換えます。<hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。

  2. 次のコマンドを入力して、ホステッドクラスターを作成します。 

    $ 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
    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
    コントロールプレーンの可用性ポリシーのデフォルト値は、HighlyAvailable です。
    10
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.17.0-multi)。

検証

  • しばらくしてから、次のコマンドを入力して、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 コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。
  2. コンソールのヘッダーで、All Clusters を選択します。
  3. Infrastructure Clusters をクリックします。

  4. Create cluster Host inventory Hosted control plane をクリックします。

    Create cluster ページが表示されます。

  5. 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 にリダイレクトするロードバランサーを指すレコードを指定できます。

    1. エントリーを確認し、Create をクリックします。

    Hosted cluster ビューが表示されます。

    1. Hosted cluster ビューでホストされたクラスターのデプロイメントを監視します。ホストされたクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
    2. ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホストされたクラスターに参加したかどうかを確認することもできます。

次のステップ

4.4.3.2. ミラーレジストリーを使用してベアメタル上にホストされたクラスターを作成する

ミラーレジストリーを使用して、hcp create cluster コマンドで --image-content-sources フラグを指定して、ベアメタル上にホステッドクラスターを作成できます。

手順

  1. 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
  2. ファイルを icsp.yaml として保存します。このファイルにはミラーレジストリーが含まれます。

  3. ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。 

    $ 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 リリースイメージダイジェストの抽出 を参照してください。

次のステップ

4.4.4. 非ベアメタルエージェントマシンでのホステッドクラスターの作成を検証する

デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。

手順

  1. 次のコマンドを入力して、新しいホステッドクラスターの kubeconfig ファイルを取得します。 

    $ oc extract -n <hosted_cluster_namespace> secret/<hosted_cluster_name>-admin-kubeconfig --to=- > kubeconfig-<hosted_cluster_name>

  2. 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

  3. 次のコマンドを入力して、ホステッドクラスター上で実行中の 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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.