1.5. クラスターライフサイクルの概要

リリースイメージを参照する YAML ファイルは、acm-hive-openshift-releases GitHub リポジトリーに保持されます。これらのファイルは、コンソールで利用可能なリリースイメージのリストを作成します。これには、OpenShift Container Platform における最新の fast チャネルイメージが含まれます。

コンソールには、OpenShift Container Platform の 3 つの最新バージョンの最新リリースイメージのみが表示されます。たとえば、コンソールオプションに以下のリリースイメージが表示される可能性があります。

quay.io/openshift-release-dev/ocp-release:4.12.1-x86_64

コンソールには最新バージョンが表示され、最新のリリースイメージを使用してクラスターを作成するのに役立ちます。特定のバージョンのクラスターを作成する必要がある場合は、古いリリースイメージバージョンも利用できます。

注記: コンソールでクラスターを作成する場合は、visible: 'true' ラベルを持つイメージのみを選択できます。ClusterImageSet リソース内のこのラベルの例は、以下の内容で提供されます。4.x.1 は、製品の最新バージョンに置き換えます。

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.x.1-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64

追加のリリースイメージは保管されますが、コンソールには表示されません。利用可能なリリースイメージをすべて表示するには、次のコマンドを実行します。

oc get clusterimageset

リポジトリーには、clusterImageSets ディレクトリーがあります。これは、リリースイメージを操作するときに使用するディレクトリーです。clusterImageSets ディレクトリーには、次のディレクトリーがあります。

次のオプションを使用して ClusterImageSets を設定できます。

両方のアーキテクチャーのファイルを持つリリースイメージを手動で作成することで、ハブクラスターのアーキテクチャーとは異なるアーキテクチャーでクラスターを作成できます。

たとえば、ppc64le、aarch64、または s390x アーキテクチャーで実行されているハブクラスターから x86_64 クラスターを作成する必要があるとします。両方のファイルセットでリリースイメージを作成する場合に、新規のリリースイメージにより OpenShift Container Platform リリースレジストリーがマルチアーキテクチャーイメージマニフェストを提供できるので、クラスターの作成は成功します。

OpenShift Container Platform 4.12 以降は、デフォルトで複数のアーキテクチャーをサポートします。以下の clusterImageSet を使用してクラスターをプロビジョニングできます。4.x.0 は、最新バージョンに置き換えます。

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.x.0-multi-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.0-multi

複数のアーキテクチャーをサポートしない OpenShift Container Platform イメージのリリースイメージを作成するには、アーキテクチャータイプについて以下のような手順を実行します。

作成プロセスでは、マージされたリリースイメージを使用してクラスターを作成します。

Central Infrastructure Management サービスを有効にする前に、次の前提条件を確認してください。

Central Infrastructure Management サービスを有効にする前に、ベアメタルホストのカスタムリソース定義が必要です。

Central Infrastructure Management サービスを有効にする前に、Provisioning リソースが必要です。

非接続環境で Central Infrastructure Management を有効にするには、以下の手順を実行します。

重要: 遅延バインディング機能を使用しており、AgentServiceConfig カスタムリソースの spec.osImages リリースがバージョン 4.13 以降である場合、クラスターの作成時に使用する OpenShift Container Platform リリースイメージはバージョン 4.13 以降である必要があります。バージョン 4.13 以降の Red Hat Enterprise Linux CoreOS イメージは、バージョン 4.13 より前のイメージとは互換性がありません。

assisted-service デプロイメントおよび assisted-image-service デプロイメントをチェックし、その Pod が準備ができており実行中であることを確認することで、中央インフラストラクチャー管理サービスが正常であることを確認できます。

接続環境で Central infrastructure management を有効にするには、以下の YAML コンテンツを agent_service_config.yaml ファイルに保存して、AgentServiceConfig カスタムリソースを作成します。

apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
 name: agent
spec:
  databaseStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <db_volume_size> 1
  filesystemStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <fs_volume_size> 2
  imageStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <img_volume_size> 3

Central Infrastructure Management サービスが設定されている。assisted-service と assisted-image-service デプロイメントをチェックして、Pod の準備ができ、実行されていることを確認して、正常性を検証できます。

コンソールを使用してホストインベントリーを作成するには、次の手順を実行します。

コンソールでは使用できない詳細な設定オプションが必要な場合は、コマンドラインインターフェイスを使用したホストインベントリーの作成 に進みます。

高度な設定オプションが必要ない場合は、必要に応じて静的ネットワークの設定を続行し、インフラストラクチャー環境へのホストの追加を開始できます。

ホストインベントリーにアクセスするには、コンソールで Infrastructure > Host inventory を選択します。一覧からインフラストラクチャー環境を選択し、詳細とホストを表示します。

コマンドラインインターフェイスを使用してホストインベントリー (インフラストラクチャー環境) を作成するには、次の手順を実行します。

重要なプロパティーのリストは次のとおりです。

注: InfraEnv リソースを変更する場合は、createdTime プロパティーを確認して、InfraEnv が新しい Discovery Image を作成したことを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。

必要に応じて静的ネットワークを設定し、インフラストラクチャー環境へのホストの追加を開始することで続行できます。

コマンドラインインターフェイスを使用してインフラストラクチャー環境の詳細ネットワークを設定するには、以下の手順を実行します。

