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

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

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

quay.io/openshift-release-dev/ocp-release:4.15.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 では、デフォルトで複数のアーキテクチャーがサポートされます。以下の 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 イメージのリリースイメージを作成するには、アーキテクチャータイプについて以下のような手順を実行します。

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

クラスターを作成する前に、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 でクラスターを作成します。

追加のリソースマニフェストが含まれる config map リソースを指定する ClusterDeployment リソースへの参照を追加する。

注記: ClusterDeployment リソースと config map は同じ namespace にある必要があります。

リソースマニフェストを含む config map を使用して追加のマニフェストを設定する場合は、次の手順を実行します。

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.15 以降のリリースイメージがサポートされています。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、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 で管理されるように自動的に設定されます。

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

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

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

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

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

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

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの 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.15.0
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.15.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.15.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>
  nmStateConfigLabelSelector:
    matchLabels:
      demo-nmstate-label: value
  proxy:
    httpProxy: http://USERNAME:PASSWORD@proxy.example.com:PORT
    httpsProxy: https://USERNAME:PASSWORD@proxy.example.com:PORT
    noProxy: .example.com,172.22.0.0/24,10.10.0.0/24

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 クラスターを手動でインポートし、ノードを追加する準備をするには、以下の手順を実行します。

OpenShift Container Platform マネージドクラスターが アシステッドインストーラーによってインストールされている場合、マネージドクラスターとそのリソースを 1 つのハブクラスターから別のハブクラスターに移動できます。

元のリソースのコピーを保存し、それらを新しいハブクラスターに適用し、元のリソースを削除することで、新しいハブクラスターからクラスターを管理できます。その後、新しいハブクラスターからマネージドクラスターをスケールダウンまたはスケールアップできます。

重要： インポートされた 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 サポートにお問い合わせください。

ハブクラスター KubeAPIServer 証明書検証ストラテジーを確認し、デフォルトの UseAutoDetectedCABundle ストラテジーが機能することを確認します。ストラテジーを手動で変更する必要がある場合は、ハブクラスター KubeAPIServer 検証戦略の設定 を参照してください。

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 セクションが存在しない場合は、次の例のようなコマンドを実行して、マネージドクラスターに taint を追加できます。

oc patch managedcluster <managed_cluster_name> -p '{"spec":{"taints":[{"key": "key", "value": "value", "effect": "NoSelect"}]}}' --type=merge

または、次の例のようなコマンドを実行して、既存の taint に taint を追加することもできます。

oc patch managedcluster <managed_cluster_name> --type='json' -p='[{"op": "add", "path": "/spec/taints/-", "value": {"key": "key", "value": "value", "effect": "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 リソースに次のアノテーションを追加してください。

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 インターフェイスを使用してその情報を更新することで更新できます。更新された情報を含む認証情報を使用して、新しいクラスタープールを作成することもできます。新しいプールで作成されるクラスターは、新しい認証情報で提供される設定を使用します。

ハブクラスターとマネージドクラスターとの間でプロキシー設定を指定するには、以下の手順を実行します。

開発が変更された場合は、HTTP または HTTPS プロキシーを無効にする必要がある場合があります。

Red Hat Advanced Cluster Management for Kubernetes を使用してクラスターを作成する場合、マネージドクラスターの nodeSelector および tolerations アノテーションを設定することで、マネージドクラスター klusterlet を実行するノードを指定できます。これらの設定を構成するには、次の手順を実行します。

マネージドクラスターをインポートするときにカスタムハブ API サーバー URL と CA バンドルを使用するには、次の手順を実行します。

KlusterletConfig リソースを作成し、名前を global に設定すると、グローバル KlusterletConfig 内の設定が全マネージドクラスターに自動的に適用されます。

グローバル KlusterletConfig がある環境では、agent.open-cluster-management.io/klusterlet-config: <klusterletconfig-name> アノテーションを ManagedCluster リソース に追加して、クラスター 固有の KlusterletConfig を作成し、マネージドクラスターにバインドすることもできます。同じフィールドに異なる値を設定すると、クラスター固有の KlusterletConfig の値は、グローバル KlusterletConfig 値を上書きします。

次の例では、hubKubeAPIServerURL フィールドに、KlusterletConfig とグローバル KlusterletConfig で異なる値が設定されています。https://api.example.test.com:6443値は、"https://api.example.global.com:6443" 値を上書きします。

非推奨： hubKubeAPIServerURL フィールドは非推奨になりました。詳細は、API の非推奨 を参照してください。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerConfig:
    url: "https://api.example.test.com:6443"
---
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerConfig:
    url: "https://api.example.global.com:6443"

マネージドクラスターにバインドされているクラスター固有の KlusterletConfig がない場合や、同じフィールドが見つからないか、クラスター固有の KlusterletConfig に値がない場合は、グローバル KlusterletConfig の値が使用されます。

次の例を参照してください。ここでは、グローバル KlusterletConfig の hubKubeAPIServerURL フィールドの "example.global.com" 値が KlusterletConfig をオーバーライドします。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerURL: ""
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"

次の例を参照してください。ここでは、グローバル KlusterletConfig の hubKubeAPIServerURL フィールドの "example.global.com" 値が KlusterletConfig をオーバーライドします。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"

デフォルト設定ストラテジーは UseAutoDetectedCABundle です。マルチクラスターエンジン Operator はハブクラスターの証明書を自動的に検出し、実際の CA バンドルへの設定マップ参照の trustedCABundles リストに設定された証明書をマージします（ある場合）。

以下の例では、ハブクラスターから自動的に検出された証明書と、new-ocp-ca 設定マップで設定した証明書をマージし、両方をマネージドクラスターに追加します。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseAutoDetectedCABundle
   trustedCABundles:
   - name: new-ca
     caBundle:
       name: new-ocp-ca
       namespace: default

UseSystemTruststore を使用すると、マルチクラスターエンジン Operator は証明書を検出せず、trustedCABundles パラメーターセクションに設定された証明書を無視します。この設定では、マネージドクラスターに証明書は渡されません。代わりに、マネージドクラスターは、マネージドクラスターのシステム信頼されるストアからの証明書を使用して、ハブクラスター API サーバーを確認します。これは、Let's Encrypt などのパブリック CA がハブクラスター証明書を発行する状況に適用されます。UseSystemTruststore を使用する次の例を参照してください。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseSystemTruststore

ハブクラスター API サーバーの CA を把握しており、マルチクラスターエンジン Operator が自動的に検出しない場合は、UseCustomCABundles を使用できます。このストラテジーでは、マルチクラスターエンジン Operator は設定された証明書を trustedCABundles パラメーターからマネージドクラスターに追加します。UseCustomCABundles の使用方法については、以下の例を参照してください。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseCustomCABundles
   trustedCABundles:
   - name: ca
     caBundle:
       name: ocp-ca
       namespace: default

通常、このポリシーは各マネージドクラスターで同じになります。ハブクラスター管理者は、マルチクラスターエンジン Operator またはハブクラスター証明書の変更時に、global という名前の KlusterletConfig を設定して各マネージドクラスターのポリシーをアクティベートできます。以下の例を参照してください。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: global
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseSystemTruststore

マネージドクラスターが別のストラテジーを使用する必要がある場合は、別の KlusterletConfig を作成し、マネージドクラスターの agent.open-cluster-management.io/klusterlet-config アノテーションを使用して、特定のストラテジーを指すこともできます。以下の例を参照してください。

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: test-ca
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseCustomCABundles
   trustedCABundles:
   - name: ca
     caBundle:
       name: ocp-ca
       namespace: default
--
apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config: test-ca
  name: cluster1
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60