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

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
  • Central Infrastructure Management を有効にした。詳細は、Red Hat Advanced Cluster Management ドキュメントの Central Infrastructure Management サービスの有効化 を参照してください。
  • hcp コマンドラインインターフェイスをインストールした。
  • ホステッドクラスターの名前がクラスター全体で一意である。
  • 管理クラスターとワーカーを同じインフラストラクチャー上で実行している。

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

注記

サービスはデフォルトのポートで実行されます。ただし、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: 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.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 パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。 

    #...
spec:
  configuration:
    apiServer:
      servingCerts:
        namedCertificates:
        - names:
          - xxx.example.com
          - yyy.example.com
          servingCertificate:
            name: <my_serving_certificate>
  kubeAPIServerDNSName: <custom_address>
    1
    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 には作成できない。

手順

  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 
    
  --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.19.0-multi)。
    11
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。それ以外の場合、ノードプールは作成されません。

検証

  • しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。 

    $ oc -n <hosted_cluster_namespace>-<hosted_cluster_name> 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

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 をクリックして、ノードがホステッドクラスターに参加したかどうかを確認することもできます。

次のステップ

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

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 エンドポイントに対して有効である必要があります。
  • 証明書の有効期間は、クラスターの予想されるライフサイクルと一致します。

手順

  1. 次のコマンドを入力して、カスタム証明書を使用してシークレットを作成します。 

    $ oc create secret tls sample-hosted-kas-custom-cert \
  --cert=path/to/cert.crt \
  --key=path/to/key.key \
  -n <hosted_cluster_namespace>

  2. 次の例に示すように、カスタム証明書の詳細を使用して HostedCluster 設定を更新します。 

    spec:
  configuration:
    apiServer:
      servingCerts:
        namedCertificates:
        - names:
    1 
    
          - api-custom-cert-sample-hosted.sample-hosted.example.com
          servingCertificate:
    2 
    
            name: sample-hosted-kas-custom-cert
    1
    証明書が有効な DNS の名前のリスト。
    2
    カスタム証明書が含まれるシークレットの名前。

  3. 次のコマンドを入力して、HostedCluster 設定に変更を適用します。 

    $ oc apply -f <hosted_cluster_config>.yaml

検証

  • API サーバー Pod をチェックして、新しい証明書がマウントされていることを確認します。
  • カスタムドメイン名を使用して API サーバーへの接続をテストします。
  • ブラウザーで、または openssl などのツールを使用して、証明書の詳細を確認します。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る