注: イメージサービスは、InfraEnv プロパティーを更新するか、そのラベルセレクターに一致する NMStateConfig リソースを変更すると、新しいイメージを自動的に作成します。InfraEnv リソースの作成後に NMStateConfig リソースを追加する場合は、InfraEnv の createdTime プロパティーを確認して、InfraEnv が新しい Discovery Image を作成していることを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。

以下の手順を実行して ISO をダウンロードします。

ISO をダウンロードするための URL が表示されます。ブートされたホストがホストインベントリーテーブルに表示されます。ホストが表示されるまでに数分かかる場合があります。使用する前に、各ホストを承認する必要があります。Actions をクリックして Approve を選択し、インベントリーテーブルからホストを選択できます。

ISO をダウンロードするための URL は、InfraEnv リソースのステータスの isoDownloadURL プロパティーで確認できます。InfraEnv リソースの詳細は、コマンドラインインターフェイスを使用したホストインベントリーの作成を参照してください。

起動したホストごとに、同じ namespace に Agent リソースを作成します。使用する前に、各ホストを承認する必要があります。

コンソールを使用してベアメタルホストをホストインベントリーに自動的に追加するには、次の手順を実行します。

コマンドラインインターフェイスを使用してベアメタルホストをホストインベントリーに自動的に追加するには、以下の手順を実施します。

ホストの電源をオンにすると、イメージのダウンロードが開始されます。これには数分かかる場合があります。ホストが検出されると、Agent カスタムリソースが自動的に作成されます。

デフォルトでは、コンバージドフローが有効になっています。ホストが表示されない場合は、一時的にコンバージドフローを無効にする必要がある場合があります。コンバージドフローを無効にするには、次の手順を実行します。

Discovery ISO で正常に起動した各ホストは、ホストインベントリーの行として表示されます。コンソールを使用してホストを編集および管理できます。ホストを手動で起動し、ベアメタル Operator の自動化を使用していない場合は、使用する前にコンソールでホストを承認する必要があります。OpenShift ノードとしてインストールできるホストが Available ステータスになっています。

Agent リソースは、各ホストを表します。Agent リソースで次のプロパティーを設定できます。

Agent リソースの status には、以下のプロパティーがあります。

クラスターを作成する前に、clusterImageSets リポジトリーのクローンを作成し、ハブクラスターに適用する必要があります。以下の手順を参照してください。

クラスターを作成するときに、Red Hat OpenShift Container Platform リリースイメージを選択します。

注記: Nutanix プラットフォームを使用する場合は、ClusterImageSet リソースの releaseImage に x86_64 アーキテクチャーを使用し、visible のラベル値を 'true' に設定してください。以下の例を参照してください。

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: stable
    visible: 'true'
  name: img4.x.47-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.47-x86_64

ClusterDeployment は、クラスターのライフサイクルを制御するために使用される Hive カスタムリソースです。

Using Hive のドキュメントに従って ClusterDeployment カスタムリソースを作成し、個別のクラスターを作成します。

ClusterPool は、複数のクラスターを作成するために使用される Hive カスタムリソースでもあります。

Cluster Pools のドキュメントに従って、Hive ClusterPool API でクラスターを作成します。

AWS でクラスターを作成する前に、以下の前提条件を確認してください。

AWS クラスターの作成に関する次の重要な情報を参照してください。

新しいクラスターを作成するには、次の手順を参照してください。代わりに既存のクラスターを インポート する場合は、クラスターのインポート を参照してください。

注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、マルチクラスターエンジン Operator で管理されるように自動的に設定されます。

認証情報を作成する必要がある場合は、Amazon Web Services の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

AWS GovCloud クラスターを作成する前に、以下の前提条件を満たす必要があります。

注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator コンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

AWS GovCloud でのクラスターの作成は、標準の AWS でクラスターを作成することとほぼ同じですが、AWS GovCloud でクラスターの AWS PrivateLink を準備するために追加の手順を実行する必要があります。

spec:
  awsPrivateLink:
    ## The list of inventory of VPCs that can be used to create VPC
    ## endpoints by the controller.
    endpointVPCInventory:
    - region: us-east-1
      vpcID: vpc-1
      subnets:
      - availabilityZone: us-east-1a
        subnetID: subnet-11
      - availabilityZone: us-east-1b
        subnetID: subnet-12
      - availabilityZone: us-east-1c
        subnetID: subnet-13
      - availabilityZone: us-east-1d
        subnetID: subnet-14
      - availabilityZone: us-east-1e
        subnetID: subnet-15
      - availabilityZone: us-east-1f
        subnetID: subnet-16
    - region: us-east-1
      vpcID: vpc-2
      subnets:
      - availabilityZone: us-east-1a
        subnetID: subnet-21
      - availabilityZone: us-east-1b
        subnetID: subnet-22
      - availabilityZone: us-east-1c
        subnetID: subnet-23
      - availabilityZone: us-east-1d
        subnetID: subnet-24
      - availabilityZone: us-east-1e
        subnetID: subnet-25
      - availabilityZone: us-east-1f
        subnetID: subnet-26
    ## The credentialsSecretRef points to a secret with permissions to create.
    ## The resources in the account where the inventory of VPCs exist.
    credentialsSecretRef:
      name: <hub-account-credentials-secret-name>

    ## A list of VPC where various mce clusters exists.
    associatedVPCs:
    - region: region-mce1
      vpcID: vpc-mce1
      credentialsSecretRef:
        name: <credentials-that-have-access-to-account-where-MCE1-VPC-exists>
    - region: region-mce2
      vpcID: vpc-mce2
      credentialsSecretRef:
        name: <credentials-that-have-access-to-account-where-MCE2-VPC-exists>

コンソールからクラスターを作成するには、Infrastructure > Clusters > Create cluster AWS > Standalone に移動して、コンソールで手順を実行します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。

AWS GovCloud クラスターを作成する場合、選択する認証情報は AWS GovCloud リージョンのリソースにアクセスできる必要があります。クラスターをデプロイするために必要な権限を持つ場合は、Hive namespace にある AWS GovCloud シークレットを使用できます。コンソールに既存の認証情報が表示されます。認証情報を作成する必要がある場合は、Amazon Web Services の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

AWS または AWS GovCloud アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。この名前はクラスターのホスト名で使用されます。詳細は、AWS アカウントの設定 を参照してください。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。情報には以下のフィールドが含まれます。

ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。

クラスターにはネットワークの詳細が必要であり、IPv6 を使用するには複数のネットワークが必要です。AWS GovCloud クラスターの場合は、Machine CIDR フィールドに Hive VPC のアドレスのブロックの値を入力します。Add network をクリックして、追加のネットワークを追加できます。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

AWS GovCloud クラスターを作成するか、プライベート環境を使用する場合は、AMI ID およびサブネット値を使用して、AWS プライベート設定 ページのフィールドに入力します。ClusterDeployment.yaml ファイルで spec:platform:aws:privateLink:enabled の値が true に設定されていることを確認します。これは、Use private configuration を選択すると自動的に設定されます。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML: On を選択して、パネルに install-config.yaml ファイルの内容を表示できます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、Kubernetes Operator のマルチクラスターエンジンの管理下に自動的に設定されます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

Azure でクラスターを作成する前に、以下の前提条件を確認してください。

注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator のコンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。

認証情報を作成する必要がある場合は、詳細について Microsoft Azure の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

Azure アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、Configuring a custom domain name for an Azure cloud service を参照してください。この名前はクラスターのホスト名で使用されます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、次のオプションフィールドが含まれます。

クラスターの作成後に、コントロールプレーンプールのタイプおよびルートストレージの割り当て (必須) を変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、マルチクラスターエンジン Operator で管理されるように自動的に設定されます。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

GCP でクラスターを作成する前に、次の前提条件を確認してください。

注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator のコンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。

認証情報を作成する必要がある場合は、Google Cloud Platform の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。GCP クラスターの命名に適用される制限がいくつかあります。この制限には、名前を goog で開始しないことや、名前に google に類似する文字および数字のグループが含まれないことなどがあります。制限の完全な一覧は、Bucket naming guidelines を参照してください。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

選択した GCP アカウントの認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、Setting up a custom domain を参照してください。この名前はクラスターのホスト名で使用されます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。情報には以下のフィールドが含まれます。

コントロールプレーンプールのインスタンスタイプを指定できます。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

ネットワークの詳細が必要であり、IPv6 アドレスを使用するには複数のネットワークが必要です。Add network をクリックして、追加のネットワークを追加できます。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML: On を選択して、パネルに install-config.yaml ファイルの内容を表示できます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、マルチクラスターエンジン Operator で管理されるように自動的に設定されます。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

vSphere でクラスターを作成する前に、次の前提条件を確認してください。

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。

認証情報を作成する必要がある場合は、認証情報の作成の詳細について、VMware vSphere の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

vSphere アカウントで設定した、選択した認証情報に関連付けられているベースドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、カスタマイズによる vSphere へのクラスターのインストール を参照してください。値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。この名前はクラスターのホスト名で使用されます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

注: OpenShift Container Platform バージョン 4.12 以降のリリースイメージがサポートされています。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、CPU アーキテクチャー フィールドが含まれます。次のフィールドの説明を表示します。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。この情報には、ソケットあたりのコア数、CPU、Memory_min MiB、GiB 単位の _Disk サイズ、および ノード数 が含まれます。

ネットワーク情報が必要です。IPv6 を使用するには、複数のネットワークが必要です。必要なネットワーク情報の一部は、次のフィールドに含まれています。

Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

Disconnected installation をクリックして、オフラインインストールイメージを定義できます。Red Hat OpenStack Platform プロバイダーとオフラインインストールを使用してクラスターを作成する際に、ミラーレジストリーにアクセスするための証明書が必要な場合は、クラスターを作成する際の認証情報または Disconnected installation セクションを設定するときに、Configuration for disconnected installation セクションの Additional trust bundle フィールドにその証明書を入力する必要があります。

Add automation template をクリックしてテンプレートを作成できます。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、マルチクラスターエンジン Operator で管理されるように自動的に設定されます。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

Red Hat OpenStack Platform でクラスターを作成する前に、以下の前提条件を確認してください。

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。

認証情報を作成する必要がある場合は、Red Hat OpenStack Platform の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。名前には 15 文字以上指定できません。値は、認証情報の要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

Red Hat OpenStack Platform アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、Red Hat OpenStack Platform ドキュメントの ドメインの管理 を参照してください。この名前はクラスターのホスト名で使用されます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。OpenShift Container Platform バージョン 4.6.x 以降のリリースイメージのみがサポートされます。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。

コントロールプレーンプールのインスタンスタイプを追加する必要がありますが、インスタンスの作成後にインスタンスのタイプとサイズを変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

クラスターにはネットワークの詳細が必要です。IPv4 ネットワーク用に 1 つ以上のネットワークの値を指定する必要があります。IPv6 ネットワークの場合は、複数のネットワークを定義する必要があります。

Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

Disconnected installation をクリックして、オフラインインストールイメージを定義できます。Red Hat OpenStack Platform プロバイダーとオフラインインストールを使用してクラスターを作成する際に、ミラーレジストリーにアクセスするための証明書が必要な場合は、クラスターを作成する際の認証情報または Disconnected installation セクションを設定するときに、Configuration for disconnected installation セクションの Additional trust bundle フィールドにその証明書を入力する必要があります。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

内部認証局 (CA) を使用するクラスターを作成する場合、以下の手順を実行してクラスターの YAML ファイルをカスタマイズする必要があります。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、マルチクラスターエンジン Operator で管理されるように自動的に設定されます。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

Red Hat Virtualization でクラスターを作成する前に、以下の前提条件を確認してください (非推奨)。

注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator のコンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合は、クラスターのインポート でインポート手順を参照してください。

認証情報を作成する必要がある場合は Red Hat Virtualization の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

Red Hat Virtualization アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値を上書きして変更できます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

コントロールプレーンプールのコア、ソケット、メモリー、およびディスクサイズの数など、ノードプールの情報。3 つのコントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、Architecture フィールドが含まれます。次のフィールドの説明を表示します。

ワーカープール情報には、ワーカープールのプール名、コア数、メモリー割り当て、ディスクサイズ割り当て、およびノード数が必要です。ワーカープール内のワーカーノードは単一のワーカープールに配置するか、複数のワーカープールに分散できます。

事前設定された oVirt 環境には、以下のネットワークの詳細が必要です。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、マルチクラスターエンジン Operator で管理されるように自動的に設定されます。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

オンプレミス環境にクラスターを作成する前に、以下の前提条件を確認してください。

コンソールからクラスターを作成するには、次の手順を実行します。

支援インストールでは、次のオプションを使用できます。

認証情報を作成する必要がある場合、詳細は オンプレミス環境の認証情報の作成 を参照してください。

クラスターの名前は、クラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

注記: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

プロバイダーアカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は上書きすると変更できますが、この設定はクラスターの作成後には変更できません。プロバイダーのベースドメインは、Red Hat OpenShift Container Platform クラスターコンポーネントへのルートの作成に使用されます。これは、クラスタープロバイダーの DNS で Start of Authority (SOA) レコードとして設定されます。

OpenShift version は、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。詳細は、リリースイメージ を参照してください。

サポート対象の OpenShift Container Platform バージョンを選択すると、Install single node OpenShift を選択するオプションが表示されます。シングルノード OpenShift クラスターには、コントロールプレーンサービスとユーザーワークロードをホストするシングルノードが含まれます。シングルノード OpenShift クラスターの作成後にノードを追加する方法の詳細は、インフラストラクチャー環境へのホストのスケーリング を参照してください。

クラスターをシングルノード OpenShift クラスターにする場合は、シングルノード OpenShift オプションを選択します。以下の手順を実行することで、シングルノードの OpenShift クラスターにワーカーを追加できます。

注記: シングルノード OpenShift コントロールプレーンには 8 つの CPU コアが必要ですが、マルチノードコントロールプレーンクラスターのコントロールプレーンノードには 4 つの CPU コアしか必要ありません。

クラスターを確認して保存すると、クラスターはドラフトクラスターとして保存されます。Clusters ページでクラスター名を選択すると、作成プロセスを閉じてプロセスを終了することができます。

既存のホストを使用している場合は、ホストを独自に選択するか、自動的に選択するかどうかを選択します。ホストの数は、選択したノード数に基づいています。たとえば、シングルノード OpenShift クラスターではホストが 1 つだけ必要ですが、標準の 3 ノードクラスターには 3 つのホストが必要です。

このクラスターの要件を満たす利用可能なホストの場所は、ホストの場所 のリストに表示されます。ホストと高可用性設定の分散については、複数の場所を選択します。

既存のインフラストラクチャー環境がない新しいホストを検出する場合は、Discovery Image を使用したホストインベントリーへのホストの追加 の手順を実行します。

ホストがバインドされ、検証に合格したら、以下の IP アドレスを追加してクラスターのネットワーク情報を入力します。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

Clusters ナビゲーションページで、インストールのステータスを表示できます。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

Central Infrastructure Management 管理コンポーネント内のアシステッドインストーラー機能を使用して、コンソールを使用せずにクラスターを作成することもできます。この手順を完了したら、生成された検出イメージからホストを起動できます。通常、手順の順序は重要ではありませんが、順序が必要な場合は注意してください。

apiVersion: v1
kind: Namespace
metadata:
  name: sample-namespace

apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: <pull-secret>
  namespace: sample-namespace
stringData:
  .dockerconfigjson: 'your-pull-secret-json' 1

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-v4.12.0
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.0-rc.0-x86_64

apiVersion: hive.openshift.io/v1
kind: ClusterDeployment
metadata:
  name: single-node
  namespace: demo-worker4
spec:
  baseDomain: hive.example.com
  clusterInstallRef:
    group: extensions.hive.openshift.io
    kind: AgentClusterInstall
    name: test-agent-cluster-install 1
    version: v1beta1
  clusterName: test-cluster
  controlPlaneConfig:
    servingCertificates: {}
  platform:
    agentBareMetal:
      agentSelector:
        matchLabels:
          location: internal
  pullSecretRef:
    name: <pull-secret> 2

apiVersion: extensions.hive.openshift.io/v1beta1
kind: AgentClusterInstall
metadata:
  name: test-agent-cluster-install
  namespace: demo-worker4
spec:
  platformType: BareMetal 1
  clusterDeploymentRef:
    name: single-node 2
  imageSetRef:
    name: openshift-v4.12.0 3
  networking:
    clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
    machineNetwork:
    - cidr: 192.168.111.0/24
    serviceNetwork:
    - 172.30.0.0/16
  provisionRequirements:
    controlPlaneAgents: 1
  sshPublicKey: ssh-rsa <your-public-key-here> 4

apiVersion: agent-install.openshift.io/v1beta1
kind: NMStateConfig
metadata:
  name: <mynmstateconfig>
  namespace: <demo-worker4>
  labels:
    demo-nmstate-label: <value>
spec:
  config:
    interfaces:
      - name: eth0
        type: ethernet
        state: up
        mac-address: 02:00:00:80:12:14
        ipv4:
          enabled: true
          address:
            - ip: 192.168.111.30
              prefix-length: 24
          dhcp: false
      - name: eth1
        type: ethernet
        state: up
        mac-address: 02:00:00:80:12:15
        ipv4:
          enabled: true
          address:
            - ip: 192.168.140.30
              prefix-length: 24
          dhcp: false
    dns-resolver:
      config:
        server:
          - 192.168.126.1
    routes:
      config:
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.111.1
          next-hop-interface: eth1
          table-id: 254
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.140.1
          next-hop-interface: eth1
          table-id: 254
  interfaces:
    - name: "eth0"
      macAddress: "02:00:00:80:12:14"
    - name: "eth1"
      macAddress: "02:00:00:80:12:15"

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: myinfraenv
  namespace: demo-worker4
spec:
  clusterRef:
    name: single-node  1
    namespace: demo-worker4 2
  pullSecretRef:
    name: pull-secret
    sshAuthorizedKey: <your_public_key_here> 3
  nmStateConfigLabelSelector:
    matchLabels:
      demo-nmstate-label: value 4

AgentClusterInstall プロキシーを設定するには、プロキシー 設定を AgentClusterInstall リソースに追加します。httpProxy、httpsProxy、noProxy を使用した次の YAML サンプルを参照してください。

apiVersion: extensions.hive.openshift.io/v1beta1
kind: AgentClusterInstall
spec:
  proxy:
    httpProxy: http://<username>:<password>@<proxy.example.com>:<port> 1
    httpsProxy: https://<username>:<password>@<proxy.example.com>:<port> 2
    noProxy: <wildcard-of-domain>,<provisioning-network/CIDR>,<BMC-address-range/CIDR> 3

Required user type or access level: クラスター管理者

新しいプルシークレットを作成する必要がある場合は、以下の手順を実行します。

利用可能なクラウドプロバイダーごとに、コンソールから既存のクラスターをインポートできます。

注記: ハブクラスターは別のハブクラスターを管理できません。ハブクラスターは、自動的にインポートおよび自己管理するように設定されるため、ハブクラスターを手動でインポートして自己管理する必要はありません。

デフォルトでは、namespace がクラスター名と namespace に使用されますが、これは変更できます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、クラスターは default マネージドクラスターセットに自動的に追加されます。

クラスターを別のクラスターセットに追加する場合は、クラスターセットへの clusterset-admin 権限が必要です。クラスターのインポート時に cluster-admin 権限がない場合は、clusterset-admin 権限を持つクラスターセットを選択する必要があります。指定されたクラスターセットに適切な権限がない場合、クラスターのインポートは失敗します。選択するクラスターセットが存在しない場合は、クラスター管理者に連絡して、クラスターセットへの clusterset-admin 権限を受け取ってください。

OpenShift Container Platform Dedicated クラスターをインポートし、vendor=OpenShiftDedicated のラベルを追加してベンダーを指定しない場合、vendor=auto-detect のラベルを追加すると、managed-by=platform ラベルがクラスターに自動的に追加されます。この追加されたラベルを使用して、クラスターを OpenShift Container Platform Dedicated クラスターとして識別し、OpenShift Container Platform Dedicated クラスターをグループとして取得できます。

以下の表は、クラスターをインポートする方法を指定する インポートモード で使用できるオプションを示しています。

注記: Ansible Automation Platform ジョブを作成して実行するには、OperatorHub から Red Hat Ansible Automation Platform Resource Operator をインストールし、実行する必要があります。

クラスター API アドレスを設定するには、任意: Configuring the cluster API address を参照してください。

マネージドクラスター klusterlet を特定のノードで実行するように設定するには、オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

以下の手順を実行して、インポートされたクラスターと、マネージドクラスターで作成された open-cluster-management-agent-addon を削除します。

Clusters ページで、Actions > Detach cluster をクリックしてマネージメントからクラスターを削除します。

注記: local-cluster という名前のハブクラスターをデタッチしようとする場合は、デフォルトの disableHubSelfManagement 設定が false である点に注意してください。この設定が原因で、ハブクラスターがデタッチされると、自身を再インポートして管理し、MultiClusterHub コントローラーが調整されます。ハブクラスターがデタッチプロセスを完了して再インポートするのに時間がかかる場合があります。プロセスが完了するのを待たずにハブクラスターを再インポートする場合は、次のコマンドを実行して multiclusterhub-operator Pod を再起動し、再インポートを高速化できます。

oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`

disableHubSelfManagement の値を true に指定して、自動的にインポートされないように、ハブクラスターの値を変更できます。詳細は、disableHubSelfManagement のトピックを参照してください。

CLI を使用してマネージドクラスターをインポートする前に、以下の手順を実行する必要があります。

これで、自動インポートシークレットを使用してクラスターをインポートする か、手動でクラスターをインポートする のいずれかに進むことができます。

自動インポートシークレットを使用してマネージドクラスターをインポートするには、クラスターの kubeconfig ファイルへの参照、またはクラスターの kube API サーバーとトークンのペアのいずれかの参照を含むシークレットを作成する必要があります。自動インポートシークレットを使用してクラスターをインポートするには、以下の手順を実行します。

klusterlet アドオンのインポート に進むことができます。

重要: import コマンドには、インポートされた各マネージドクラスターにコピーされるプルシークレット情報が含まれます。インポートしたクラスターにアクセスできるユーザーであれば誰でも、プルシークレット情報を表示することもできます。

マネージドクラスターを手動でインポートするには、以下の手順を実行します。

klusterlet アドオンのインポート に進むことができます。

KlusterletAddonConfig klusterlet アドオン設定を実装して、マネージドクラスターで他のアドオンを有効にします。次の手順を実行して、設定ファイルを作成して適用します。

コマンドラインインターフェイスを使用してマネージドクラスターを削除するには、以下のコマンドを実行します。

oc delete managedcluster <cluster_name>

<cluster_name> をクラスターの名前に置き換えます。

エージェント登録エンドポイントを使用してマネージドクラスターをインポートするには、次の手順を実行します。

静的ネットワークまたはベアメタルホストなしで OpenShift Container Platform クラスターを手動でインポートし、ノードを追加する準備をするには、以下の手順を実行します。

ManagedClusterImageRegistry カスタムリソース定義でカスタマイズされるクラスターをインポートするには、以下の手順を実行します。

自動スケーリングを設定すると、トラフィックが少ない場合にリソースをスケールダウンし、多くのリソースが必要な場合に十分にリソースを確保できるようにスケールアップするなど、必要に応じてクラスターに柔軟性を持たせることができます。

コンソールまたはコマンドラインを使用して自動スケーリングを無効にできます。

コンソールおよびコマンドラインから手動でスケーリングできます。

マネージドクラスター API を信頼するために必要な新しい CA 証明書が必要です。

実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加する前に、有効な kubeconfig があるかどうかを確認する必要があります。

マネージドクラスターの API 証明書が変更された場合は、次の手順を実行して、kubeconfig を新しい CA 証明書で更新します。

有効な kubeconfig がある場合は、以下の手順を実行して、実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加します。

ワーカーノードのインストールを待ちます。ワーカーノードのインストールが完了すると、ワーカーノードは証明書署名要求 (CSR) を使用してマネージドクラスターに接続し、参加プロセスを開始します。CSR は自動的に署名されます。

以下の手順を実行して、コントロールプレーンノードを正常なマネージドクラスターに追加します。

以下の手順を実行して、コントロールプレーンノードを正常でないマネージドクラスターに追加します。

OpenShift Update Service を使用して非接続クラスターをアップグレードするには、以下の前提条件を満たす必要があります。

ローカルのミラーリングレジストリーに、アップグレード前の現行のイメージと、アップグレード後のイメージの療法をミラーリングする必要があります。イメージをミラーリングするには以下の手順を実行します。

OpenShift Container Platform 環境で OpenShift Update Service の Operator をデプロイするには、以下の手順を実行します。

OpenShift Update Service はグラフデータ情報を使用して、利用可能なアップグレードを判別します。オンライン環境では、OpenShift Update Service は Cincinnati グラフデータの GitHub リポジトリー から直接利用可能なアップグレードがないか、グラフデータ情報をプルします。非接続環境を設定しているため、init container を使用してローカルリポジトリーでグラフデータを利用できるようにする必要があります。以下の手順を実行して、グラフデータの init container を作成します。

セキュアな外部コンテナーレジストリーを使用してミラーリングされた OpenShift Container Platform リリースイメージを保存する場合は、アップグレードグラフをビルドするために OpenShift Update Service からこのレジストリーへのアクセス権が必要です。OpenShift Update Service Pod と連携するように CA 証明書を設定するには、以下の手順を実行します。

OpenShift Update Service Operator は、変更がないか、image.config.openshift.io API と、openshift-config namespace に作成した ConfigMap を監視し、CA 証明書が変更された場合はデプロイメントを再起動します。

ハブクラスターへの OpenShift Update Service インスタンスのデプロイが完了したら、このインスタンスは、クラスターのアップグレードのイメージをミラーリングして非接続マネージドクラスターに提供する場所に配置されます。インスタンスをデプロイするには、以下の手順を実行します。

注記: 本セクションの手順は、ミラーレジストリーにリリースをミラーリングした場合にのみ該当します。

OpenShift Container Platform にはイメージレジストリーのデフォルト値があり、この値でアップグレードパッケージの検索先を指定します。オフライン環境では、オーバーライドを作成して、その値をリリースイメージをミラーリングしたローカルイメージレジストリーへのパスに置き換えることができます。

デフォルトのレジストリーを上書きするには、次の手順を実行します。

マネージドクラスターで、デフォルトのカタログソースをすべて無効にし、新しいカタログソースを作成します。デフォルトの場所を接続された場所からオフラインローカルレジストリーに変更するには、次の手順を実行します。

マネージドクラスターの ClusterVersion リソース情報を更新して、アップグレードを取得するデフォルトの場所を変更します。

Cluster ページでは、オフラインレジストリーにアップグレードがある場合、クラスターの Distribution version に、利用可能なアップグレードがあることが示されます。クラスターを選択し、Actions メニューから Upgrade clusters を選択すると、利用可能なアップグレードを表示できます。オプションのアップグレードパスが利用可能な場合は、利用可能なアップグレードがリストされます。

注記: 現行バージョンがローカルのイメージリポジトリーにミラーリングされていないと、利用可能なアップグレードバージョンは表示されません。

コンソールを使用して、OpenShift Container Platform バージョン 4.6 以降でクラスターをアップグレードするためのチャネルを選択できます。これらのバージョンはミラーレジストリーで利用可能である必要があります。チャネルの選択 の手順を実行して、アップグレードチャネルを指定します。

オフラインレジストリーを設定すると、マルチクラスターエンジン Operator と OpenShift Update Service はオフラインレジストリーを使用して、アップグレードが利用可能かどうかを判断します。利用可能なアップグレードが表示されない場合は、クラスターの現行のリリースイメージと、1 つ後のイメージがローカルリポジトリーにミラーリングされていることを確認します。クラスターの現行バージョンのリリースイメージが利用できないと、アップグレードは利用できません。

Cluster ページでは、オフラインレジストリーにアップグレードがある場合、クラスターの Distribution version に、利用可能なアップグレードがあることが示されます。イメージをアップグレードするには、Upgrade available をクリックし、アップグレードするバージョンを選択します。

マネージドクラスターは、選択したバージョンに更新されます。

クラスターのアップグレードに失敗すると、Operator は通常アップグレードを数回再試行し、停止し、コンポーネントに問題があるステータスを報告します。場合によっては、アップグレードプロセスは、プロセスの完了を繰り返し試行します。アップグレードに失敗した後にクラスターを以前のバージョンにロールバックすることはサポートされていません。クラスターのアップグレードに失敗した場合は、Red Hat サポートにお問い合わせください。

CLI を使用してマネージドクラスターセットの定義を YAML ファイルに追加し、マネージドクラスターセットを作成します。

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: <cluster_set>

<cluster_set> をマネージドクラスターセットの名前に置き換えます。

ManagedClusterSet の作成後に、コンソールまたは CLI を使用してクラスターをマネージドクラスターセットに追加できます。

CLI を使用してクラスターをマネージドクラスターに追加するには、以下の手順を実行します。

コンソールを使用して ManagedClusterSetBinding を作成するには、以下の手順を実行します。

CLI を使用して ManagedClusterSetBinding を作成するには、以下の手順を実行します。

taint はマネージドクラスターのプロパティーで指定され、placement がマネージドクラスターまたはマネージドクラスターのセットを除外できます。以下の例のようなコマンドを入力して、taint をマネージドクラスターに追加できます。

oc taint ManagedCluster <managed_cluster_name> key=value:NoSelect

taint の仕様には以下のフィールドが含まれます。

マネージドクラスターにアクセスできない場合には、クラスターを placement に追加しないでください。以下の taint は、アクセスできないマネージドクラスターに自動的に追加されます。

toleration は placement に適用され、placement の toleration と taint が同じでないマネージドクラスターを placement から除外できます。toleration の仕様には以下のフィールドが含まれます。

以下の例は、taint が含まれるクラスターを許容する toleration を設定する方法を示しています。

注記: マネージドクラスターは、taint の toleration が含まれる placement に置かれる保証はありません。他の placement に同じ toleration が含まれる場合には、マネージドクラスターはそれらの placement のいずれかに置かれる可能性があります。

TolerationSeconds の値は、toleration が taint を許容する期間を指定します。この一時的な toleration は、マネージドクラスターがオフラインで、このクラスターにデプロイされているアプリケーションを、許容時間中に別のマネージドクラスターに転送できる場合に役立ちます。

たとえば、以下の taint を持つマネージドクラスターに到達できなくなります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

以下の例のように、TolerationSeconds の値で placement を定義すると、ワークロードは 5 分後に利用可能な別のマネージドクラスターに転送されます。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: demo4
  namespace: demo1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300

マネージドクラスターに到達できなくなると、アプリケーションが 5 分間別のマネージドクラスターに移動されます。

コンソールを使用してマネージドクラスターセットからクラスターを削除するには、次の手順を実行します。

注記: マネージドクラスターを別のマネージドクラスターセットに移動する場合には、マネージドクラスターセット両方で RBAC 権限の設定が必要です。

コマンドラインを使用してマネージドクラスターセットからクラスターを削除するには、以下の手順を実行します。

注記: マネージドクラスターを別のクラスターセットに移動する場合は、マネージドクラスターセット両方で RBAC 権限の設定が必要です。

一致するテイントを使用して ManagedClusters をフィルタリングする方法は、次の例を参照してください。

tolerationSeconds パラメーターを使用して、指定した期間、一致するテイントを持つ ManagedClusters を選択することもできます。tolerationSeconds は、許容がテイントにバインドされ続ける期間を定義します。tolerationSeconds は、指定された時間が経過すると、オフラインになったクラスターにデプロイされたアプリケーションを別のマネージドクラスターに自動的に転送できます。

次の例を見て、tolerationSeconds の使用方法を学習します。

次の例を参照して、prioritizerPolicy パラメーターと配置を使用して ManagedClusters に優先順位を付ける方法を学習します。

デプロイされているアドオンのステータスに基づいて、プレースメント用のマネージドクラスターを選択することもできます。たとえば、マネージドクラスターで有効になっている特定のアドオンがある場合にのみ、placement にマネージドクラスターを選択できます。

placement を作成するときに、アドオンのラベルとそのステータスを指定できます。マネージドクラスターでアドオンが有効になっている場合、ラベルは ManagedCluster リソース上に自動的に作成されます。アドオンが無効になると、ラベルは自動的に削除されます。

各アドオンは、feature.open-cluster-management.io/addon-<addon_name>=<status_of_addon> の形式でラベルで表現します。

addon_name を選択したマネージドクラスターで有効にするアドオンの名前に置き換えます。

status_of_addon をマネージドクラスターが選択されている場合にアドオンに設定するステータスに置き換えます。

status_of_addon に指定できる値については、次の表を参照してください。

たとえば、使用可能な application-manager. アドオンは、マネージドクラスター上の次のようなラベルで表されます。

feature.open-cluster-management.io/addon-application-manager: available

アドオンとそのステータスに基づいて placement を作成する方法については、次の例を参照してください。

クラスタープールを作成する前に、次の前提条件を参照してください。

注意: この手順でクラスタープールを追加すると、プールからクラスターを要求するときに、マルチクラスターエンジン Operator によって管理されるクラスターが自動的にインポートされるように設定されます。クラスター要求で管理用に、要求されたクラスターを自動的にインポートしないようにクラスタープールを作成する場合には、clusterClaim 理 s−すを以下ののテーションに追加します。

kind: ClusterClaim
metadata:
  annotations:
    cluster.open-cluster-management.io/createmanagedcluster: "false" 1

クラスタープールを作成するには、ナビゲーションメニューで Infrastructure > Clusters を選択します。Cluster pools タブには、アクセス可能なクラスタープールがリスト表示されます。Create cluster pool を選択し、コンソールの手順を実行します。

クラスタープールに使用するインフラストラクチャー認証情報がない場合は、Add credential を選択して作成できます。

リストから既存の namespace を選択するか、作成する新規 namespace の名前を入力します。クラスタープールは、クラスターと同じ namespace に配置する必要はありません。

クラスタープールの RBAC ロールを使用して、既存クラスターセットのロール割り当てを共有する場合は、クラスターセット名を選択します。クラスタープールのクラスターセットは、クラスタープールの作成時にのみ設定できます。クラスタープールの作成後には、クラスタープールまたはクラスタープールのクラスターセットの関連付けを変更できません。クラスタープールから要求したクラスターは、クラスタープールと同じクラスターセットに自動的に追加されます。

注記: cluster admin の権限がない場合は、クラスターセットを選択する必要があります。この状況でクラスターセットの名前が含まれない場合は、禁止エラーで、クラスターセットの作成要求が拒否されます。選択できるクラスターセットがない場合は、クラスター管理者に連絡してクラスターセットを作成し、clusterset admin 権限を付与してもらいます。

cluster pool size は、クラスタープールにプロビジョニングするクラスターの数を指定し、クラスタープールの実行回数は、プールが実行を継続し、すぐに使用できるように要求できるクラスターの数を指定します。

この手順は、クラスターを作成する手順と非常に似ています。

プロバイダーに必要な固有の情報は、以下を参照してください。

クラスタープールからクラスターを要求する前に、以下を利用意する必要があります。

利用可能なクラスターのある/ないクラスタープール。クラスタープールに利用可能なクラスターがある場合、利用可能なクラスターが要求されます。クラスタープールに利用可能なクラスターがない場合は、要求を満たすためにクラスターが作成されます。クラスタープールの作成方法については、クラスタープールの作成 を参照してください。

クラスター要求の作成時に、クラスタープールから新規クラスターを要求します。クラスターが利用可能になると、クラスターはプールからチェックアウトされます。自動インポートを無効にしていない限り、要求されたクラスターはマネージドクラスターの 1 つとして自動的にインポートされます。

以下の手順を実行してクラスターを要求します。

クラスターが利用可能な場合には、クラスターが要求され、マネージドクラスター タブにすぐに表示されます。利用可能なクラスターがない場合は、休止状態のクラスターの再開や、新しいクラスターのプロビジョニングに数分かかる場合があります。この間、要求のステータスは pending です。クラスタープールをデプロイメントして、保留中の要求を表示または削除します。

要求されたクラスターは、クラスタープールにあった時に関連付けられたクラスターセットに所属します。要求時には、要求したクラスターのクラスターセットは変更できません。

注記: クラウドプロバイダーの認証情報のプルシークレット、SSH キー、またはベースドメインへの変更は、クラスタープールから請求された既存のクラスターについては、元の認証情報を使用してすでにプロビジョニングされているため、反映されません。コンソールを使用してクラスタープール情報を編集することはできませんが、CLI インターフェイスを使用してその情報を更新することで更新できます。更新された情報を含む認証情報を使用して、新しいクラスタープールを作成することもできます。新しいプールで作成されるクラスターは、新しい認証情報で提供される設定を使用します。