マルチクラスターエンジン

Red Hat Advanced Cluster Management for Kubernetes 2.6

Kubernetes 用のマルチクラスターエンジンを作成および管理する方法について

概要

Kubernetes 用のマルチクラスターエンジンを作成および管理する方法については、詳細をご覧ください。

第1章 Kubernetes Operator のマルチクラスターエンジンの概要

1.1. Kubernetes operator のマルチクラスターエンジンについて

Kubernetes operator のマルチクラスターエンジンは、Red Hat OpenShift Container Platform にマルチクラスターライフサイクル機能を提供するクラスターライフサイクルの Operator です。The multicluster engine for Kubernetes operator 2.1 support matrix、および Kubernetes operator のマルチクラスターエンジンに関する次のドキュメントを参照してください。

1.1.1. 要件および推奨事項

Kubernetes Operator のマルチクラスターエンジンをインストールする前に、次のシステム設定要件と設定を確認してください。

重要: 2.5 より前の Red Hat Advanced Cluster Management for Kubernetes がインストールされていないクラスターには、Kubernetes Operator 用のマルチクラスターエンジンをインストールする必要があります。バージョン 2.5 以降で Red Hat Advanced Cluster Management を使用している場合、Kubernetes 用のマルチクラスターエンジンはすでにクラスターにインストールされています。

1.1.1.1. サポートされているブラウザーとプラットフォーム

multicluster engine for Kubernetes operator 2.1 support matrix で、サポートされているブラウザーと機能に関する重要な情報を参照してください。

1.1.2. ネットワーク

Kubernetes オペレーターハブクラスターおよびマネージドクラスター用のマルチクラスターエンジンのネットワーク要件について説明します。

重要: 信頼できる CA バンドルは、Kubernetes オペレーターの namespace のマルチクラスターエンジンで使用できますが、その拡張にはネットワークへの変更が必要です。信頼できる CA バンドル ConfigMap は、trusted-ca-bundle のデフォルト名を使用します。この名前は、TRUSTED_CA_BUNDLE という名前の環境変数でオペレーターに提供することで変更できます。詳細については、Red Hat OpenShift Container Platform の ネットワーク セクションの クラスター全体のプロキシーの設定 を参照してください。の上。

1.1.2.1. ハブクラスターのネットワーク設定

ハブクラスターネットワークの設定を参照できます。

次の表のハブクラスターネットワーク要件を参照してください。

方向接続ポート (指定されている場合)

送信

クラウドプロバイダーの API

 

Outbound

プロビジョニングしたマネージドクラスターの Kubernetes API サーバー

6443

送信および受信

マネージドクラスターの WorkManager サービスルート

443

受信

マネージドクラスターからの Kubernetes クラスター用のマルチクラスターエンジンの Kubernetes API サーバー

6443

1.1.2.2. マネージドクラスターのネットワーク設定

マネージドクラスターネットワークの要件については、以下の表を参照してください。

方向接続ポート (指定されている場合)

送信および受信

Kubernetes クラスター用のマルチクラスターエンジンの Kubernetes API サーバー

6443

1.1.2.3. インフラストラクチャーオペレーターを使用してインストールする場合の追加のネットワーク要件

Infrastructure Operator を使用してベアメタルマネージドクラスターをインストールする場合は、以下の表で追加のネットワーク要件について参照してください。

方向プロトコル接続ポート (指定されている場合)

ISO/rootfs イメージリポジトリーへのハブクラスターの送信

HTTPS (非接続環境では HTTP)

Red Hat Advanced Cluster Management ハブで ISO イメージを作成するのに使用します。

443 (非接続環境では 80)

単一ノードの OpenShift Container Platform マネージドクラスターでの BMC インターフェイスへのハブクラスター送信

HTTPS (非接続環境では HTTP)

OpenShift Container Platform クラスターをブートします。

443

OpenShift Container Platform マネージドクラスターからハブクラスターへの送信

HTTPS

assistedService ルートを使用してハードウェア情報を報告します。

443

OpenShift Container Platform マネージドクラスターから ISO/rootfs イメージリポジトリーへの送信

HTTP、HTTPS、または TLS

rootfs イメージをダウンロードします。

HTTP 80, HTTPS 443

OpenShift Container Platform 管理クラスターから registry.redhat.com イメージリポジトリーへのアウトバウンド

HTTPS/TLS

イメージをダウンロードします

443

1.1.2.4. Hive Operator を使用してインストールする場合の追加のネットワーク要件

Central Infrastructure Management の使用が含まれる Hive Operator を使用してベアメタルマネージドクラスターをインストールする場合は、ハブクラスターと libvirt プロビジョニングホスト間で、レイヤー 2 またはレイヤー 3 のポート接続を設定する必要があります。プロビジョニングホストへのこの接続は、Hive を使用したベースベアメタルクラスターの作成時に必要になります。詳細は、以下の表を参照してください。

方向プロトコル接続ポート (指定されている場合)

libvirt プロビジョニングホストへのハブクラスターの送信および受信

IP

Hive Operator がインストールされているハブクラスターを、ベアメタルクラスターの作成時にブートストラップとして機能する libvirt プロビジョニングホストに接続します。

 

注記:これらの要件はインストール時にのみ適用され、Infrastructure Operator でインストールされたクラスターのアップグレード時には必要ありません。

1.1.2.4.1. ホステッドコントロールプレーンのネットワーク要件 (テクノロジープレビュー)

ホステッドコントロールプレーンを使用する場合、HypershiftDeployment リソースには、次の表に示すエンドポイントへの接続が必要です。

方向接続ポート (指定されている場合)

Outbound

OpenShift Container Platform コントロールプレーンおよびワーカーノード

 

Outbound

Amazon Web Services のホステッドクラスターのみ: AWS API および S3 API へのアウトバウンド接続

 

Outbound

Microsoft Azure クラウドサービスのホステッドクラスターのみ: Azure API へのアウトバウンド接続

 

Outbound

coreOS の ISO イメージと OpenShift Container Platform Pod のイメージレジストリーを格納する OpenShift Container Platform イメージリポジトリー

 

1.1.3. コンソールの概要

OpenShift Container Platform コンソールプラグインは OpenShift Container Platform 4.10 Web コンソールで利用可能であり、統合することができます。この機能を使用するには、コンソールプラグインを有効にしておく必要があります。Kubernetes Operator 用のマルチクラスターエンジンは、Infrastructure および Credentials のナビゲーション項目から特定のコンソール機能を表示します。Red Hat Advanced Cluster Management をインストールすると、より多くのコンソール機能が表示されます。

注記:プラグインが有効になっている OpenShift Container Platform 4.10 の場合は、ドロップダウンメニューから All Clusters を選択することにより、クラスタースイッチャーから OpenShift Container Platform コンソール内で Red Hat Advanced Cluster Management にアクセスできます。

  1. プラグインを無効にするには、OpenShift Container Platform コンソールの Administrator パースペクティブにいることを確認してください。
  2. ナビゲーションで Administration を探し、Cluster Settings をクリックし、続いて Configuration タブをクリックします。
  3. Configuration resources のリストから、operator.openshift.io API グループが含まれる Console リソースをクリックします。この API グループには、Web コンソールのクラスター全体の設定が含まれています。
  4. Console plug-ins タブをクリックします。mce プラグインがリスト表示されます。注記: Red Hat Advanced Cluster Management がインストールされている場合は、acm としても表示されます。
  5. テーブルからプラグインのステータスを変更します。しばらくすると、コンソールを更新するように求められます。

1.1.4. ロールベースのアクセス制御

Kubernetes Operator のマルチクラスターエンジンは、ロールベースのアクセス制御 (RBAC) をサポートします。ロールによって実行できるアクションが決まります。RBAC は、Red Hat OpenShift Container Platform と同様に Kubernetes の承認メカニズムに基づいています。RBAC の詳細は、OpenShift Container Platform ドキュメント の OpenShift Container Platform RBAC の概要を参照してください。

注記: ユーザーロールのアクセス権がない場合には、コンソールのアクションボタンが無効になります。

コンポーネントでサポートされる RBAC の詳細は、以下のセクションを参照してください。

1.1.4.1. ロールの概要

クラスター別の製品リソースと、スコープに namespace が指定されている製品リソースがあります。アクセス制御に一貫性を持たせるため、クラスターのロールバインドと、namespace のロールバインドをユーザーに適用する必要があります。サポートされている次のロール定義の表リストを表示します。

1.1.4.1.1. ロール定義表
ロール定義

cluster-admin

これは OpenShift Container Platform のデフォルトのロールです。cluster-admin ロールへのクラスターバインディングがあるユーザーは、すべてのアクセス権限を持つ OpenShift Container Platform のスーパーユーザーです。

open-cluster-management:cluster-manager-admin

open-cluster-management:cluster-manager-admin ロールにクラスターをバインドするユーザーは、すべてのアクセス権を持つスーパーユーザーです。このロールを指定すると、ユーザーは ManagedCluster リソースを作成できます。

open-cluster-management:admin:<managed_cluster_name>

open-cluster-management:admin:<managed_cluster_name> ロールへのクラスターバインディングがあるユーザーには、managedcluster-<managed_cluster_name> という名前の ManagedCluster リソースに管理者アクセス権が付与されます。ユーザーにマネージドクラスターがある場合は、このロールが自動的に作成されます。

open-cluster-management:view:<managed_cluster_name>

open-cluster-management:view:<managed_cluster_name> ロールへのクラスターバインディングがあるユーザーには、managedcluster-<managed_cluster_name> という名前の ManagedCluster リソースの表示権限が付与されます。

open-cluster-management:managedclusterset:admin:<managed_clusterset_name>

open-cluster-management:managedclusterset:admin:<managed_clusterset_name> ロールへのクラスターバインドのあるユーザーには、<managed_clusterset_name> という名前の ManagedCluster リソースへの管理者アクセスがあります。また、ユーザーには managedcluster.cluster.open-cluster-management.ioclusterclaim.hive.openshift.ioclusterdeployment.hive.openshift.io および clusterpool.hive.openshift.io リソースへの管理者アクセスがあり、cluster.open-cluster-management.ioclusterset=<managed_clusterset_name> のマネージドクラスターセットのラベルが付いています。ロールバインドは、クラスターセットの使用時に自動的に生成されます。リソースの管理方法については、ManagedClusterSet の作成と管理 を参照してください。

open-cluster-management:managedclusterset:view:<managed_clusterset_name>

open-cluster-management:managedclusterset:view:<managed_clusterset_name> ロールへのクラスターバインディングがあるユーザーには、<managed_clusterset_name>` という名前の ManagedCluster リソースへの表示権限が付与されます。また、ユーザーには managedcluster.cluster.open-cluster-management.ioclusterclaim.hive.openshift.ioclusterdeployment.hive.openshift.io および clusterpool.hive.openshift.io リソースへの表示権限があり、cluster.open-cluster-management.ioclusterset=<managed_clusterset_name> のマネージドクラスターセットのラベルが付いています。マネージドクラスターセットリソースを管理する方法の詳細については、ManagedClusterSet の作成と管理 を参照してください。

admin、edit、view

admin、edit、および view は OpenShift Container Platform のデフォルトロールです。これらのロールに対して namespace に限定されたバインドが指定されているユーザーは、特定の namespace 内の open-cluster-management リソースにアクセスでき、同じロールに対してクラスター全体のバインドが指定されている場合には、クラスター全体の全 open-cluster-management リソースにアクセス権があります。

重要:

  • ユーザーは OpenShift Container Platform からプロジェクトを作成できます。これにより、namespace の管理者ロール権限が付与されます。
  • ユーザーにクラスターへのロールアクセスがない場合、クラスター名は表示されません。クラスター名は、- の記号で表示されます。

RBAC はコンソールレベルと API レベルで検証されます。コンソール内のアクションは、ユーザーのアクセスロールの権限に基づいて有効化/無効化できます。製品の特定ライフサイクルの RBAC の詳細は、以下のセクションを参照してください。

1.1.4.1.2. クラスターライフサイクル RBAC
  • すべてのマネージドクラスターを作成および管理するには、次の情報を参照してください。

    • 以下のコマンドを入力して、クラスターロール open-cluster-management:cluster-manager-admin にバインドするクラスターロールを作成します。

      oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin

      このロールはスーパーユーザーであるため、すべてのリソースとアクションにアクセスできます。このロールを使用すると、クラスターレベルの managedcluster リソース、マネージドクラスターを管理するリソースの namespace、namespace 内のリソースを作成できます。また、このロールで、プロバイダー接続、マネージドクラスター作成に使用するベアメタルアセットにアクセスできます。

  • cluster-name という名前のマネージドクラスターを管理するには、以下を参照してください。

    • 以下のコマンドを入力して、クラスターロール open-cluster-management:admin:<cluster-name> にバインドするクラスターロールを作成します。

      oc create clusterrolebinding (role-binding-name) --clusterrole=open-cluster-management:admin:<cluster-name>

      このロールを使用すると、クラスターレベルの managedcluster リソースに読み取り/書き込みアクセスができるようになります。managedcluster はクラスターレベルのリソースで、namespace レベルのリソースではないので、このロールが必要です。

    • 以下のコマンドを入力して、クラスターロール admin にバインドする namespace ロールを作成します。

      oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=admin

      このロールでは、マネージドクラスターの namespace 内にあるリソースに対して読み取り/書き込みアクセスができるようになります。

  • cluster-name という名前のマネージドクラスターを表示するには、以下を参照してください。

    • 以下のコマンドを入力して、クラスターロール open-cluster-management:view:<cluster-name> にバインドするクラスターロールを作成します。

      oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name>

      このロールを使用すると、クラスターレベルの managedcluster リソースに読み取りアクセスができるようになります。managedcluster はクラスターレベルのリソースで、namespace レベルのリソースではないので、このロールが必要です。

    • 以下のコマンドを入力して、クラスターロール view にバインドする namespace ロールを作成します。

      oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=view

      このロールでは、マネージドクラスターの namespace 内にあるリソースに対して読み取り専用アクセスができるようになります。

  • 以下のコマンドを入力して、アクセス可能なマネージドクラスターの一覧を表示します。

    oc get managedclusters.clusterview.open-cluster-management.io

    このコマンドは、クラスター管理者権限なしで、管理者およびユーザーが使用できます。

  • 以下のコマンドを入力して、アクセス可能なマネージドクラスターセットの一覧を表示します。

    oc get managedclustersets.clusterview.open-cluster-management.io

    このコマンドは、クラスター管理者権限なしで、管理者およびユーザーが使用できます。

1.1.4.1.2.1. クラスタープール RBAC

以下のクラスタープール RBAC 操作を確認してください。

  • クラスタープールのプロビジョニングクラスターを使用するには、以下を実行します。

    • クラスター管理者は、グループにロールを追加してマネージドクラスターセットを作成し、管理者権限をロールに付与します。

      • 以下のコマンドを使用して、server-foundation-clusterset マネージドクラスターセットに admin パーミッションを付与します。

        oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-admin:server-foundation-clusterset
        server-foundation-team-admin
      • 以下のコマンドを使用して、server-foundation-clusterset マネージドクラスターセットに view 権限を付与します。

        oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-view:server-foundation-clusterset server-foundation-team-user
    • クラスタープールの namespace (server-foundation-clusterpool) を作成します。

      • 以下のコマンドを実行して、server-foundation-team-adminserver-foundation-clusterpooladmin 権限を付与します。

        oc adm new-project server-foundation-clusterpool
        
        oc adm policy add-role-to-group admin server-foundation-team-admin --namespace  server-foundation-clusterpool
    • チーム管理者として、クラスタープール namespace に、クラスターセットラベル cluster.open-cluster-management.io/clusterset=server-foundation-clusterset を使用して ocp46-aws-clusterpool という名前のクラスタープールを作成します。

      • server-foundation-webhook は、クラスタープールにクラスターセットラベルがあるかどうか、またユーザーにクラスターセットのクラスタープールを作成するパーミッションがあるかどうかを確認します。
      • server-foundation-controller は、server-foundation-team-userserver-foundation-clusterpool namespace に view 権限を付与します。
    • クラスタープールが作成されると、クラスタープールは clusterdeployment を作成します。

      • server-foundation-controller は、server-foundation-team-adminclusterdeployment namespace に admin パーミッションを付与します。
      • server-foundation-controller は、server-foundation-team-userclusterdeployment namespace に view パーミッションを付与します。

        注記: team-admin および team-user は、clusterpoolclusterdeplyment および clusterclaim への admin 権限があります。

クラスターライフサイクルの以下のコンソールおよび API RBAC の表を表示します。

1.1.4.1.2.2. クラスターライフサイクルのコンソール RBAC の表
リソース管理編集表示

クラスター

read, update, delete

データなし

read

クラスターセット

get, update, bind, join

編集ロールなし

get

マネージドクラスター

read, update, delete

編集ロールなし

get

プロバイダー接続

create, read, update, delete

データなし

read

ベアメタルアセット

create, read, update, delete

データなし

read

1.1.4.1.2.3. クラスターライフサイクルの RBAC API テーブルのテーブル
API管理編集表示

managedclusters.cluster.open-cluster-management.io (この API のコマンドでは mcl (単数) または mcls (複数) を使用できます。)

create, read, update, delete

read, update

read

managedclusters.view.open-cluster-management.io (この API のコマンドでは mcv (単数) または mcvs (複数) を使用できます。)

read

read

read

managedclusters.register.open-cluster-management.io/accept

update

update

none

managedclusterset.cluster.open-cluster-management.io (この API のコマンドでは mclset (単数) または mclsets (複数) を使用できます。)

create, read, update, delete

read, update

read

managedclustersets.view.open-cluster-management.io

read

read

read

managedclustersetbinding.cluster.open-cluster-management.io (この API のコマンドでは mclsetbinding (単数) または mclsetbindings (複数) を使用できます。)

create, read, update, delete

read, update

read

baremetalassets.inventory.open-cluster-management.io

create, read, update, delete

read, update

read

klusterletaddonconfigs.agent.open-cluster-management.io

create, read, update, delete

read, update

read

managedclusteractions.action.open-cluster-management.io

create, read, update, delete

read, update

read

managedclusterviews.view.open-cluster-management.io

create, read, update, delete

read, update

read

managedclusterinfos.internal.open-cluster-management.io

create, read, update, delete

read, update

read

manifestworks.work.open-cluster-management.io

create, read, update, delete

read, update

read

submarinerconfigs.submarineraddon.open-cluster-management.io

create, read, update, delete

read, update

read

placements.cluster.open-cluster-management.io

create, read, update, delete

read, update

read

1.1.4.1.2.4. 認証情報ロールベースのアクセス制御

認証情報へのアクセスは Kubernetes で制御されます。認証情報は Kubernetes Secret として保存され、セキュリティーを確保します。シークレットへのアクセスには、次のアクセス許可が適用されます。

  • namespace でシークレットの作成権限のあるユーザーは認証情報を作成できます。
  • namespace でシークレットの読み取り権限のあるユーザーは、認証情報を表示することもできます。
  • Kubernetes ロール admin および edit のあるユーザーは、シークレットの作成と編集が可能です。
  • Kubernetes クラスターロール view のあるユーザーは、シークレットの内容を読み取ると、サービスアカウントの認証情報にアクセスできるようになるため、シークレットを表示できません。

1.2. インストール

Kubernetes Operator のマルチクラスターエンジンは、クラスターフリート管理を強化するソフトウェア Operator です。Kubernetes Operator 用のマルチクラスターエンジンは、Red Hat OpenShift Container Platform と、クラウドおよびデータセンター全体の Kubernetes クラスターライフサイクル管理をサポートします。

以下のドキュメントを参照してください。

1.2.1. ネットワーク接続時のオンラインインストール

Kubernetes Operator 用のマルチクラスターエンジンは、Operator Lifecycle Manager とともにインストールされます。このマネージャーは、Kubernetes Operator 用のマルチクラスターエンジンを含むコンポーネントのインストール、アップグレード、および削除を管理します。

必要なアクセス権限: クラスターの管理者

重要:

  • 2.5 より前の Red Hat Advanced Cluster Management for Kubernetes がインストールされていないクラスターには、Kubernetes Operator 用のマルチクラスターエンジンをインストールする必要があります。Kubernetes Operator 用のマルチクラスターエンジンは、同じ管理コンポーネントの一部を提供するため、2.5 より前のバージョンでは Red Hat Advanced Cluster Management for Kubernetes と共存できません。これまで Red Hat Advanced Cluster Management をインストールしたことがないクラスターに Kubernetes Operator 用のマルチクラスターエンジンをインストールすることが推奨されます。バージョン 2.5 以降で Red Hat Advanced Cluster Management for Kubernetes を使用している場合、Kubernetes Operator 用のマルチクラスターエンジンはすでにクラスターにインストールされています。
  • OpenShift Container Platform 専用環境の場合は、cluster-admin 権限が必要です。デフォルトで、dedicated-admin ロールには OpenShift Container Platform Dedicated 環境で namespace を作成するために必要なパーミッションがありません。
  • デフォルトでは、Kubernetes Operator コンポーネント用のマルチクラスターエンジンは、追加の設定なしで OpenShift Container Platform クラスターのワーカーノードにインストールされます。OpenShift Container Platform OperatorHub Web コンソールインターフェイスまたは OpenShift Container Platform CLI を使用して、Kubernetes Operator 用のマルチクラスターエンジンをワーカーノードにインストールできます。
  • OpenShift Container Platform クラスターをインフラストラクチャーノードで設定した場合は、OpenShift Container Platform CLI と追加のリソースパラメーターを使用して、Kubernetes Operator 用のマルチクラスターエンジンをそれらのインフラストラクチャーノードにインストールできます。Kubernetes Operator コンポーネント用のすべてのマルチクラスターエンジンがインフラストラクチャーノードをサポートしているわけではないため、インフラストラクチャーノードに Kubernetes Operator 用マルチクラスターエンジンをインストールする場合は、一部のワーカーノードが必要です。詳細は、インフラストラクチャーノードへのマルチクラスターエンジンのインストール セクションを参照してください。
  • OpenShift Container Platform または Kubernetes のマルチクラスターエンジンによって作成されていない Kubernetes クラスターをインポートする場合は、イメージプルシークレットを設定する必要があります。イメージプルシークレットおよびその他の高度な設定方法については、このドキュメントの 詳細設定 セクションのオプションを参照してください。

1.2.1.1. 前提条件

Kubernetes 用のマルチクラスターエンジンをインストールする前に、次の要件を確認してください。

  • RedHat OpenShift Container Platform クラスターは、OpenShift Container Platform コンソールから OperatorHub カタログにある Kubernetes Operator のマルチクラスターエンジンにアクセスできるようにしている。
  • catalog.redhat.com へのアクセスがある。
  • お使いの環境に OpenShift Container Platform バージョン 4.8 以降をデプロイし、OpenShift Container Platform CLI でログインしている。以下の OpenShift Container Platform のインストールドキュメントを参照してください。

  • OpenShift Container Platform のコマンドラインインターフェイス (CLI) は、oc コマンドを実行できるように設定している。Red Hat OpenShift CLI のインストールおよび設定の詳細は、CLI の使用方法 を参照してください。
  • namespace の作成が可能な OpenShift Container Platform の権限を設定している。
  • operator の依存関係にアクセスするには、インターネット接続が必要。
  • OpenShift Container Platform Dedicated 環境にインストールするには、以下を参照してください。

    • OpenShift Container Platform Dedicated 環境が設定され、実行している。
    • エンジンのインストール先の OpenShift Container Platform Deplicated 環境での cluster-admin がある。
  • Red Hat OpenShift Container Platform で提供される Assisted Installer を使用してマネージドクラスターを作成する予定の場合は、OpenShift Container Platform ドキュメントの アシステッドインストーラーを使用したインストールの準備 トピックを参照してください。

1.2.1.2. OpenShift Container Platform インストールの確認

レジストリー、ストレージサービスなど、サポート対象の OpenShift Container Platform バージョンがインストールされ、機能する状態である必要があります。OpenShift Container Platform のインストールの詳細は、OpenShift Container Platform のドキュメントを参照してください。

  1. Kubernetes Operator 用のマルチクラスターエンジンが OpenShift Container Platform クラスターにインストールされていないことを確認します。Kubernetes Operator 用のマルチクラスターエンジンでは、OpenShift Container Platform クラスターごとに 1 つのインストールのみが許可されます。インストールがない場合は、次の手順に進みます。
  2. OpenShift Container Platform クラスターが正しく設定されていることを確認するには、以下のコマンドを使用して OpenShift Container Platform Web コンソールにアクセスします。

    kubectl -n openshift-console get route console

    以下の出力例を参照してください。

    console console-openshift-console.apps.new-coral.purple-chesterfield.com
    console   https   reencrypt/Redirect     None
  3. ブラウザーで URL を開き、結果を確認します。コンソール URL の表示が console-openshift-console.router.default.svc.cluster.local の場合は、Red Hat OpenShift Container Platform のインストール時に openshift_master_default_subdomain を設定します。https://console-openshift-console.apps.new-coral.purple-chesterfield.com の例を参照してください。

Kubernetes Operator 用のマルチクラスターエンジンのインストールに進むことができます。

1.2.1.3. OperatorHub Web コンソールインターフェイスからのインストール

ベストプラクティス: OpenShift Container Platform ナビゲーションの Administrator ビューから、OpenShift Container Platform で提供される OperatorHub Web コンソールインターフェイスをインストールします。

  1. Operators > OperatorHub を選択して利用可能な operator のリストにアクセスし、multicluster engine for Kubernetes operator を選択します。
  2. Install をクリックします。
  3. Operator Installation ページで、インストールのオプションを選択します。

    • Namespace:

      • Kubernetes Operator エンジンのマルチクラスターエンジンは、独自の namespace またはプロジェクトにインストールする必要があります。
      • デフォルトでは、OperatorHub コンソールのインストールプロセスにより、multicluster-engine という名前の namespace が作成されます。ベストプラクティス: multicluster-engine namespace が使用可能な場合は、引き続き使用します。
      • multicluster-engine という名前の namespace が存在する場合は、別の namespace を選択してください。
    • チャネル: インストールするリリースに対応するチャネルを選択します。チャネルを選択すると、指定のリリースがインストールされ、そのリリース内の今後のエラータ更新が取得されます。
    • 承認ストラテジー: 承認ストラテジーでは、サブスクライブ先のチャネルまたはリリースに更新を適用するのに必要な人の間のやり取りを特定します。

      • そのリリース内の更新が自動的に適用されるようにするには、デフォルトで選択されている Automatic を選択します。
      • Manual を選択して、更新が利用可能になると通知を受け取ります。更新がいつ適用されるかについて懸念がある場合は、これがベストプラクティスになる可能性があります。

    注記: 次のマイナーリリースにアップグレードするには、OperatorHub ページに戻り、最新リリースの新規チャネルを選択する必要があります。

  4. Install を選択して変更を適用し、Operator を作成します。
  5. MultiClusterEngine カスタムリソースを作成するには、次のプロセスを参照してください。

    1. OpenShift Container Platform コンソールナビゲーションで、Installed Operators > multicluster engine for Kubernetes を選択します。
    2. MultiCluster Engine タブを選択します。
    3. Create MultiClusterEngine を選択します。
    4. YAML ファイルのデフォルト値を更新します。このドキュメントの MultiClusterEngine advanced configuration のオプションを参照してください。

      • 次の例は、エディターにコピーできるデフォルトのテンプレートを示しています。
      apiVersion: multicluster.openshift.io/v1
      kind: MultiClusterEngine
      metadata:
        name: multiclusterengine
      spec: {}
  6. Create を選択して、カスタムリソースを初期化します。Kubernetes Operator エンジン用のマルチクラスターエンジンがビルドされて起動するまで、最大 10 分かかる場合があります。

    MultiClusterEngine リソースが作成されると、リソースのステータスが MultiCluster Engine タブで Available になります。

1.2.1.4. OpenShift Container Platform CLI からのインストール

  1. Operator 要件が含まれている Kubernetes Operator エンジン namespace 用のマルチクラスターエンジンを作成します。次のコマンドを実行します。ここで、namespace は、Kubernetes エンジン namespace のマルチクラスターエンジンの名前です。namespace の値は、OpenShift Container Platform 環境では プロジェクト と呼ばれる場合があります。

    oc create namespace <namespace>
  2. プロジェクトの namespace を、作成した namespace に切り替えます。namespace は、手順 1 で作成した Kubernetes エンジン用のマルチクラスターエンジンの namespace の名前に置き換えてください。

    oc project <namespace>
  3. OperatorGroup リソースを設定するために YAML ファイルを作成します。namespace ごとに割り当てることができる Operator グループ は 1 つだけです。default はお使いの operator グループ名に置き換えます。namespace はお使いのプロジェクトの namespace 名に置き換えます。以下の例を参照してください。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: <default>
    spec:
      targetNamespaces:
      - <namespace>
  4. 以下のコマンドを実行して OperatorGroup リソースを作成します。operator-group は、作成した operator グループの YAML ファイル名に置き換えます。

    oc apply -f <path-to-file>/<operator-group>.yaml
  5. OpenShift Container Platform サブスクリプションを設定するための YAML ファイルを作成します。ファイルは以下の例のようになります。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: multicluster-engine
    spec:
      sourceNamespace: openshift-marketplace
      source: redhat-operators
      channel: stable-2.1
      installPlanApproval: Automatic
      name: multicluster-engine

    注記: インフラストラクチャーノードに Kubernetes エンジン用のマルチクラスターエンジンをインストールする場合は、Operator Lifecycle Manager サブスクリプションの追加設定 セクションを参照してください。

  6. 以下のコマンドを実行して OpenShift Container Platform サブスクリプションを作成します。subscription は、作成したサブスクリプションファイル名に置き換えます。

    oc apply -f <path-to-file>/<subscription>.yaml
  7. YAML ファイルを作成して、MultiClusterEngine カスタムリソースを設定します。デフォルトのテンプレートは、以下の例のようになります。

    apiVersion: multicluster.openshift.io/v1
    kind: MultiClusterEngine
    metadata:
      name: multiclusterengine
    spec: {}

    注記: インフラストラクチャーノードに Kubernetes Operator 用のマルチクラスターエンジンをインストールするには、MultiClusterEngine カスタムリソースの追加設定 セクションを参照してください。

  8. 次のコマンドを実行して、MultiClusterEngine カスタムリソースを作成します。custom-resource は、カスタムリソースファイル名に置き換えます。

    oc apply -f <path-to-file>/<custom-resource>.yaml

    以下のエラーで、この手順に失敗した場合でも、リソースは作成され、適用されます。リソースが作成されてから数分後にもう一度コマンドを実行します。

    error: unable to recognize "./mce.yaml": no matches for kind "MultiClusterEngine" in version "operator.multicluster-engine.io/v1"
  9. 以下のコマンドを実行してカスタムリソースを編集します。次のコマンドを実行した後、MultiClusterEngine カスタムリソースステータスが status.phase フィールドに Available として表示されるまでに最大 10 分かかる場合があります。

    oc get mce -o=jsonpath='{.items[0].status.phase}'

Kubernetes Operator 用のマルチクラスターエンジンを再インストールしても、Pod が起動しない場合は、この問題を回避する手順について、再インストールに失敗する場合のトラブルシューティング を参照してください。

注記:

  • ClusterRoleBinding を使用する ServiceAccount は、クラスター管理者特権を Kubernetes Operator のマルチクラスターエンジンと、Kubernetes Operator のマルチクラスターエンジンをインストールする namespace にアクセスできるすべてのユーザー認証情報に自動的に付与します。

1.2.1.5. インフラストラクチャーノードへのインストール

OpenShift Container Platform クラスターを、承認された管理コンポーネントを実行するためのインフラストラクチャーノードを組み込むように設定できます。インフラストラクチャーノードでコンポーネントを実行すると、それらの管理コンポーネントを実行しているノードの OpenShift Container Platform サブスクリプションクォータの割り当てる必要がなくなります。

OpenShift Container Platform クラスターにインフラストラクチャーノードを追加した後に、OpenShift Container Platform CLI からのインストール 手順に従い、以下の設定を Operator Lifecycle Manager サブスクリプションおよび MultiClusterEngine カスタムリソースに追加します。

1.2.1.5.1. インフラストラクチャーノードを OpenShift Container Platform クラスターに追加する

OpenShift Container Platform ドキュメントの インフラストラクチャーマシンセットの作成 で説明されている手順に従います。インフラストラクチャーノードは、Kubernetes の taint および label で設定され、管理以外のワークロードがそれらで稼働し続けます。

Kubernetes Operator のマルチクラスターエンジンによって提供されるインフラストラクチャーノードの有効化と互換性を持たせるには、インフラストラクチャーノードに次の taintlabel が適用されていることを確認してください。

metadata:
  labels:
    node-role.kubernetes.io/infra: ""
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
1.2.1.5.2. Operator Lifecycle Manager サブスクリプションの追加設定

Operator Lifecycle Manager サブスクリプションを適用する前に、以下の追加設定を追加します。

spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
    - key: node-role.kubernetes.io/infra
      effect: NoSchedule
      operator: Exists
1.2.1.5.3. MultiClusterEngine カスタムリソースの追加設定

MultiClusterEngine カスタムリソースを適用する前に、以下の設定を追加します。

spec:
  nodeSelector:
    node-role.kubernetes.io/infra: ""

1.2.2. ネットワーク切断状態でのインストール

インターネットに接続されていない Red Hat OpenShift Container Platform クラスターに Kubernetes Operator 用のマルチクラスターエンジンをインストールする必要がある場合があります。ネットワーク接続のないエンジンにインストールする手順でも一部、オンラインインストールと同じ手順が必要になります。

重要: 2.5 より前の Red Hat Advanced Cluster Management for Kubernetes がインストールされていないクラスターには、Kubernetes Operator 用のマルチクラスターエンジンをインストールする必要があります。Kubernetes Operator 用のマルチクラスターエンジンは、同じ管理コンポーネントの一部を提供するため、2.5 より前のバージョンでは Red Hat Advanced Cluster Management for Kubernetes と共存できません。これまで Red Hat Advanced Cluster Management をインストールしたことがないクラスターに Kubernetes Operator 用のマルチクラスターエンジンをインストールすることが推奨されます。バージョン 2.5.0 以降で Red Hat Advanced Cluster Management for Kubernetes を使用している場合、Kubernetes Operator 用のマルチクラスターエンジンはすでにクラスターにインストールされています。

インストール時にネットワークから直接パッケージにアクセスするのではなく、パッケージをダウンロードしておき、インストール時にアクセスできるようにする必要があります。

1.2.2.1. 前提条件

Kubernetes Operator 用のマルチクラスターエンジンをインストールする前に、次の要件を満たしている必要があります。

  • お使いの環境に Red Hat OpenShift Container Platform バージョン 4.8 以降をインストールし、コマンドラインインターフェイス (CLI) でログインしている。
  • catalog.redhat.com にアクセスできる。

    注記: ベアメタルクラスターを管理する場合は、Red Hat OpenShift Container Platform バージョン 4.8 以降が必要です。

    OpenShift Container Platform version 4.10OpenShift Container Platform version 4.8 を参照してください。

  • Red Hat OpenShift Container Platform の CLI バージョンは 4.8 以降を使用し、oc コマンドを実行できるように設定している。Red Hat OpenShift CLI のインストールおよび設定の詳細は、CLI の使用方法 を参照してください。
  • namespace の作成が可能な Red Hat OpenShift Container Platform の権限を設定している。
  • Operator の依存関係をダウンロードするために、インターネット接続のあるワークステーションが必要。

1.2.2.2. OpenShift Container Platform インストールの確認

  • レジストリー、ストレージサービスなど、サポート対象の OpenShift Container Platform バージョンがクラスターにインストールされ、機能する状態である必要があります。OpenShift Container Platform バージョン 4.8 の詳細は、OpenShift Container Platform documentation を参照してください。
  • 接続されている場合は、以下のコマンドを使用して OpenShift Container Platform Web コンソールにアクセスすることにより、OpenShift Container Platform クラスターが正しく設定されていることを確認できます。

    kubectl -n openshift-console get route console

    以下の出力例を参照してください。

    console console-openshift-console.apps.new-coral.purple-chesterfield.com
    console   https   reencrypt/Redirect     None

    この例のコンソール URL は https:// console-openshift-console.apps.new-coral.purple-chesterfield.com です。ブラウザーで URL を開き、結果を確認します。

    コンソール URL の表示が console-openshift-console.router.default.svc.cluster.local の場合は、Red Hat OpenShift Container Platform のインストール時に openshift_master_default_subdomain を設定します。

1.2.2.3. 非接続環境でのインストール

重要: 必要なイメージをミラーリングレジストリーにダウンロードし、非接続環境で Operator をインストールする必要があります。ダウンロードがないと、デプロイメント時に ImagePullBackOff エラーが表示される可能性があります。

次の手順に従って、切断された環境に Kubernetes Operator 用のマルチクラスターエンジンをインストールします。

  1. ミラーレジストリーを作成します。ミラーレジストリーがまだない場合は、Red Hat OpenShift Container Platform ドキュメントの 非接続インストールのミラーリング の手順を実行してミラーレジストリーを作成してください。

    ミラーレジストリーがすでにある場合は、既存のレジストリーを設定して使用できます。

  2. 注記: ベアメタルの場合のみ、install-config.yaml ファイルに、接続なしのレジストリーの証明書情報を指定する必要があります。保護された切断されたレジストリー内のイメージにアクセスするには、Kubernetes Operator のマルチクラスターエンジンがレジストリーにアクセスできるように、証明書情報を提供する必要があります。

    1. レジストリーから証明書情報をコピーします。
    2. エディターで install-config.yaml ファイルを開きます。
    3. additionalTrustBundle: | のエントリーを検索します。
    4. additionalTrustBundle の行の後に証明書情報を追加します。追加後の内容は以下の例のようになります。

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        certificate_content
        -----END CERTIFICATE-----
      sshKey: >-
  3. 重要: 以下のガバナンスポリシーが必要な場合は、非接続イメージレジストリーの追加ミラーが必要です。

    • Container Security Operator ポリシー: イメージはソース registry.redhat.io/quay にあります。
    • Compliance Operator ポリシー: イメージはソース registry.redhat.io/compliance にあります。
    • 非推奨 Gatekeeper Operator ポリシー: イメージはソース registry.redhat.io/rhacm2 にあります。

      Gatekeeper Operator は、Gatekeeper コミュニティーの取り組みおよびリリースに合わせて非推奨になりました。代わりにサブスクリプションでインストールしてください。

      3 つのすべての Operator については、以下のミラー一覧を参照してください。

        - mirrors:
          - <your_registry>/rhacm2
          source: registry.redhat.io/rhacm2
        - mirrors:
          - <your_registry>/quay
          source: registry.redhat.io/quay
        - mirrors:
          - <your_registry>/compliance
          source: registry.redhat.io/compliance
  4. install-config.yaml ファイルを保存します。
  5. mce-policy.yaml という名前の ImageContentSourcePolicy を含む YAML ファイルを作成します。注記: 実行中のクラスターでこれを変更すると、すべてのノードのローリング再起動が実行されます。

    apiVersion: operator.openshift.io/v1alpha1
    kind: ImageContentSourcePolicy
    metadata:
      name: mce-repo
    spec:
      repositoryDigestMirrors:
      - mirrors:
        - mirror.registry.com:5000/multicluster-engine
        source: registry.redhat.io/multicluster-engine
  6. 以下のコマンドを入力して ImageContentSourcePolicy ファイルを適用します。

    oc apply -f mce-policy.yaml
  7. ネットワーク接続されていない Operator Lifecycle Manager の Red Hat Operator と コミュニティーの Operator を有効にします。

    Kubernetes Operator 用のマルチクラスターエンジンは、Operator Lifecycle Manager Red Hat カタログに含まれています。

  8. Red Hat Operator カタログの非接続 Operator Lifecycle Manager を設定します。Red Hat OpenShift Container Platform ドキュメントの ネットワークが制限された環境での Operator Lifecycle Manager の使用 の手順を実行します。
  9. 切断された Operator Lifecycle Manager にイメージが作成されたので、引き続き、Operator Lifecycle Manager カタログから Kubernetes 用の Kubernetes Operator 用のマルチクラスターエンジンをインストールします。

必要な手順については、ネットワーク接続時のオンラインインストール を参照してください。

1.2.3. 詳細設定

Kubernetes Operator のマルチクラスターエンジンは、必要なすべてのコンポーネントをデプロイする Operator を使用してインストールされます。Kubernetes Operator のマルチクラスターエンジンは、インストール中またはインストール後に、MultiClusterEngine カスタムリソースに次の属性の 1 つ以上を追加することでさらに設定できます。

1.2.3.1. ローカルクラスターの有効化

マネージド ハブクラスターの名前は local-cluster です。ハブクラスターがそれ自体を管理するようにする場合は、spec. disableHubSelfManagement の設定を true に変更して、既存のクラスターを local-cluster としてインポートする必要があります。

この設定が、カスタムリソースを定義する YAML ファイルに含まれていない場合は、これを追加する必要があります。ハブクラスターは、このオプションでのみ管理できます。

  1. 使用するデフォルトのテンプレートの次の例のような import-hub.yaml という名前の YAML ファイルを作成します。namespace はお使いのプロジェクト名に置き換えます。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      labels:
        local-cluster: "true"
        cloud: auto-detect
        vendor: auto-detect
      name: local-cluster
    spec:
      hubAcceptsClient: true
      leaseDurationSeconds: 60
  2. 次のコマンドを実行して、ファイルを適用します。

    oc apply -f import-hub.yaml

自己管理されるハブクラスターは、クラスターの一覧で local-cluster として指定されます。

1.2.3.2. カスタムイメージプルシークレット

OpenShift Container Platform または Kubernetes Operator 用のマルチクラスターエンジンによって作成されていない Kubernetes クラスターをインポートする場合は、OpenShift Container Platform プルシークレット情報を含むシークレットを生成して、ディストリビューションレジストリーから資格のあるコンテンツにアクセスします。

OpenShift Container Platform クラスターのシークレット要件は、OpenShift Container Platform および multicluster engine for Kubernetes により自動で解決されるため、他のタイプの Kubernetes クラスターをインポートして管理しない場合には、このシークレットを作成する必要はありません。

重要: これらのシークレットは namespace に依存するため、エンジンに使用する namespace にいることを確認してください。

  1. cloud.redhat.com/openshift/install/pull-secret から Download pull secret を選択して、OpenShift Container Platform のプルシークレットファイルをダウンロードします。OpenShift Container Platform プルシークレットは Red Hat カスタマーポータル ID に関連しており、すべての Kubernetes プロバイダーで同じです。
  2. 以下のコマンドを実行してシークレットを作成します。

    oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
    • secret は作成するシークレット名に置き換えます。
    • シークレットは namespace 固有であるため、namespace はプロジェクトの namespace に置き換えます。
    • path-to-pull-secret はダウンロードした OpenShift Container Platform のプルシークレットへのパスに置き換えます。

以下の例では、カスタムプルシークレットを使用する場合に使用する spec.imagePullSecret テンプレートを表示しています。secret は、プルシークレット名に置き換えます。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  imagePullSecret: <secret>

1.2.3.3. ターゲット namespace

MultiClusterEngine カスタムリソースで場所を指定することにより、指定された namespace にオペランドをインストールできます。この namespace は、MultiClusterEngine カスタムリソースの適用時に作成されます。

重要: ターゲット namespace が指定されていない場合、Operator は multicluster-engine namespace にインストールし、MultiClusterEngine カスタムリソース仕様で設定します。

次の例は、ターゲット namespace を指定するために使用できる spec.targetNamespace テンプレートを示しています。target を宛先 namespace の名前に置き換えます。注記: target namespace を default namespace にすることはできません。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  targetNamespace: <target>

1.2.3.4. availabilityConfig

ハブクラスターには、HighBasic の 2 つの可用性があります。デフォルトでは、ハブクラスターには High の可用性があります。これにより、ハブクラスターコンポーネントに replicaCount 2 が提供されます。これにより、フェイルオーバー時のサポートが向上しますが、Basic 可用性よりも多くのリソースを消費します。これにより、コンポーネントには replicaCount 1 が提供されます。

以下の例は、Basic の可用性のある spec.availabilityConfig テンプレートを示しています。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  availabilityConfig: "Basic"

1.2.3.5. nodeSelector

MultiClusterEngine でノードセレクターのセットを定義して、クラスター上の特定のノードにインストールできます。次の例は、ラベル node-role.kubernetes.io/infra を持つノードに Pod を割り当てる spec.nodeSelector を示しています。

spec:
  nodeSelector:
    node-role.kubernetes.io/infra: ""

1.2.3.6. Toleration

許容範囲のリストを定義して、MultiClusterEngine がクラスターで定義された特定の taint を許容できるようにすることができます。以下の例は、node-role.kubernetes.io/infra Taint に一致する spec.tolerations を示しています。

spec:
  tolerations:
  - key: node-role.kubernetes.io/infra
    effect: NoSchedule
    operator: Exists

以前の infra-node Toleration は、設定に Toleration を指定せずにデフォルトで Pod に設定されます。設定で許容値をカスタマイズすると、このデフォルトの動作が置き換えられます。

1.2.3.7. ManagedServiceAccount アドオン (テクノロジープレビュー)

デフォルトでは、Managed-ServiceAccount アドオンは無効になっています。このコンポーネントを有効にすると、マネージドクラスターでサービスアカウントを作成または削除できます。このアドオンを有効にしてインストールするには、spec.overridesMultiClusterEngine 仕様に以下を含めます。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: managedserviceaccount-preview
      enabled: true

Managed-ServiceAccount アドオンは、MultiClusterEngine の作成後に、コマンドラインでリソースを編集し、managedserviceaccount-preview コンポーネントを enabled: true に設定することで有効にできます。または、次のコマンドを実行して、<multiclusterengine-name> を MultiClusterEngine リソースの名前に置き換えることもできます。

oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"managedserviceaccount-preview","enabled":true}}]'

1.2.3.8. hypershift アドオン (テクノロジープレビュー)

デフォルトでは、Hypershift アドオンは無効になっています。このアドオンを有効にしてインストールするには、spec.overridesMultiClusterEngine 値に以下を含めます。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: hypershift-preview
      enabled: true

Hypershift アドオンは、MultiClusterEngine の作成後に、コマンドラインでリソースを編集し、hypershift-preview コンポーネントを enabled: true に設定することで有効にできます。または、次のコマンドを実行して、<multiclusterengine-name> を MultiClusterEngine リソースの名前に置き換えることもできます。

oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"hypershift-preview","enabled":true}}]'

1.2.4. アンインストール

Kubernetes のマルチクラスターエンジンをアンインストールすると、プロセスの 2 つの異なるレベルが表示されます。custom resource removalcomplete operator uninstall です。アンインストールプロセスの完了に最長 5 分かかる可能性があります。

  • カスタムリソースの削除は、最も基本的なアンインストールの種類で、MultiClusterEngine インスタンスのカスタムリソースを削除しますが、他の必要なコンポーネントが残されたままになります。このレベルのアンインストールは、同じ設定とコンポーネントを使用して再インストールする予定の場合に役立ちます。
  • 2 番目のレベルは、より完全なアンインストールで、カスタムリソース定義などのコンポーネントを除き、ほとんどの Operator コンポーネントを削除します。この手順を続行すると、カスタムリソースの削除で削除されていないコンポーネントおよびサブスクリプションがすべて削除されます。アンインストールが済むと、カスタムリソースの前に Operator を再インストールする必要があります。

1.2.4.1. 前提条件: 有効化されたサービスのデタッチ

Kubernetes エンジンのマルチクラスターエンジンをアンインストールする前に、そのエンジンによって管理されているすべてのクラスターをデタッチする必要があります。エラーを回避するには、エンジンによって管理されているすべてのクラスターをデタッチしてから、アンインストールを再試行してください。

  • マネージドクラスターがアタッチされている場合は、以下のメッセージが表示される可能性があります。

    Cannot delete MultiClusterEngine resource because ManagedCluster resource(s) exist

    クラスターのデタッチの詳細は、クラスターの作成 でお使いのプロバイダーの情報を選択して、マネージメントからのクラスターの削除 セクションを参照してください。

1.2.4.2. コマンドを使用したリソースの削除

  1. まだの場合には、oc コマンドが実行できるように、OpenShift Container Platform CLI が設定されていることを確認してください。oc コマンドの設定方法は、Red Hat OpenShift Container Platform ドキュメントの OpenShift CLI の使用方法 を参照してください。
  2. 以下のコマンドを入力してプロジェクトの namespace に移動します。namespace はお使いのプロジェクトの namespace 名に置き換えます。

    oc project <namespace>
  3. 次のコマンドを入力して、MultiClusterEngine カスタムリソースを削除します。

    oc delete multiclusterengine --all

    以下のコマンドを入力して進捗を表示できます。

    oc get multiclusterengine -o yaml
  4. 以下のコマンドを入力し、インストールされている namespace の multicluster-engine ClusterServiceVersion を削除します。
❯ oc get csv
NAME                         DISPLAY                              VERSION   REPLACES   PHASE
multicluster-engine.v2.0.0   multicluster engine for Kubernetes   2.0.0                Succeeded

❯ oc delete clusterserviceversion multicluster-engine.v2.0.0
❯ oc delete sub multicluster-engine

ここに表示されている CSV バージョンは異なる場合があります。

1.2.4.3. コンソールを使用したコンポーネントの削除

Red Hat OpenShift Container Platform コンソールを使用してアンインストールする場合に、operator を削除します。コンソールを使用してアンインストールを行うには、以下の手順を実行します。

  1. OpenShift Container Platform コンソールナビゲーションで、Operators > Installed Operators > multicluster engine for Kubernetes を選択します。
  2. MultiClusterEngine カスタムリソースを削除します。

    1. Multiclusterengine のタブを選択します。
    2. MultiClusterEngine カスタムリソースの Options メニューを選択します。
    3. Delete MultiClusterEngine を選択します。
  3. 次のセクションの手順に従って、クリーンアップスクリプトを実行します。

    ヒント: Kubernetes バージョンで同じマルチクラスターエンジンを再インストールする場合は、この手順の残りの手順をスキップして、カスタムリソースを再インストールできます。

  4. Installed Operators に移動します。
  5. Options メニューから Uninstall operator を選択して、_ multicluster engine for Kubernetes_ Operator を削除してください。

1.2.4.4. トラブルシューティングアンインストール

マルチクラスターエンジンのカスタムリソースが削除されていない場合は、クリーンアップスクリプトを実行して、残っている可能性のあるアーティファクトをすべて削除します。

  1. 以下のスクリプトをファイルにコピーします。

    #!/bin/bash
    oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
    oc delete validatingwebhookconfiguration multiclusterengines.multicluster.openshift.io
    oc delete mce --all

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html/installing/disconnected-installation-mirroring

1.3. 認証情報の管理

クラスターの認証情報を作成して管理できます。Kubernetes Operator 用のマルチクラスターエンジンを備えたクラウドサービスプロバイダーで Red Hat OpenShift Container Platform クラスターを作成するには、認証情報 が必要です。認証情報では、クラウドプロバイダーのアクセス情報を保存します。1 つのプロバイダーのドメインごとに独自の認証情報が必要になるのと同様に、プロバイダーアカウントごとに独自の認証情報が必要です。

認証情報は Kubernetes Secret として保存されます。シークレットはマネージドクラスターの namespace にコピーされ、マネージドクラスターのコントローラーがシークレットにアクセスできるようになります。認証情報が更新されると、シークレットのコピーはマネージドクラスターの namespace で自動的に更新されます。

注記: 元の認証情報を使用してすでにプロビジョニングされているため、クラウドプロバイダーの認証情報のプルシークレットまたは SSH キーへの変更は、既存のマネージドクラスターに反映されません。

必要なアクセス権限: 編集

1.3.1. Amazon Web Services の認証情報の作成

Amazon Web Services (AWS) で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、Kubernetes Operator コンソール用のマルチクラスターエンジンを使用するための認証情報が必要です。

必要なアクセス権限: 編集

注意: この手順は、Kubernetes Operator 用のマルチクラスターエンジンを使用してクラスターを作成する前に実行する必要があります。

1.3.1.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジン
  • Amazon Web Services (AWS) で Kubernetes クラスターを作成できるように、Kubernetes Operator ハブクラスター用のマルチクラスターエンジンのインターネットアクセス
  • アクセスキー ID およびシークレットアクセスキーなど、AWS のログイン認証情報。Understanding and getting your AWS credentials を参照してください。
  • AWS でクラスターをインストールできるようにするアカウントの権限。設定の方法は、AWS アカウントの設定 を参照してください。

1.3.1.2. コンソールを使用した認証情報の管理

Kubernetes Operator コンソール用のマルチクラスターエンジンから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。

  1. AWS アカウントの AWS アクセスキー ID を追加します。AWS にログインして ID を見つけます。
  2. 新しい AWS Secret Access Key の内容を提供します。
  3. プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。
  4. Red Hat OpenShift pull secret を入力します。Pull secret からプルシークレットをダウンロードします。
  5. SSH 秘密鍵SSH 公開鍵 を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。

キー生成の方法は、SSH プライベートキーの生成およびエージェントへの追加 を参照してください。

Amazon Web Services でのクラスターの作成 の手順を完了することで、この認証情報を使用するクラスターを作成できます。

コンソールで認証情報を編集できます。このプロバイダー接続を使用してクラスターが作成された場合には、<cluster-namespace> からの <cluster-name>-aws-creds> シークレットが新規の認証情報に更新されます。

注記: クラスタープールが要求したクラスターでは、認証情報は更新されません。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.3.1.3. API を使用した不透明なシークレットの作成

API を使用して Amazon Web Services の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-aws-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    aws_access_key_id: $(echo -n "${AWS_KEY}" | base64 -w0)
    aws_secret_access_key: $(echo -n "${AWS_SECRET}" | base64 -w0)

注記: 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。

1.3.2. Microsoft Azure の認証情報の作成

Microsoft Azure または Microsoft Azure Government で Red Hat OpenShift Container Platform クラスターを作成および管理するには、Kubernetes Operator コンソール用のマルチクラスターエンジンを使用するための認証情報が必要です。

必要なアクセス権限: 編集

注意: この手順は、Kubernetes Operator 用のマルチクラスターエンジンを使用してクラスターを作成するための前提条件です。

1.3.2.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジン。
  • Azure 上に Kubernetes クラスターを作成できるようにする Kubernetes Operator ハブクラスター用のマルチクラスターエンジンのインターネットアクセス。
  • ベースドメインのリソースグループおよび Azure Service Principal JSON などの Azure ログイン認証情報。azure.microsoft.com を参照してください。
  • Azre でクラスターがインストールできるようにするアカウントの権限。詳細は、How to configure Cloud Services および Azure アカウントの設定 を参照してください。

1.3.2.2. コンソールを使用した認証情報の管理

Kubernetes Operator コンソール用のマルチクラスターエンジンから認証情報を作成するには、コンソールで手順を実行します。ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

  1. オプション: 認証情報の ベース DNS ドメイン を追加します。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。
  2. クラスターの環境が AzurePublicCloud または、AzureUSGovernmentCloud であるかを選択します。この設定は Azure Government 環境とは異なるため、これが正しく設定されていることを確認します。
  3. Azure アカウントの ベースドメインリソースグループ名 を追加します。このエントリーは、Azure アカウントで作成したリソース名です。Azure インターフェイスで Home > DNS Zones を選択することで、ベースドメインのリソースグループ名を検索できます。ベースドメインリソースグループ名を見つけるには、Create an Azure service principal with the Azure CLI を参照してください。
  4. クライアント ID の内容を入力します。この値は、以下のコマンドを使用してサービスプリンシパルを作成すると、appId プロパティーとして設定されます。

    az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>

    service_principal は、お使いのサービスプリンシパル名に置き換えます。

  5. Client Secret を追加します。この値は、以下のコマンドを使用してサービスプリンシパルを作成すると、password プロパティーとして設定されます。

    az ad sp create-for-rbac --role Contributor --name <service_principal> --scopes <subscription_path>

    service_principal は、お使いのサービスプリンシパル名に置き換えます。詳細については、Create an Azure service principal with the Azure CLI を参照してください。

  6. Subscription ID を追加します。以下のコマンドの出力では、この値は、id プロパティーになります。

    az account show
  7. Tenant ID を追加します。以下のコマンドの出力では、この値は、tenantId プロパティーになります。

    az account show
  8. プロキシーを有効にする場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。
  9. Red Hat OpenShift pull secret を入力します。Pull secret からプルシークレットをダウンロードします。
  10. クラスターへの接続に使用する SSH 秘密鍵SSH 公開鍵 を追加します。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。キー生成の方法は、SSH プライベートキーの生成およびエージェントへの追加 を参照してください。

Microsoft Azure でのクラスターの作成 の手順を実行して、この認証情報を使用するクラスターを作成します。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.3.2.3. API を使用した不透明なシークレットの作成

コンソールの代わりに API を使用して Microsoft Azure の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-azure-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    baseDomainResourceGroupName: $(echo -n "${azure_resource_group_name}" | base64 -w0)
    osServicePrincipal.json: $(base64 -w0 "${AZURE_CRED_JSON}")

注記: 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。

1.3.3. Google Cloud Platform の認証情報の作成

Google Cloud Platform (GCP) で Red Hat OpenShift Container Platform クラスターを作成および管理するには、Kubernetes Operator コンソール用のマルチクラスターエンジンを使用するための認証情報が必要です。

必要なアクセス権限: 編集

注意: この手順は、Kubernetes Operator 用のマルチクラスターエンジンを使用してクラスターを作成するための前提条件です。

1.3.3.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジン
  • GCP 上に Kubernetes クラスターを作成できるように、Kubernetes Operator ハブクラスター用のマルチクラスターエンジンのインターネットアクセス
  • ユーザーの Google Cloud Platform プロジェクト ID および Google Cloud Platform サービスアカウント JSON キーなど、GCP ログインの認証情報。Creating and managing projects を参照してください。
  • GCP でクラスターがインストールできるようにするアカウントの権限。アカウントの設定方法は、GCP プロジェクトの設定 を参照してください。

1.3.3.2. コンソールを使用した認証情報の管理

Kubernetes Operator コンソール用のマルチクラスターエンジンから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。

  1. GCP アカウントの Google Cloud Platform project ID を追加します。GCP にログインして設定を取得します。
  2. Google Cloud Platform service account JSON key を追加します。https://cloud.google.com/iam/docs/creating-managing-service-accounts を参照して、サービスアカウントの JSON キーを作成してください。GCP コンソールの手順に従います。
  3. 新しい Google Cloud Platform サービスアカウントの JSON キー の内容を提供します。
  4. プロキシーを有効にする場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。
  5. Red Hat OpenShift pull secret を入力します。Pull secret からプルシークレットをダウンロードします。
  6. クラスターにアクセスできるように SSH 秘密鍵SSH 公開鍵 を追加します。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。

キー生成の方法は、SSH プライベートキーの生成およびエージェントへの追加 を参照してください。

Google Cloud Platform でのクラスターの作成 の手順を実行することで、クラスターの作成時にこの接続を使用できます。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.3.3.3. API を使用した不透明なシークレットの作成

コンソールの代わりに API を使用して Google Cloud Platform の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-gcp-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    osServiceAccount.json: $(base64 -w0 "${GCP_CRED_JSON}")

注記: 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。

1.3.4. VMware vSphere の認証情報の作成

VMware vSphere で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、Kubernetes Operator コンソール用のマルチクラスターエンジンを使用するための認証情報が必要です。OpenShift Container Platform バージョン 4.5.x 以降のみがサポートされます。

必要なアクセス権限: 編集

注意: この手順は、Kubernetes Operator 用のマルチクラスターエンジンを使用してクラスターを作成する前に実行する必要があります。

1.3.4.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスター。
  • VMware vSphere に Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
  • インストーラーでプロビジョニングされるインフラストラクチャーを使用する場合に OpenShift Container Platform 向けに設定された VMware vSphere ログイン認証情報および vCenter 要件。カスタマイズによる vSphere へのクラスターのインストール を参照してください。これらの認証除法には、以下の情報が含まれます。

    • vCenter アカウントの権限
    • クラスターリソース
    • HDCP が利用できる
    • 時間を同期した ESXi ホスト (例: NTP)

1.3.4.2. コンソールを使用した認証情報の管理

Kubernetes Operator コンソール用のマルチクラスターエンジンから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。

  1. VMware vCenter サーバーの完全修飾ホスト名または IP アドレス を追加します。値は vCenter サーバーのルート CA 証明書に定義する必要があります。可能な場合は、完全修飾ホスト名を使用します。
  2. VMware vCenter のユーザー名 を追加します。
  3. VMware vCenter パスワード を追加します。
  4. VMware vCenter ルート CA 証明書 を追加します。

    1. VMware vCenter サーバー (https://<vCenter_address>/certs/download.zip) から download.zip として証明書をダウンロードできます。vCenter_address は、vCenter サーバーのアドレスに置き換えます。
    2. download.zip のパッケージを展開します。
    3. 拡張子が .0certs/<platform> ディレクトリーの証明書を使用します。ヒント: ls certs/<platform> コマンドを使用して、お使いのプラットフォームで使用可能な全証明書を一覧表示できます。

      <platform> は、linmac、または win など、お使いのプラットフォームに置き換えます。

      例: certs/lin/3a343545.0

      ベストプラクティス: 次のコマンドを使用して、拡張子が .0 の複数の証明書をリンクします。

      cat certs/lin/*.0 > ca.crt
  5. VMware vSphere クラスター名 を追加します。
  6. VMware vSphere データセンター を追加します。
  7. VMware vSphere デフォルトデータストア を追加します。
  8. オフラインインストールのみ: Configuration for disconnected installation サブセクションのフィールドに必要な情報を入力します。

    • Image content source: この値には、オフラインのレジストリーパスが含まれます。このパスには、オフラインインストールに使用する全インストールイメージのホスト名、ポート、レジストリーパスが含まれます。たとえば、repository.com:5000/openshift/ocp-release となります。

      このパスは、Red Hat OpenShift Container Platform リリースイメージに対して、install-config.yaml のイメージコンテンツソースポリシーのマッピングを作成します。たとえば、repository.com:5000 は以下の imageContentSource コンテンツを作成します。

      imageContentSources:
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-release-nightly
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-release
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    • Additional trust bundle: この値で、ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。

      注記: 非接続環境にあるハブクラスターからマネージドクラスターをデプロイして、インストール後の設定を自動的にインポートする場合は、YAML エディターを使用してイメージコンテンツソースポリシーを install-config.yaml ファイルに追加します。エントリーの例を以下に示します。

      imageContentSources:
      - mirrors:
        - registry.example.com:5000/rhacm2
        source: registry.redhat.io/rhacm2
  9. プロキシーを有効にする場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。
  10. Red Hat OpenShift pull secret を入力します。Pull secret からプルシークレットをダウンロードします。
  11. SSH 秘密鍵SSH 公開鍵 を追加し、クラスターに接続できるようにします。

    既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。詳細は、クラスターノードの SSH アクセス用のキーペアの生成 を参照してください。

VMware vSphere でのクラスターの作成 の手順を完了することで、この認証情報を使用するクラスターを作成できます。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.3.4.3. API を使用した不透明なシークレットの作成

コンソールの代わりに API を使用して VMware vSphere の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-vsphere-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    username: $(echo -n "${VMW_USERNAME}" | base64 -w0)
    password.json: $(base64 -w0 "${VMW_PASSWORD}")

注記: 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。

1.3.5. Red Hat OpenStack の認証情報の作成

Red Hat OpenStack Platform で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、Kubernetes Operator コンソール用のマルチクラスターエンジンを使用するための認証情報が必要です。OpenShift Container Platform バージョン 4.5.x 以降のみがサポートされます。

注記: この手順は、Kubernetes Operator 用のマルチクラスターエンジンでクラスターを作成する前に、実行する必要があります。

1.3.5.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスター。
  • Red Hat OpenStack Platform で Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
  • インストーラーでプロビジョニングされるインフラストラクチャーを使用する場合に OpenShift Container Platform 向けに設定された Red Hat OpenStack Platform ログイン認証情報および Red Hat OpenStack Platform の要件。カスタマイズによる OpenStack へのクラスターのインストール を参照してください。
  • CloudStack API にアクセスするための clouds.yaml ファイルをダウンロードまたは作成する。clouds.yaml ファイルで以下を行います。

    • 使用する cloud auth セクション名を決定します。
    • username 行の直後に、password の行を追加します。

1.3.5.2. コンソールを使用した認証情報の管理

Kubernetes Operator コンソール用のマルチクラスターエンジンから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー向上のため、認証情報のホスト専用の namespace を作成します。

  1. Red Hat OpenStack Platform の clouds.yaml ファイルの内容を追加します。パスワードを含む clouds.yaml ファイルの内容で、Red Hat OpenStack Platform サーバーへの接続に必要な情報を提供します。ファイルの内容には、username の直後に新たに追加したパスワードを含める必要があります。
  2. 内部認証局を使用する設定については、clouds.yaml ファイルを変更して、Hive デプロイヤー Pod 内の証明書バンドルの最終場所を参照します。Hive は、証明書バンドルシークレットをデプロイヤー Pod 内の /etc/openstack-ca にマウントします。そのディレクトリー内のファイルは、クラスターの作成時に提供されるシークレットのキーに対応します。

    シークレットでキー ca.crt が使用されている場合は、以下の例のように cacert パラメーターを clouds.yaml ファイルに追加します。

    clouds:
      openstack:
        auth:
          auth_url: https://openstack.example.local:13000
          username: "svc-openshift"
          project_id: aa0owet0wfwerj
          user_domain_name: "idm"
          password: REDACTED
          region_name: "regionOne"
          interface: "public"
          identity_api_version: 3
          cacert: /etc/openstack-ca/ca.crt
  3. Red Hat OpenStack Platform クラウド名を追加します。このエントリーは、Red Hat OpenStack Platform サーバーへの通信確立に使用する clouds.yaml の cloud セクションで指定した名前です。
  4. オプションで、認証情報のベース DNS ドメインを追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。
  5. オフラインインストールのみ: Configuration for disconnected installation サブセクションのフィールドに必要な情報を入力します。

    • Cluster OS image: この値には、Red Hat OpenShift Container Platform クラスターマシンに使用するイメージの URL が含まれます。
    • イメージコンテンツソース: この値には、オフラインのレジストリーパスが含まれます。このパスには、オフラインインストールに使用する全インストールイメージのホスト名、ポート、レジストリーパスが含まれます。たとえば、repository.com:5000/openshift/ocp-release となります。

      このパスは、Red Hat OpenShift Container Platform リリースイメージに対して、install-config.yaml のイメージコンテンツソースポリシーのマッピングを作成します。たとえば、repository.com:5000 は以下の imageContentSource コンテンツを作成します。

      imageContentSources:
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-release-nightly
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-release
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    • Additional trust bundle: この値で、ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。

      注記: 非接続環境にあるハブクラスターからマネージドクラスターをデプロイして、インストール後の設定を自動的にインポートする場合は、YAML エディターを使用してイメージコンテンツソースポリシーを install-config.yaml ファイルに追加します。エントリーの例を以下に示します。

      imageContentSources:
      - mirrors:
        - registry.example.com:5000/rhacm2
        source: registry.redhat.io/rhacm2
  6. プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。
  7. Red Hat OpenShift プルシークレットを入力します。Pull secret からプルシークレットをダウンロードします。
  8. SSH 秘密鍵と SSH 公開鍵を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。詳細は、クラスターノードの SSH アクセス用のキーペアの生成 を参照してください。
  9. Create をクリックします。
  10. 新規の認証情報を確認し、Add をクリックします。認証情報を追加すると、認証情報のリストに追加されます。

Red Hat OpenStack Platform でのクラスターの作成 の手順を実行して、この認証情報を使用するクラスターを作成します。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.3.5.3. API を使用した不透明なシークレットの作成

コンソールの代わりに API を使用して Red Hat OpenStack Platform の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-osp-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    clouds.yaml: $(base64 -w0 "${OSP_CRED_YAML}") cloud: $(echo -n "openstack" | base64 -w0)

注記: 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。

1.3.6. Red Hat Virtualization の認証情報の作成

Red Hat Virtualization で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、Kubernetes Operator コンソール用のマルチクラスターエンジンを使用するための認証情報が必要です。

注意: この手順は、Kubernetes Operator 用のマルチクラスターエンジンを使用してクラスターを作成する前に実行する必要があります。

1.3.6.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • OpenShift Container Platform バージョン 4.7 以降にデプロイされたハブクラスター。
  • Red Hat Virtualization で Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
  • 設定済み Red Hat Virtualization 環境の Red Hat Virtualization ログイン認証情報。Red Hat Virtualization ドキュメントの インストールガイド を参照してください。以下のリストは、必要な情報を示しています。

    • oVirt URL
    • ovirt 完全修飾ドメイン名 (FQDN)
    • oVirt ユーザー名
    • oVirt パスワード
    • oVirt CA/証明書
  • オプション: プロキシーを有効にした場合にはプロキシー情報。
  • Red Hat OpenShift Container Platform のプルシークレット情報。Pull secret からプルシークレットをダウンロードします。
  • 最終的なクラスターの情報を転送するための SSH 秘密鍵と公開鍵。
  • oVirt でクラスターをインストールできるようにするアカウントの権限。

1.3.6.2. コンソールを使用した認証情報の管理

Kubernetes Operator コンソール用のマルチクラスターエンジンから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー向上のため、認証情報のホスト専用の namespace を作成します。

  1. 新しい認証情報の基本情報を追加します。オプションで、この認証情報を使用してクラスターを作成すると自動的に正しいフィールドにデータが投入される Base DNS ドメインを追加できます。認証情報に追加しない場合は、クラスターの作成時に追加できます。
  2. Red Hat Virtualization 環境に必要な情報を追加します。
  3. プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。

    • HTTP Proxy URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS Proxy URL: HTTPS トラフィックに使用する必要のあるセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  4. Red Hat OpenShift Container Platform プルシークレットを入力します。Pull secret からプルシークレットをダウンロードします。
  5. SSH 秘密鍵と SSH 公開鍵を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。詳細は、クラスターノードの SSH アクセス用のキーペアの生成 を参照してください。
  6. 新規の認証情報を確認し、Add をクリックします。認証情報を追加すると、認証情報の一覧に追加されます。

Red Hat Virtualization でのクラスターの作成 の手順を実行して、この認証情報を使用するクラスターを作成します。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.3.7. Red Hat OpenShift Cluster Manager の認証情報の作成

クラスターを検出できるように OpenShift Cluster Manager の認証情報を追加します。

必要なアクセス権限: 管理者

1.3.7.1. 前提条件

cloud.redhat.com アカウントへのアクセスが必要です。console.redhat.com/openshift/token から取得できる値が後で必要になります。

1.3.7.2. コンソールを使用した認証情報の管理

クラスター検出用の認証情報を追加する必要があります。Kubernetes Operator コンソール用のマルチクラスターエンジンから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

OpenShift Cluster Manager API トークンは、console.redhat.com/openshift/token から取得できます。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

認証情報が削除されるか、OpenShift Cluster Manager API トークンの有効期限が切れるか、取り消されると、関連付けられた検出クラスターが削除されます。

1.3.8. Ansible Automation Platform の認証情報の作成

Red Hat Ansible Automation Platform を使用している Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、Kubernetes Operator コンソール用のマルチクラスターエンジンを使用するための認証情報が必要です。

必要なアクセス権限: 編集

注意: この手順は、Ansible ジョブテンプレートを作成してクラスターで自動化を有効にする前に実行する必要があります。

1.3.8.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジン
  • Kubernetes Operator ハブクラスター用のマルチクラスターエンジンのインターネットアクセス
  • Ansible Tower ホスト名および OAuth トークンを含む Ansible ログイン認証情報。Ansible Tower の認証情報 を参照してください。
  • ハブクラスターのインストールおよび Ansible 操作をできるようにするアカウントパーミッション。Ansible ユーザー の詳細を確認してください。

1.3.8.2. コンソールを使用した認証情報の管理

Kubernetes Operator コンソール用のマルチクラスターエンジンから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

Ansible 認証情報の作成時に指定する Ansible トークンとホストの URL は、認証情報の編集時にその認証情報を使用する自動化向けに、自動で更新されます。更新は、クラスターライフサイクル、ガバナンス、およびアプリケーション管理の自動化に関連するものなど、Ansible 認証情報を使用する自動化にコピーされます。これにより、認証情報の更新後も自動化が引き続き実行されます。

コンソールで認証情報を編集できます。Ansible 認証情報は、認証情報の更新時に、対象の認証情報を使用する自動化で、自動的に更新されあす。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.3.9. オンプレミス環境の認証情報の作成

コンソールを使用してオンプレミス環境で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。認証情報では、クラスターに使用される接続を指定します。

必要なアクセス権限: 編集

1.3.9.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • デプロイされたハブクラスター。
  • インフラストラクチャー環境に Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
  • 切断された環境では、クラスター作成用のリリースイメージをコピーできるミラーレジストリーを設定している。詳細は、OpenShift Container Platform ドキュメントの 非接続インストールのイメージのミラーリング を参照してください。
  • オンプレミス環境でのクラスターのインストールをサポートするアカウントの権限。

1.3.9.2. コンソールを使用した認証情報の管理

コンソールから認証情報を作成するには、コンソールで手順を完了します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

  1. 認証情報の種類に Host inventory を選択します。
  2. オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。DNS ドメインを追加していない場合は、クラスターの作成時に追加できます。
  3. Red Hat OpenShift pull secret を入力します。Pull secret からプルシークレットをダウンロードします。プルシークレットの詳細は、イメージプルシークレットの使用 を参照してください。
  4. Add を選択して認証情報を作成します。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.4. Kubernetes Operator クラスターのライフサイクルの概要のマルチクラスターエンジン

Kubernetes Operator のマルチクラスターエンジンは、クラスターフリート管理を強化するソフトウェア Operator です。Kubernetes Operator のマルチクラスターエンジンは、クラウドおよびデータセンター全体の Red Hat OpenShift Container Platform および Kubernetes クラスターライフサイクル管理をサポートします。

以下のドキュメントを参照してください。

1.4.1. クラスターライフサイクルのアーキテクチャー

Kubernetes のマルチクラスターエンジンは、ハブクラスターマネージドクラスター の 2 つの主なタイプのクラスターを使用します。

ハブクラスターは、マルチクラスターエンジンがインストールされたメインクラスターです。ハブクラスターを使用して他の Kubernetes クラスターの作成、管理、および監視を行うことができます。マネージドクラスターは、ハブクラスターが管理する Kubernetes クラスターです。ハブクラスターを使用していくつかのクラスターを作成できますが、ハブクラスターによって管理される既存のクラスターをインポートすることもできます。

Kubernetes Operator を使用してマネージドクラスターを作成する場合は、Hive リソースを含む Red Hat OpenShift Container Platform クラスターインストーラーを使用してクラスターが作成されます。OpenShift Container Platform インストーラーでクラスターのインストールプロセスについての詳細は、OpenShift Container Platform ドキュメントの OpenShift Container Platform インストールの概要 を参照してください。

次の図は、クラスター管理に使用する Kubernetes Operator 用のマルチクラスターエンジンと共にインストールされるコンポーネントを示しています。

Cluster lifecycle architecture diagram

クラスターライフサイクル管理のアーキテクチャーのコンポーネントには、以下の項目が含まれます。

1.4.1.1. ハブクラスター

  • マネージドクラスターのインポートコントローラー は、klusterlet Operator をマネージドクラスターにデプロイします。
  • Hive コントローラー は、Kubernetes Operator 用のマルチクラスターエンジンを使用して作成したクラスターをプロビジョニングします。また、Hive コントローラーは、Kubernetes Operator 用のマルチクラスターエンジンによって作成されたマネージドクラスターを破棄します。
  • クラスターキュレーターコントローラー は、マネージドクラスターの作成またはアップグレード時にクラスターインフラストラクチャー環境を設定するためのプレフックまたはポストフックとして Ansible ジョブを作成します。
  • マネージドクラスターアドオンがハブクラスターで有効になると、その アドオンハブコントローラー がハブクラスターにデプロイされます。アドオンハブコントローラー は、アドオンエージェント をマネージドクラスターにデプロイします。

1.4.1.2. マネージドクラスター

  • klusterlet Operator マネージドクラスターに登録およびワークコントローラーをデプロイします。
  • 登録エージェント は、マネージドクラスターとマネージドクラスターアドオンをハブクラスターに登録します。登録エージェントは、管理対象クラスターと管理対象クラスターアドオンのステータスも維持します。次のアクセス許可が Clusterrole 内に自動的に作成され、マネージドクラスターがハブクラスターにアクセスできるようになります。

    • エージェントは、ハブクラスターが管理する所有クラスターを取得または更新できます。
    • エージェントが、ハブクラスターが管理する所有クラスターのステータスを更新できるようにします。
    • エージェントが証明書をローテーションできるようにします。
    • エージェントが coordination.k8s.io リースを get または update できるようにします。
    • エージェントがマネージドクラスターアドオンを get できるようにします。
    • エージェントがマネージドクラスターアドオンのステータスを更新できるようにします。
  • ワークエージェント マニフェストはマネージドクラスターで機能します。次のアクセス許可が Clusterrole 内に自動的に作成され、マネージドクラスターがハブクラスターにアクセスできるようになります。

    • エージェントがハブクラスターにイベントを送信できるようにします。
    • エージェントが manifestworks リソースを get または update できるようにします。
    • エージェントが manifestworks リソースのステータスを更新できるようにします。
  • マネージドクラスターアドオンがハブクラスターのマネージドクラスター namespace に作成されると、そのハブコントローラーはマニフェスト作業を使用してそのエージェントデプロイリソースをマニフェストします。その後、作業エージェントはマニフェスト作業をマネージドクラスターに適用して、アドオンエージェントをデプロイします。

クラスターの追加と管理を続行するには、Kubernetes Operator クラスターライフサイクルのマルチクラスターエンジンの概要 を参照してください。

1.4.2. リリースイメージ

Kubernetes Operator 用のマルチクラスターエンジンを使用してプロバイダー上にクラスターを作成する場合は、新しいクラスターに使用するリリースイメージを指定する必要があります。リリースイメージでは、クラスターのビルドに使用する Red Hat OpenShift Container Platform のバージョンを指定します。

acm-hive-openshift-releases GitHub リポジトリーの YAML ファイルを使用して、リリースイメージを参照します。Red Hat Advanced Cluster Management はこれらのファイルを使用して、コンソールで利用可能なリリースイメージの一覧を作成します。これには、OpenShift Container Platform における最新の fast チャネルイメージが含まれます。コンソールには、OpenShift Container Platform の 3 つの最新バージョンの最新リリースイメージのみが表示されます。たとえば、コンソールオプションに以下のリリースイメージが表示される可能性があります。

  • quay.io/openshift-release-dev/ocp-release:4.6.23-x86_64
  • quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64

注記: コンソールでクラスターの作成時に選択できるのは、visible: 'true' のラベルが付いたリリースイメージのみです。ClusterImageSet リソースのこのラベルの例は以下の内容で提供されます。

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

追加のリリースイメージは保管されますが、コンソールには表示されません。利用可能なすべてのリリースイメージを表示するには、CLI で kubectl get clusterimageset を実行します。最新のリリースイメージでクラスターを作成することが推奨されるため、コンソールには最新バージョンのみがあります。特定バージョンのクラスター作成が必要となる場合があります。そのため、古いバージョンが利用可能となっています。Red Hat Advanced Cluster Management はこれらのファイルを使用して、コンソールで利用可能なリリースイメージのリストを作成します。これには、OpenShift Container Platform における最新の fast チャネルイメージが含まれます。

リポジトリーには、clusterImageSets ディレクトリーと subscription ディレクトリーが含まれます。これらのディレクトリーは、リリースイメージの操作時に使用します。

clusterImageSets ディレクトリーには以下のディレクトリーが含まれます。

  • Fast: サポート対象の各 OpenShift Container Platform バージョンのリリースイメージの内、最新バージョンを参照するファイルが含まれます。このフォルダー内のリリースイメージはテストされ、検証されており、サポートされます。
  • Releases: 各 OpenShift Container Platform バージョン (stable、fast、および candidate チャネル) のリリースイメージをすべて参照するファイルが含まれます。注記: このリリースはすべてテストされ、安定していると判別されているわけではありません。
  • Stable: サポート対象の各 OpenShift Container Platform バージョンのリリースイメージの内、最新の安定版 2 つを参照するファイルが含まれます。

注記: デフォルトでは、リリースイメージの現在のリストは 1 時間ごとに更新されます。製品をアップグレードした後、リストに製品の新しいバージョンの推奨リリースイメージバージョンが反映されるまでに最大 1 時間かかる場合があります。

独自の ClusterImageSets は以下の 3 つの方法でキュレートできます。

3 つの方法のいずれかの最初のステップは、最新の fast チャンネルイメージを自動的に更新する付属のサブスクリプションを無効にすることです。最新の fast の ClusterImageSets の自動キュレーションを無効にするには、multiclusterhub リソースでインストーラーパラメーターを使用します。spec.disableUpdateClusterImageSets パラメーターを truefalse の間で切り替えることにより、Red Hat Advanced Cluster Management でインストールしたサブスクリプションが、それぞれ無効または有効になります。独自のイメージをキューレートする場合は、spec.disableUpdateClusterImageSetstrue に設定してサブスクリプションを無効にします。

オプション 1: クラスターの作成時にコンソールで使用する特定の ClusterImageSet のイメージ参照を指定します。指定する新規エントリーはそれぞれ保持され、将来のすべてのクラスタープロビジョニングで利用できます。たとえば、エントリーは quay.io/openshift-release-dev/ocp-release:4.6.8-x86_64 のようになります。

オプション 2: GitHub リポジトリー acm-hive-openshift-releases から YAML ファイル ClusterImageSets を手動で作成し、適用します。

オプション 3: GitHub リポジトリー acm-hive-openshift-releasesREADME.md に従って、フォークした GitHub リポジトリーから ClusterImageSets の自動更新を有効にします。

subscription ディレクトリーには、リリースイメージの一覧がプルされる場所を指定するファイルが含まれます。

Red Hat Advanced Cluster Management のデフォルトのリリースイメージは、Quay.io デフォルトで提供されます。

イメージは、acm-hive-openshift-releases GitHub repository for release 2.5 のファイルで参照されます。

1.4.2.1. 別のアーキテクチャーにクラスターをデプロイするためのリリースイメージの作成

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

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

OpenShift Container Platform 4.11 以降は、デフォルトで複数のアーキテクチャーをサポートします。以下の clusterImageSet を使用してクラスターをプロビジョニングできます。

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

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

  1. OpenShift Container Platform リリースレジストリー から、x86_64s390xaarch64、および ppc64le リリースイメージを含む マニフェスト一覧 を作成します。

    1. 以下のコマンド例を使用して、Quay リポジトリー から環境内の両方のアーキテクチャーのマニフェストリストをプルします。

      podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64
      podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-ppc64le
      podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-s390x
      podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-aarch64
    2. イメージを管理するプライベートリポジトリーにログインします。

      podman login <private-repo>

      private-repo は、リポジトリーへのパスに置き換えます。

    3. 環境に適用される以下のコマンドを実行して、リリースイメージマニフェストをプライベートリポジトリーに追加します。

      podman push quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64 <private-repo>/ocp-release:4.10.1-x86_64
      podman push quay.io/openshift-release-dev/ocp-release:4.10.1-ppc64le <private-repo>/ocp-release:4.10.1-ppc64le
      podman push quay.io/openshift-release-dev/ocp-release:4.10.1-s390x <private-repo>/ocp-release:4.10.1-s390x
      podman push quay.io/openshift-release-dev/ocp-release:4.10.1-aarch64 <private-repo>/ocp-release:4.10.1-aarch64

      private-repo は、リポジトリーへのパスに置き換えます。

    4. 新規情報のマニフェストを作成します。

      podman manifest create mymanifest
    5. 両方のリリースイメージへの参照をマニフェスト一覧に追加します。

      podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-x86_64
      podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-ppc64le
      podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-s390x
      podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-aarch64

      private-repo は、リポジトリーへのパスに置き換えます。

    6. マニフェストリストの一覧を既存のマニフェストにマージします。

      podman manifest push mymanifest docker://<private-repo>/ocp-release:4.10.1

      private-repo は、リポジトリーへのパスに置き換えます。

  2. ハブクラスターで、リポジトリーのマニフェストを参照するリリースイメージを作成します。

    1. 以下の例のような情報を含む YAML ファイルを作成します。

      apiVersion: hive.openshift.io/v1
      kind: ClusterImageSet
      metadata:
        labels:
          channel: fast
          visible: "true"
        name: img4.10.1-appsub
      spec:
        releaseImage: <private-repo>/ocp-release:4.10.1

      private-repo は、リポジトリーへのパスに置き換えます。

    2. ハブクラスターで以下のコマンドを実行し、変更を適用します。

      oc apply -f <file-name>.yaml

      file-name を、先の手順で作成した YAML ファイルの名前に置き換えます。

  3. OpenShift Container Platform クラスターの作成時に新規リリースイメージを選択します。
  4. Red Hat Advanced Cluster Management コンソールを使用してマネージドクラスターをデプロイする場合は、クラスター作成のプロセス時に Architecture フィールドにマネージドクラスターのアーキテクチャーを指定します。

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

1.4.2.2. 非接続時におけるリリースイメージのカスタム一覧の管理

ハブクラスターにインターネット接続がない場合は、リリースイメージのカスタムリストを管理しないといけない場合があります。クラスターの作成時に利用可能なリリースイメージのカスタムリストを作成します。非接続時に、利用可能なリリースイメージを管理するには、以下の手順を実行します。

  1. オンラインシステムを使用している場合は、GitHub リポジトリー acm-hive-openshift-releases に移動し、バージョン 2.5 で利用可能なクラスターイメージセットにアクセスします。
  2. clusterImageSets ディレクトリーを、切断された Kubernetes Operator ハブクラスター用のマルチクラスターエンジンにアクセスできるシステムにコピーします。
  3. 管理対象クラスターに適合する次の手順を実行して、管理対象クラスターと切断されたリポジトリーの間にクラスターイメージセットを含むマッピングを追加します。

  4. clusterImageSet YAML を手作業で追加し、Red Hat Advanced Cluster Management for Kubernetes コンソールを使用してクラスターを作成する時に利用できるようにイメージの YAML ファイルを追加します。
  5. 残りの OpenShift Container Platform リリースイメージの clusterImageSet YAML ファイルを、イメージの保存先の正しいオフラインリポジトリーを参照するように変更します。更新は次の例のようになります。

    apiVersion: hive.openshift.io/v1
    kind: ClusterImageSet
    metadata:
        name: img4.4.0-rc.6-x86-64
    spec:
        releaseImage: IMAGE_REGISTRY_IPADDRESS_or_DNSNAME/REPO_PATH/ocp-release:4.4.0-rc.6-x86_64

    YAML ファイルで参照されているオフラインイメージレジストリーにイメージがロードされていることを確認します。

  6. 各 YAML ファイルに以下のコマンドを入力して、各 clusterImageSets を作成します。

    oc create -f <clusterImageSet_FILE>

    clusterImageSet_FILE を、クラスターイメージセットファイルの名前に置き換えます。以下は例になります。

    oc create -f img4.11.9-x86_64.yaml

    追加するリソースごとにこのコマンドを実行すると、利用可能なリリースイメージの一覧が使用できるようになります。

  7. または Red Hat Advanced Cluster Management のクラスター作成のコンソールに直接イメージの URL を貼り付けることもできます。イメージ URL が存在しない場合は、イメージ URL を追加すると新しい clusterImageSets が作成されます。
  8. クラスターの作成時に、Red Hat Advanced Cluster Management コンソールで現在利用可能なリリースイメージの一覧を表示します。

1.4.3. インフラストラクチャー環境の作成

コンソールを使用してインフラストラクチャー環境を作成し、ホストを管理してそのホスト上にクラスターを作成できます。

インフラストラクチャー環境は、次の機能をサポートしています。

  • クラスターのゼロタッチプロビジョニング: スクリプトを使用してクラスターをデプロイメントします。詳細は、Red Hat OpenShift Container Platform ドキュメントの 切断された環境での GitOps ZTP のインストール を参照してください。
  • 遅延バインディング: 既存のクラスターにノードを追加します。インフラストラクチャー管理者はホストを起動でき、クラスター作成者は後でホストを既存のクラスターにバインドできます。遅延バインディングを使用する場合は、クラスター作成者がインフラストラクチャーにアクセスするのに管理者権限は必要ありません。
  • デュアルスタック: IPv4 と IPv6 の両方のアドレスを持つクラスターをデプロイします。デュアルスタックは、OVN-Kubernetes ネットワーク実装を使用して、複数のサブネットをサポートします。
  • リモートワーカーノードの追加: リモートワーカーノードを作成して実行した後、クラスターに追加します。これにより、バックアップ目的で他の場所にノードを追加する柔軟性が提供されます。
  • NMState を使用した静的 IP: NMState API を使用して、環境の静的 IP アドレスを定義します。

1.4.3.1. 前提条件

インフラストラクチャー環境を作成する前に、以下の前提条件を確認してください。

  • OpenShift Container Platform をハブクラスターにデプロイする必要があります。
  • クラスターを作成するために必要なイメージを取得するためのハブクラスターへのインターネットアクセス (接続済み)、あるいはインターネットへの接続がある内部またはミラーレジストリーへの接続 (非接続) がある。
  • ハブクラスター上にある設定済みの Central Infrastructure Management (CIM) 機能のインスタンスがある。
  • Bare Metal Operator をハブクラスターにインストールする必要がある。
  • OpenShift Container Platform プルシークレット がある。詳細は、イメージプルシークレットの使用 を参照してください。
  • デフォルトで ~/.ssh/id_rsa.pub ファイルに SSH キーがある。
  • 設定済みのストレージクラスがある。
  • 切断された環境のみ: OpenShift Container Platform のドキュメントで、ネットワーク遠端のクラスター の手順を完了します。

1.4.3.2. Central Infrastructure Management サービスの有効化

Central Infrastructure Management サービスは、Kubernetes 用のマルチクラスターエンジンで提供され、OpenShift Container Platform クラスターをデプロイします。CIM は、ハブクラスターで MultiClusterHub Operator を有効にするとデプロイされますが、有効にする必要があります。

CIM サービスを有効にするには、以下の手順を実行します。

重要: ハブクラスターが次のプラットフォームのいずれかにインストールされている場合のみ: ベアメタル、Red Hat OpenStack Platform、VMware vSphere、またはユーザープロビジョニングインフラストラクチャー (UPI) 方式を使用してインストールされ、プラットフォームが None の場合のみ、次の手順を実行します。ハブクラスターが他のプラットフォームにある場合は、この手順を省略します。

  1. provisioning リソースを変更し、以下のコマンドを実行してベアメタル Operator がすべての namespace を監視できるようにします。

    oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
  2. 非接続環境: では、インフラストラクチャー Operator と 同じ namespaceConfigMap を作成し、ミラーレジストリーの ca-bundle.crt および registries.conf の値を指定します。ファイルの ConfigMap は以下の例のようになります。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <mirror-config>
      namespace: "<infrastructure-operator-namespace>"
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: |
        -----BEGIN CERTIFICATE-----
        certificate contents
        -----END CERTIFICATE-----
    
      registries.conf: |
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
        [[registry]]
           prefix = ""
           location = "registry.redhat.io/multicluster-engine"
           mirror-by-digest-only = true
    
           [[registry.mirror]]
           location = "mirror.registry.com:5000/multicluster-engine"
1.4.3.2.1. AgentServiceConfig カスタムリソースの作成

以下の手順を実行して AgentServiceConfig カスタムリソースを作成します。

  1. 切断された環境のみ: 次の YAML コンテンツを agent_service_config.yaml ファイルに保存し、必要に応じて値を置き換えます。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
     name: agent
    spec:
      databaseStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_volume_size>
      filesystemStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_volume_size>
      mirrorRegistryRef:
        name: <mirror_config>
      unauthenticatedRegistries:
        - <unauthenticated_registry>
      imageStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <img_volume_size>
      osImages:
        - openshiftVersion: "<ocp_version>"
          version: "<ocp_release_version>"
          url: "<iso_url>"
          cpuArchitecture: "x86_64"

    mirror_config は、ミラーレジストリー設定の詳細が含まれる ConfigMap の名前に置き換えます。

    認証を必要としないミラーレジストリーを使用している場合は、オプションの unauthenticated_registry パラメーターを含めます。このリストのエントリーは検証されず、プルシークレットにエントリーを含める必要はありません。

  2. 接続環境の場合のみ: 次の YAML コンテンツを agent_service_config.yaml ファイルに保存します。
apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
 name: agent
spec:
  databaseStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <db_volume_size>
  filesystemStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <fs_volume_size>
  imageStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <img_volume_size>

+ db_volume_sizedatabaseStorage フィールドのボリュームサイズに置き換えます (例: 10Gi )。この値は、クラスターのデータベーステーブルやデータベースビューなどのファイルを格納するために割り当てられるストレージの量を指定します。クラスターが多い場合は、より高い値を使用する必要がある場合があります。

+ fs_volume_sizefilesystemStorage フィールドのボリュームのサイズに置き換えます (例: クラスターごとに 200M、サポートされる OpenShift Container Platform バージョンごとに 2-3Gi)。必要な最小値は 100Gi です。この値は、クラスターのログ、マニフェスト、および kubeconfig ファイルを保存するために割り当てられるストレージのサイズを指定します。クラスターが多い場合は、より高い値を使用する必要がある場合があります。

+ img_volume_sizeimageStorage フィールドのボリュームのサイズに置き換えます (例: オペレーティングシステムイメージごとに 2Gi)。最小サイズは 50Gi です。この値は、クラスターのイメージに割り当てられるストレージの量を指定します。実行中の Red Hat Enterprise Linux CoreOS の各インスタンスに 1 GB のイメージストレージを許可する必要があります。Red Hat Enterprise Linux CoreOS のクラスターおよびインスタンスが多数ある場合は、より高い値を使用する必要がある場合があります。

+ ocp_version は、インストールする OpenShift Container Platform バージョンに置き換えます。

+ ocp_release_version は、特定のインストールバージョン (例: 49.83.2021032516400) に置き換えます。

+ iso_url は、ISO URL に置き換えます (例:https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.10/4.10.3/rhcos-4.10.3-x86_64-live.x86_64.iso)。他の値は https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.10/4.10.3/ にあります。

  1. 次のコマンドを実行して、AgentServiceConfig カスタムリソースを作成します。

    oc create -f agent_service_config.yaml

    出力は次の例のような内容になります。

    agentserviceconfig.agent-install.openshift.io/agent created

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

1.4.3.2.2. プロビジョニングカスタムリソース (CR) を手動で作成する

次のコマンドを使用して、プロビジョニング CR を手動で作成し、サービスの自動プロビジョニングを有効にします。

oc create -f provisioning-configuration.yaml

CR は次のサンプルのようになります。

apiVersion: metal3.io/v1alpha1
kind: Provisioning
metadata:
  name: provisioning-configuration
spec:
  provisioningNetwork: Disabled
  watchAllNamespaces: true
1.4.3.2.3. Amazon Web Services での中央インフラストラクチャー管理の有効化

Amazon Web Services でハブクラスターを実行していて、CIM サービスを有効にする場合は、CIM を有効 にした後に次の追加手順を実行します。

  1. ハブにログインしていることを確認し、次のコマンドを実行して、assisted-image-service で設定された一意のドメインを見つけます。

    oc get routes --all-namespaces | grep assisted-image-service

    ドメインは assisted-image-service-multicluster-engine.apps.<yourdomain>.com のようになります。

  2. ハブにログインしていることを確認し、NLB type パラメーターを使用して一意のドメインで新しい IngressController を作成します。以下の例を参照してください。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: ingress-controller-with-nlb
      namespace: openshift-ingress-operator
    spec:
      domain: nlb-apps.<domain>.com
      routeSelector:
          matchLabels:
            router-type: nlb
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
  3. nlb-apps.<domain>.com<domain><yourdomain> に置き換えて、IngressControllerdomain パラメーターに <yourdomain> を追加します。
  4. 次のコマンドを使用して、新しい IngressController を適用します。

    oc apply -f ingresscontroller.yaml
  5. 次の手順を実行して、新しい IngressControllerspec.domain パラメーターの値が既存の IngressController と競合していないことを確認します。

    1. 次のコマンドを実行して、すべての IngressController を一覧表示します。

      oc get ingresscontroller -n openshift-ingress-operator
    2. 先ほど作成した ingress-controller-with-nlb を除く各 IngressControllers で次のコマンドを実行します。

      oc edit ingresscontroller <name> -n openshift-ingress-operator

      spec.domain レポートが見つからない場合は、nlb-apps.<domain>.com を除く、クラスターで公開されているすべてのルートに一致するデフォルトドメインを追加します。

      spec.domain レポートが提供されている場合は、指定された範囲から nlb-apps.<domain>.com ルートが除外されていることを確認してください。

  6. 次のコマンドを実行して、assisted-image-service ルートを編集し、nlb-apps の場所を使用します。

    oc edit route assisted-image-service -n <namespace>
  7. 次の行を assisted-image-service ルートに追加します。

    metadata:
      labels:
        router-type: nlb
      name: assisted-image-service
  8. assisted-image-service ルートで、spec.host の URL 値を見つけます。URL は次の例のようになります。

    assisted-image-service-multicluster-engine.apps.<yourdomain>.com

  9. URL 内の appsnlb-apps に置き換えて、新しい IngressController で設定されたドメインと一致させます。

Amazon Web Services で CIM サービスが有効になっていることを確認するには、次の手順を実行します。

  1. 次のコマンドを実行して、Pod が正常であることを確認します。

    oc get pods -n multicluster-engine | grep assist
  2. 新しいインフラストラクチャー環境を作成し、ダウンロード URL が新しい nlb-apps URL を使用していることを確認します。

1.4.3.3. コンソールを使用したインフラストラクチャー環境の作成

コンソールからインフラストラクチャー環境を作成するには、次の手順を実行します。

  1. ナビゲーションメニューから、Infrastructure > Host inventory に移動し、Create infrastructure environment をクリックします。
  2. お使いのインフラストラクチャー環境設定に以下の情報を追加します。

    • 名前: インフラストラクチャー環境の一意の名前。
    • ネットワークの種類: インフラストラクチャー環境に追加できるホストの種類を指定します。ベアメタルホストを使用している場合には、静的 IP オプションのみを使用できます。
    • Location: ホストの地理的な場所を指定します。地理的な場所を使用すると、クラスターの作成時に、クラスター上のデータの保存場所を簡単に判断できます。
    • Labels: インフラストラクチャー環境にラベルを追加できる任意のフィールド。これにより、検索がかんたんになり、特徴がよく似た他の環境とグループ化できます。ネットワークタイプと場所に対して行った選択は、自動的にラベルのリストに追加されます。
    • プルシークレット: OpenShift Container Platform リソースへのアクセスを可能にする OpenShift Container Platform プルシークレット
    • SSH 公開鍵: ホストとのセキュアな通信を可能にする SSH キー。これは通常 ~/.ssh/id_rsa.pub ファイルにあります。
    • すべてのクラスターでプロキシー設定を有効にする必要がある場合は、有効にする設定を選択します。この設定は、以下の情報を入力する必要があります。

      • HTTP Proxy URL: 検出サービスへのアクセス時に使用する必要のある URL。
      • HTTPS Proxy URL: 検出サービスへのアクセス時に使用する必要のあるセキュアなプロキシー URL。https はまだサポートされていないため、形式は http である必要があります。
      • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。

ホストをインフラストラクチャー環境に追加して、続行できるようになりました。

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

1.4.4. クラスターの作成

Kubernetes Operator 用のマルチクラスターエンジンを使用して、複数のクラウドプロバイダー間で Red Hat OpenShift Container Platform クラスターを作成する方法を学びます。

Kubernetes Operator 用のマルチクラスターエンジンは、OpenShift Container Platform で提供される Hive Operator を使用して、オンプレミスクラスターおよびホスティングされたコントロールプレーンを除くすべてのプロバイダーのクラスターをプロビジョニングします。オンプレミスクラスターをプロビジョニングする場合、Kubernetes Operator 用のマルチクラスターエンジンは、OpenShift Container Platform で提供される Central Infrastructure Management (CIM) および Assisted Installer 機能を使用します。ホステッドコントロールプレーンのホステッドクラスターは、HyperShift Operator を使用してプロビジョニングされます。

1.4.4.1. CLI を使用したクラスターの作成

Kubernetes のマルチクラスターエンジンは、内部 Hive コンポーネントを使用して Red Hat OpenShift Container Platform クラスターを作成します。クラスターの作成方法については、以下の情報を参照してください。

1.4.4.1.1. 前提条件

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

  1. 次のコマンドを実行してクローンを作成します。

    git clone https://github.com/stolostron/acm-hive-openshift-releases.git
    cd acm-hive-openshift-releases
    git checkout origin/release-2.6
  2. 次のコマンドを実行して、ハブクラスターに適用します。

    find clusterImageSets/fast -type d -exec oc apply -f {} \; 2> /dev/null

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

1.4.4.1.2. ClusterDeployment を使用してクラスターを作成する

ClusterDeployment は、Hive カスタムリソースです。個々のクラスターを作成する方法については、次のドキュメントを参照してください。

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

1.4.4.1.3. ClusterPool を使用してクラスターを作成

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

Cluster Pools のドキュメントに従って、クラスターをプロビジョニングします。

1.4.4.2. クラスター作成時の追加のマニフェストの設定

追加の Kubernetes リソースマニフェストは、クラスター作成のインストールプロセス中に設定できます。これは、ネットワークの設定やロードバランサーの設定など、シナリオの追加マニフェストを設定する必要がある場合に役立ちます。

クラスターを作成する前に、追加のリソースマニフェストが含まれる ConfigMap を指定する ClusterDeployment リソースへの参照を追加する必要があります。

注記: ClusterDeployment リソースと ConfigMap は同じ namespace にある必要があります。以下の例で、どのような内容かを紹介しています。

  • リソースマニフェストを含む ConfigMap

    ConfigMap リソースが別のマニフェストが含まれる ConfigMap。リソースマニフェストの ConfigMap には、data.<resource_name>\.yaml パターンに追加されたリソース設定が指定されたキーを複数含めることができます。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: <my-baremetal-cluster-install-manifests>
      namespace: <mynamespace>
    data:
      99_metal3-config.yaml: |
        kind: ConfigMap
        apiVersion: v1
        metadata:
          name: metal3-config
          namespace: openshift-machine-api
        data:
          http_port: "6180"
          provisioning_interface: "enp1s0"
          provisioning_ip: "172.00.0.3/24"
          dhcp_range: "172.00.0.10,172.00.0.100"
          deploy_kernel_url: "http://172.00.0.3:6180/images/ironic-python-agent.kernel"
          deploy_ramdisk_url: "http://172.00.0.3:6180/images/ironic-python-agent.initramfs"
          ironic_endpoint: "http://172.00.0.3:6385/v1/"
          ironic_inspector_endpoint: "http://172.00.0.3:5150/v1/"
          cache_url: "http://192.168.111.1/images"
          rhcos_image_url: "https://releases-art-rhcos.svc.ci.openshift.org/art/storage/releases/rhcos-4.3/43.81.201911192044.0/x86_64/rhcos-43.81.201911192044.0-openstack.x86_64.qcow2.gz"
  • リソースマニフェスト ConfigMap が参照される ClusterDeployment

    リソースマニフェスト ConfigMapspec.provisioning.manifestsConfigMapRef で参照されます。

    apiVersion: hive.openshift.io/v1
    kind: ClusterDeployment
    metadata:
      name: <my-baremetal-cluster>
      namespace: <mynamespace>
      annotations:
        hive.openshift.io/try-install-once: "true"
    spec:
      baseDomain: test.example.com
      clusterName: <my-baremetal-cluster>
      controlPlaneConfig:
        servingCertificates: {}
      platform:
        baremetal:
          libvirtSSHPrivateKeySecretRef:
            name: provisioning-host-ssh-private-key
      provisioning:
        installConfigSecretRef:
          name: <my-baremetal-cluster-install-config>
        sshPrivateKeySecretRef:
          name: <my-baremetal-hosts-ssh-private-key>
        manifestsConfigMapRef:
          name: <my-baremetal-cluster-install-manifests>
        imageSetRef:
          name: <my-clusterimageset>
        sshKnownHosts:
        - "10.1.8.90 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXvVVVKUYVkuyvkuygkuyTCYTytfkufTYAAAAIbmlzdHAyNTYAAABBBKWjJRzeUVuZs4yxSy4eu45xiANFIIbwE3e1aPzGD58x/NX7Yf+S8eFKq4RrsfSaK2hVJyJjvVIhUsU9z2sBJP8="
      pullSecretRef:
        name: <my-baremetal-cluster-pull-secret>

1.4.4.3. Amazon Web Services でのクラスターの作成

Kubernetes Operator コンソールのマルチクラスターエンジンを使用して、Amazon Web Services (AWS) に Red Hat OpenShift Container Platform クラスターを作成できます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの AWS へのインストール でプロセスの詳細を確認してください。

1.4.4.3.1. 前提条件

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

  • Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジンがある。
  • Amazon Web Services で Kubernetes クラスターを作成できるように、Kubernetes Operator ハブクラスター用のマルチクラスターエンジンにインターネットアクセスが必要です。
  • AWS 認証情報がある。詳細は、Amazon Web Services の認証情報の作成 を参照してください。
  • AWS で設定されたドメインがある。ドメインの設定方法は、AWS アカウントの設定 を参照してください。
  • ユーザー名、パスワード、アクセスキー ID およびシークレットアクセスキーなど、Amazon Web Services (AWS) のログイン認証情報がある。Understanding and Getting Your Security Credentials を参照してください。
  • OpenShift Container Platform イメージのプルシークレットがある。イメージプルシークレットの使用 を参照してください。

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

1.4.4.3.2. コンソールを使用したクラスターの作成

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

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

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

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

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

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

1.4.4.3.3. クラスターを既存のクラスターセットに追加する

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

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

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

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

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

  • アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。
  • ゾーン: コントロールプレーンプールを実行する場所を指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • インスタンスタイプ: コントロールプレーンノードのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
  • ルートストレージ: クラスターに割り当てるルートストレージの量を指定します。

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

  • ゾーン: ワーカープールを実行する場所を指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • インスタンスタイプ: ワーカープールのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
  • ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。
  • ルートストレージ: ワーカープールに割り当てるルートストレージの量を指定します。ワーカープールを定義する場合にこの設定は必須です。

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

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

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加のトランスバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。

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

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

1.4.4.4. Microsoft Azure でのクラスターの作成

Kubernetes Operator コンソール用のマルチクラスターエンジンを使用して、Red Hat OpenShift Container Platform クラスターを Microsoft Azure または Microsoft Azure Government にデプロイできます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの Azure へのインストール でプロセスの詳細を確認してください。

1.4.4.4.1. 前提条件

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

  • Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジンがある。
  • Azure または Azure Government で Kubernetes クラスターを作成できるように、Kubernetes Operator ハブクラスター用のマルチクラスターエンジンにインターネットアクセスが必要です。
  • Azure 認証情報がある。詳細は、Microsoft Azure の認証情報の作成 を参照してください。
  • Azure または Azure Government に設定済みドメインがある。ドメイン設定の方法は、Configuring a custom domain name for an Azure cloud service を参照してください。
  • ユーザー名とパスワードなどの Azure ログイン認証情報がある。Microsoft Azure Portal を参照してください。
  • clientIdclientSecret および tenantId などの Azure サービスプリンシパルがある。azure.microsoft.com を参照してください。
  • OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。

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

1.4.4.4.2. コンソールを使用したクラスターの作成

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

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

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

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

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

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

1.4.4.4.3. クラスターを既存のクラスターセットに追加する

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

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

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

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

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

  • リージョン: ノードプールを実行するリージョンを指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。
  • コントロールプレーンプールのインスタンスタイプおよびルートストレージの割り当て (必須)。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。

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

  • ゾーン: ワーカープールを実行することを指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。

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

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

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。

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

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

1.4.4.5. Google Cloud Platform でのクラスターの作成

Google Cloud Platform (GCP) で Red Hat OpenShift Container Platform クラスターを作成する手順に従います。GCP の詳細については、Google Cloud Platform を参照してください。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの GCP のインストール でプロセスの詳細を確認してください。

1.4.4.5.1. 前提条件

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

  • Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジンがある。
  • Kubernetes Operator ハブクラスター用のマルチクラスターエンジンが GCP 上に Kubernetes クラスターを作成できるようにするには、インターネットアクセスが必要です。
  • GCP 認証情報がある。詳細は、Google Cloud Platform の認証情報の作成 を参照してください。
  • GCP に設定済みのドメインがある。ドメインの設定方法は、Setting up a custom domain を参照してください。
  • ユーザー名とパスワードを含む GCP ログイン認証情報がある。
  • OpenShift Container Platform イメージのプルシークレットがある。イメージプルシークレットの使用 を参照してください。

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

1.4.4.5.2. コンソールを使用したクラスターの作成

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

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

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

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

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

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

1.4.4.5.3. クラスターを既存のクラスターセットに追加する

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

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

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

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

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

  • リージョン: コントロールプレーンプールを実行するリージョンを指定します。リージョンが近くにある場合はパフォーマンスの速度が向上しますが、リージョンの距離が離れると、より分散されます。
  • アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。
  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。

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

  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
  • ノード数: ワーカープールを定義するときに必要な設定です。

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

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

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。

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

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

1.4.4.6. VMware vSphere でのクラスターの作成

Kubernetes Operator コンソールのマルチクラスターエンジンを使用して、Red Hat OpenShift Container Platform クラスターを VMware vSphere にデプロイできます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの vSphere のインストール でプロセスの詳細を確認してください。

1.4.4.6.1. 前提条件

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

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスターが必要です。
  • ハブクラスターが vSphere に Kubernetes クラスターを作成できるようにするには、ハブクラスターにインターネットアクセスが必要です。
  • vSphere 認証情報がある。詳細は、VMware vSphere の認証情報の作成 を参照してください。
  • OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。
  • デプロイする VMware インスタンスについて、以下の情報がある。

    • API および Ingress インスタンスに必要な静的 IP アドレス
    • 以下の DNS レコード。

      • 静的 API VIP を指す api.<cluster_name>.<base_domain>
      • Ingress VIP の静的 IP アドレスを指す *.apps.<cluster_name>.<base_domain>

注記: VMware vSphere または Red Hat OpenStack Platform プロバイダーと切断されたインストールを使用してクラスターを作成する場合、ミラーレジストリーにアクセスするために証明書が必要であれば、切断されたインストールの設定セクション で認証情報の Additional trust bundle フィールドに証明書を入力する必要があります。クラスター作成コンソールエディターで入力することはできません。

1.4.4.6.2. コンソールを使用したクラスターの作成

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

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

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

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

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

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

1.4.4.6.3. クラスターを既存のクラスターセットに追加する

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

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

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

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

注記: OpenShift Container Platform バージョン 4.5.x 以降のリリースイメージのみがサポートされます。

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

  • アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。

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

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

  • vSphere ネットワーク名: VMware vSphere ネットワーク名を指定します。
  • API VIP: 内部 API 通信に使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して api. が正しく解決されるようにします。

  • Ingress VIP: Ingress トラフィックに使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して test.apps. が正しく解決されるようにします。

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

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

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリストを提供します。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加のトランスバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。

Disconnected installation をクリックして、切断されたインストールイメージを定義できます。VMware vSphere プロバイダーを使用してクラスターを作成し、切断されたインストールを行う場合、ミラーレジストリーにアクセスするために証明書が必要な場合は、切断されたインストールの設定セクションの認証情報の 追加の信頼バンドル フィールドに証明書を入力する必要があります。その証明書をクラスター作成コンソールエディターに入力すると、無視されます。

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

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

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

1.4.4.7. Red Hat OpenStack Platform でのクラスターの作成

Kubernetes Operator コンソールのマルチクラスターエンジンを使用して、Red Hat OpenStack Platform に Red Hat OpenShift Container Platform クラスターをデプロイできます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの OpenStack のインストール でプロセスの詳細を確認してください。

1.4.4.7.1. 前提条件

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

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスターが必要です。
  • ハブクラスターが Red Hat OpenStack Platform で Kubernetes クラスターを作成できるようにするには、ハブクラスターにインターネットアクセスが必要です。
  • Red Hat OpenStack Platform の認証情報がある。詳細は、Red Hat OpenStack Platform の認証情報の作成 を参照してください。
  • OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。
  • デプロイする Red Hat OpenStack Platform インスタンスについての以下の情報がある。

    • コントロールプレーンとワーカーインスタンスのフレーバー名 (例:m1.xlarge)
    • Floating IP アドレスを提供する外部ネットワークのネットワーク名
    • API および Ingress インスタンスに必要な静的 IP アドレス
    • 以下の DNS レコード。

      • API の Floating IP アドレスを指す api.<cluster_name>.<base_domain>
      • Ingreess の Floating IP アドレスを指す *.apps.<cluster_name>.<base_domain>
1.4.4.7.2. コンソールを使用したクラスターの作成

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

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

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

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

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

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

1.4.4.7.3. クラスターを既存のクラスターセットに追加する

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に 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 以降のリリースイメージのみがサポートされます。

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

  • (オプション) アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。
  • コントロールプレーンプールのインスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。

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

  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
  • ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。

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

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

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

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリストを定義します。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加のトランスバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。

Disconnected installation をクリックして、切断されたインストールイメージを定義できます。Red Hat OpenStack Platform プロバイダーを使用してクラスターを作成し、切断されたインストールを行う場合、ミラーレジストリーにアクセスするために証明書が必要な場合は、切断されたインストールの設定セクション の認証情報の 追加の信頼バンドル フィールドに証明書を入力する必要があります。.その証明書をクラスター作成コンソールエディターに入力すると、無視されます。

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

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

  1. レビューステップで YAML スイッチをオンにし、CA 証明書バンドルを使用してリストの上部に Secret オブジェクトを挿入します。注記: Red Hat OpenStack Platform 環境が複数の機関によって署名された証明書を使用してサービスを提供する場合、バンドルには、必要なすべてのエンドポイントを検証するための証明書を含める必要があります。ocp3 という名前のクラスターの追加は以下の例のようになります。

    apiVersion: v1
    kind: Secret
    type: Opaque
    metadata:
      name: ocp3-openstack-trust
      namespace: ocp3
    stringData:
      ca.crt: |
        -----BEGIN CERTIFICATE-----
        <Base64 certificate contents here>
        -----END CERTIFICATE-----
        -----BEGIN CERTIFICATE-----
        <Base64 certificate contents here>
        -----END CERTIFICATE----
  2. 以下の例のように、Hive ClusterDeployment オブジェクトを変更して、spec.platform.openstackcertificatesSecretRef の値を指定します。

    platform:
      openstack:
        certificatesSecretRef:
          name: ocp3-openstack-trust
        credentialsSecretRef:
          name: ocp3-openstack-creds
        cloud: openstack

    上記の例では、clouds.yaml ファイルのクラウド名が openstack であることを前提としています。

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

1.4.4.8. Red Hat Virtualization でのクラスターの作成

Kubernetes Operator コンソールのマルチクラスターエンジンを使用して、Red Hat Virtualization 上に Red Hat OpenShift Container Platform クラスターを作成できます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターを作成する場合、このプロセスの詳細について、OpenShift Container Platform ドキュメントの RHV へのインストール を参照してください。

1.4.4.8.1. 前提条件

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

  • Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジンがある。
  • Red Hat Virtualization で Kubernetes クラスターを作成できるように、Kubernetes Operator ハブクラスター用のマルチクラスターエンジンにインターネットアクセスが必要です。
  • Red Hat Virtualization の認証情報がある。詳細は、Red Hat Virtualization の認証情報の作成 を参照してください。
  • oVirt Engine 仮想マシンに設定されたドメインおよび仮想マシンプロキシーがある。ドメインの設定方法は、Red Hat OpenShift Container Platform ドキュメントの RHV へのインストール を参照してください。
  • Red Hat Virtualization のログイン認証情報 (Red Hat カスタマーポータルのユーザー名およびパスワードを含む) がある。
  • OpenShift Container Platform イメージプルシークレットがある。Pull secret からプルシークレットをダウンロードします。プルシークレットの詳細は、イメージプルシークレットの使用 を参照してください。

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

1.4.4.8.2. コンソールを使用したクラスターの作成

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

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

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

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

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

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

1.4.4.8.3. クラスターを既存のクラスターセットに追加する

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

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

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

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

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

  • アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。

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

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

  • oVirt ネットワーク名
  • API VIP: 内部 API 通信に使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して api. が正しく解決されるようにします。

  • Ingress VIP: Ingress トラフィックに使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して test.apps. が正しく解決されるようにします。

  • ネットワークタイプ: デフォルト値は OpenShiftSDN です。IPv6 を使用するには、OVNKubernetes の設定は必須です。
  • クラスターネットワーク CIDR: これは、Pod IP アドレスに使用できる IP アドレスの数およびリストです。このブロックは他のネットワークブロックと重複できません。デフォルト値は 10.128.0.0/14 です。
  • ネットワークホストの接頭辞: 各ノードのサブネット接頭辞の長さを設定します。デフォルト値は 23 です。
  • サービスネットワーク CIDR: サービスの IP アドレスのブロックを指定します。このブロックは他のネットワークブロックと重複できません。デフォルト値は 172.30.0.0/16 です。
  • マシン CIDR: OpenShift Container Platform ホストで使用される IP アドレスのブロックを指定します。このブロックは他のネットワークブロックと重複できません。デフォルト値は 10.0.0.0/16 です。

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

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

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリストを提供します。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加のトランスバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。

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

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

1.4.4.9. オンプレミス環境でのクラスターの作成

コンソールを使用して、オンプレミスの Red Hat OpenShift Container Platform クラスターを作成できます。非推奨となったベアメタルプロセスの代わりに、このプロセスを使用してください。

この手順を使用すると、VMware vSphere、Red Hat OpenStack、Red Hat Virtualization Platform、およびベアメタル環境で、単一ノード OpenShift (SNO) クラスター、マルチノードクラスター、およびコンパクトな 3 ノードクラスターを作成できます。

Red Hat OpenShift Container Platform で利用できる機能であるゼロタッチプロビジョニング機能を使用して、エッジリソース上に複数の単一ノード OpenShift クラスターをプロビジョニングすることもできます。詳細は、OpenShift Container Platform ドキュメントの 非接続環境でのスケールでの分散ユニットのデプロイ を参照してください。

1.4.4.9.1. 前提条件

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

  • ハブクラスターが OpenShift Container Platform バージョン 4.9 以降にデプロイされている。
  • 設定済みホストのホストインベントリーを備えた設定済みインフラストラクチャー環境が必要です。
  • クラスターの作成に必要なイメージを取得するには、ハブクラスターのインターネットアクセス (接続)、またはインターネットへの接続 (切断) を持つ内部またはミラーレジストリーへの接続が必要です。
  • オンプレミス認証情報が設定されている。
  • OpenShift Container Platform イメージプルシークレットがある。詳細については、イメージプルシークレットの使用 を参照してください。
1.4.4.9.2. コンソールを使用したクラスターの作成

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

  • クラスターのタイプとして Host inventory を選択します。

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

  • 既存の検出されたホストを使用する: 既存のホストインベントリーにあるホストのリストからホストを選択します。
  • 新規ホストの検出: 既存のインフラストラクチャー環境にないホストを検出します。インフラストラクチャー環境にあるものを使用するのではなく、独自のホストを検出します。

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

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

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

ヒント: 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 を入力できます。リリースイメージの詳細は、リリースイメージ を参照してください。

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

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

  1. コンソールから、Infrastructure > Clusters に移動し、作成したクラスターまたはアクセスするクラスターの名前を選択します。
  2. Actions > Add hosts を選択して、ワーカーを追加します。

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

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

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

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

既存のインフラストラクチャー環境がない新規ホストを検出する場合には、手順 4 から始まる インフラストラクチャー環境にホストをスケーリング してホストを定義します。

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

  • API VIP: 内部 API 通信に使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して api. が正しく解決されるようにします。

  • Ingress VIP: Ingress トラフィックに使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して test.apps. が正しく解決されるようにします。

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

1.4.4.10. ホステッドクラスターの作成 (テクノロジープレビュー)

Kubernetes Operator コンソール用のマルチクラスターエンジンを使用して、Red Hat OpenShift Container Platform がホストするクラスターを作成できます。

1.4.4.10.1. 前提条件

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

  • OpenShift Container Platform バージョン 4.6 以降で、Kubernetes Operator ハブクラスター用にデプロイされたマルチクラスターエンジンが必要です。
  • Kubernetes Operator ハブクラスター用のマルチクラスターエンジン (接続済み)のインターネットアクセス、またはクラスターの作成に必要なイメージを取得するために、インターネットへの接続 (切断済み) を持つ内部レジストリーまたはミラーレジストリーへの接続が必要です。
  • ホストされたコントロールプレーン Operator を有効にする必要があります。詳細については、ホスティングされたコントロールプレーンクラスターの使用 を参照してください。
  • OpenShift Container Platform イメージプルシークレットがある。詳細については、イメージプルシークレットの使用 を参照してください。
  • ホストが検出されたインフラストラクチャー環境が必要です。

    注意: インベントリーのホストと切断されたインストールを使用してクラスターを作成する場合は、切断されたインストールの設定 セクションの認証情報にすべての設定を保存する必要があります。クラスター作成コンソールエディターで入力することはできません。

1.4.4.10.2. ホストされたクラスターの作成

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

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、ハブクラスターへのターゲットマネージドクラスターのインポート の手順を参照してください。

重要: クラスターを作成すると、Kubernetes Operator コントローラー用のマルチクラスターエンジンによって、クラスターとそのリソースの名前空間が作成されます。その名前空間には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、名前空間とその中のすべてのリソースが削除されます。

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

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

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

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。ホストされたクラスターは、提供されたリリースイメージのいずれかを使用する必要があります。

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

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。

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

注意: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されません。

1.4.4.11. プロキシー環境でのクラスターの作成

ハブクラスターがプロキシーサーバー経由で接続されている場合は、Red Hat OpenShift Container Platform クラスターを作成できます。

クラスターの作成を成功させるには、以下のいずれかの状況が true である必要があります。

  • Kubernetes Operator には、作成しているマネージドクラスターとのプライベートネットワーク接続がありますが、Red Hat Advanced Cluster Management とマネージドクラスターはプロキシーを使用してインターネットにアクセスします。
  • マネージドクラスターはインフラストラクチャープロバイダーにありますが、ファイアウォールポートを使用することでマネージドクラスターからハブクラスターへの通信を有効にします。

プロキシーで設定されたクラスターを作成するには、以下の手順を実行します。

  1. 以下の情報を install-config.yaml ファイルに追加して、ハブクラスターに cluster-wide-proxy 設定を指定します。

    apiVersion: v1
    kind: Proxy
    baseDomain: <domain>
    proxy:
      httpProxy: http://<username>:<password>@<proxy.example.com>:<port>
      httpsProxy: https://<username>:<password>@<proxy.example.com>:<port>
      noProxy: <wildcard-of-domain>,<provisioning-network/CIDR>,<BMC-address-range/CIDR>

    username は、プロキシーサーバーのユーザー名に置き換えます。

    password は、プロキシーサーバーへのアクセス時に使用するパスワードに置き換えます。

    proxy.example.com は、プロキシーサーバーのパスに置き換えます。

    port は、プロキシーサーバーとの通信ポートに置き換えます。

    wildcard-of-domain は、プロキシーをバイパスするドメインのエントリーに置き換えます。

    provisioning-network/CIDR は、プロビジョニングネットワークの IP アドレスと割り当てられた IP アドレスの数 (CIDR 表記) に置き換えます。

    BMC-address-range/CIDR は、BMC アドレスおよびアドレス数 (CIDR 表記) に置き換えます。

    以前の値を追加すると、設定はクラスターに適用されます。

  2. クラスターの作成手順を実行してクラスターをプロビジョニングします。クラスターの作成 を参照してプロバイダーを選択します。

注: install-config YAML は、クラスターをデプロイする場合にのみ使用できます。クラスターをデプロイした後、install-config.yaml に加えた新しい変更は適用されません。導入後に設定を更新するには、ポリシーを作成する必要があります。詳細は、Pod ポリシー を参照してください。

1.4.4.11.1. 既存のクラスターアドオンでクラスター全体のプロキシーを有効にする

クラスター namespace で KlusterletAddonConfig を設定して、ハブクラスターが管理する Red Hat OpenShift Container Platform クラスターのすべての klusterlet アドオン Pod にプロキシー環境変数を追加できます。

KlusterletAddonConfig が 3 つの環境変数を klusterlet アドオンの Pod に追加するように設定するには、以下の手順を実行します。

  1. プロキシーを追加する必要のあるクラスターの namespace にある KlusterletAddonConfig ファイルを開きます。
  2. ファイルの .spec.proxyConfig セクションを編集して、以下の例のようにします。

    spec
      proxyConfig:
        httpProxy: "<proxy_not_secure>"
        httpsProxy: "<proxy_secure>"
        noProxy: "<no_proxy>"

    proxy_not_secure は、http 要求のプロキシーサーバーのアドレスに置き換えます。(例: http://192.168.123.145:3128)。

    proxy_secure は、https 要求のプロキシーサーバーのアドレスに置き換えます。例: https://192.168.123.145:3128

    no_proxy は、トラフィックがプロキシー経由でルーティングされない IP アドレス、ホスト名、およびドメイン名のコンマ区切りのリストに置き換えます。(例: .cluster.local,.svc,10.128.0.0/14,example.com)。

    spec.proxyConfig は任意のセクションです。OpenShift Container Platform クラスターがハブクラスターでクラスターワイドプロキシーを設定して作成されている場合は、以下の条件が満たされると、クラスターワイドプロキシー設定値が環境変数として klusterlet アドオンの Pod に追加されます。

    • addon セクションの .spec.policyController.proxyPolicy が有効になり、OCPGlobalProxy に設定されます。
    • .spec.applicationManager.proxyPolocy が有効になり、CustomProxy に設定されます。

      注記: addon セクションの proxyPolicy のデフォルト値は Disabled です。

      以下の例を参照してください。

      apiVersion: agent.open-cluster-management.io/v1
          kind: KlusterletAddonConfig
          metadata:
            name: clusterName
            namespace: clusterName
          spec:
            proxyConfig:
              httpProxy: http://pxuser:12345@10.0.81.15:3128
              httpsProxy: http://pxuser:12345@10.0.81.15:3128
              noProxy: .cluster.local,.svc,10.128.0.0/14, example.com
            applicationManager:
              enabled: true
              proxyPolicy: CustomProxy
            policyController:
              enabled: true
              proxyPolicy: OCPGlobalProxy
            searchCollector:
              enabled: true
              proxyPolicy: Disabled
            certPolicyController:
              enabled: true
              proxyPolicy: Disabled
            iamPolicyController:
              enabled: true
              proxyPolicy: Disabled

重要: グローバルプロキシー設定は、アラートの転送には影響しません。クラスター全体のプロキシーを使用して Red Hat Advanced Cluster Management ハブクラスターのアラート転送を設定する場合は、その詳細について アラートの転送 を参照してください。

1.4.5. 作成されたクラスターの休止 (テクノロジープレビュー)

リソースを節約するために、Kubernetes Operator 用のマルチクラスターエンジンを使用して作成されたクラスターを休止状態にすることができます。休止状態のクラスターに必要となるリソースは、実行中のものより少なくなるので、クラスターを休止状態にしたり、休止状態を解除したりすることで、プロバイダーのコストを削減できる可能性があります。この機能は、次の環境で Kubernetes Operator 用のマルチクラスターエンジンによって作成されたクラスターにのみ適用されます。

  • Amazon Web Services
  • Microsoft Azure
  • Google Cloud Platform

1.4.5.1. コンソールを使用したクラスターの休止

コンソールを使用して、Kubernetes Operator 用のマルチクラスターエンジンによって作成されたクラスターを休止状態にするには、次の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Clusters を選択します。Manage clusters タブが選択されていることを確認します。
  2. そのクラスターの Options メニューから Hibernate cluster を選択します。注記: Hibernate cluster オプションが利用できない場合には、クラスターを休止状態にすることはできません。これは、クラスターがインポートされ、Kubernetes Operator のマルチクラスターエンジンによって作成されていない場合に発生する可能性があります。

Clusters ページのクラスターのステータスは、プロセスが完了すると Hibernating になります。

ヒント: Clusters ページで休止するするクラスターを選択し、Actions > Hibernate cluster を選択して、複数のクラスターを休止できます。

選択したクラスターが休止状態になりました。

1.4.5.2. CLI を使用したクラスターの休止

CLI を使用して、Kubernetes Operator 用のマルチクラスターエンジンによって作成されたクラスターを休止状態にするには、次の手順を実行します。

  1. 以下のコマンドを入力して、休止するクラスターの設定を編集します。

    oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>

    name-of-cluster は、休止するクラスター名に置き換えます。

    namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

  2. spec.powerState の値は Hibernating に変更します。
  3. 以下のコマンドを実行して、クラスターのステータスを表示します。

    oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml

    name-of-cluster は、休止するクラスター名に置き換えます。

    namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

    クラスターを休止するプロセスが完了すると、クラスターのタイプの値は type=Hibernating になります。

選択したクラスターが休止状態になりました。

1.4.5.3. コンソールを使用して休止中のクラスターの通常操作を再開する手順

コンソールを使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Clusters を選択します。Manage clusters タブが選択されていることを確認します。
  2. 再開するクラスターの Options メニューから Resume cluster を選択します。

プロセスを完了すると、Clusters ページのクラスターのステータスは Ready になります。

ヒント: Clusters ページで、再開するクラスターを選択し、Actions > Resume cluster の順に選択して、複数のクラスターを再開できます。

選択したクラスターで通常の操作が再開されました。

1.4.5.4. CLI を使用して休止中のクラスターの通常操作を再開する手順

CLI を使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。

  1. 以下のコマンドを入力してクラスターの設定を編集します。

    oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>

    name-of-cluster は、休止するクラスター名に置き換えます。

    namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

  2. spec.powerState の値を Running に変更します。
  3. 以下のコマンドを実行して、クラスターのステータスを表示します。

    oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml

    name-of-cluster は、休止するクラスター名に置き換えます。

    namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

    クラスターの再開プロセスが完了すると、クラスターのタイプの値は type=Running になります。

選択したクラスターで通常の操作が再開されました。

1.4.6. ハブクラスターへのターゲットのマネージドクラスターのインポート

別の Kubernetes クラウドプロバイダーからクラスターをインポートできます。インポート後、対象のクラスターは、Kubernetes Operator ハブクラスターのマルチクラスターエンジンのマネージドクラスターになります。指定されていない場合は、ハブクラスターとターゲットのマネージドクラスターにアクセスできる場所で、インポートタスクを実行します。

ハブクラスターは のハブクラスターの管理はできず、自己管理のみが可能です。ハブクラスターは、自動的にインポートして自己管理できるように設定されています。ハブクラスターは手動でインポートする必要はありません。

ただし、ハブクラスターを削除して、もう一度インポートする場合は、local-cluster:true ラベルを追加する必要があります。

コンソールまたは CLI からのマネージドクラスターの設定は、以下の手順から選択します。

必要なユーザータイプまたはアクセスレベル: クラスター管理者

1.4.6.1. コンソールを使用した既存クラスターのインポート

Kubernetes Operator 用のマルチクラスターエンジンをインストールすると、クラスターをインポートして管理できるようになります。コンソールと CLI の両方からインポートできます。

コンソールからインポートするには、以下の手順に従います。この手順では、認証用にターミナルが必要です。

1.4.6.1.1. 前提条件
  • デプロイされたハブクラスターが必要です。ベアメタルクラスターをインポートする場合には、ハブクラスターを Red Hat OpenShift Container Platform バージョン 4.8 以降にインストールする必要があります。
  • 管理するクラスターとインターネット接続が必要である。
  • kubectl をインストールしておく必要がある。kubectl のインストール手順は、Kubernetes ドキュメントInstall and Set Up kubectl を参照してください。
  • Base64 コマンドラインツールが必要である。
  • 注意: OpenShift Container Platform によって作成されていないクラスターをインポートする場合は、multiclusterhub.spec.imagePullSecret を定義する必要があります。このシークレットは、Kubernetes Operator 用のマルチクラスターエンジンがインストールされたときに作成される可能性があります。

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

    1. cloud.redhat.com から Kubernetes プルシークレットをダウンロードします。
    2. プルシークレットをハブクラスターの namespace に追加します。
    3. 次のコマンドを実行して、open-cluster-management namespace に新しいシークレットを作成します。

      oc create secret generic pull-secret -n <open-cluster-management> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson

      open-cluster-management をハブクラスターの namespace の名前に置き換えます。ハブクラスターのデフォルトの名前空間は open-cluster-management です。

      path-to-pull-secret を、ダウンロードしたプルシークレットへのパスに置き換えます。

      シークレットは、インポート時にマネージドクラスターに自動的にコピーされます。

      プルシークレットの詳細は、イメージプルシークレットの使用 または サービスアカウントの理解と作成 を参照してください。

      このシークレットを定義する方法の詳細については、カスタムイメージプルシークレット を参照してください。

  • インポートするクラスターでエージェントが削除されていることを確認します。エラーを避けるために、open-cluster-management-agent および open-cluster-management-agent-addon namespace を削除する必要があります。
  • Red Hat OpenShift Dedicated 環境にインポートする場合には、以下の注意点を参照してください。

    • ハブクラスターを Red Hat OpenShift Dedicated 環境にデプロイしている必要があります。
    • Red Hat OpenShift Dedicated のデフォルトパーミッションは dedicated-admin ですが、namespace を作成するためのパーミッションがすべて含まれているわけではありません。Kubernetes Operator 用のマルチクラスターエンジンを使用してクラスターをインポートおよび管理するには、cluster-admin アクセス権が必要です。
  • インポートしたクラスターで自動化を有効にする場合は、Red Hat Ansible Automation Platform が必要です。

必要なユーザータイプまたはアクセスレベル: クラスター管理者

1.4.6.1.2. クラスターのインポート

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

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

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

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

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

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

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

次のリストは、クラスターをインポートする方法を指定する インポートモード で使用可能なオプションを示しています。

  • インポートコマンドを手動で実行する: Red Hat Ansible Automation Platform テンプレートを含む情報をコンソールに入力して送信したら、提供されたコマンドをターゲットクラスターで実行してクラスターをインポートします。Ansible Automation Platform ジョブを作成して実行するには、OperatorHub から Red Hat Ansible Automation Platform Resource Operator をインストールする必要があります。インポートコマンドを手動で実行するための追加手順 を続行します。
  • 既存のクラスターのサーバー URL および API トークンを入力する: インポートするクラスターの サーバー URL および API トークンを指定します。

    クラスターのアップグレード時に実行する Red Hat Ansible Automation Platform テンプレートを指定できます。Ansible Automation Platform ジョブを作成して実行するには、OperatorHub から Red Hat Ansible Automation Platform Resource Operator をインストールする必要があります。

    クラスター API アドレスを設定する場合は、オプション: クラスター API アドレスを設定する の手順を完了します。

  • kubeconfig ファイルを提供します。インポートするクラスターの kubeconfig ファイルの内容をコピーして貼り付けます。

    クラスターのアップグレード時に実行する Red Hat Ansible Automation Platform テンプレートを指定できます。Ansible Automation Platform ジョブを作成して実行するには、OperatorHub から Red Hat Ansible Automation Platform Resource Operator をインストールする必要があります。

    クラスター API アドレスを設定する場合は、オプション: クラスター API アドレスを設定する の手順に進みます。

1.4.6.1.2.1. インポートコマンドを手動で実行するための追加手順

指定されたコマンドをターゲットクラスターで実行して、クラスターをインポートします。

クラスターの詳細および自動化情報を送信したら、Copy command を選択して、生成されたコマンドおよびトークンをクリップボードにコピーします。

重要: コマンドには、インポートした各クラスターにコピーされるプルシークレット情報が含まれます。インポートしたクラスターにアクセスできるユーザーであれば誰でも、プルシークレット情報を表示することもできます。https://cloud.redhat.com/ で 2 つ目のプルシークレットを作成することを検討するか、サービスアカウントを作成して個人の認証情報を保護してください。

  1. インポートするマネージドクラスターにログインします。
  2. Red Hat OpenShift Dedicated 環境の場合のみ、次の手順を実行します (Red Hat OpenShift Dedicated 環境を使用していない場合は、手順 3 に進みます)。

    1. マネージドクラスターで open-cluster-management-agent および open-cluster-management namespace またはプロジェクトを作成します。
    2. OpenShift Container Platform カタログで klusterlet Operator を検索します。
    3. 作成した open-cluster-management namespace またはプロジェクトにインストールします。

      重要: open-cluster-management-agent namespace に Operator をインストールしないでください。

    4. 以下の手順を実行して、import コマンドからブートストラップシークレットをデプロイメントします。

      1. import コマンドを生成します。

        1. コンソールナビゲーションから Infrastructure > Clusters を選択します。
        2. Add a cluster > Import an existing cluster を選択します。
        3. クラスター情報を追加し、Save import and generate code を選択します。
      2. import コマンドをコピーします。
      3. import-command という名前で作成したファイルに、import コマンドを貼り付けます。
      4. 以下のコマンドを実行して、新しいファイルにコンテンツを挿入します。

        cat import-command | awk '{split($0,a,"&&"); print a[3]}' | awk '{split($0,a,"|"); print a[1]}' | sed -e "s/^ echo //" | base64 -d
      5. 出力で bootstrap-hub-kubeconfig という名前のシークレットを見つけ、コピーします。
      6. シークレットをマネージドクラスターの open-cluster-management-agent namespace に適用します。
      7. インストールした Operator の例を使用して klusterlet リソースを作成します。clusterName は、インポート中に設定されたクラスター名と同じ名前に変更する必要があります。

        注記: managedcluster リソースがハブに正しく登録されると、2 つの klusterlet Operator がインストールされます。klusterlet Operator の 1 つは open-cluster-management namespace に、もう 1 つは open-cluster-management-agent namespace にあります。Operator が複数あっても klusterlet の機能には影響はありません。

  3. Red Hat OpenShift Dedicated 環境に含まれていないクラスターのインポート: 以下の手順を実行します。

    1. 必要な場合は、マネージドクラスターの kubectl コマンドを設定します。
    2. マネージドクラスターに open-cluster-management-agent-addon をデプロイするには、コピーしたトークンでコマンドを実行します。
  4. View cluster をクリックして Overview ページのクラスターの概要を表示します。

    クラスターがインポートされると、クラスターの Cluster details ページで進行状況を表示できます。

クラスター API アドレスを設定する場合は、オプション: クラスター API アドレスを設定する の手順に進みます。

1.4.6.1.2.2. オプション: クラスター API アドレスを設定する

oc get managedcluster コマンドを実行する際に、テーブルに表示される URL を設定して、クラスターの詳細ページにある Cluster API アドレス を任意で設定できます。

  1. cluster-admin パーミッションがある ID でハブクラスターにログインします。
  2. ターゲットのマネージドクラスターの kubectl を設定します。
  3. 以下のコマンドを入力して、インポートしているクラスターのマネージドクラスターエントリーを編集します。

    oc edit managedcluster <cluster-name>

    cluster-name は、マネージドクラスターの名前に置き換えます。

  4. 以下の例のように、YAML ファイルの ManagedCluster 仕様に manageClusterClientConfigs セクションを追加します。

    spec:
      hubAcceptsClient: true
      managedClusterClientConfigs:
      - url: https://multicloud-console.apps.new-managed.dev.redhat.com

    URL の値を、インポートするマネージドクラスターへの外部アクセスを提供する URL に置き換えます。

1.4.6.1.3. インポートされたクラスターの削除

以下の手順を実行して、インポートされたクラスターと、マネージドクラスターで作成された 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 トピックを参照してください。

1.4.6.2. CLI を使用したマネージドクラスターのインポート

Kubernetes Operator 用のマルチクラスターエンジンをインストールしたら、Red Hat OpenShift Container Platform CLI を使用して管理するクラスターをインポートする準備が整います。インポートしているクラスターの kubeconfig ファイルを使用してクラスターをインポートするか、インポートしているクラスターで import コマンドを手動で実行できます。どちらの手順も文書化されています。

重要: ハブクラスターは別のハブクラスターを管理できません。ハブクラスターは、自動でインポートおよび自己管理するように設定されます。ハブクラスターは、手動でインポートして自己管理する必要はありません。ただし、ハブクラスターを削除して、もう一度インポートする場合は、local-cluster:true ラベルを追加する必要があります。

1.4.6.2.1. 前提条件
  • デプロイされたハブクラスターが必要です。ベアメタルクラスターをインポートする場合は、ハブクラスターを Red Hat OpenShift Container Platform バージョン 4.6 以降にインストールする必要があります。
  • インターネットに接続できる、管理する別のクラスターが必要です。
  • oc コマンドを実行するには、Red Hat OpenShift Container Platform の CLI バージョン 4.6 以降が必要である。Red Hat OpenShift Container Platform CLI (oc) のインストールおよび設定の詳細は、Getting started with the OpenShift CLI を参照してください。コンソールから CLI ツールのインストールファイルをダウンロードします。
  • Kubernetes CLI (kubectl) をインストールする必要がある。kubectl のインストール手順は、Kubernetes ドキュメントInstall and Set Up kubectl を参照してください。
  • OpenShift Container Platform によって作成されていないクラスターをインポートする場合は、multiclusterhub.spec.imagePullSecret を定義する必要があります。このシークレットは、Kubernetes Operator 用のマルチクラスターエンジンがインストールされたときに作成された可能性があります。このシークレットを定義する方法の詳細については、カスタムイメージプルシークレット を参照してください。
1.4.6.2.2. サポートされているアーキテクチャー
  • Linux (x86_64, s390x, ppc64le)
  • MacOS
1.4.6.2.3. インポートの準備
  1. 以下のコマンドを実行して ハブクラスター にログインします。

    oc login
  2. ハブクラスターで次のコマンドを実行して、プロジェクトおよび namespace を作成します。CLUSTER_NAME で定義したクラスター名は、YAML ファイルおよびコマンドでクラスターの namespace としても使用します。

    oc new-project ${CLUSTER_NAME}

    重要: cluster.open-cluster-management.io/managedCluster ラベルは、マネージドクラスターの namespace に対して自動的に追加および削除されます。マネージドクラスターに手動で追加したり、クラスターから削除したりしないでください。

  3. 以下の内容例で managed-cluster.yaml という名前のファイルを作成します。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: ${CLUSTER_NAME}
      labels:
        cloud: auto-detect
        vendor: auto-detect
    spec:
      hubAcceptsClient: true

    cloud および vendor の値を auto-detect する場合、Red Hat Advanced Cluster Management はインポートしているクラスターからクラウドおよびベンダータイプを自動的に検出します。オプションで、auto-detect の値をクラスターのクラウドおよびベンダーの値に置き換えることができます。以下の例を参照してください。

    cloud: Amazon
    vendor: OpenShift
  4. 以下のコマンドを入力して、YAML ファイルを ManagedCluster リソースに適用します。

    oc apply -f managed-cluster.yaml

次に、以下のいずれかの手順を実行してクラスターをインポートします。

1.4.6.2.4. 自動インポートシークレットを使用したクラスターのインポート

自動インポートシークレットでインポートするには、クラスターの kubeconfig ファイルを参照するか、クラスターの kube API サーバーおよびトークンのペアのいずれかの参照を含むシークレットを作成する必要があります。

  1. インポートしているクラスターの kubeconfig ファイルまたは kube API サーバーおよびトークンを取得します。kubeconfig ファイルまたは kube API サーバーおよびトークンの場所を特定する方法については、Kubernetes クラスターのドキュメントを参照してください。
  2. ${CLUSTER_NAME} namespace に auto-import-secret.yaml ファイルを作成します。

    1. 以下のテンプレートのようなコンテンツが含まれる auto-import-secret.yaml という名前の YAML ファイルを作成します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: auto-import-secret
        namespace: <cluster_name>
      stringData:
        autoImportRetry: "5"
        # If you are using the kubeconfig file, add the following value for the kubeconfig file
        # that has the current context set to the cluster to import:
        kubeconfig: |- <kubeconfig_file>
        # If you are using the token/server pair, add the following two values instead of
        # the kubeconfig file:
        token: <Token to access the cluster>
        server: <cluster_api_url>
      type: Opaque
    2. 次のコマンドを使用して、${CLUSTER_NAME} 名前空間の YAML ファイルを適用します。

      oc apply -f auto-import-secret.yaml

      注記: デフォルトでは、自動インポートシークレットは 1 回使用され、インポートプロセスの完了時に削除されます。自動インポートシークレットを保持する場合は、managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret をシークレットに追加します。これを追加するには、以下のコマンドを実行します。

    oc -n <cluster_name> annotate secrets auto-import-secret managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret=""
  3. インポートしたクラスターのステータス (JOINED および AVAILABLE) を確認します。ハブクラスターから以下のコマンドを実行します。

    oc get managedcluster ${CLUSTER_NAME}
  4. マネージドクラスターで次のコマンドを実行して、マネージドクラスターにログインします。

    oc login
  5. 次のコマンドを実行して、インポートするクラスターの Pod ステータスを検証します。

    oc get pod -n open-cluster-management-agent

に、klusterlet アドオンのインポート の手順を実行し ます。アドオンのインポートは、クラスターのインポートプロセス全体を完了するために必要な手順です。

1.4.6.2.5. 手動コマンドを使用したクラスターのインポート

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

  1. 以下のコマンドを実行して、ハブクラスターでインポートコントローラーによって生成された klusterlet-crd.yaml ファイルを取得します。

    oc get secret ${CLUSTER_NAME}-import -n ${CLUSTER_NAME} -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yaml
  2. 以下のコマンドを実行して、ハブクラスターにインポートコントローラーによって生成された import.yaml ファイルを取得します。

    oc get secret ${CLUSTER_NAME}-import -n ${CLUSTER_NAME} -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yaml

    インポートするクラスターで次の手順を実行します。

  3. 次のコマンドを入力して、インポートするマネージドクラスターにログインします。

    oc login
  4. 以下のコマンドを実行して、手順 1 で生成した klusterlet-crd.yaml を適用します。

    oc apply -f klusterlet-crd.yaml
  5. 以下のコマンドを実行して、以前に生成した import.yaml ファイルを適用します。

    oc apply -f import.yaml
  6. インポートしているクラスターの JOINED および AVAILABLE のステータスを検証します。ハブクラスターから以下のコマンドを実行します。

    oc get managedcluster ${CLUSTER_NAME}

に、klusterlet アドオンのインポート の手順を実行し ます。アドオンのインポートは、クラスターのインポートプロセス全体を完了するために必要な手順です。

1.4.6.2.6. klusterlet アドオンのインポート

以下の手順を実行して、klusterlet アドオン設定ファイルを作成および適用できます。

  1. 以下の例のような YAML ファイルを作成します。

    apiVersion: agent.open-cluster-management.io/v1
    kind: KlusterletAddonConfig
    metadata:
      name: <cluster_name>
      namespace: <cluster_name>
    spec:
      applicationManager:
        enabled: true
      certPolicyController:
        enabled: true
      iamPolicyController:
        enabled: true
      policyController:
        enabled: true
      searchCollector:
        enabled: true
  2. ファイルは klusterlet-addon-config.yaml として保存します。
  3. 以下のコマンドを実行して YAML を適用します。

    oc apply -f klusterlet-addon-config.yaml

    ManagedCluster-Import-Controller は ${CLUSTER_NAME}-import という名前のシークレットを生成します。${CLUSTER_NAME}-import シークレットには、import.yaml が含まれており、このファイルをユーザーがマネージドクラスターに適用して klusterlet をインストールします。

    アドオンは、インポートするクラスターの AVAILABLE の後にインストールされます。

  4. 次のコマンドを実行して、インポートするクラスター上のアドオンの Pod ステータスを検証します。

    oc get pod -n open-cluster-management-agent-addon
1.4.6.2.7. CLI でのインポートされたクラスターの削除

クラスターを削除するには、以下のコマンドを実行します。

oc delete managedcluster ${CLUSTER_NAME}

cluster_name は、クラスターの名前に置き換えます。

これでクラスターが削除されます。

1.4.6.3. カスタム ManagedClusterImageRegistry CRD を使用したクラスターのインポート

インポートするマネージドクラスターのイメージレジストリーをオーバーライドする必要がある場合があります。この方法は、ManagedClusterImageRegistry カスタムリソース定義 (CRD) を作成して実行できます。

ManagedClusterImageRegistry CRD は namespace スコープのリソースです。

ManagedClusterImageRegistry CRD は、配置が選択するマネージドクラスターのセットを指定しますが、カスタムイメージレジストリーとは異なるイメージが必要になります。マネージドクラスターが新規イメージで更新されると、識別用に各マネージドクラスターに、open-cluster-management.io/image-registry=<namespace>.<managedClusterImageRegistryName> のラベルが追加されます。

以下の例は、ManagedClusterImageRegistry CRD を示しています。

apiVersion: imageregistry.open-cluster-management.io/v1alpha1
kind: ManagedClusterImageRegistry
metadata:
  name: <imageRegistryName>
  namespace: <namespace>
spec:
  placementRef:
    group: cluster.open-cluster-management.io
    resource: placements
    name: <placementName>
  pullSecret:
    name: <pullSecretName>
  registries:
  - mirror: <mirrored-image-registry-address>
    source: <image-registry-address>
  - mirror: <mirrored-image-registry-address>
    source: <image-registry-address>

spec セクション:

  • placementName は、マネージドクラスターセットを選択する同じ namespace の Placement 名に置き換えます。
  • pullSecretName は、カスタムイメージレジストリーからイメージをプルするために使用されるプルシークレットの名前に置き換えます。
  • ソース および ミラー レジストリーのそれぞれの値をリスト表示します。mirrored-image-registry-address および image-registry-address は、レジストリーの各 ミラー および ソース 値に置き換えます。

    • 例 1: registry.redhat.io/rhacm2 という名前のソースイメージレジストリーを localhost:5000/rhacm2 に、registry.redhat.io/multicluster-enginelocalhost:5000/multicluster-engine に置き換えるには、以下の例を使用します。

      registries:
      - mirror: localhost:5000/rhacm2/
          source: registry.redhat.io/rhacm2
      - mirror: localhost:5000/multicluster-engine
          source: registry.redhat.io/multicluster-engine
    • 例 2: ソースイメージ registry.redhat.io/rhacm2/registration-rhel8-operatorlocalhost:5000/rhacm2-registration-rhel8-operator に置き換えるには、以下の例を使用します。

      registries:
      - mirror: localhost:5000/rhacm2-registration-rhel8-operator
          source: registry.redhat.io/rhacm2/registration-rhel8-operator
1.4.6.3.1. ManagedClusterImageRegistry CRD を使用したクラスターのインポート

ManagedClusterImageRegistry CRD でクラスターをインポートするには、以下の手順を実行します。

  1. クラスターをインポートする必要のある namespace にプルシークレットを作成します。これらの手順では、これは myNamespace です。

    $ kubectl create secret docker-registry myPullSecret \
      --docker-server=<your-registry-server> \
      --docker-username=<my-name> \
      --docker-password=<my-password>
  2. 作成した namespace に Placement を作成します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: myPlacement
      namespace: myNamespace
    spec:
      clusterSets:
      - myClusterSet
      tolerations:
      - key: "cluster.open-cluster-management.io/unreachable"
        operator: Exists

    注記: Placement がクラスターを選択できるようにするには、Toleration を unreachable に指定する必要があります。

  3. ManagedClusterSet リソースを作成し、これを namespace にバインドします。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: ManagedClusterSet
    metadata:
      name: myClusterSet
    
    ---
    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: ManagedClusterSetBinding
    metadata:
      name: myClusterSet
      namespace: myNamespace
    spec:
      clusterSet: myClusterSet
  4. namespace に ManagedClusterImageRegistry CRD を作成します。

    apiVersion: imageregistry.open-cluster-management.io/v1alpha1
    kind: ManagedClusterImageRegistry
    metadata:
      name: myImageRegistry
      namespace: myNamespace
    spec:
      placementRef:
        group: cluster.open-cluster-management.io
        resource: placements
        name: myPlacement
      pullSecret:
        name: myPullSecret
      registry: myRegistryAddress
  5. コンソールからマネージドクラスターをインポートし、マネージドクラスターセットに追加します。
  6. open-cluster-management.io/image-registry=myNamespace.myImageRegistry ラベルをマネージドクラスターに追加した後に、マネージドクラスターで import コマンドをコピーして実行します。

1.4.7. マネージメントからのクラスターの削除

Kubernetes Operator 用のマルチクラスターエンジンで作成された OpenShift Container Platform クラスターを管理から削除する場合は、それを デタッチ または 破壊 できます。クラスターをデタッチするとマネージメントから削除されますが、完全には削除されません。管理する場合には、もう一度インポートし直すことができます。このオプションは、クラスターが Ready 状態にある場合にだけ利用できます。

次の手順により、次のいずれかの状況でクラスターが管理から削除されます。

  • すでにクラスターを削除しており、削除したクラスターを Red Hat Advanced Cluster Management から削除したいと考えています。
  • クラスターを管理から削除したいが、クラスターを削除していない。

重要:

1.4.7.1. コンソールを使用したクラスターの削除

ナビゲーションメニューから、Infrastructure > Clusters に移動し、管理から削除するクラスターの横にあるオプションメニューから Destroy cluster または Detach cluster を選択します。

+ ヒント: 複数のクラスターをデタッチまたは破棄するには、デタッチまたは破棄するクラスターのチェックボックスを選択して、Detach または Destroy を選択します。

注記: 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 に変更して、自動的にインポートされないようにハブクラスターの値を変更できます。

1.4.7.2. コマンドラインを使用したクラスターの削除

ハブクラスターのコマンドラインを使用してマネージドクラスターをデタッチするには、以下のコマンドを実行します。

oc delete managedcluster $CLUSTER_NAME

デタッチ後にマネージドクラスターを削除するには、次のコマンドを実行します。

oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME

注記: 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 に変更して、自動的にインポートされないようにハブクラスターの値を変更できます。

1.4.7.3. クラスター削除後の残りのリソースの削除

削除したマネージドクラスターにリソースが残っている場合は、残りのすべてのコンポーネントを削除するための追加の手順が必要になります。これらの追加手順が必要な場合には、以下の例が含まれます。

  • マネージドクラスターは、完全に作成される前にデタッチされ、klusterlet などのコンポーネントはマネージドクラスターに残ります。
  • マネージドクラスターをデタッチする前に、クラスターを管理していたハブが失われたり、破棄されているため、ハブからマネージドクラスターをデタッチする方法はありません。
  • マネージドクラスターは、デタッチ時にオンライン状態ではありませんでした。

これらの状況の 1 つがマネージドクラスターのデタッチの試行に該当する場合は、マネージドクラスターから削除できないリソースがいくつかあります。マネージドクラスターをデタッチするには、以下の手順を実行します。

  1. oc コマンドラインインターフェイスが設定されていることを確認してください。
  2. また、マネージドクラスターに KUBECONFIG が設定されていることを確認してください。

    oc get ns | grep open-cluster-management-agent を実行すると、2 つの namespace が表示されるはずです。

    open-cluster-management-agent         Active   10m
    open-cluster-management-agent-addon   Active   10m
  3. 次のコマンドを実行して、残りのリソースを削除します。

    oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false
    oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false
    oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'
  4. 次のコマンドを実行して、namespaces と開いているすべてのクラスター管理 crds の両方が削除されていることを確認します。

    oc get crds | grep open-cluster-management.io | awk '{print $1}'
    oc get ns | grep open-cluster-management-agent

1.4.7.4. クラスターの削除後の etcd データベースのデフラグ

マネージドクラスターが多数ある場合は、ハブクラスターの etcd データベースのサイズに影響を与える可能性があります。OpenShift Container Platform 4.8 では、マネージドクラスターを削除すると、ハブクラスターの etcd データベースのサイズは自動的に縮小されません。シナリオによっては、etcd データベースは領域不足になる可能性があります。etcdserver: mvcc: database space exceeded のエラーが表示されます。このエラーを修正するには、データベース履歴を圧縮し、etcd データベースのデフラグを実行して etcd データベースのサイズを縮小します。

注記: OpenShift Container Platform バージョン 4.9 以降では、etcd Operator はディスクを自動的にデフラグし、etcd 履歴を圧縮します。手動による介入は必要ありません。以下の手順は、OpenShift Container Platform 4.8 以前のバージョン向けです。

以下の手順を実行して、ハブクラスターで etcd 履歴を圧縮し、ハブクラスターで etcd データベースをデフラグします。

1.4.7.4.1. 前提条件
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
1.4.7.4.2. 手順
  1. etcd 履歴を圧縮します。

    1. 次に、etcd メンバーへのリモートシェルセッションを開きます。

      $ oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w table
    2. 以下のコマンドを実行して etcd 履歴を圧縮します。

      sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" |  egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)

      出力例

      $ compacted revision 158774421

  2. Defragmenting etcd data で説明されているように、 etcd データベースを デフラグし、NOSPACE アラームを消去します。

1.4.8. マネージドクラスターのスケーリング

作成したクラスターについては、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をカスタマイズおよびサイズ変更できます。以下のオプションを参照してください。

1.4.8.1. MachinePool を使用したスケーリング (テクノロジープレビュー)

作成したクラスターについては、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をカスタマイズおよびサイズ変更できます。

テクノロジープレビュー: コンソールを使用した MachinePool スケーリングはプレビューステータスですが、MachinePool リソースは完全にサポートされています。

  • MachinePool リソースの使用は、ベアメタルクラスターではサポートされていない機能です。
  • MachinePool リソースは、ハブクラスター上の Kubernetes リソースで、MachineSet リソースをマネージドクラスターでグループ化します。
  • MachinePool リソースは、ゾーンの設定、インスタンスタイプ、ルートストレージなど、マシンリソースのセットを均一に設定します。
  • MachinePool では、マネージドクラスターで、必要なノード数を手動で設定したり、ノードの自動スケーリングを設定したりするのに役立ちます。
1.4.8.1.1. 自動スケーリング

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

1.4.8.1.1.1. 自動スケーリングの有効化
  • コンソールを使用して MachinePool リソースで自動スケーリングを有効にするには、以下の手順を実行します。

    1. Red Hat Advanced Cluster Management ナビゲーションで Infrastructure > Clusters に移動します。
    2. ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
    3. マシンプールページのターゲットマシンプールの Options メニューから Enable autoscale を選択します。
    4. マシンセットレプリカの最小数および最大数を選択します。マシンセットレプリカは、クラスターのノードに直接マップします。

      Scale をクリックした後、変更がコンソールに反映されるまでに数分かかる場合があります。Machine pools タブの通知がある場合は、View machines をクリックしてスケーリング操作のステータスを表示できます。

  • コマンドラインを使用して MachinePool リソースで自動スケーリングを有効にするには、以下の手順を実行します。

    1. 以下のコマンドを実行して、マシンプールのリストを表示します。

      oc get machinepools -n <managed-cluster-namespace>

      managed-cluster-namespace は、ターゲットのマネージドクラスターの namespace に置き換えます。

    2. 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。

      oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>

      name-of-MachinePool-resource は、MachinePool リソースの名前に置き換えます。

      namespace-of-managed-cluster は、マネージドクラスターの namespace 名に置き換えます。

    3. YAML ファイルから spec.replicas フィールドを削除します。
    4. spec.autoscaling.minReplicas 設定および spec.autoscaling.maxReplicas フィールドをリソース YAML に追加します。
    5. レプリカの最小数を minReplicas 設定に追加します。
    6. レプリカの最大数を maxReplicas 設定に追加します。
    7. ファイルを保存して変更を送信します。

マシンプールの自動スケーリングが有効になりました。

1.4.8.1.1.2. 自動スケーリングの無効化

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

  • コンソールを使用して自動スケーリングを無効にするには、次の手順を実行します。

    1. ナビゲーションで、Infrastructure > Clusters を選択します。
    2. ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
    3. マシンプールページから、ターゲットマシンプールの Options メニューから autoscale を無効にします。
    4. 必要なマシンセットのレプリカ数を選択します。マシンセットのレプリカは、クラスター上のノードを直接マップします。

      Scale をクリックした後、表示されるまでに数分かかる場合があります。Machine pools タブの通知で View machines をクリックすると、スケーリングの状態を表示できます。

  • コマンドラインを使用して自動スケーリングを無効にするには、以下の手順を実行します。

    1. 以下のコマンドを実行して、マシンプールのリストを表示します。

      oc get machinepools -n <managed-cluster-namespace>

      managed-cluster-namespace は、ターゲットのマネージドクラスターの namespace に置き換えます。

    2. 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。

      oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>

      name-of-MachinePool-resource は、MachinePool リソースの名前に置き換えます。

      namespace-of-managed-cluster は、マネージドクラスターの namespace 名に置き換えます。

    3. YAML ファイルから spec.autoscaling フィールドを削除します。
    4. spec.replicas フィールドをリソース YAML に追加します。
    5. replicas の設定にレプリカ数を追加します。
    6. ファイルを保存して変更を送信します。

1.4.8.2. Scaling hosts to an infrastructure environment

コンソールを使用して、ホストをインフラストラクチャー環境に追加できます。ホストを追加すると、クラスターの作成時に設定済みホストを簡単に選択できます。

以下の手順を実行して、新規スポットを追加します。

  1. ナビゲーションから、Infrastructure > Host inventory を選択します。
  2. ホストを追加するホストインベントリーを選択して、設定を表示します。
  3. ホスト タブを選択して、その環境にすでに追加されているホスト、またはホストを追加するホストを表示します。利用可能なホストが表に表示されるまでに数分かかる場合があります。
  4. Using a Discovery ISOWith BMC form、または By Uploading a YAML を選択して、ホストの情報を入力します。
  5. Using a Discovery ISO オプションを選択した場合は、次の手順を実行します。

    1. コンソールで提供されるコマンドをコピーして ISO をダウンロードするか、Download Discovery ISO を選択します。
    2. ブート可能なデバイスで以下のコマンドを実行し、各ホストを起動します。
    3. セキュリティーを強化する場合は、検出された各ホストに対して Approve host を選択します。この追加手順では、ISO ファイルが変更されたり、アクセス権のないユーザーにより実行された場合に備えて保護します。
    4. localhost に指定されたホスト名を一意の名前に変更します。
  6. With BMC form オプションを選択した場合は、次の手順を実行します。

    注記: ホストを追加する BMC オプションは、ハブクラスターのプラットフォームがベアメタル、Red Hat OpenStack Platform、VMware vSphere、またはユーザープロビジョニングのインフラストラクチャー (UPI) メソッドを使用してインストールされており、プラットフォームが None である場合にのみ使用できます。

    1. ホストの BMC の接続詳細を追加します。
    2. ホストの追加 を選択して、ブートプロセスを開始します。ホストは、検出 ISO イメージを使用して自動的に起動され、起動時にホストのリストに追加されます。

      BMC オプションを使用してホストを追加すると、ホストは自動的に承認されます。

  7. By uploading a YAML オプションを選択した場合は、次の手順を実行します。

    注意: YAML オプションを使用すると、複数のホストを同時にアップロードできます。

    1. Download template を選択して、提供された YAML に入力します。
    2. Upload を選択し、完成した YAML テンプレートに移動して、複数のホストを追加します。

このインフラストラクチャー環境にオンプレミスクラスターを作成できるようになりました。クラスターの作成の詳細については、オンプレミス環境でのクラスターの作成 を参照してください。

1.4.8.2.1. CIM でデプロイされた既存の OpenShift Container Platform クラスターへのノードの追加

CIM を使用してデプロイされた既存の OpenShift Container Platform クラスターにさらにノードを追加するには、前の手順を完了してから、新しい Agent カスタムリソース定義を agentSelector パラメーターに追加して ClusterDeployment カスタムリソースに関連付けます。

1.4.9. クラスタープロキシーアドオンの使用

一部の環境では、マネージドクラスターはファイアウォールの背後にあり、ハブクラスターから直接アクセスすることはできません。アクセスを取得するには、プロキシーアドオンを設定してマネージドクラスターの kube-apiserver にアクセスし、よりセキュアな接続を提供できます。

必要なアクセス: 編集

ハブクラスターとマネージドクラスターのクラスタープロキシーアドオンを設定するには、次の手順を実行します。

  1. 次の手順を実行してマネージドクラスター kube-apiserver にアクセスするように kubeconfig ファイルを設定します。

    1. マネージドクラスターに有効なアクセストークンを指定します。

      注記: サービスアカウントの対応するトークンを使用できます。デフォルトの namespace にあるデフォルトのサービスアカウントを使用することもできます。

      1. 次のコマンドを実行して、マネージドクラスターの kubeconfig ファイルをエクスポートします。

        export KUBECONFIG=<managed-cluster-kubeconfig>
      2. 次のコマンドを実行して、Pod へのアクセス権があるロールをサービスアカウントに追加します。

        oc create role -n default test-role --verb=list,get --resource=pods
        oc create rolebinding -n default test-rolebinding --serviceaccount=default:default --role=test-role
      3. 次のコマンドを実行して、サービスアカウントトークンのシークレットを見つけます。

        oc get secret -n default | grep <default-token>

        default-token は、シークレット名に置き換えます。

      4. 次のコマンドを実行して、トークンをコピーします。

        export MANAGED_CLUSTER_TOKEN=$(kubectl -n default get secret <default-token> -o jsonpath={.data.token} | base64 -d)

        default-token は、シークレット名に置き換えます。

    2. Red Hat Advanced Cluster Management ハブクラスターで kubeconfig ファイルを設定します。

      1. 次のコマンドを実行して、ハブクラスター上の現在の kubeconfig ファイルをエクスポートします。

        oc config view --minify --raw=true > cluster-proxy.kubeconfig
      2. エディターで server ファイルを変更します。この例では、sed の使用時にコマンドを使用します。OSX を使用している場合は、alias sed=gsed を実行します。

        export TARGET_MANAGED_CLUSTER=<managed-cluster-name>
        
        export NEW_SERVER=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/$TARGET_MANAGED_CLUSTER
        
        sed -i'' -e '/server:/c\    server: '"$NEW_SERVER"'' cluster-proxy.kubeconfig
        
        export CADATA=$(oc get configmap -n openshift-service-ca kube-root-ca.crt -o=go-template='{{index .data "ca.crt"}}' | base64)
        
        sed -i'' -e '/certificate-authority-data:/c\    certificate-authority-data: '"$CADATA"'' cluster-proxy.kubeconfig

        cluster1 は、アクセスするマネージドクラスター名に置き換えます。

      3. 次のコマンドを入力して、元のユーザー認証情報を削除します。

        sed -i'' -e '/client-certificate-data/d' cluster-proxy.kubeconfig
        sed -i'' -e '/client-key-data/d' cluster-proxy.kubeconfig
        sed -i'' -e '/token/d' cluster-proxy.kubeconfig
      4. サービスアカウントのトークンを追加します。

        sed -i'' -e '$a\    token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfig
  2. 次のコマンドを実行して、ターゲットマネージドクラスターのターゲット namespace にあるすべての Pod をリスト表示します。

    oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>

    default namespace は、使用する namespace に置き換えます。

  3. マネージドクラスター上の他のサービスにアクセスします。この機能は、マネージドクラスターが Red Hat OpenShift Container Platform クラスターの場合に利用できます。サービスは service-serving-certificate を使用してサーバー証明書を生成する必要があります。

    • マネージドクラスターから、以下のサービスアカウントトークンを使用します。

      export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)
  4. ハブクラスターから、以下のコマンドを実行して認証局をファイルに変換します。

    oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crt

1.4.10. 特定のクラスター管理ロールの設定

Kubernetes Operator 用のマルチクラスターエンジンをインストールすると、デフォルトの設定により、ハブクラスターで cluster-admin ロールが提供されます。このパーミッションを使用すると、ハブクラスターでマネージドクラスターを作成、管理、およびインポートできます。状況によっては、ハブクラスターのすべてのマネージドクラスターへのアクセスを提供するのではなく、ハブクラスターが管理する特定のマネージドクラスターへのアクセスを制限する必要がある場合があります。

クラスターロールを定義し、ユーザーまたはグループに適用することで、特定のマネージドクラスターへのアクセスを制限できます。ロールを設定して適用するには、以下の手順を実行します。

  1. 以下の内容を含む YAML ファイルを作成してクラスターロールを定義します。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: <clusterrole-name>
    rules:
    - apiGroups:
      - cluster.open-cluster-management.io
      resources:
      - managedclusters
      resourceNames:
      - <managed-cluster-name>
      verbs:
      - get
      - list
      - watch
      - update
      - delete
      - deletecollection
      - patch
    - apiGroups:
      - cluster.open-cluster-management.io
      resources:
      - managedclusters
      verbs:
      - create
    - apiGroups:
      - ""
      resources:
      - namespaces
      resourceNames:
      - <managed-cluster-name>
      verbs:
      - create
      - get
      - list
      - watch
      - update
      - delete
      - deletecollection
      - patch
    - apiGroups:
      - register.open-cluster-management.io
      resources:
      - managedclusters/accept
      resourceNames:
      - <managed-cluster-name>
      verbs:
      - update

    clusterrole-name は、作成するクラスターロールの名前に置き換えます。

    managed-cluster-name は、ユーザーにアクセスを許可するマネージドクラスターの名前に置き換えます。

  2. 以下のコマンドを入力して clusterrole 定義を適用します。

    oc apply -f <filename>

    filename を、先の手順で作成した YAML ファイルの名前に置き換えます。

  3. 以下のコマンドを入力して、clusterrole を指定されたユーザーまたはグループにバインドします。

    oc adm policy add-cluster-role-to-user <clusterrole-name> <username>

    clusterrole-name を、直前の手順で適用したクラスターロールの名前に置き換えます。username を、クラスターロールをバインドするユーザー名に置き換えます。

1.4.11. クラスターラベルの管理

クラスターにラベルを追加してグループリソースを選択します。詳細は、Labels and Selectors を参照してください。

クラスターの新規ラベルの追加、既存ラベルの削除、既存ラベルの編集が可能です。

ラベルを管理するには、Infrastructure > Clusters に移動し、Clusters の表でクラスターを見つけます。クラスターの Options メニューを使用して Edit labels を選択します。

  • 新しいラベルを追加するには、Edit labels ダイアログボックスにラベルを入力します。エントリーは Key=Value の形式である必要があります。複数のラベルを追加する場合は、Enter キーを押すか、コンマを追加するか、ラベル間にスペースを追加して、ラベルを区切ります。

    Save をクリックしてからでないと、ラベルは保存されません。

  • 既存のラベルを削除するには、リストから削除するラベルの Remove アイコンをクリックします。
  • 既存のラベルを更新する場合は、同じキーに別の値を使用して、新規ラベルを追加すると、新しい値にキーを再割り当てすることができます。たとえば、Key=Value を変更するには、Key=NewValue を入力して Key の値を更新します。

ヒント: クラスターの詳細ページからクラスターラベルを編集することもできます。ナビゲーションメニューから Infrastructure > Clusters をクリックします。Clusters ページで、クラスターの名前をクリックしてクラスターの詳細ページにアクセスします。Labels セクションの Edit アイコンをクリックします。Edit labels ダイアログボックスが表示されます。

1.4.12. マネージドクラスターで実行する Ansible Tower タスクの設定

Kubernetes Operator 用のマルチクラスターエンジンは Ansible Tower 自動化と統合されているため、クラスターの作成またはアップグレードの前または後に発生するプリフックおよびポストフックの AnsibleJob インスタンスを作成できます。クラスター破棄の prehook および posthook ジョブの設定やクラスターのスケールアクションはサポートされません。

必要なアクセス権限: クラスターの管理者

1.4.12.1. 前提条件

クラスターで Ansible テンプレートを実行するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform 4.6 以降
  • Ansible Automation Platform Resource Operator をインストールして、Ansible ジョブを Git サブスクリプションのライフサイクルに接続している。AnsibleJob を使用した Ansible Tower ジョブの実行時に最善の結果を得るには、実行時に Ansible Tower ジョブテンプレートが冪等でなければなりません。Ansible Automation Platform Resource Operator は、Red Hat OpenShift Container Platform OperatorHub ページから検索できます。

Ansible Tower 自動化のインストールおよび設定に関する詳細は、Ansible Tower タスクの設定 を参照してください。

1.4.12.2. コンソールでを使用したクラスターでの実行用の AnsibleJob テンプレート設定

クラスターの作成時、クラスターのインポート時、またはクラスターの作成後に、クラスターに使用する Ansible ジョブテンプレートを指定できます。

クラスターの作成時またはインポート時にテンプレートを指定するには、Automation の手順でクラスターに適用する Ansible テンプレートを選択します。Ansible テンプレートがない場合は、Add automation template をクリックして作成します。

クラスターの作成後にテンプレートを指定するには、既存のクラスターのアクションメニューで Update automation template をクリックします。Update automation template オプションを使用して、既存の自動化テンプレートを更新することもできます。

1.4.12.3. AnsibleJob テンプレートの作成

クラスターのインストールまたはアップグレードで Ansible ジョブを開始するには、ジョブ実行のタイミングを指定する Ansible ジョブテンプレートを作成する必要があります。これらは、クラスターのインストールまたはアップグレード前後に実行するように設定できます。

テンプレートの作成時に Ansible テンプレートの実行に関する詳細を指定するには、コンソールで以下の手順を実行します。

  1. ナビゲーションから Infrastructure > Automation を選択します。
  2. 状況に適したパスを選択します。

    • 新規テンプレートを作成する場合には、Create Ansible template をクリックして手順 3 に進みます。
    • 既存のテンプレートを変更する場合は、変更するテンプレートの Options メニューの Edit template をクリックして、手順 5 に進みます。
  3. 一意のテンプレート名を入力します。名前には小文字の英数字またはハイフン (-) を指定してください。
  4. 新規テンプレートの認証情報を選択します。Ansible 認証情報を Ansible テンプレートにリンクするには、以下の手順を実行します。

    1. ナビゲーションから Automation を選択します。認証情報にリンクされていないテンプレートの一覧内のテンプレートには、テンプレートを既存の認証情報にリンクするために使用できるリンク 認証情報へのリンク アイコンが含まれています。テンプレートと同じ namespace の認証情報のみが表示されます。
    2. 選択できる認証情報がない場合や、既存の認証情報を使用しない場合は、リンクするテンプレートの Options メニューから Edit template を選択します。
    3. 認証情報を作成する場合は、Add credential をクリックして、Ansible Automation Platform の認証情報の作成 の手順を行います。
    4. テンプレートと同じ namespace に認証情報を作成したら、テンプレートの編集時に Ansible Automation Platform credential フィールドで認証情報を選択します。
  5. クラスターをインストールする前に Ansible ジョブを開始する場合は、Pre-install Ansible job templates セクションで Add an Ansible job template を選択します。
  6. prehook および posthook Ansible ジョブを選択するか、名前を入力して、クラスターのインストールまたはアップグレードに追加します。

    注記: Ansible job template name は、Ansible Tower の Ansible ジョブの名前と一致している必要があります。

  7. 必要に応じて、Ansible ジョブをドラッグして、順番を変更します。
  8. Post-install Ansible job templates セクション、Pre-upgrade Ansible job templates セクション、および Post-upgrade Ansible job templates セクションで、クラスターがインストール後に開始する Ansible ジョブテンプレートに対して、手順 5-7 を繰り返します。

Ansible テンプレートは、指定のアクションが起こるタイミングで、このテンプレートを指定するクラスターで実行するように設定されます。

1.4.12.4. Ansible ジョブのステータスの表示

実行中の Ansible ジョブのステータスを表示して、起動し、正常に実行されていることを確認できます。実行中の Ansible ジョブの現在のステータスを表示するには、以下の手順を実行します。

  1. メニューで、Infrastructure > Clusters を選択して、Clusters ページにアクセスします。
  2. クラスターの名前を選択して、その詳細を表示します。
  3. クラスター情報で Ansible ジョブの最後の実行ステータスを表示します。エントリーには、以下のステータスの 1 つが表示されます。

    • インストール prehook または posthook ジョブが失敗すると、クラスターのステータスは Failed と表示されます。
    • アップグレード prehook または posthook ジョブが失敗すると、アップグレードに失敗した Distribution フィールドに警告が表示されます。

      ヒント: クラスターの prehook または posthook が失敗した場合は、Clusters ページからアップグレードを再試行できます。

1.4.13. ManagedClusterSets の作成および管理

ManagedClusterSet は、マネージドクラスターのグループです。マネージドクラスターセットでは、グループ内の全マネージドクラスターに対するアクセス権を管理できます。ManagedClusterSetBinding リソースを作成して ManagedClusterSet リソースを namespace にバインドすることもできます。

各マネージドクラスターは、マネージドクラスターセットのメンバーである必要があります。ハブクラスターをインストールすると、default と呼ばれるデフォルトの ManagedClusterSet リソースが作成されます。マネージドクラスターセットに特に割り当てられていないマネージドクラスターはすべて、デフォルト のマネージドクラスターセットに自動的に割り当てられます。デフォルトのマネージドクラスターセットを常に利用可能にするには、デフォルト のマネージドクラスターセットを削除したり、更新したりできません。

注意: マネージドクラスターセットに明確に追加されていないクラスタープールは、デフォルトの ManagedClusterSet リソースに追加されません。マネージドクラスターがクラスタープールから要求された後、マネージドクラスターはデフォルトの ManagedClusterSet に追加されます。

1.4.13.1. Global ManagedClusterSet

マネージドクラスターを作成すると、管理を容易にするために次のものが自動的に作成されます。

  • global と呼ばれる ManagedClusterSet
  • open-cluster-management-global-set という namespace。
  • global と呼ばれる ManagedClusterSetBinding は、global ManagedClusterSetopen-cluster-management-global-set namespace にバインドします。

    重要: global マネージドクラスターセットを削除、更新、または編集することはできません。global マネージドクラスターセットには、すべてのマネージドクラスターが含まれます。以下の例を参照してください。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: ManagedClusterSetBinding
    metadata:
      name: global
      namespace: open-cluster-management-global-set
    spec:
      clusterSet: global

マネージドクラスターセットの更新の詳細については、以下を参照してください。

1.4.13.2. ManagedClusterSet の作成

マネージドクラスターセットにマネージドクラスターをグループ化して、マネージドクラスターでのユーザーのアクセス権限を制限できます。

必要なアクセス権限: クラスターの管理者

ManagedClusterSet は、クラスタースコープのリソースであるため、ManagedClusterSet の作成先となるクラスターで管理者権限が必要です。マネージドクラスターは、複数の ManagedClusterSet に追加できません。マネージドクラスターセットは、Kubernetes Operator コンソール用のマルチクラスターエンジンまたはコマンドラインインターフェイスから作成できます。

1.4.13.2.1. コンソールを使用した ManagedClusterSet の作成

コンソールを使用して、マネージドクラスターセットを作成するには、以下の手順を実行します。

  1. メインコンソールナビゲーションで Infrastructure > Clusters を選択し、Cluster sets タブが選択されていることを確認します。
  2. Create cluster set を選択し、クラスターセットの名前を入力します。
1.4.13.2.2. コマンドラインを使用した ManagedClusterSet の作成

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

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ManagedClusterSet
metadata:
  name: <clusterset1>

clusterset1 はマネージドクラスターセットの名前に置き換えます。

1.4.13.3. ManagedClusterSet に対するユーザーまたはグループのロールベースのアクセス制御パーミッションの割り当て

ハブクラスターに設定したアイデンティティープロバイダーが提供するクラスターセットに、ユーザーまたはグループを割り当てることができます。

必要なアクセス権限: クラスターの管理者

ManagedClusterSet API が提供する RBAC パーミッションにはレベルが 3 つあります。

  • クラスターセット admin

    • マネージドクラスターセットに割り当てられた、すべてのクラスターおよびクラスタープールリソースに対する完全なアクセス権限。
    • クラスターの作成、クラスターのインポート、クラスタープールの作成権限。パーミッションは、マネージドクラスターセットの作成時に設定したマネージドクラスターに割り当てる必要があります。
  • クラスターセット bind

    • ManagedClusterSetBinding を作成してクラスターセットを namespace にバインドするアクセス許可。ユーザーまたはグループには、ターゲット namespace で ManagedClusterSetBinding を作成する権限も必要です。
    • マネージドクラスターセットに割り当てられた、すべてのクラスターおよびクラスタープールリソースに対する読み取り専用の権限。
    • クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。
  • クラスターセット view

    • マネージドクラスターセットに割り当てられた、すべてのクラスターおよびクラスタープールリソースに対する読み取り専用の権限。
    • クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。

注意: グローバルクラスターセットにクラスターセット admin 権限を適用することはできません。

コンソールからマネージドクラスターセットにユーザーまたはグループを割り当てるには、次の手順を実行します。

  1. コンソールのメインナビゲーションメニューで、Infrastructure > Clusters を選択します。
  2. Cluster sets タブを選択します。
  3. ターゲットクラスターセットを選択します。
  4. Access management タブを選択します。
  5. Add user or group を選択します。
  6. アクセス権を割り当てるユーザーまたはグループを検索して選択します。
  7. Cluster set admin または Cluster set view ロールを選択して、選択したユーザーまたはグループに付与します。ロールの権限の詳細については、ロールの概要 を参照してください。
  8. Add を選択して変更を送信します。

テーブルにユーザーまたはグループが表示されます。全マネージドクラスターセットリソースのパーミッションの割り当てがユーザーまたはグループに伝播されるまでに数秒かかる場合があります。

ロールベースのアクションの詳細については、ロールベースのアクセス制御 を参照してください。

配置情報については、配置での ManagedClusterSets の使用 を参照してください。

1.4.13.3.1. ManagedClusterSetBinding リソースの作成

ManagedClusterSetBinding リソースを作成して ManagedClusterSet リソースを namespace にバインドします。同じ namespace で作成されたアプリケーションおよびポリシーがアクセスできるのは、バインドされたマネージドクラスターセットリソースに含まれるマネージドクラスターだけです。

namespace へのアクセスパーミッションは、その namespace にバインドされるマネージドクラスターセットに自動的に適用されます。マネージドクラスターセットがバインドされる namespace へのアクセス権限がある場合は、その namespace にバインドされているマネージドクラスターセットにアクセス権限が自動的に付与されます。ただし、マネージドクラスターセットへのアクセス権限のみがある場合は、対象の namespace にある他のマネージドクラスターセットにアクセスする権限は自動的に割り当てられません。マネージドクラスターセットが表示されない場合は、表示に必要なパーミッションがない可能性があります。

コンソールまたはコマンドラインを使用してマネージドクラスターセットバインディングを作成できます。

1.4.13.3.1.1. コンソールを使用した ManagedClusterSetBinding の作成

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

  1. メインナビゲーションで Infrastructure > Clusters を選択し、Cluster sets タブを選択します。
  2. バインディングを作成するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
  3. Actions > Edit namespace bindings を選択します。
  4. Edit namespace bindings ページで、ドロップダウンメニューからクラスターセットをバインドする namespace を選択します。このクラスターセットにバインディングされている既存の namespace は選択してあります。
1.4.13.3.1.2. コマンドラインを使用した ManagedClusterSetBinding の作成

コマンドラインを使用してマネージドクラスターセットバインディングを作成するには、以下の手順を実行します。

  1. yaml ファイルに ManagedClusterSetBinding リソースを作成します。クラスターセットバインディングの作成時には、クラスターセットバインディング名と、バインドするマネージドクラスターセット名を一致させる必要があります。ManagedClusterSetBinding リソースは、以下の情報のようになります。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: ManagedClusterSetBinding
    metadata:
      namespace: project1
      name: clusterset1
    spec:
      clusterSet: clusterset1
  2. ターゲットのマネージドクラスターセットでのバインド権限を割り当てておく必要があります。以下の ClusterRole リソースの例を確認してください。この例には、ユーザーが clusterset1 にバインドできるように、複数のルールが含まれています。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: clusterrole1
    rules:
      - apiGroups: ["cluster.open-cluster-management.io"]
        resources: ["managedclustersets/bind"]
        resourceNames: ["clusterset1"]
        verbs: ["create"]

1.4.13.4. クラスターの ManagedClusterSet への追加

ManagedClusterSet の作成後に、1 つ以上のマネージドクラスターを追加する必要があります。コンソールまたはコマンドラインのいずれかを使用して、マネージドクラスターをマネージドクラスターセットに追加できます。

1.4.13.4.1. コンソールを使用したクラスターの ManagedClusterSet への追加

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

  1. マネージドクラスターセットを作成している場合は、Manage resource assignments を選択して、Manage resource assignments ページに直接移動します。この手順のステップ 6 に進みます。
  2. クラスターがすでに存在する場合は、メインのナビゲーションで Infrastructure > Clusters を選択してクラスターページにアクセスします。
  3. Cluster sets タブを選択して、利用可能なクラスターセットを表示します。
  4. マネージドクラスターセットに追加するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
  5. Actions > Manage resource assignments を選択します。
  6. Manage resource assignments ページで、クラスターセットに追加するリソースのチェックボックスを選択します。
  7. Review を選択して変更を確認します。
  8. Save を選択して変更を保存します。

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

1.4.13.4.2. コマンドラインを使用した ManagedClusterSet へのクラスターの追加

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

  1. managedclustersets/join の仮想サブリソースに作成できるように、RBAC ClusterRole エントリーが追加されていることを確認します。このパーミッションがない場合は、マネージドクラスターを ManagedClusterSet に割り当てることはできません。

    このエントリーが存在しない場合は、yaml ファイルに追加します。サンプルエントリーは以下の内容のようになります。

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: clusterrole1
    rules:
      - apiGroups: ["cluster.open-cluster-management.io"]
        resources: ["managedclustersets/join"]
        resourceNames: ["<clusterset1>"]
        verbs: ["create"]

    clusterset1ManagedClusterSet の名前に置き換えます。

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

  2. yaml ファイルでマネージドクラスターの定義を検索します。ラベルの追加先のマネージドクラスター定義のセクションは、以下の内容のようになります。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: cluster1
    spec:
      hubAcceptsClient: true

    この例では、cluster1 はマネージドクラスターの名前です。

  3. ManagedClusterSet の名前を cluster.open-cluster-management.io/clusterset: clusterset1 形式で指定してラベルを追加します。

    コードは以下の例のようになります。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: cluster1
      labels:
        cluster.open-cluster-management.io/clusterset: clusterset1
    spec:
      hubAcceptsClient: true

    この例では、cluster1 は、clusterset1 のマネージドクラスターセット名に追加するクラスターです。

    注記: マネージドクラスターが削除済みのマネージドクラスターセットにこれまでに割り当てられていた場合は、すでに存在しないクラスターが指定されたマネージドクラスターセットがマネージドクラスターに設定されている可能性があります。その場合は、名前を新しい名前に置き換えます。

1.4.13.5. Placement での ManagedClusterSets の使用

Placement リソースは、namespace レベルのリソースで、placement namespace にバインドされる ManagedClusterSets から ManagedClusters セットを選択するルールを定義します。

必要なアクセス権限: クラスター管理者またはクラスターセット管理者。

1.4.13.5.1. 配置の概要

マネージドクラスターを使用した配置がどのように機能するかについては、次の情報を参照してください。

  • Kubernetes クラスターは、cluster スコープの ManagedClusters としてハブクラスターに登録されます。
  • managedcluster は、クラスタースコープの ManagedClusterSets に編成されます。
  • ManagedClusterSets はワークロード namespace にバインドされます。
  • namespace スコープの Placements は、ManagedClusterSets の一部を指定して、ManagedClusters 候補の作業セットを選択します。
  • Placements は、ラベルと要求セレクターを使用して作業セットから選択します。

    重要: Placement では、placement namespace に ManagedClusterSet がバインドされていない場合、ManagedCluster は選択されません。

  • ManagedClusters の配置は、テイントおよび容認 (Toleration) を使用して制御できます。詳細は、Taint と Toleration を使用したマネージドクラスターの配置 を参照してください。

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

  • ClusterSets は、ManagedClusters の選択元の ManagedClusterSets を表します。

    • 指定されていない場合は、Placement namespace にバインドされる ManagedClusterSets から ManagedClusters が選択されます。
    • 指定されている場合は、ManagedClusters がこのセットの交差部分から選択され、ManagedClusterSets は Placement namespace にバインドされます。
  • NumberOfClusters は、配置要件を満たす ManagedClusters の中から選択する数を表します。

    指定されていない場合は、配置要件を満たすすべての ManagedClusters が選択されます。

  • Predicates は、ラベルおよび要求セレクターで ManagedClusters を選択する述語のスライスを表します。述語は ORed です。
  • prioritizerPolicy は優先順位のポリシーを表します。

    • モードExactAdditive、 または "" のいずれかになります。ここで "" はデフォルトで Additive になります。

      • Additive モードでは、設定値が特に指定されていない Prioritizer はデフォルト設定で有効になっています。現在のデフォルト設定では、SteadyBalance の重みは 1 で、他の Prioritizer は 0 になります。デフォルトの設定は、今後変更される可能性があるので、優先順位が変更される可能性があります。Additive モードでは、すべての Prioritizer を設定する必要はありません。
      • Exact モードでは、設定値で特に指定されていない Prioritizer の重みがゼロになります。Exact モードでは、必要な Prioritizer の完全なセットを入力する必要がありますが、リリースごとに動作が変わることはありません。
    • 設定 とは、Prioritizer の設定を表します。

      • scoreCoordinate は prioritizer およびスコアソースの設定を表します。

        • type は prioritizer スコアのタイプを定義します。タイプは BuiltInAddOn、または " " です。" " のデフォルトは BuiltIn です。タイプが BuiltIn の場合、prioritizer 名を指定する必要があります。タイプが AddOn の場合、AddOn でスコアソースを設定する必要があります。
        • builtin は、BuiltIn prioritizer の名前を定義します。以下のリストには、有効な BuiltIn の prioritizer 名が含まれます。

          • Balance: クラスター間の決定を分散します。
          • Steady: 既存の意思決定が安定していることを確認します。
          • ResourceAllocatableCPU & ResourceAllocatableMemory: 割り当て可能なリソースに基づいてクラスターを分類します。
        • addOn はリソース名およびスコア名を定義します。AddOnPlacementScore は、アドオンスコアを記述するために導入されました。詳細は Extensible scheduling を参照してください。

          • resourceNameAddOnPlacementScore のリソース名を定義します。Placement prioritizer は、この名前で AddOnPlacementScore カスタムリソースを選択します。
          • scoreNameAddOnPlacementScore 内でスコア名を定義します。AddOnPlacementScore には、スコア名とスコア値のリストが含まれます。scoreName: prioritizer で使用されるスコアを指定します。
      • weight は Prioritizer の重みを定義します。値は [-10,10] の範囲に指定する必要があります。それぞれの prioritizer は、[-100, 100] の範囲でクラスターの整数スコアを計算します。クラスターの最後のスコアは、以下の式 sum(weight * prioritizer_score) で決定されます。重みが大きい場合は、Prioritizer はクラスターの選択で重みの高いものを受け取ることを意味し、一方、重みが 0 の場合は Prioritizer が無効であることを示します。負の重みは、最後に選択されたものであることを示します。

注記: configurations.name ファイルは v1beta1 で削除され、scoreCoordinate.builtIn ファイルに置き換えられる予定です。namescoreCoordinate.builtIn の両方が定義されている場合には、scoreCoordinate.builtIn の値を使用して選択を決定します。

1.4.13.5.2. 配置の例

namespace に ManagedClusterSetBinding を作成して、その namespace に ManagedClusterSet を最低でも 1 つバインドする必要があります。注記: managedclustersets/bind の仮想サブリソースの CREATE に対してロールベースのアクセスが必要です。以下の例を参照してください。

  • labelSelectorManagedClusters を選択します。以下の例では、labelSelector はラベル vendor: OpenShift のクラスターだけに一致します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement1
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchLabels:
                vendor: OpenShift
  • claimSelectorManagedClusters を選択します。以下の例では、claimSelectorregion.open-cluster-management.ious-west-1 のクラスターだけに一致します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement2
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            claimSelector:
              matchExpressions:
                - key: region.open-cluster-management.io
                  operator: In
                  values:
                    - us-west-1
  • clusterSets から ManagedClusters を選択します。以下の例では、claimSelectorclusterSets: clusterset1 clusterset2 だけに一致します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement3
      namespace: ns1
    spec:
      clusterSets:
        - clusterset1
        - clusterset2
      predicates:
        - requiredClusterSelector:
            claimSelector:
              matchExpressions:
                - key: region.open-cluster-management.io
                  operator: In
                  values:
                    - us-west-1
  • 任意の数の ManagedClusters を選択します。以下の例は、numberOfClusters3 の場合です。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement4
      namespace: ns1
    spec:
      numberOfClusters: 3
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchLabels:
                vendor: OpenShift
            claimSelector:
              matchExpressions:
                - key: region.open-cluster-management.io
                  operator: In
                  values:
                    - us-west-1
  • 割り当て可能なメモリーが最大のクラスターを選択します。

    注記: Kubernetes Node Allocatable と同様に、allocatable は、各クラスターの Pod で利用可能なコンピュートリソースの量として定義されます。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement6
      namespace: ns1
    spec:
      numberOfClusters: 1
      prioritizerPolicy:
        configurations:
          - scoreCoordinate:
              builtIn: ResourceAllocatableMemory
  • 割り当て可能な CPU およびメモリーが最大のクラスターを選択し、配置がリソースの変更に厳密に対応するように設定します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement7
      namespace: ns1
    spec:
      numberOfClusters: 1
      prioritizerPolicy:
        configurations:
          - scoreCoordinate:
              builtIn: ResourceAllocatableCPU
            weight: 2
          - scoreCoordinate:
              builtIn: ResourceAllocatableMemory
            weight: 2
  • 最大割り当て可能なメモリーと最大のアドオンスコアの cpu 比率を持つ 2 つのクラスターを選択し、配置の決定を固定します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement8
      namespace: ns1
    spec:
      numberOfClusters: 2
      prioritizerPolicy:
        mode: Exact
        configurations:
          - scoreCoordinate:
              builtIn: ResourceAllocatableMemory
          - scoreCoordinate:
              builtIn: Steady
            weight: 3
          - scoreCoordinate:
              type: AddOn
              addOn:
                resourceName: default
                scoreName: cpuratio
1.4.13.5.3. 配置のデシジョン

ラベルが cluster.open-cluster-management.io/placement={placement name}PlacementDecisions が 1 つまたは複数作成され、Placement で選択された ManagedClusters を表します。

ManagedCluster が選択され、PlacementDecision に追加されると、この Placement を使用するコンポーネントは、ManagedCluster でワークロードを適用する可能性があります。ManagedCluster が選択されなくなり、PlacementDecisions から削除されると、この ManagedCluster に適用されるワークロードも随時削除する必要があります。

以下の PlacementDecision の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: PlacementDecision
metadata:
  labels:
    cluster.open-cluster-management.io/placement: placement1
  name: placement1-kbc7q
  namespace: ns1
  ownerReferences:
    - apiVersion: cluster.open-cluster-management.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: Placement
      name: placement1
      uid: 05441cf6-2543-4ecc-8389-1079b42fe63e
status:
  decisions:
    - clusterName: cluster1
      reason: ''
    - clusterName: cluster2
      reason: ''
    - clusterName: cluster3
      reason: ''
1.4.13.5.4. アドオンのステータス

デプロイ先のアドオンのステータスに合わせて、配置用のマネージドクラスターを選択できます。たとえば、クラスターで有効になっている特定のアドオンがある場合にのみ、配置のマネージドクラスターを選択します。

これは、アドオンのラベルと、必要に応じてそのステータスを指定して実行できます。クラスターでアドオンが有効になっている場合、ラベルは ManagedCluster リソースで自動的に作成されます。アドオンが無効になると、ラベルは自動的に削除されます。

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

addon_name は、選択するマネージドクラスターで有効にする必要があるアドオンの名前に置き換えます。

status_of_addon は、クラスターが選択されている場合にアドオンに指定すべきステータスに置き換えます。status_of_addon の使用可能な値は以下のリストのとおりです。

  • Available: アドオンが有効で利用可能である。
  • unhealthy: アドオンは有効になっているが、リースは継続的に更新されない。
  • unreachable: アドオンは有効になっているが、リースが見つからない。これは、マネージドクラスターがオフライン時にも発生する可能性があります。

たとえば、利用可能な application-manager アドオンは、以下を読み取るマネージドクラスターのラベルで表されます。

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

アドオンおよびそれらのステータスに基づいて配置を作成する以下の例を参照してください。

  • 以下の YAML コンテンツを追加して、application-manager を有効化したマネージドクラスターすべてを含む配置を作成できます。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement1
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchExpressions:
                - key: feature.open-cluster-management.io/addon-application-manager
                  operator: Exists
  • 以下の YAML コンテンツを追加して、application-manageravailable のステータスで有効化されているすべてのマネージドクラスターを含む配置を作成できます。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement2
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchLabels:
                "feature.open-cluster-management.io/addon-application-manager": "available"
  • 以下の YAML コンテンツを追加して、application-manager が無効にされているマネージドクラスターすべてを含む配置を作成できます。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement3
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchExpressions:
                - key: feature.open-cluster-management.io/addon-application-manager
                  operator: DoesNotExist
1.4.13.5.5. 拡張可能なスケジューリング

配置リソースベースのスケジューリングでは、マネージドクラスターのスコアを計算するために、prioritizer が MananagedCluster リソースで提供されるデフォルト値よりも多くのデータを必要とする場合があります。たとえば、モニタリングシステム経由で取得されるクラスターの CPU またはメモリー使用量データに基づいてクラスターをスケジュールします。

API AddOnPlacementScore は、カスタムのスコアをもとにスケジューリングする拡張可能な方法をサポートします。

  • placement.yaml ファイルにスコアを指定して、クラスターを選択できます。
  • スコアプロバイダーとして、サードパーティーのコントローラーをハブクラスターまたはマネージドクラスターのいずれかで実行して、AddOnPlacementScore のライフサイクルを維持し、スコアを更新することができます。

詳細は、open-cluster-management リポジトリーの 配置拡張可能なスケジューリングの拡張機能 を参照してください。

1.4.13.6. テイントおよび容認 (Toleration) を使用したマネージドクラスターの配置

テイントおよび容認 (Toleration) を使用して、マネージドクラスターまたはマネージドクラスターセットの配置を制御できます。Taint と Toleration は、特定の placement でマネージドクラスターが選択されないようにする方法を提供します。この制御は、特定のマネージドクラスターが一部の placement に含まれないようにする場合に役立ちます。Taint をマネージドクラスターに、Toleration を placement に追加できます。Taint と Toleration が一致しない場合は、マネージドクラスターはその placement には選択されません。

1.4.13.6.1. マネージドクラスターへの Taint の追加

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

kubectl taint ManagedCluster <managed_cluster_name> key=value:NoSelect

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

  • (必須) key: クラスターに適用される Taint キー。この値は、その placement に追加される基準を満たすように、マネージドクラスターの Toleration の値と一致させる必要があります。この値は確認できます。たとえば、この値は bar または foo.example.com/bar です。
  • (オプション) Value: Taint キーのTaint値。この値は、その placement に追加される基準を満たすように、マネージドクラスターの Toleration の値と一致させる必要があります。たとえば、この値は value とすることができます。
  • (必須) Effect: Taint を許容しない placement における Taint の効果、または placement の Taint と Toleration が一致しないときに何が起こるか。effect の値は、以下のいずれかの値である必要があります。

    • NoSelect: placement は、この Taint を許容しない限り、クラスターを選択できません。Taint の設定前に placement でクラスターが選択された場合は、クラスターは placement の決定から削除されます。
    • NoSelectIfNew: スケジューラーは、クラスターが新しい場合にそのクラスターを選択できません。プレイスメントは、Taint を許容し、すでにクラスター決定にそのクラスターがある場合にのみ、そのクラスターを選択することができます。
  • (必須) TimeAdded: Taint を追加した時間。この値は自動的に設定されます。
1.4.13.6.2. マネージドクラスターのステータスを反映させる組み込み Taint の特定

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

  • cluster.open-cluster-management.io/unavailable: この Taint は、ステータスが FalseManagedClusterConditionAvailable の条件がある場合にマネージドクラスターに追加されます。Taint には NoSelect と同じ効果があり、空の値を指定すると、利用不可のクラスターがスケジュールされないようにできます。この 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/unavailable
         timeAdded: '2022-02-21T08:11:54Z'
  • cluster.open-cluster-management.io/unreachable - ManagedClusterConditionAvailable の条件のステータスが Unknown であるか、条件がない場合に、この Taint はマネージドクラスターに追加されます。この Taint には NoSelect と同じ効果があり、空の値を指定すると、到達不可のクラスターがスケジュールされないようにできます。この 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'
1.4.13.6.3. Toleration の placement への追加

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

  • (任意) Key: キーは placement ができるように Taint キーに一致します。
  • (任意) Value: toleration の値は、 placement を許可する Toleration の Taint の値と一致する必要があります。
  • (任意) Operator: 演算子はキーと値の関係を表します。有効な演算子は equalexists です。デフォルト値は equal です。Toleration は、キーが同じ場合、効果が同じ場合、さらび演算子が以下の値のいずれかである場合に、Taint にマッチします。

    • equal: Operator は equal で、値は Taint および Toleration と同じになります。
    • exists: 値のワイルドカード。これにより、 placement は特定のカテゴリーのすべての Taint を許容できます。
  • (任意) Effect: 一致する Taint の効果。空のままにすると、すべての Taint の効果と一致します。指定可能な値は、NoSelect または NoSelectIfNew です。
  • (任意) TolerationSeconds: マネージドクラスターを新しい placement に移動する前に、Taint を許容する時間の長さ (秒単位) です。effect 値が NoSelect または PreferNoSelect でない場合は、このフィールドは無視されます。デフォルト値は nil で、時間制限がないことを示します。TolerationSeconds のカウント開始時刻は、クラスターのスケジュール時刻や TolerationSeconds 加算時刻の値ではなく、自動的に Taint の TimeAdded の値として記載されます。

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

  • この例のマネージドクラスターの Taint:

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: cluster1
    spec:
      hubAcceptsClient: true
      taints:
        - effect: NoSelect
          key: gpu
          value: "true"
          timeAdded: '2022-02-21T08:11:06Z'
  • Taint を許容できる placement の Toleration

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement1
      namespace: default
    spec:
      tolerations:
        - key: gpu
          value: "true"
          operator: Equal

    Toleration の定義例では、key: gpuvalue: "true" が一致するため、placement で cluster1 を選択できます。

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

1.4.13.6.4. 一時的な Toleration の指定

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/v1alpha1
kind: Placement
metadata:
  name: demo4
  namespace: demo1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300
----

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

1.4.13.7. ManagedClusterSet からのマネージドクラスターの削除

マネージドクラスターセットからマネージドクラスターを削除して別のマネージドクラスターセットに移動するか、セットの管理設定から削除する必要がある場合があります。コンソールまたはコマンドラインインターフェイスを使用して、マネージドクラスターセットからマネージドクラスターを削除できます。

注記: マネージドクラスターはすべて、マネージドクラスターセットに割り当てる必要があります。ManagedClusterSet からマネージドクラスターを削除して、別の ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

1.4.13.7.1. コンソールを使用した ManagedClusterSet からのマネージドクラスターの削除

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

  1. Infrastructure > Clusters をクリックし、Cluster sets タブが選択されていることを確認します。
  2. マネージドクラスターセットから削除するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
  3. Actions > Manage resource assignments を選択します。
  4. Manage resource assignments ページで、クラスターセットから削除するリソースのチェックボックスをオフにします。

    この手順では、すでにクラスターセットのメンバーであるリソースを削除します。マネージドクラスターの詳細を表示して、リソースがすでにクラスターセットのメンバーであるかどうかを確認できます。

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

1.4.13.7.2. コマンドラインを使用した ManagedClusterSet からのクラスターの削除

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

  1. 以下のコマンドを実行して、マネージドクラスターセットでマネージドクラスターのリストを表示します。

    oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<clusterset1>

    clusterset1 はマネージドクラスターセットの名前を置き換えます。

  2. 削除するクラスターのエントリーを見つけます。
  3. 削除するクラスターの yaml エントリーからラベルを削除します。ラベルの例については、以下のコードを参照してください。

    labels:
       cluster.open-cluster-management.io/clusterset: clusterset1

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

1.4.14. クラスタープールの管理 (テクノロジープレビュー)

クラスタープールは、Red Hat OpenShift Container Platform クラスターにオンデマンドで、スケーリングする場合に、迅速かつコスト効果を高く保ちながら、アクセスできるようにします。クラスタープールは、Amazon Web Services、Google Cloud Platform または Microsoft Azure で設定可能な数多くの OpenShift Container Platform クラスターをプロビジョニングします。このプールは、開発、継続統合、および実稼働のシナリオにおいてクラスター環境を提供したり、置き換えたりする場合に特に便利です。実行を継続するクラスターの数を指定して、すぐに要求できるようにすることができます。残りのクラスターは休止状態に保たれるため、数分以内に再開して要求できます。

ClusterClaim リソースは、クラスタープールからクラスターをチェックアウトするために使用されます。クラスター要求が作成されると、その要求にプールは実行中のクラスターを割り当てます。実行中のクラスターがない場合は、休止状態のクラスターを再開してクラスターを提供するか、新規クラスターをプロビジョニングします。クラスタープールは自動的に新しいクラスターを作成し、休止状態のクラスターを再開して、プール内で利用可能な実行中のクラスターの指定サイズおよび数を維持します。

クラスタープールを作成する手順は、クラスターの作成手順と似ています。クラスタープールのクラスターは、すぐ使用するために作成されるわけではありません。

1.4.14.1. クラスタープールの作成

クラスタープールを作成する手順は、クラスターの作成手順と似ています。クラスタープールのクラスターは、すぐ使用するために作成されるわけではありません。

必要なアクセス権限: 管理者

1.4.14.1.1. 前提条件

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

  • Kubernetes Operator ハブクラスター用のマルチクラスターエンジンをデプロイする必要があります。
  • プロバイダー環境で Kubernetes クラスターを作成できるように、Kubernetes Operator ハブクラスター用のマルチクラスターエンジンにインターネットアクセスが必要です。
  • AWS、GCP、または Microsoft Azure プロバイダーのクレデンシャルが必要です。詳細は、認証情報の管理の概要 を参照してください。
  • プロバイダー環境で設定済みのドメインが必要です。ドメインの設定方法は、プロバイダーのドキュメントを参照してください。
  • プロバイダーのログイン認証情報が必要です。
  • OpenShift Container Platform イメージプルシークレットが必要です。イメージプルシークレットの使用 を参照してください。

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

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

文字列であることを示すには、"false" という単語を引用符で囲む必要があります。

1.4.14.1.2. クラスタープールを作成する

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

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

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

クラスターセットでクラスタープールを作成すると、クラスタープールの追加先の namespace の clusterset admin パーミッションがある全ユーザーに、namespace admin パーミッションが適用されます。同様に、namespace view パーミッションは clusterset view パーミッションのあるユーザーに適用されます。

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

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

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

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

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

1.4.14.2. クラスタープールからのクラスターの要求

ClusterClaim リソースは、クラスタープールからクラスターをチェックアウトするために使用されます。クラスターの稼働中で、クラスタープールで準備できると、要求が完了します。クラスタープールは、クラスタープールに指定された要件を維持するために、クラスタープールに新しい実行中およびハイバネートされたクラスターを自動的に作成します。

注記: クラスタープールから要求されたクラスターが不要になり、破棄されると、リソースは削除されます。クラスターはクラスタープールに戻りません。

必要なアクセス権限: 管理者

1.4.14.2.1. 前提条件

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

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

1.4.14.2.2. クラスタープールからのクラスターの要求

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

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

  1. ナビゲーションメニューから Infrastructure > Clusters をクリックし、Cluster pools タブを選択します。
  2. クラスターを要求するクラスタープールの名前を見つけ、Claim cluster を選択します。

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

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

1.4.14.3. クラスタープールリリースイメージの更新

クラスタープールのクラスターが一定期間、休止状態のままになると、クラスターの Red Hat OpenShift Container Platform リリースイメージがバックレベルになる可能性があります。このような場合は、クラスタープールにあるクラスターのリリースイメージのバージョンをアップグレードしてください。

必要なアクセス: 編集

クラスタープールにあるクラスターの OpenShift Container Platform リリースイメージを更新するには、以下の手順を実行します。

注記: この手順では、クラスタープールですでに要求されているクラスタープールからクラスターを更新しません。この手順を完了すると、リリースイメージの更新は、クラスタープールに関連する次のクラスターにのみ適用されます。

  • この手順でリリースイメージを更新した後にクラスタープールによって作成されたクラスター。
  • クラスタープールで休止状態になっているクラスター。古いリリースイメージを持つ既存の休止状態のクラスターは破棄され、新しいリリースイメージを持つ新しいクラスターがそれらを置き換えます。
  1. ナビゲーションメニューから infrastructure > Clusters をクリックします。
  2. Cluster pools タブを選択します。
  3. クラスタープール の表で、更新するクラスタープールの名前を見つけます。
  4. 表の Cluster poolsOptions メニューをクリックし、Update release image を選択します。
  5. このクラスタープールから今後、クラスターの作成に使用する新規リリースイメージを選択します。

クラスタープールのリリースイメージが更新されました。

ヒント: アクション 1 つで複数のクラスターのリリースイメージを更新するには、各クラスタープールのボックスを選択して Actions メニューを使用し、選択したクラスタープールのリリースイメージを更新します。

1.4.14.4. Scaling cluster pools (Technology Preview)

クラスタープールのクラスター数は、クラスタープールサイズのクラスター数を増やしたり、減らしたりして変更できます。

必要なアクセス権限: クラスターの管理者

クラスタープールのクラスター数を変更するには、以下の手順を実行します。

  1. ナビゲーションメニューから infrastructure > Clusters をクリックします。
  2. Cluster pools タブを選択します。
  3. 変更するクラスタープールの Options メニューで、Scale cluster pool を選択します。
  4. プールサイズの値を変更します。
  5. オプションで、実行中のクラスターの数を更新して、要求時にすぐに利用可能なクラスター数を増減できます。

クラスタープールは、新しい値を反映するようにスケーリングされます。

1.4.14.5. クラスタープールの破棄

クラスタープールを作成し、不要になった場合は、そのクラスタープールを破棄できます。クラスタープールを破棄する時に、要求されていない休止状態のクラスターはすべて破棄され、そのリソースは解放されます。

必要なアクセス権限: クラスターの管理者

クラスタープールを破棄するには、以下の手順を実行します。

  1. ナビゲーションメニューから infrastructure > Clusters をクリックします。
  2. Cluster pools タブを選択します。
  3. 削除するクラスタープールの Options メニューで、Destroy cluster pool を選択します。クラスタープールで要求されていないクラスターは破棄されます。すべてのリソースが削除されるまでに時間がかかる場合があります。また、クラスタープールは、すべてのリソースが削除されるまでコンソールに表示されたままになります。

    ClusterPool が含まれる namespace は削除されません。namespace を削除すると、これらのクラスターの ClusterClaim リソースは同じ namespace で作成されるため、ClusterPool から要求されたクラスターがすべて破棄されます。

ヒント: アクション 1 つで複数のクラスタープールを破棄するには、各クラスタープールのボックスを選択して Actions メニューを使用し、選択したクラスタープールを破棄します。

1.4.15. ClusterClaims

ClusterClaim は、マネージドクラスター上のカスタムリソース定義 (CRD) です。ClusterClaim は、マネージドクラスターが要求する情報の一部を表します。以下の例は、YAML ファイルで特定される要求を示しています。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: id.openshift.io
spec:
  value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c

次の表は、Kubernetes Operator 用のマルチクラスターエンジンが管理するクラスター上にある可能性がある、定義済みの ClusterClaims を示しています。

要求名予約変更可能説明

id.k8s.io

true

false

アップストリームの提案で定義された ClusterID

kubeversion.open-cluster-management.io

true

true

Kubernetes バージョン

platform.open-cluster-management.io

true

false

AWS、GCE、Equinix Metal など、マネージドクラスターが稼働しているプラットフォーム

product.open-cluster-management.io

true

false

OpenShift、Anthos、EKS、および GKE などの製品名

id.openshift.io

false

false

OpenShift Container Platform クラスターでのみ利用できる OpenShift Container Platform 外部 ID

consoleurl.openshift.io

false

true

OpenShift Container Platform クラスターでのみ利用できる管理コンソールの URL

version.openshift.io

false

true

OpenShift Container Platform クラスターでのみ利用できる OpenShift Container Platform バージョン

マネージドクラスターで以前の要求が削除されるか、更新されると、自動的に復元またはロールバックされます。

マネージドクラスターがハブに参加すると、マネージドクラスターで作成された ClusterClaim は、ハブの ManagedCluster リソースのステータスと同期されます。ClusterClaims のマネージドクラスターは、以下の例のようになります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  labels:
    cloud: Amazon
    clusterID: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    installer.name: multiclusterhub
    installer.namespace: open-cluster-management
    name: cluster1
    vendor: OpenShift
  name: cluster1
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
status:
  allocatable:
    cpu: '15'
    memory: 65257Mi
  capacity:
    cpu: '18'
    memory: 72001Mi
  clusterClaims:
    - name: id.k8s.io
      value: cluster1
    - name: kubeversion.open-cluster-management.io
      value: v1.18.3+6c42de8
    - name: platform.open-cluster-management.io
      value: AWS
    - name: product.open-cluster-management.io
      value: OpenShift
    - name: id.openshift.io
      value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    - name: consoleurl.openshift.io
      value: 'https://console-openshift-console.apps.xxxx.dev04.red-chesterfield.com'
    - name: version.openshift.io
      value: '4.5'
  conditions:
    - lastTransitionTime: '2020-10-26T07:08:49Z'
      message: Accepted by hub cluster admin
      reason: HubClusterAdminAccepted
      status: 'True'
      type: HubAcceptedManagedCluster
    - lastTransitionTime: '2020-10-26T07:09:18Z'
      message: Managed cluster joined
      reason: ManagedClusterJoined
      status: 'True'
      type: ManagedClusterJoined
    - lastTransitionTime: '2020-10-30T07:20:20Z'
      message: Managed cluster is available
      reason: ManagedClusterAvailable
      status: 'True'
      type: ManagedClusterConditionAvailable
  version:
    kubernetes: v1.18.3+6c42de8

1.4.15.1. 既存の ClusterClaim の表示

kubectl コマンドを使用して、マネージドクラスターに適用される ClusterClaim をリスト表示できます。これは、ClusterClaim をエラーメッセージと比較する場合に便利です。

注記: clusterclaims.cluster.open-cluster-management.io のリソースに list の権限があることを確認します。

以下のコマンドを実行して、マネージドクラスターにある既存の ClusterClaim のリストを表示します。

kubectl get clusterclaims.cluster.open-cluster-management.io

1.4.15.2. カスタム ClusterClaims の作成

ClusterClaim は、マネージドクラスターでカスタム名を使用して作成できるため、簡単に識別できます。カスタム ClusterClaim は、ハブクラスターの ManagedCluster リソースのステータスと同期されます。以下のコンテンツでは、カスタマイズされた ClusterClaim の定義例を示しています。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: <custom_claim_name>
spec:
  value: <custom_claim_value>

spec.value フィールドの最大長は 1024 です。ClusterClaim を作成するには clusterclaims.cluster.open-cluster-management.io リソースの create パーミッションが必要です。

1.4.16. ManagedServiceAccount アドオンの有効化 (テクノロジープレビュー)

Kubernetes Operator 用のマルチクラスターエンジンをインストールすると、ManagedServiceAccount アドオンはデフォルトで無効になります。このコンポーネントを有効にすると、マネージドクラスターでサービスアカウントを作成または削除できます。

必要なアクセス権限: 編集

ManagedServiceAccount カスタムリソースがハブクラスターの <managed_cluster> namespace に作成されると、ServiceAccount がマネージドクラスターに作成されます。

TokenRequest は、マネージドクラスターの ServiceAccount を使用して、マネージドクラスターの Kubernetes API サーバーに対して行われます。トークンは、ハブクラスターの <target_managed_cluster> namespace の Secret に保存されます。

注記 トークンは期限切れになり、ローテーションされる可能性があります。トークンリクエストの詳細については、TokenRequest を参照してください。

1.4.16.1. 前提条件

  • お使いの環境に Red Hat OpenShift Container Platform バージョン 4.11 以降をインストールし、コマンドラインインターフェイス (CLI) でログインしている。
  • Kubernetes Operator 用のマルチクラスターエンジンがインストールされている。

1.4.16.2. ManagedServiceAccount の有効化

ハブクラスターとマネージドクラスターの Managed-ServiceAccount アドオンを有効にするには、次の手順を実行します。

  1. ハブクラスターで ManagedServiceAccount アドオンを有効にします。詳細は、詳細設定 を参照してください。
  2. ManagedServiceAccount アドオンをデプロイし、それをターゲットのマネージドクラスターに適用します。次の YAML ファイルを作成し、target_managed_clusterManaged-ServiceAccount アドオンを適用するマネージドクラスターの名前に置き換えます。

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: ManagedClusterAddOn
    metadata:
      name: managed-serviceaccount
      namespace: <target_managed_cluster>
    spec:
      installNamespace: open-cluster-management-agent-addon
  3. 次のコマンドを実行して、ファイルを適用します。

    oc apply -f -

    これで、マネージドクラスターの Managed-ServiceAccount プラグインが有効になりました。ManagedServiceAccount を設定するには、次の手順を参照してください。

  4. 次の YAML ソースを使用して ManagedServiceAccount カスタムリソースを作成します。

    apiVersion: authentication.open-cluster-management.io/v1alpha1
    kind: ManagedServiceAccount
    metadata:
      name: <managed_serviceaccount_name>
      namespace: <target_managed_cluster>
    spec:
      rotation: {}
    • managed_serviceaccount_nameManagedServiceAccount の名前に置き換えます。
    • target_managed_cluster を、ManagedServiceAccount を適用するマネージドクラスターの名前に置き換えます。
  5. 確認するには、ManagedServiceAccount オブジェクトのステータスで tokenSecretRef 属性を表示して、シークレット名と namespace を見つけます。アカウントとクラスター名を使用して次のコマンドを実行します。

    oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
  6. マネージドクラスターで作成された ServiceAccount に接続されている取得されたトークンを含む Secret を表示します。以下のコマンドを実行します。

    oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml

1.4.17. クラスターのアップグレード

Kubernetes Operator コンソール用マルチクラスターエンジンで管理する Red Hat OpenShift Container Platform クラスターを作成したら、Kubernetes Operator コンソール用マルチクラスターエンジンを使用して、それらのクラスターを、マネージドクラスターが使用するバージョンチャネルで利用可能な最新のマイナーバージョンにアップグレードできます。

オンライン環境では、Red Hat Advanced Cluster Management コンソールでアップグレードが必要なクラスターごとに送信される通知を使用して、更新が自動識別されます。

注記:

メジャーバージョンへのアップグレードには、そのバージョンへのアップグレードの前提条件をすべて満たしていることを確認する必要があります。コンソールでクラスターをアップグレードする前に、マネージドクラスターのバージョンチャネルを更新する必要があります。

マネージドクラスターでバージョンチャネルを更新すると、Kubernetes Operator コンソールのマルチクラスターエンジンに、アップグレードに使用できる最新バージョンが表示されます。

このアップグレードの手法は、ステータスが Ready の OpenShift Container Platform のマネージドクラスタークラスターでだけ使用できます。

重要: Red Hat OpenShift Kubernetes Service マネージドクラスターまたは OpenShift Container Platform マネージドクラスターを Red Hat OpenShift Dedicated で Kubernetes Operator コンソール用のマルチクラスターエンジンを使用してアップグレードすることはできません。

オンライン環境でクラスターをアップグレードするには、以下の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Clusters に移動します。アップグレードが利用可能な場合には、Distribution version の列に表示されます。
  2. アップグレードする Ready 状態のクラスターを選択します。クラスターはコンソールを使用してアップグレードされる OpenShift Container Platform クラスターである必要があります。
  3. Upgrade を選択します。
  4. 各クラスターの新しいバージョンを選択します。
  5. Upgrade を選択します。

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

1.4.17.1. チャネルの選択

Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform バージョン 4.6 以降でクラスターのアップグレードのチャネルを選択できます。チャネルを選択すると、エラータバージョン (4.8.1> 4.8.2> 4.8.3 など) とリリースバージョン (4.8> 4.9 など) の両方で使用できるクラスターアップグレードが自動的に通知されます。

クラスターのチャネルを選択するには、以下の手順を実行します。

  1. Red Hat Advanced Cluster Management ナビゲーションで Infrastructure > Clusters に移動します。
  2. 変更するクラスターの名前を選択して、Cluster details ページを表示します。クラスターに別のチャネルが利用可能な場合は、編集アイコンが Channel フィールドに表示されます。
  3. 編集アイコンをクリックして、フィールドの設定を変更します。
  4. New channel フィールドでチャネルを選択します。

利用可能なチャネル更新のリマインダーは、クラスターの Cluster details ページで見つけることができます。

1.5. Discovery サービスの概要

OpenShift Cluster Manager で利用可能な OpenShift 4 クラスターを検出できます。検出後に、クラスターをインポートして管理できます。Discovery サービスは、バックエンドおよびコンソールでの用途に Discover Operator を使用します。

OpenShift Cluster Manager 認証情報が必要になります。認証情報を作成する必要がある場合は、Red Hat OpenShift Cluster Manager の認証情報の作成 を参照してください。

必要なアクセス権限: 管理者

1.5.1. コンソールでの検出の設定

製品のコンソールを使用して検出を有効にします。

必要なアクセス権: 認証情報が作成された namespace へのアクセス権。

1.5.1.1. 前提条件

1.5.1.2. 検出の設定

コンソールで検出を設定し、クラスターを検索します。個別の認証情報を使用して複数の DiscoveryConfig リソースを作成できます。コンソールの指示に従います。

1.5.1.3. 検出されたクラスターの表示

認証情報を設定してインポートするクラスターを検出した後に、コンソールで表示できます。

  1. Clusters > Discovered clustersの順にクリックします。
  2. 以下の情報が投入された表を確認してください。

    • name は、OpenShift Cluster Manager で指定された表示名です。クラスターに表示名がない場合は、クラスターコンソール URL をもとに生成された名前が表示されます。OpenShift Cluster Manager でコンソール URL がない場合や手動で変更された場合には、クラスターの外部 ID が表示されます。
    • Namespace は、認証情報および検出クラスターを作成した namespace です。
    • type は検出されたクラスターの Red Hat OpenShift タイプです。
    • distribution version は、検出されたクラスターの Red Hat OpenShift バージョンです。
    • infrastrcture provider は検出されたクラスターのクラウドプロバイダーです。
    • Last active は、検出されたクラスターが最後にアクティブであった時間です。
    • Created は検出クラスターが作成された時間です。
    • Discovered は検出クラスターが検出された時間です。
  3. 表の中にある情報はどれでも検索できます。たとえば、特定の namespace で Discovered clusters のみを表示するには、その namespace を検索します。
  4. Import cluster をクリックすると、マネージドクラスターを作成できます。検出クラスターのインポート を参照してください。

1.5.1.4. 検出クラスターのインポート

クラスターの検出後に、コンソールの Discovered clusters に表示されるクラスターをインポートできます。

1.5.1.5. 前提条件

検出の設定に使用した namespace へのアクセス権が必要である。

1.5.1.6. 検出クラスターのインポート

  1. 既存の Clusters ページに移動し、Discovered clusters タブをクリックします。
  2. Discovered Clusters の表から、インポートするクラスターを見つけます。
  3. オプションメニューから Import cluster を選択します。
  4. 検出クラスターの場合は、本書を使用して手動でインポートしたり、Import cluster を自動的に選択したりできます。
  5. 認証情報または Kubeconfig ファイルを使用して自動でインポートするには、コンテンツをコピーして貼り付けます。
  6. Import をクリックします。

1.5.2. CLI を使用した検出の有効化

CLI を使用して検出を有効にし、Red Hat OpenShift Cluster Manager が入手できるクラスターを見つけます。

必要なアクセス権限: 管理者

1.5.2.1. 前提条件

  • Red Hat OpenShift Cluster Manager に接続するための認証情報を作成している。

1.5.2.2. 検出の設定とプロセス

注記: DiscoveryConfigdiscovery という名前に指定し、選択した credential と同じ namespace に作成する必要があります。以下の DiscoveryConfig のサンプルを参照してください。

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveryConfig
metadata:
  name: discovery
  namespace: <NAMESPACE_NAME>
spec:
  credential: <SECRET_NAME>
  filters:
    lastActive: 7
    openshiftVersions:
    - "4.10"
    - "4.11"
    - "4.8"
  1. SECRET_NAME は、以前に設定した認証情報に置き換えます。
  2. NAMESPACE_NAMESECRET_NAME の namespace に置き換えます。
  3. クラスターの最後のアクティビティー (日数) からの最大時間を入力します。たとえば、lastActive: 7 では、過去 7 日間にアクティブなクラスターが検出されます。
  4. Red Hat OpenShift クラスターのバージョンを入力して、文字列の一覧として検出します。注記: openshiftVersions 一覧に含まれるエントリーはすべて、OpenShift のメジャーバージョンとマイナーバージョンを指定します。たとえば、"4.11" には OpenShift バージョン 4.11 のすべてのパッチリリース (4.11.14.11.2 など) が含まれます。

1.5.2.3. 検出されたクラスターの表示

検出されたクラスターを表示するには、oc get discoveredclusters -n <namespace> を実行して、namespace は検出認証情報が存在する namespace に置き換えます。

1.5.2.3.1. DiscoveredClusters

オブジェクトは Discovery コントローラーにより作成されます。このような DiscoveredClusters は、DiscoveryConfig discoveredclusters.discovery.open-cluster-management.io API で指定したフィルターと認証情報を使用して OpenShift Cluster Manager で検出されたクラスターを表します。name の値はクラスターの外部 ID です。

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  namespace: <NAMESPACE_NAME>
spec:
  activity_timestamp: "2021-04-19T21:06:14Z"
  cloudProvider: vsphere
  console: https://console-openshift-console.apps.qe1-vmware-pkt.dev02.red-chesterfield.com
  creation_timestamp: "2021-04-19T16:29:53Z"
  credential:
    apiVersion: v1
    kind: Secret
    name: <SECRET_NAME>
    namespace: <NAMESPACE_NAME>
  display_name: qe1-vmware-pkt.dev02.red-chesterfield.com
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  openshiftVersion: 4.10
  status: Stale

1.6. ホストされたコントロールプレーンクラスターの使用 (テクノロジープレビュー)

Kubernetes Operator バージョン 2.5 用のマルチクラスターエンジンと Kubernetes Operator 2.0 用のマルチクラスターエンジンは、2 つの異なるコントロールプレーン設定を使用して Red Hat OpenShift Container Platform クラスターをデプロイできます。スタンドアロン設定では、複数の専用仮想マシンまたは物理マシンを使用して、OpenShift Container Platform コントロールプレーンをホストします。ホストされたコントロールプレーンをプロビジョニングして、OpenShift Container Platform コントロールプレーンをホスティングサービスクラスター上の Pod としてプロビジョニングできます。コントロールプレーンごとに専用の物理マシンは必要ありません。

注意: この機能は、Kubernetes Operator 用のマルチクラスターエンジンを使用せずに、Kubernetes Operator 2.0 用のマルチクラスターエンジンでも動作します。

Amazon Web Services は、テクノロジープレビューとしてサポートされています。Red Hat OpenShift Container Platform バージョン 4.10.7 のコントロールプレーンをホストできます。

コントロールプレーンは、単一の名前空間に含まれる Pod として実行され、ホストされたコントロールプレーンクラスターに関連付けられます。OpenShift Container Platform がこのタイプのホストされたクラスターをプロビジョニングする場合、コントロールプレーンから独立したワーカーノードをプロビジョニングします。

以下は、ホストされたコントロールプレーンクラスターの利点です。

  • 専用コントロールプレーンノードをホストする必要がなくなるため、コストを節約できます。
  • コントロールプレーンとワークロードを分離することで、分離が改善され、変更が必要になる設定エラーが減少します。
  • コントロールプレーンノードのブートストラップが不要になるため、クラスターのプロビジョニング時間が大幅に短縮されます。
  • ターンキーデプロイメントまたは完全にカスタマイズされた OpenShift Container Platform プロビジョニングをサポートします。

詳細については、次の製品ドキュメントを参照してください。

1.6.1. ホストされているコントロールプレーンの設定

ホストされているコントロールプレーンを設定するには、ホスティングサービスクラスターとホストされているクラスターが必要です。HyperShift Operator を既存のクラスターにデプロイすることで、そのクラスターをホスティングサービスクラスターにし、ホストされるクラスターの作成を開始できます。

ホストされたコントロールプレーンはテクノロジープレビュー機能であるため、関連コンポーネントはデフォルトで無効になっています。multiclusterengine カスタムリソースを編集して spec.overrides.components[?(@.name=='hypershift-preview')].enabledtrue に設定して、この機能を有効にします。

以下のコマンドを実行して、ホストされるコントロールプレーン機能が有効であることを確認します。

oc patch mce multiclusterengine-sample --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": true}]}}}'

1.6.1.1. ホスティングサービスクラスターの設定

既存クラスターをホスティングサービスクラスターとして機能するように設定することで、ホストされたコントロールプレーンをデプロイできます。ホスティングサービスクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターであり、ハブクラスターまたは OpenShift Container Platform 管理対象クラスターの 1 つにできます。

ベストプラクティス: ホストされたコントロールプレーンとワーカーノードを同じ環境で実行します。

1.6.1.1.1. 前提条件

ホスティングサービスクラスターを設定するには、次の前提条件を満たす必要があります。

  • Red Hat OpenShift Container Platform で管理される 1 つ以上のクラスターに Kubernetes Operator 用のマルチクラスターエンジンがインストールされている必要があります。Kubernetes Operator 用のマルチクラスターエンジンは、Red Hat Advanced Cluster Management バージョン 2.5 以降をインストールすると自動的にインストールされ、Red Hat Advanced Cluster Management なしで OpenShift Container Platform OperatorHub から Operator としてインストールすることもできます。
  • ハブクラスターをホスティングサービスクラスターにする場合は、高度な設定 ドキュメントの local-cluster の有効化 セクションの手順を実行して、local-cluster をホスティングサービスクラスターとして設定する必要があります。
1.6.1.1.2. ホスティングサービスクラスター の設定

Kubernetes Operator 用のマルチクラスターエンジンがインストールされているクラスターで以下の手順を実行し、OpenShift Container Platform マネージドクラスターをホスティングサービスクラスターとして有効にします。

  1. AWS でホストされたクラスターを作成および管理する場合は、HyperShift Operator 用に hypershift- operator -oidc-provider-s3-credentials という名前の OIDC S3 認証情報シークレットを作成します。マネージドクラスターの名前空間にシークレットを保存します。これは、ホスティングサービスクラスターとして使用されるマネージドクラスターの名前空間です。local-cluster を使用した場合は、local-cluster 名前空間にシークレットを作成します

    シークレットには以下の 3 つのフィールドを含める必要があります。bucket フィールドには、HyperShift クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを持つ S3 バケットが含まれています。credentials フィールドは、バケットにアクセスできる default プロファイルの認証情報を含むファイルへの参照です。デフォルトでは、HyperShift は default プロファイルのみを使用して バケット を操作します。region フィールドは、S3 バケットのリージョンを指定します。

    シークレットの詳細は、HyperShift のドキュメント の Getting started を参照してください。次の例は、サンプルの AWS シークレットテンプレートを示しています。

    oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=$HOME/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift>
    --from-literal=region=<region> -n <hypershift-hosting-service-cluster>

    注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に hypershift-operator-oidc-provider-s3-credentials シークレットのバックアップを有効にするラベルを追加します。

    oc label secret hypershift-operator-oidc-provider-s3-credentials -n <hypershift-hosting-service-cluster> cluster.open-cluster-management.io/backup=""
  2. Private Link を使用して AWS プラットフォームでホストされたクラスターをプロビジョニングする場合は、HyperShiftOperator の AWS 認証情報シークレットを作成し、hypershift-operator-private-link-credentials という名前を付けます。これは、ホスティングサービスクラスターとして使用されているマネージドクラスターの namespace であるマネージドクラスターの名前空間に存在する必要があります。local-cluster を使用した場合は、local-cluster namespace にシークレットを作成します詳細は、AWS プライベートクラスターのデプロイ の手順 1 ~ 5 を参照してください。

    シークレットには、次の 3 つのフィールドが含まれている必要があります。

    • aws-access-key-id: AWS 認証情報アクセスキー ID
    • aws-secret-access-key: AWS 認証情報アクセスキーシークレット
    • region: Private Link で使用するリージョン

      シークレットの詳細は、HyperShift のドキュメント の Getting started を参照してください。次の例は、サンプルの hypershift-operator-private-link-credentials シークレットテンプレートを示しています。

      oc create secret generic hypershift-operator-private-link-credentials --from-literal=aws-access-key-id=<aws-access-key-id> --from-literal=aws-secret-access-key=<aws-secret-access-key> --from-literal=region=<region> -n <hypershift-hosting-service-cluster>

      注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に hypershift-operator-private-link-credentials シークレットのバックアップを有効にするラベルを追加します。

      oc label secret hypershift-operator-private-link-credentials -n <hypershift-hosting-service-cluster> cluster.open-cluster-management.io/backup=""

      クラスターの作成時に、HypershiftDeployment カスタムリソースで次のパラメーターを設定します。

      spec:
        hostedClusterSpec:
          platform:
            type: AWS
            aws:
              endpointAccess: Private
  3. AWS プラットフォームでコントロールプレーンサービスにサービスレベルの DNS を使用する予定の場合は、HyperShift Operator 用の外部 DNS クレデンシャルシークレットを作成し、hypershift-operator-external-dns-credentials という名前を付けます。これは、ホスティングサービスクラスターとして使用されているマネージドクラスターの namespace であるマネージドクラスターの名前空間に存在する必要があります。local-cluster を使用した場合は、local-cluster 名前空間にシークレットを作成します

    シークレットには、次の 3 つのフィールドが含まれている必要があります。

    • provider: サービスレベルの DNS ゾーンを管理する DNS プロバイダー (例: aws)
    • domain-filter: サービスレベルドメイン
    • credentials: (オプション: aws キーを使用する場合のみ) - すべての外部 DNS タイプについて、認証情報ファイルがサポートされています
    • aws-access-key-id: (オプション) - AWS DNS サービスを使用する場合は、認証情報アクセスキー ID
    • aws-secret-access-key: (オプション) - AWS DNS サービスを使用する場合、AWS DNS サービスを使用する場合、認証情報アクセスキーシークレット

      詳細は、、コントロールプレーンサービスにサービスレベル DNS を使用する を参照してください。次の例は、サンプルの hypershift-operator-external-dns-credentials シークレットテンプレートを示しています。

      oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=service.my.domain.com --from-file=credentials=<credentials-file> -n <hypershift-hosting-service-cluster>

      注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に hypershift-operator-external-dns-credentials シークレットのバックアップを有効にするラベルを追加します。

      oc label secret hypershift-operator-external-dns-credentials -n <hypershift-hosting-service-cluster> cluster.open-cluster-management.io/backup=""

      クラスターの作成時に、HypershiftDeployment カスタムリソースで次のパラメーターを設定します。

      spec:
        hostedClusterSpec:
          platform:
            type: AWS
            aws:
              endpointAccess: PublicAndPrivate
  4. HyperShift アドオンをインストールします。

    HyperShift Operator をホストするクラスターは、ホストサービスクラスターです。この手順では、hypershift-addon を使用して、マネージドクラスターに HyperShift Operator をインストールします。

    1. HyperShift Operator が作成される namespace を作成します。
    2. 以下の例のようなファイルを作成して、ManagedClusterAddon HyperShift アドオンを作成します。

      apiVersion: addon.open-cluster-management.io/v1alpha1
      kind: ManagedClusterAddOn
      metadata:
        name: hypershift-addon
        namespace: <managed-cluster-name>
      spec:
        installNamespace: open-cluster-management-agent-addon

      managed-cluster-name を、HyperShift Operator をインストールするマネージドクラスターの名前に置き換えます。Red Hat Advanced Cluster Management ハブクラスターにインストールする場合は、この値に local-cluster を使用します。

    3. 以下のコマンドを実行してこのファイルを適用します。

      oc apply -f <filename>

      filename は、作成したファイル名に置き換えます。

  5. 以下のコマンドを実行して、hypershift-addon がインストールされていることを確認します。

    oc get managedclusteraddons -n <hypershift-hosting-service-cluster> hypershift-addon

    アドオンがインストールされている場合、出力は以下の例のようになります。

    NAME               AVAILABLE   DEGRADED   PROGRESSING
    hypershift-addon   True

HyperShift アドオンがインストールされ、ホストサービスクラスターを使用して HyperShift クラスターを管理できるようになりました。

1.6.1.2. ホストされたクラスターのデプロイ

HyperShift Operator をインストールして既存クラスターをホストサービスクラスターとして有効にすると、HypershiftDeployment カスタムリソースを作成して HyperShift ホストクラスターをプロビジョニングできます。

  1. コンソールまたはファイルの追加を使用して、認証情報としてクラウドプロバイダーシークレットを作成します。VPC、サブネット、NAT ゲートウェイなどのクラスターのインフラストラクチャーリソースを作成するパーミッションが必要です。このアカウントは、ワーカーが置かれるゲストクラスターのアカウントに対応している必要があります。必要なパーミッションに関する詳細は、HyperShift ドキュメントの AWS インフラストラクチャーおよび IAM リソースの作成 を参照してください。

    次の例は、AWS のシークレット形式を示しています。

    apiVersion: v1
    metadata:
      name: my-aws-cred
      namespace: default      # Where you create HypershiftDeployment resources
    type: Opaque
    kind: Secret
    stringData:
      ssh-publickey:          # Value
      ssh-privatekey:         # Value
      pullSecret:             # Value, required
      baseDomain:             # Value, required
      aws_secret_access_key:  # Value, required
      aws_access_key_id:      # Value, required
    • コンソールでこのシークレットを作成するには、ナビゲーションメニューの Credentials にアクセスし、認証情報の作成手順に従います。
    • コマンドラインを使用してシークレットを作成するには、以下のコマンドを実行します。

      oc create secret generic <my-secret> -n <hypershift-deployment-namespace> --from-literal=baseDomain='your.domain.com' --from-literal=aws_access_key_id='your-aws-access-key' --from-literal=aws_secret_access_key='your-aws-secret-key' --from-literal=pullSecret='your-quay-pull-secret' --from-literal=ssh-publickey='your-ssh-publickey' --from-literal=ssh-privatekey='your-ssh-privatekey'

      注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用にシークレットのバックアップを可能にするラベルを追加します。

      oc label secret <my-secret> -n <hypershift-deployment-namespace> cluster.open-cluster-management.io/backup=""
  2. HypershiftDeployment カスタムリソースを作成します。HypershiftDeployment カスタムリソースは、プロバイダーアカウントにインフラストラクチャーを作成し、作成されたインフラストラクチャーでインフラストラクチャーコンピュート容量を設定し、ホストされるコントロールプレーンを使用する nodePools をプロビジョニングし、ホスティングサービスクラスターに、ホストされたコントロールプレーンを作成します。

    1. 以下の例のような情報が含まれるファイルを作成します。

      apiVersion: cluster.open-cluster-management.io/v1alpha1
      kind: HypershiftDeployment
      metadata:
        name: <cluster>
        namespace: default
      spec:
        hostingCluster: <hosting-service-cluster>
        hostingNamespace: clusters
        infrastructure:
          cloudProvider:
            name: <my-secret>
          configure: True
          platform:
            aws:
              region: <region>

      cluster は、クラスターの名前に置き換えます。

      hosting-service-cluster は、HyperShift Operator をホストするクラスター名に置き換えます。

      my-secret は、クラウドプロバイダーにアクセスするためのシークレットに置き換えます。

      region は、クラウドプロバイダーのリージョンに置き換えます。

    2. 以下のコマンドを入力してファイルを適用します。

      oc apply -f <filename>

      API の フィールド定義 を参照して、それらが正しいことを確認します。

  3. 以下のコマンドを実行して HypershiftDeployment のステータスを確認します。

    oc get hypershiftdeployment -n default hypershift-demo -w
  4. ホストされているクラスターが作成されると、自動的にハブにインポートされます。これを確認するには、コンソールでクラスターリストを表示するか、次のコマンドを実行します。

    oc get managedcluster <hypershiftDeployment.Spec.infraID>

1.6.1.3. カスタマイズされたホストクラスターのデプロイ

作成した HypershiftDeployment カスタムリソースは、ホストされたコントロールプレーンとその nodePools をデフォルト値でプロビジョニングします。また、HypershiftDeployment カスタムリソースで、hostedClusterSpec および nodePools を指定して、ホストされたコントロールプレーンおよび nodePools をカスタマイズすることもできます。

以下の例のような情報が含まれるファイルを作成します。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: HypershiftDeployment
metadata:
  name: <cluster>
  namespace: default
spec:
  hostingCluster: <hosting-service-cluster>
  hostingNamespace: clusters
  hostedClusterSpec:
    networking:
      machineCIDR: 10.0.0.0/16    # Default
      networkType: OVNKubernetes
      podCIDR: 10.132.0.0/14      # Default
      serviceCIDR: 172.31.0.0/16  # Default
    platform:
      type: AWS
    pullSecret:
      name: <cluster>-pull-secret    # This secret is created by the controller
    release:
      image: quay.io/openshift-release-dev/ocp-release:4.11.2-x86_64  # Default
    services:
    - service: APIServer
      servicePublishingStrategy:
        type: LoadBalancer
    - service: OAuthServer
      servicePublishingStrategy:
        type: Route
    - service: Konnectivity
      servicePublishingStrategy:
        type: Route
    - service: Ignition
      servicePublishingStrategy:
        type: Route
    sshKey: {}
  nodePools:
  - name: <cluster>-<zone-1>
    spec:
      clusterName: <cluster>
      management:
        autoRepair: false
        replace:
          rollingUpdate:
            maxSurge: 1
            maxUnavailable: 0
          strategy: RollingUpdate
        upgradeType: Replace
      platform:
        aws:
          instanceType: m5.large
        type: AWS
      release:
        image: quay.io/openshift-release-dev/ocp-release:4.10.15-x86_64
      replicas: 3
  - name: <cluster>-<zone-2>
    spec:
      clusterName: <cluster>
      management:
        autoRepair: false
        replace:
          rollingUpdate:
            maxSurge: 1
            maxUnavailable: 0
          strategy: RollingUpdate
        upgradeType: Replace
      platform:
        aws:
          instanceType: m5.large
        type: AWS
      release:
        image: quay.io/openshift-release-dev/ocp-release:4.10.15-x86_64
      replicas: 3
  infrastructure:
    cloudProvider:
      name: <my-secret>
    configure: True
    platform:
      aws:
        region: <region>
        zones:
          - <zone-1>
          - <zone-2>

zone-1 をリージョン内のゾーンの名前に置き換えます。

zone-2 をリージョン内のゾーンの名前に置き換えます。

1.6.1.4. ホストサービスクラスターへのアクセス

これで、クラスターにアクセスできます。アクセスシークレットは hypershift-hosting-service-cluster namespace に保存されます。この namespace は、ホストサービスクラスターの名前と同じです。次の形式のシークレット名形式について学習します。

  • kubeconfig シークレット: <hypershiftDeployment.Spec.hostingNamespace>-<hypershiftDeployment.Name>-admin-kubeconfig (clusters-hypershift-demo-admin-kubeconfig)
  • kubeadmin パスワードシークレット: <hypershiftDeployment.Spec.hostingNamespace>-<hypershiftDeployment.Name>-kubeadmin-password (clusters-hypershift-demo-kubeadmin-password)

1.6.2. ホストされているコントロールプレーンリソースの無効化

ホストされているコントロールプレーンクラスター機能を無効にする場合は、HyperShift ホステッドクラスターを破棄し、HyperShift Operator をアンインストールする必要があります。

1.6.2.1. HyperShift がホストするクラスターの破棄

HyperShift がホストするクラスターを破棄するには、次のコマンドのいずれかを実行して、HypershiftDeployment リソースを削除します。

oc delete -f <HypershiftDeployment_yaml_file_name>

または

oc delete hd -n <HypershiftDeployment_namespace> <HypershiftDeployment_resource_name>

1.6.2.2. HyperShift Operator のアンインストール

管理またはホスティングサービスクラスターから HyperShift Operator をアンインストールするには、次のコマンドを実行して、管理クラスターから hypershift-addon ManagedClusterAddon を削除します。

oc delete managedclusteraddon -n <hypershift-management-cluster> hypershift-addon

1.7. API

クラスターライフサイクル管理のために、Kubernetes Operator のマルチクラスターエンジンの API にアクセスできます。ユーザーに必要なアクセス権: ロールが割り当てられているアクションのみを実行できます。詳細は、以下の各リソースに関する API のドキュメントを参照してください。

1.7.1. Clusters API

1.7.1.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンのクラスターリソースを対象としています。クラスターリソースには、create、query、delete、update の 4 つの要求を使用できます。

1.7.1.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.7.1.1.2. タグ
  • cluster.open-cluster-management.io: クラスターを作成して管理します。

1.7.1.2. パス

1.7.1.2.1. 全クラスターのクエリー
GET /cluster.open-cluster-management.io/v1/managedclusters
1.7.1.2.1.1. 説明

クラスターに対してクエリーを実行して詳細を確認します。

1.7.1.2.1.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.7.1.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.1.2.1.4. 消費
  • cluster/yaml
1.7.1.2.1.5. タグ
  • cluster.open-cluster-management.io
1.7.1.2.2. クラスターの作成
POST /cluster.open-cluster-management.io/v1/managedclusters
1.7.1.2.2.1. 説明

クラスターの作成

1.7.1.2.2.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成するクラスターを記述するパラメーター

クラスター

1.7.1.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.1.2.2.4. 消費
  • cluster/yaml
1.7.1.2.2.5. タグ
  • cluster.open-cluster-management.io
1.7.1.2.2.6. HTTP リクエストの例
1.7.1.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1",
  "kind" : "ManagedCluster",
  "metadata" : {
    "labels" : {
      "vendor" : "OpenShift"
    },
    "name" : "cluster1"
  },
  "spec": {
    "hubAcceptsClient": true,
    "managedClusterClientConfigs": [
      {
        "caBundle": "test",
        "url": "https://test.com"
      }
    ]
  },
  "status" : { }
}
1.7.1.2.3. 単一クラスターのクエリー
GET /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
1.7.1.2.3.1. 説明

1 つのクラスターに対してクエリーを実行して詳細を確認します。

1.7.1.2.3.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

cluster_name
必須

問い合わせるクラスターの名前。

string

1.7.1.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.1.2.3.4. タグ
  • cluster.open-cluster-management.io
1.7.1.2.4. クラスターの削除
DELETE /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
1.7.1.2.4.1. 説明

単一クラスターを削除します。

1.7.1.2.4.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

cluster_name
必須

削除するクラスターの名前。

string

1.7.1.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.1.2.4.4. タグ
  • cluster.open-cluster-management.io

1.7.1.3. 定義

1.7.1.3.1. クラスター
名前スキーマ

apiVersion
必須

string

kind
必須

string

metadata
必須

object

spec
必須

spec

spec

名前スキーマ

hubAcceptsClient
必須

bool

managedClusterClientConfigs
任意

< managedClusterClientConfigs > array

leaseDurationSeconds
任意

integer (int32)

managedClusterClientConfigs

名前説明スキーマ

URL
必須

 

string

CABundle
任意

パターン: "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$"

文字列 (バイト)

1.7.2. Clustersets API (v1beta1)

1.7.2.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの Clusterset リソースを対象としています。Clusterset リソースには、create、query、delete、update の 4 つの要求を使用できます。

1.7.2.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.7.2.1.2. タグ
  • cluster.open-cluster-management.io: Clustersets を作成して管理します。

1.7.2.2. パス

1.7.2.2.1. 全 clusterset のクエリー
GET /cluster.open-cluster-management.io/v1beta1/managedclustersets
1.7.2.2.1.1. 説明

Clustersets に対してクエリーを実行して詳細を確認します。

1.7.2.2.1.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.7.2.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.2.2.1.4. 消費
  • clusterset/yaml
1.7.2.2.1.5. タグ
  • cluster.open-cluster-management.io
1.7.2.2.2. clusterset の作成
POST /cluster.open-cluster-management.io/v1beta1/managedclustersets
1.7.2.2.2.1. 説明

Clusterset を作成します。

1.7.2.2.2.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する clusterset を記述するパラメーター

Clusterset

1.7.2.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.2.2.2.4. 消費
  • clusterset/yaml
1.7.2.2.2.5. タグ
  • cluster.open-cluster-management.io
1.7.2.2.2.6. HTTP リクエストの例
1.7.2.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta1",
  "kind" : "ManagedClusterSet",
  "metadata" : {
    "name" : "clusterset1"
  },
  "spec": { },
  "status" : { }
}
1.7.2.2.3. 単一 clusterset のクエリー
GET /cluster.open-cluster-management.io/v1beta1/managedclustersets/{clusterset_name}
1.7.2.2.3.1. 説明

単一の clusterset に対してクエリーを実行して詳細を確認します。

1.7.2.2.3.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

clusterset_name
必須

問い合わせる clusterset の名前。

string

1.7.2.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.2.2.3.4. タグ
  • cluster.open-cluster-management.io
1.7.2.2.4. clusterset の削除
DELETE /cluster.open-cluster-management.io/v1beta1/managedclustersets/{clusterset_name}
1.7.2.2.4.1. 説明

単一 clusterset を削除します。

1.7.2.2.4.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

clusterset_name
必須

削除する clusterset の名前。

string

1.7.2.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.2.2.4.4. タグ
  • cluster.open-cluster-management.io

1.7.2.3. 定義

1.7.2.3.1. Clusterset
名前スキーマ

apiVersion
必須

string

kind
必須

string

metadata
必須

object

1.7.3. Clustersetbindings API (v1beta1)

1.7.3.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの clustersetbinding リソースを対象としています。clustersetbinding リソースには、create、query、delete、update の 4 つの要求を使用できます。

1.7.3.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.7.3.1.2. タグ
  • cluster.open-cluster-management.io: clustersetbinding を作成して管理します。

1.7.3.2. パス

1.7.3.2.1. 全 clustersetbinding のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedclustersetbindings
1.7.3.2.1.1. 説明

clustersetbinding に対してクエリーを実行して詳細を確認します。

1.7.3.2.1.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

namespace
必須

使用する namespace (例: default)

string

1.7.3.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.3.2.1.4. 消費
  • clustersetbinding/yaml
1.7.3.2.1.5. タグ
  • cluster.open-cluster-management.io
1.7.3.2.2. clustersetbinding の作成
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedclustersetbindings
1.7.3.2.2.1. 説明

clustersetbinding を作成します。

1.7.3.2.2.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

namespace
必須

使用する namespace (例: default)

string

Body

body
必須

作成する clustersetbinding を記述するパラメーター

Clustersetbinding

1.7.3.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.3.2.2.4. 消費
  • clustersetbinding/yaml
1.7.3.2.2.5. タグ
  • cluster.open-cluster-management.io
1.7.3.2.2.6. HTTP リクエストの例
1.7.3.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1",
  "kind" : "ManagedClusterSetBinding",
  "metadata" : {
    "name" : "clusterset1",
    "namespace" : "ns1"
  },
 "spec": {
    "clusterSet": "clusterset1"
  },
  "status" : { }
}
1.7.3.2.3. 単一 clustersetbinding のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/managedclustersetbindings/{clustersetbinding_name}
1.7.3.2.3.1. 説明

単一の clustersetbinding に対してクエリーを実行して詳細を確認します。

1.7.3.2.3.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

namespace
必須

使用する namespace (例: default)

string

Path

clustersetbinding_name
必須

問い合わせる clustersetbinding の名前

string

1.7.3.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.3.2.3.4. タグ
  • cluster.open-cluster-management.io
1.7.3.2.4. clustersetbinding の削除
DELETE /cluster.open-cluster-management.io/v1beta1/managedclustersetbindings/{clustersetbinding_name}
1.7.3.2.4.1. 説明

単一 clustersetbinding を削除します。

1.7.3.2.4.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

namespace
必須

使用する namespace (例: default)

string

Path

clustersetbinding_name
必須

削除する clustersetbinding の名前

string

1.7.3.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.3.2.4.4. タグ
  • cluster.open-cluster-management.io

1.7.3.3. 定義

1.7.3.3.1. Clustersetbinding
名前スキーマ

apiVersion
必須

string

kind
必須

string

metadata
必須

object

spec
必須

spec

spec

名前スキーマ

clusterSet
必須

string

1.7.4. Clusterview API (v1alpha1)

1.7.4.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの clusterview リソースを対象としています。clusterview リソースには、アクセス可能なマネージドクラスターおよびマネージドクラスターセットのリストを表示できる CLI コマンドが含まれます。使用できる要求は、list、get、および watch の 3 つです。

1.7.4.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.7.4.1.2. タグ
  • clusterview.open-cluster-management.io: お使いの ID がアクセスできるマネージドクラスターのリストを表示します。

1.7.4.2. パス

1.7.4.2.1. マネージドクラスターの取得
GET /managedclusters.clusterview.open-cluster-management.io
1.7.4.2.1.1. 説明

アクセス可能なマネージドクラスターのリストを表示します。

1.7.4.2.1.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.7.4.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.4.2.1.4. 消費
  • managedcluster/yaml
1.7.4.2.1.5. タグ
  • clusterview.open-cluster-management.io
1.7.4.2.2. マネージドクラスターのリスト表示
LIST /managedclusters.clusterview.open-cluster-management.io
1.7.4.2.2.1. 説明

アクセス可能なマネージドクラスターのリストを表示します。

1.7.4.2.2.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
任意

マネージドクラスターをリスト表示するユーザー ID の名前

string

1.7.4.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.4.2.2.4. 消費
  • managedcluster/yaml
1.7.4.2.2.5. タグ
  • clusterview.open-cluster-management.io
1.7.4.2.2.6. HTTP リクエストの例
1.7.4.2.2.6.1. 要求の body
{
  "apiVersion" : "clusterview.open-cluster-management.io/v1alpha1",
  "kind" : "ClusterView",
  "metadata" : {
    "name" : "<user_ID>"
  },
  "spec": { },
  "status" : { }
}
1.7.4.2.3. マネージドクラスターセットの監視
WATCH /managedclusters.clusterview.open-cluster-management.io
1.7.4.2.3.1. 説明

アクセス可能なマネージドクラスターを確認します。

1.7.4.2.3.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

clusterview_name
任意

監視するユーザー ID の名前

string

1.7.4.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.4.2.4. マネージドクラスターセットのリスト表示
GET /managedclustersets.clusterview.open-cluster-management.io
1.7.4.2.4.1. 説明

アクセス可能なマネージドクラスターをリスト表示します。

1.7.4.2.4.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

clusterview_name
任意

監視するユーザー ID の名前

string

1.7.4.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.4.2.5. マネージドクラスターセットのリスト表示
LIST /managedclustersets.clusterview.open-cluster-management.io
1.7.4.2.5.1. 説明

アクセス可能なマネージドクラスターをリスト表示します。

1.7.4.2.5.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

clusterview_name
任意

監視するユーザー ID の名前

string

1.7.4.2.5.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.4.2.6. マネージドクラスターセットの監視
WATCH /managedclustersets.clusterview.open-cluster-management.io
1.7.4.2.6.1. 説明

アクセス可能なマネージドクラスターを確認します。

1.7.4.2.6.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

clusterview_name
任意

監視するユーザー ID の名前

string

1.7.4.2.6.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.5. マネージドサービスアカウント (テクノロジープレビュー)

1.7.5.1. 概要

このドキュメントは、Kubernetes Operator のマルチクラスターエンジンの ManagedServiceAccount リソースを対象としています。ManagedServiceAccount リソースには、create、query、delete、update の 4 つのリクエストがあります。

1.7.5.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.7.5.1.2. タグ
  • managedserviceaccounts.multicluster.openshift.io`: ManagedServiceAccounts を作成および管理します

1.7.5.2. パス

1.7.5.2.1. ManagedServiceAccount を作成する
POST /apis/multicluster.openshift.io/v1alpha1/ManagedServiceAccounts
1.7.5.2.1.1. 説明

ManagedServiceAccount を作成します。

1.7.5.2.1.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する ManagedServiceAccount を説明するパラメーター。

ManagedServiceAccount

1.7.5.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.5.2.1.4. 消費
  • managedserviceaccount/yaml
1.7.5.2.1.5. タグ
  • managedserviceaccount.multicluster.openshift.io
1.7.5.2.1.5.1. 要求のボディー
{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "CustomResourceDefinition",
  "metadata": {
    "annotations": {
      "controller-gen.kubebuilder.io/version": "v0.4.1"
    },
    "creationTimestamp": null,
    "name": "managedserviceaccount.authentication.open-cluster-management.io"
  },
  "spec": {
    "group": "authentication.open-cluster-management.io",
    "names": {
      "kind": "ManagedServiceAccount",
      "listKind": "ManagedServiceAccountList",
      "plural": "managedserviceaccounts",
      "singular": "managedserviceaccount"
    },
    "scope": "Namespaced",
    "versions": [
      {
        "name": "v1alpha1",
        "schema": {
          "openAPIV3Schema": {
            "description": "ManagedServiceAccount is the Schema for the managedserviceaccounts\nAPI",
            "properties": {
              "apiVersion": {
                "description": "APIVersion defines the versioned schema of this representation\nof an object. Servers should convert recognized schemas to the latest\ninternal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
                "type": "string"
              },
              "kind": {
                "description": "Kind is a string value representing the REST resource this\nobject represents. Servers may infer this from the endpoint the client\nsubmits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
                "type": "string"
              },
              "metadata": {
                "type": "object"
              },
              "spec": {
                "description": "ManagedServiceAccountSpec defines the desired state of ManagedServiceAccount",
                "properties": {
                  "rotation": {
                    "description": "Rotation is the policy for rotation the credentials.",
                    "properties": {
                      "enabled": {
                        "default": true,
                        "description": "Enabled prescribes whether the ServiceAccount token\nwill be rotated from the upstream",
                        "type": "boolean"
                      },
                      "validity": {
                        "default": "8640h0m0s",
                        "description": "Validity is the duration for which the signed ServiceAccount\ntoken is valid.",
                        "type": "string"
                      }
                    },
                    "type": "object"
                  },
                  "ttlSecondsAfterCreation": {
                    "description": "ttlSecondsAfterCreation limits the lifetime of a ManagedServiceAccount.\nIf the ttlSecondsAfterCreation field is set, the ManagedServiceAccount\nwill be automatically deleted regardless of the ManagedServiceAccount's\nstatus. When the ManagedServiceAccount is deleted, its lifecycle\nguarantees (e.g. finalizers) will be honored. If this field is unset,\nthe ManagedServiceAccount won't be automatically deleted. If this\nfield is set to zero, the ManagedServiceAccount becomes eligible\nfor deletion immediately after its creation. In order to use ttlSecondsAfterCreation,\nthe EphemeralIdentity feature gate must be enabled.",
                    "exclusiveMinimum": true,
                    "format": "int32",
                    "minimum": 0,
                    "type": "integer"
                  }
                },
                "required": [
                  "rotation"
                ],
                "type": "object"
              },
              "status": {
                "description": "ManagedServiceAccountStatus defines the observed state of\nManagedServiceAccount",
                "properties": {
                  "conditions": {
                    "description": "Conditions is the condition list.",
                    "items": {
                      "description": "Condition contains details for one aspect of the current\nstate of this API Resource. --- This struct is intended for direct\nuse as an array at the field path .status.conditions.  For example,\ntype FooStatus struct{     // Represents the observations of a\nfoo's current state.     // Known .status.conditions.type are:\n\"Available\", \"Progressing\", and \"Degraded\"     // +patchMergeKey=type\n    // +patchStrategy=merge     // +listType=map     // +listMapKey=type\n    Conditions []metav1.Condition `json:\"conditions,omitempty\"\npatchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n     // other fields }",
                      "properties": {
                        "lastTransitionTime": {
                          "description": "lastTransitionTime is the last time the condition\ntransitioned from one status to another. This should be when\nthe underlying condition changed.  If that is not known, then\nusing the time when the API field changed is acceptable.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "message": {
                          "description": "message is a human readable message indicating\ndetails about the transition. This may be an empty string.",
                          "maxLength": 32768,
                          "type": "string"
                        },
                        "observedGeneration": {
                          "description": "observedGeneration represents the .metadata.generation\nthat the condition was set based upon. For instance, if .metadata.generation\nis currently 12, but the .status.conditions[x].observedGeneration\nis 9, the condition is out of date with respect to the current\nstate of the instance.",
                          "format": "int64",
                          "minimum": 0,
                          "type": "integer"
                        },
                        "reason": {
                          "description": "reason contains a programmatic identifier indicating\nthe reason for the condition's last transition. Producers\nof specific condition types may define expected values and\nmeanings for this field, and whether the values are considered\na guaranteed API. The value should be a CamelCase string.\nThis field may not be empty.",
                          "maxLength": 1024,
                          "minLength": 1,
                          "pattern": "^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$",
                          "type": "string"
                        },
                        "status": {
                          "description": "status of the condition, one of True, False, Unknown.",
                          "enum": [
                            "True",
                            "False",
                            "Unknown"
                          ],
                          "type": "string"
                        },
                        "type": {
                          "description": "type of condition in CamelCase or in foo.example.com/CamelCase.\n--- Many .condition.type values are consistent across resources\nlike Available, but because arbitrary conditions can be useful\n(see .node.status.conditions), the ability to deconflict is\nimportant. The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)",
                          "maxLength": 316,
                          "pattern": "^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$",
                          "type": "string"
                        }
                      },
                      "required": [
                        "lastTransitionTime",
                        "message",
                        "reason",
                        "status",
                        "type"
                      ],
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "expirationTimestamp": {
                    "description": "ExpirationTimestamp is the time when the token will expire.",
                    "format": "date-time",
                    "type": "string"
                  },
                  "tokenSecretRef": {
                    "description": "TokenSecretRef is a reference to the corresponding ServiceAccount's\nSecret, which stores the CA certficate and token from the managed\ncluster.",
                    "properties": {
                      "lastRefreshTimestamp": {
                        "description": "LastRefreshTimestamp is the timestamp indicating\nwhen the token in the Secret is refreshed.",
                        "format": "date-time",
                        "type": "string"
                      },
                      "name": {
                        "description": "Name is the name of the referenced secret.",
                        "type": "string"
                      }
                    },
                    "required": [
                      "lastRefreshTimestamp",
                      "name"
                    ],
                    "type": "object"
                  }
                },
                "type": "object"
              }
            },
            "type": "object"
          }
        },
        "served": true,
        "storage": true,
        "subresources": {
          "status": {}
        }
      }
    ]
  },
  "status": {
    "acceptedNames": {
      "kind": "",
      "plural": ""
    },
    "conditions": [],
    "storedVersions": []
  }
}
1.7.5.2.2. 単一の ManagedServiceAccount をクエリーする
GET /cluster.open-cluster-management.io/v1alpha1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
1.7.5.2.2.1. 説明

詳細については、単一の ManagedServiceAccount を照会してください。

1.7.5.2.2.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

managedserviceaccount_name
required

照会する ManagedServiceAccount の名前。

string

1.7.5.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.5.2.2.4. タグ
  • cluster.open-cluster-management.io
1.7.5.2.3. ManagedServiceAccount を削除する
DELETE /cluster.open-cluster-management.io/v1alpha1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
1.7.5.2.3.1. 説明

単一の ManagedServiceAccount を削除します。

1.7.5.2.3.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

managedserviceaccount_name
required

削除する ManagedServiceAccount の名前。

string

1.7.5.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.5.2.3.4. タグ
  • cluster.open-cluster-management.io

1.7.5.3. 定義

1.7.5.3.1. ManagedServiceAccount
名前説明スキーマ

apiVersion
必須

ManagedServiceAccount のバージョン管理されたスキーマ。

string

kind
必須

REST リソースを表す文字列の値

string

metadata
必須

ManagedServiceAccount のメタデータ。

object

spec
必須

ManagedServiceAccount の仕様。

 

1.7.6. MultiClusterEngine API

1.7.6.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジン用の MultiClusterEngine リソースを対象としています。MultiClusterEngine リソースには、create、query、delete、update の 4 つのリクエストがあります。

1.7.6.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.7.6.1.2. タグ
  • multiclusterengines.multicluster.openshift.io : MultiClusterEngine を作成および管理します。

1.7.6.2. パス

1.7.6.2.1. MultiClusterEngine を作成する
POST /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
1.7.6.2.1.1. 説明

MultiClusterEngine を作成します。

1.7.6.2.1.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する MultiClusterEngine を説明するパラメーター。

MultiClusterEngine

1.7.6.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.6.2.1.4. 消費
  • MultiClusterEngines/yaml
1.7.6.2.1.5. タグ
  • multiclusterengines.multicluster.openshift.io
1.7.6.2.1.5.1. 要求のボディー
{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "CustomResourceDefinition",
  "metadata": {
    "annotations": {
      "controller-gen.kubebuilder.io/version": "v0.4.1"
    },
    "creationTimestamp": null,
    "name": "multiclusterengines.multicluster.openshift.io"
  },
  "spec": {
    "group": "multicluster.openshift.io",
    "names": {
      "kind": "MultiClusterEngine",
      "listKind": "MultiClusterEngineList",
      "plural": "multiclusterengines",
      "shortNames": [
        "mce"
      ],
      "singular": "multiclusterengine"
    },
    "scope": "Cluster",
    "versions": [
      {
        "additionalPrinterColumns": [
          {
            "description": "The overall state of the MultiClusterEngine",
            "jsonPath": ".status.phase",
            "name": "Status",
            "type": "string"
          },
          {
            "jsonPath": ".metadata.creationTimestamp",
            "name": "Age",
            "type": "date"
          }
        ],
        "name": "v1alpha1",
        "schema": {
          "openAPIV3Schema": {
            "description": "MultiClusterEngine is the Schema for the multiclusterengines\nAPI",
            "properties": {
              "apiVersion": {
                "description": "APIVersion defines the versioned schema of this representation\nof an object. Servers should convert recognized schemas to the latest\ninternal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
                "type": "string"
              },
              "kind": {
                "description": "Kind is a string value representing the REST resource this\nobject represents. Servers may infer this from the endpoint the client\nsubmits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
                "type": "string"
              },
              "metadata": {
                "type": "object"
              },
              "spec": {
                "description": "MultiClusterEngineSpec defines the desired state of MultiClusterEngine",
                "properties": {
                  "imagePullSecret": {
                    "description": "Override pull secret for accessing MultiClusterEngine\noperand and endpoint images",
                    "type": "string"
                  },
                  "nodeSelector": {
                    "additionalProperties": {
                      "type": "string"
                    },
                    "description": "Set the nodeselectors",
                    "type": "object"
                  },
                  "targetNamespace": {
                    "description": "Location where MCE resources will be placed",
                    "type": "string"
                  },
                  "tolerations": {
                    "description": "Tolerations causes all components to tolerate any taints.",
                    "items": {
                      "description": "The pod this Toleration is attached to tolerates any\ntaint that matches the triple <key,value,effect> using the matching\noperator <operator>.",
                      "properties": {
                        "effect": {
                          "description": "Effect indicates the taint effect to match. Empty\nmeans match all taint effects. When specified, allowed values\nare NoSchedule, PreferNoSchedule and NoExecute.",
                          "type": "string"
                        },
                        "key": {
                          "description": "Key is the taint key that the toleration applies\nto. Empty means match all taint keys. If the key is empty,\noperator must be Exists; this combination means to match all\nvalues and all keys.",
                          "type": "string"
                        },
                        "operator": {
                          "description": "Operator represents a key's relationship to the\nvalue. Valid operators are Exists and Equal. Defaults to Equal.\nExists is equivalent to wildcard for value, so that a pod\ncan tolerate all taints of a particular category.",
                          "type": "string"
                        },
                        "tolerationSeconds": {
                          "description": "TolerationSeconds represents the period of time\nthe toleration (which must be of effect NoExecute, otherwise\nthis field is ignored) tolerates the taint. By default, it\nis not set, which means tolerate the taint forever (do not\nevict). Zero and negative values will be treated as 0 (evict\nimmediately) by the system.",
                          "format": "int64",
                          "type": "integer"
                        },
                        "value": {
                          "description": "Value is the taint value the toleration matches\nto. If the operator is Exists, the value should be empty,\notherwise just a regular string.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  }
                },
                "type": "object"
              },
              "status": {
                "description": "MultiClusterEngineStatus defines the observed state of MultiClusterEngine",
                "properties": {
                  "components": {
                    "items": {
                      "description": "ComponentCondition contains condition information for\ntracked components",
                      "properties": {
                        "kind": {
                          "description": "The resource kind this condition represents",
                          "type": "string"
                        },
                        "lastTransitionTime": {
                          "description": "LastTransitionTime is the last time the condition\nchanged from one status to another.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "message": {
                          "description": "Message is a human-readable message indicating\ndetails about the last status change.",
                          "type": "string"
                        },
                        "name": {
                          "description": "The component name",
                          "type": "string"
                        },
                        "reason": {
                          "description": "Reason is a (brief) reason for the condition's\nlast status change.",
                          "type": "string"
                        },
                        "status": {
                          "description": "Status is the status of the condition. One of True,\nFalse, Unknown.",
                          "type": "string"
                        },
                        "type": {
                          "description": "Type is the type of the cluster condition.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "conditions": {
                    "items": {
                      "properties": {
                        "lastTransitionTime": {
                          "description": "LastTransitionTime is the last time the condition\nchanged from one status to another.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "lastUpdateTime": {
                          "description": "The last time this condition was updated.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "message": {
                          "description": "Message is a human-readable message indicating\ndetails about the last status change.",
                          "type": "string"
                        },
                        "reason": {
                          "description": "Reason is a (brief) reason for the condition's\nlast status change.",
                          "type": "string"
                        },
                        "status": {
                          "description": "Status is the status of the condition. One of True,\nFalse, Unknown.",
                          "type": "string"
                        },
                        "type": {
                          "description": "Type is the type of the cluster condition.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "phase": {
                    "description": "Latest observed overall state",
                    "type": "string"
                  }
                },
                "type": "object"
              }
            },
            "type": "object"
          }
        },
        "served": true,
        "storage": true,
        "subresources": {
          "status": {}
        }
      }
    ]
  },
  "status": {
    "acceptedNames": {
      "kind": "",
      "plural": ""
    },
    "conditions": [],
    "storedVersions": []
  }
}
1.7.6.2.2. すべての MultiClusterEngine をクエリーする
GET /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
1.7.6.2.2.1. 説明

詳細については、マルチクラスターエンジンに問い合わせてください。

1.7.6.2.2.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.7.6.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.6.2.2.4. 消費
  • operator/yaml
1.7.6.2.2.5. タグ
  • multiclusterengines.multicluster.openshift.io
1.7.6.2.3. MultiClusterEngine Operator の削除
DELETE /apis/multicluster.openshift.io/v1alpha1/multiclusterengines/{name}
1.7.6.2.3.1. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

name
必須

削除するマルチクラスターエンジンの名前。

string

1.7.6.2.3.2. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.6.2.3.3. タグ
  • multiclusterengines.multicluster.openshift.io

1.7.6.3. 定義

1.7.6.3.1. MultiClusterEngine
名前説明スキーマ

apiVersion
必須

MultiClusterEngines のバージョン管理されたスキーマ。

string

kind
必須

REST リソースを表す文字列の値

string

metadata
必須

リソースを定義するルールを記述します。

object

spec
必須

MultiClusterEngineSpec は、MultiClusterEngine の望ましい状態を定義します。

仕様のリスト を参照してください。

1.7.6.3.2. 仕様のリスト
Name説明スキーマ

nodeSelector
任意

nodeselectors を設定します。

map[string]string

imagePullSecret
任意

MultiClusterEngine オペランドおよびエンドポイントイメージにアクセスするためのプルシークレットをオーバーライドします。

string

tolerations
任意

許容範囲により、すべてのコンポーネントがあらゆる Taint を許容します。

[]corev1.Toleration

targetNamespace
任意

MCE リソースが配置される場所。

string

1.7.7. Placements API (v1beta1)

1.7.7.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの配置リソースに関するものです。Placement リソースには、create、query、delete、update の 4 つの要求を使用できます。

1.7.7.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.7.7.1.2. タグ
  • cluster.open-cluster-management.io: Placement を作成して管理します。

1.7.7.2. パス

1.7.7.2.1. 全 Placement のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
1.7.7.2.1.1. 説明

Placement に対してクエリーを実行して詳細を確認します。

1.7.7.2.1.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.7.7.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.7.2.1.4. 消費
  • placement/yaml
1.7.7.2.1.5. タグ
  • cluster.open-cluster-management.io
1.7.7.2.2. Placement の作成
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
1.7.7.2.2.1. 説明

Placement を作成します。

1.7.7.2.2.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する placement を記述するパラメーター

Placement

1.7.7.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.7.2.2.4. 消費
  • placement/yaml
1.7.7.2.2.5. タグ
  • cluster.open-cluster-management.io
1.7.7.2.2.6. HTTP リクエストの例
1.7.7.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta1",
  "kind" : "Placement",
  "metadata" : {
    "name" : "placement1",
    "namespace": "ns1"
  },
  "spec": {
    "predicates": [
      {
        "requiredClusterSelector": {
          "labelSelector": {
            "matchLabels": {
              "vendor": "OpenShift"
            }
          }
        }
      }
    ]
  },
  "status" : { }
}
1.7.7.2.3. 単一の Placement のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
1.7.7.2.3.1. 説明

1 つの Placement に対してクエリーを実行して詳細を確認します。

1.7.7.2.3.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

placement_name
必須

問い合わせる Placement の名前

string

1.7.7.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.7.2.3.4. タグ
  • cluster.open-cluster-management.io
1.7.7.2.4. Placement の削除
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
1.7.7.2.4.1. 説明

単一の Placement を削除します。

1.7.7.2.4.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

placement_name
必須

削除する Placement の名前

string

1.7.7.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.7.2.4.4. タグ
  • cluster.open-cluster-management.io

1.7.7.3. 定義

1.7.7.3.1. Placement
Name説明スキーマ

apiVersion
必須

Placement のバージョンスキーマ

string

kind
必須

REST リソースを表す文字列の値

string

metadata
必須

Placement のメタデータ

object

spec
必須

Placement の仕様

spec

spec

Name説明スキーマ

ClusterSets
任意

ManagedClusters を選択する ManagedClusterSets のサブセット。空白の場合には、Placement namespace にバインドされる ManagedClusterSets から ManagedClusters が選択されます。それ以外の場合は、ManagedClusters がこのサブセットの交差部分から選択され、ManagedClusterSets は Placement namespace にバインドされます。

string array

numberOfClusters
任意

選択する ManagedClusters の必要数

integer (int32)

predicates
任意

ManagedClusters を選択するクラスター述語のサブセット。条件ロジックは OR です。

clusterPredicate アレイ

clusterPredicate

Name説明スキーマ

requiredClusterSelector
任意

ラベルおよびクラスター要求のある ManagedClusters を選択するクラスターセレクター

clusterSelector

clusterSelector

Name説明スキーマ

labelSelector
任意

ラベル別の ManagedClusters のセレクター

object

claimSelector
任意

要求別の ManagedClusters のセレクター

clusterClaimSelector

clusterClaimSelector

Name説明スキーマ

matchExpressions
任意

クラスター要求のセレクター要件のサブセット。条件ロジックは AND です。

< オブジェクト > 配列

1.7.8. PlacementDecisions API (v1beta1)

1.7.8.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの PlacementDecision リソースを対象としています。PlacementDecision リソースには、create、query、delete、update の 4 つの要求を使用できます。

1.7.8.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.7.8.1.2. タグ
  • cluster.open-cluster-management.io: PlacementDecision を作成して管理します。

1.7.8.2. パス

1.7.8.2.1. 全 PlacementDecision のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
1.7.8.2.1.1. 説明

PlacementDecisions に対してクエリーを実行して詳細を確認します。

1.7.8.2.1.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.7.8.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.8.2.1.4. 消費
  • placementdecision/yaml
1.7.8.2.1.5. タグ
  • cluster.open-cluster-management.io
1.7.8.2.2. PlacementDecision の作成
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
1.7.8.2.2.1. 説明

PlacementDecisions を作成します。

1.7.8.2.2.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する PlacementDecision を記述するパラメーター

PlacementDecision

1.7.8.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.8.2.2.4. 消費
  • placementdecision/yaml
1.7.8.2.2.5. タグ
  • cluster.open-cluster-management.io
1.7.8.2.2.6. HTTP リクエストの例
1.7.8.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta1",
  "kind" : "PlacementDecision",
  "metadata" : {
    "labels" : {
      "cluster.open-cluster-management.io/placement" : "placement1"
    },
    "name" : "placement1-decision1",
    "namespace": "ns1"
  },
  "status" : { }
}
1.7.8.2.3. 単一の PlacementDecision のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
1.7.8.2.3.1. 説明

1 つの PlacementDecisions に対してクエリーを実行して詳細を確認します。

1.7.8.2.3.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

placementdecision_name
必須

問い合わせる PlacementDecision の名前

string

1.7.8.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.8.2.3.4. タグ
  • cluster.open-cluster-management.io
1.7.8.2.4. PlacementDecision の削除
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
1.7.8.2.4.1. 説明

単一の PlacementDecision を削除します。

1.7.8.2.4.2. パラメーター
Name説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

placementdecision_name
必須

削除する PlacementDecision の名前

string

1.7.8.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.7.8.2.4.4. タグ
  • cluster.open-cluster-management.io

1.7.8.3. 定義

1.7.8.3.1. PlacementDecision
Name説明スキーマ

apiVersion
必須

PlacementDecision のバージョンスキーマ

string

kind
必須

REST リソースを表す文字列の値

string

metadata
必須

PlacementDecision のメタデータ

object

1.8. トラブルシューティング

トラブルシューティングガイドをご使用の前に oc adm must-gather コマンドを実行して、詳細およびログを収集し、問題のデバッグ手順を行います。詳細は、must-gather コマンドを実行したトラブルシューティング を参照してください。

また、ロールベースのアクセス権限を確認してください。詳細については、ロールベースのアクセス制御 を参照してください。

1.8.1. 文書化されたトラブルシューティング

Kubernetes Operator マルチクラスターエンジンのトラブルシューティングトピックのリストを表示します。

インストール

インストールタスクに関する主要なドキュメントを表示するには、インストール を参照してください。

クラスター管理

クラスターの管理に関する主要なドキュメントを表示するには、Kubernetes Operator クラスターライフサイクルのマルチクラスターエンジンの概要 を参照してください。

1.8.2. must-gather コマンドを実行したトラブルシューティング

トラブルシューティングを開始するには、問題のデバッグを行う must-gather コマンドを実行する場合のトラブルシューティングシナリオについて確認し、このコマンドの使用を開始する手順を参照してください。

必要なアクセス権限: クラスターの管理者

1.8.2.1. Must-gather のシナリオ

  • シナリオ 1: 文書化されたトラブルシューティング セクションを使用して、問題の解決策がまとめられているかどうかを確認します。本ガイドは、製品の主な機能別に設定されています。

    このシナリオでは、解決策が本書にまとめられているかどうかを、本ガイドで確認します。

  • シナリオ 2: 問題の解決策の手順が文書にまとめられていない場合は、must-gather コマンドを実行し、その出力を使用して問題をデバッグします。
  • シナリオ 3: must-gather コマンドの出力を使用して問題をデバッグできない場合は、出力を Red Hat サポートに共有します。

1.8.2.2. Must-gather の手順

must-gather コマンドの使用を開始するには、以下の手順を参照してください。

  1. must-gather コマンドについて確認し、Red Hat OpenShift Container Platform の クラスターに関するデータの収集 に必要な前提条件をインストールします。
  2. クラスターにログインします。通常のユースケースでは、engine クラスターにログインして、must-gather を実行する必要があります。

    注記: マネージドクラスターを確認する場合は、cluster-scoped-resources ディレクトリーにある gather-managed.log ファイルを検索します。

    <your-directory>/cluster-scoped-resources/gather-managed.log>

    JOINED および AVAILABLE 列に True が設定されていないマネージドクラスターがないかを確認します。must-gather コマンドは、ステータスが True として関連付けられていないクラスター上で、実行できます。

  3. データとディレクトリーの収集に使用される Kubernetes イメージのマルチクラスターエンジンを追加します。以下のコマンドを実行して、出力用にイメージとディレクトリーを挿入します。

    oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.1.0 --dest-dir=<directory>
  4. 指定したディレクトリーに移動し、以下のレベルに整理されている出力を確認します。

    • ピアレベル 2 つ: cluster-scoped-resourcesnamespace のリソース
    • それぞれに対するサブレベル: クラスタースコープおよび namespace スコープの両方のリソースに対するカスタムリソース定義の API グループ。
    • それぞれに対する次のレベル: kind でソートされた YAML ファイル

1.8.2.3. 非接続環境での must-gather

非接続環境で must-gather コマンドを実行するには、次の手順を実行します。

  1. 非接続環境では、Red Hat Operator のカタログイメージをミラーレジストリーにミラーリングします。詳細は、ネットワーク切断状態でのインストール を参照してください。
  2. 次のコマンドを実行して、ミラーレジストリーからイメージを参照するログを抽出します。
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8

oc adm must-gather --image=$IMAGE --dest-dir=./data

ここ で製品チームのバグを開くことができます。

1.8.3. インストールステータスがインストールまたは保留中の状態のトラブルシューティング

Kubernetes Operator 用のマルチクラスターエンジンをインストールするときに、MultiClusterEngineInstalling フェーズのままであるか、複数の Pod が Pending ステータスを維持します。

1.8.3.1. 現象: Pending 状態で止まる

MultiClusterEngine をインストールしてから、MultiClusterEngine リソースの status.components フィールドからのコンポーネントの 1 つ以上で ProgressDeadlineExceeded と報告したまま 10 分以上経過しています。クラスターのリソース制約が問題となっている場合があります。

MultiClusterEngine がインストールされた namespace で Pod を確認します。以下のようなステータスとともに Pending と表示される場合があります。

reason: Unschedulable
message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master:
        }, that the pod didn't tolerate.'

このような場合には、ワーカーノードにはクラスターでの製品実行に十分なリソースがありません。

1.8.3.2. 問題の解決: ワーカーノードのサイズの調整

この問題が発生した場合は、大規模なワーカーノードまたは複数のワーカーノードでクラスターを更新する必要があります。クラスターのサイジングのガイドラインについては、クラスターのサイジング を参照してください。

1.8.4. 再インストールに失敗する場合のトラブルシューティング

Kubernetes Operator のマルチクラスターエンジンを再インストールすると、Pod が起動しません。

1.8.4.1. 現象: 再インストールの失敗

Kubernetes Operator 用のマルチクラスターエンジンをインストールした後に Pod が起動しない場合は、多くの場合、Kubernetes Operator 用のマルチクラスターエンジンの以前のインストールからの項目が、アンインストール時に正しく削除されなかったことが原因です。

Pod はこのような場合に、インストールプロセスの完了後に起動しません。

1.8.4.2. 問題の解決: 再インストールの失敗

この問題が発生した場合は、以下の手順を実行します。

  1. アンインストール の手順に従い、現在のコンポーネントを削除し、アンインストールプロセスを実行します。
  2. Helm のインストール の手順に従い、Helm CLI バイナリーバージョン 3.2.0 以降をインストールします。
  3. oc コマンドが実行できるように、Red Hat OpenShift Container Platform CLI が設定されていることを確認してください。oc コマンドの設定方法は、Red Hat OpenShift Container Platform ドキュメントの OpenShift CLI の使用方法 を参照してください。
  4. 以下のスクリプトをファイルにコピーします。

    #!/bin/bash
    MCE_NAMESPACE=<namespace>
    oc delete multiclusterengine --all
    oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
    oc delete crd discoveredclusters.discovery.open-cluster-management.io discoveryconfigs.discovery.open-cluster-management.io
    oc delete mutatingwebhookconfiguration ocm-mutating-webhook managedclustermutators.admission.cluster.open-cluster-management.io
    oc delete validatingwebhookconfiguration ocm-validating-webhook
    oc delete ns $MCE_NAMESPACE

    スクリプト内の <namespace> を、Kubernetes Operator 用のマルチクラスターエンジンがインストールされている namespace の名前に置き換えます。namespace が消去され削除されるため、正しい namespace を指定するようにしてください。

  5. スクリプトを実行して、アーティファクトを以前のインストールから削除します。
  6. インストールを実行します。ネットワーク接続時のオンラインインストール を参照してください。

1.8.5. オフラインクラスターのトラブルシューティング

クラスターのステータスがオフラインと表示される一般的な原因がいくつかあります。

1.8.5.1. 現象: クラスターのステータスがオフライン状態である

クラスターの作成手順を完了したら、Red Hat Advanced Cluster Management コンソールからアクセスできず、クラスターのステータスが offline と表示されます。

1.8.5.2. 問題の解決: クラスターのステータスがオフライン状態になっている

  1. マネージドクラスターが利用可能かどうかを確認します。これは、Red Hat Advanced Cluster Management コンソールの Clusters エリアで確認できます。

    利用不可の場合は、マネージドクラスターの再起動を試行します。

  2. マネージドクラスターのステータスがオフラインのままの場合は、以下の手順を実行します。

    1. ハブクラスターで oc get managedcluster <cluster_name> -o yaml コマンドを実行します。<cluster_name> は、クラスター名に置き換えます。
    2. status.conditions セクションを見つけます。
    3. type: ManagedClusterConditionAvailable のメッセージを確認して、問題を解決します。

1.8.6. マネージドクラスターのインポート失敗に関するトラブルシューティング

クラスターのインポートに失敗した場合は、クラスターのインポートが失敗した理由を判別するためにいくつかの手順を実行できます。

1.8.6.1. 現象: インポートされたクラスターを利用できない

クラスターをインポートする手順を完了すると、コンソールからクラスターにアクセスできなくなります。

1.8.6.2. 問題の解決: インポートされたクラスターが利用できない

インポートの試行後にインポートクラスターが利用できない場合には、いくつかの理由があります。クラスターのインポートに失敗した場合は、インポートに失敗した理由が見つかるまで以下の手順を実行します。

  1. ハブクラスターで、次のコマンドを実行して、インポートコントローラーが実行していることを確認します。

    kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2

    実行中の Pod が 2 つ表示されるはずです。Pod のいずれかが実行されていない場合には、以下のコマンドを実行してログを表示して理由を判別します。

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1
  2. ハブクラスターで次のコマンドを実行して、マネージドクラスターのインポートシークレットがインポートコントローラーによって正常に生成されたかどうかを確認します。

    kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import

    インポートシークレットが存在しない場合は、以下のコマンドを実行してインポートコントローラーのログエントリーを表示し、作成されていない理由を判断します。

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller
  3. ハブクラスターで、マネージドクラスターが local-cluster であるか、Hive によってプロビジョニングされているか、自動インポートシークレットがある場合は、次のコマンドを実行して、マネージドクラスターのインポートステータスを確認します。

    kubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceeded

    ManagedClusterImportSucceededtrue でない場合には、コマンドの結果で失敗の理由が表示されます。

  4. マネージドクラスターの Klusterlet ステータスが degraded 状態でないかを確認します。Klusterlet のパフォーマンスが低下した理由を特定するには、degraded 状態にある Klusterlet のトラブルシューティング を参照してください。

1.8.7. クラスターの再インポートが不明な権限エラーで失敗する

マネージドクラスターを Kubernetes Operator ハブクラスターのマルチクラスターエンジンに再インポートするときに問題が発生した場合は、手順に従って問題をトラブルシューティングします。

1.8.7.1. 症状: クラスターの再インポートが不明な権限エラーで失敗する

Kubernetes Operator 用のマルチクラスターエンジンを使用して OpenShift Container Platform クラスターをプロビジョニングした後、API サーバー証明書を OpenShift Container Platform クラスターに変更または追加すると、x509: certificate signed by unknown authority エラーでクラスターの再インポートが失敗する場合があります。

1.8.7.2. 問題の特定: クラスターの再インポートが不明な権限エラーで失敗する

マネージドクラスターの再インポートに失敗した後、次のコマンドを実行して、マルチクラスターエンジンで Kubernetes Operator ハブクラスターのインポートコントローラーログを取得します。

kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f

次のエラーログが表示される場合は、マネージドクラスター API サーバーの証明書が変更されている可能性があります。

ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace":"awscluster1"}, "namespace": "awscluster1", "name": "awscluster1", "reconcileID": "a2cccf24-2547-4e26-95fb-f258a6710d80", "error": "Get \"https://api.awscluster1.dev04.red-chesterfield.com:6443/api?timeout=32s\": x509: certificate signed by unknown authority"}

マネージドクラスター API サーバー証明書が変更されたかどうかを確認するには、次の手順を実行します。

  1. 次のコマンドを実行して、your-managed-cluster-name をマネージドクラスターの名前に置き換えて、マネージドクラスターの名前を指定します。

    cluster_name=<your-managed-cluster-name>
  2. 次のコマンドを実行して、マネージドクラスター kubeconfig シークレット名を取得します。

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
  3. 次のコマンドを実行して、kubeconfig を新しいファイルにエクスポートします。

    oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.old
    export KUBECONFIG=kubeconfig.old
  4. 次のコマンドを実行して、kubeconfig を使用してマネージドクラスターから namespace を取得します。

    oc get ns

次のメッセージのようなエラーが表示された場合は、クラスター API サーバーの証明書が変更になっており、kubeconfig ファイルが無効です。

Unable to connect to the server: x509: certificate signed by unknown authority

1.8.7.3. 問題の解決: クラスターの再インポートが不明な権限エラーで失敗する

マネージドクラスター管理者は、マネージドクラスター用に新しい有効な kubeconfig ファイルを作成する必要があります。

新しい kubeconfig を作成したら、次の手順を実行して、マネージドクラスターの新しい kubeconfig を更新します。

  1. 次のコマンドを実行して、kubeconfig ファイルパスとクラスター名を設定します。<path_to_kubeconfig> を新しい kubeconfig ファイルへのパスに置き換えます。<managed_cluster_name> をマネージドクラスターの名前に置き換えます。

    cluster_name=<managed_cluster_name>
    kubeconfig_file=<path_to_kubeconfig>
  2. 次のコマンドを実行して、新しい kubeconfig をエンコードします。

    kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)

    注記: macOS では、代わりに次のコマンドを実行します。

    kubeconfig=$(cat ${kubeconfig_file} | base64)
  3. 次のコマンドを実行して、JSON パッチ kubeconfig を定義します。

    kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"
  4. 次のコマンドを実行して、マネージドクラスターから管理者の kubeconfig シークレット名を取得します。

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
  5. 次のコマンドを実行して、管理者の kubeconfig シークレットに新しい kubeconfig を適用します。

    oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"

1.8.8. Pending Import ステータスのクラスターのトラブルシューティング

クラスターのコンソールで継続的に Pending import と表示される場合は、以下の手順を実行して問題をトラブルシューティングしてください。

1.8.8.1. 現象: ステータスが Pending Import クラスター

Red Hat Advanced Cluster Management コンソールを使用してクラスターをインポートした後に、コンソールで、クラスターのステータスが Pending import と表示されます。

1.8.8.2. 問題の特定: ステータスが Pending Import クラスター

  1. マネージドクラスターで以下のコマンドを実行し、問題のある Kubernetes Pod 名を表示します。

    kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent
  2. マネージドクラスターで以下のコマンドを実行し、エラーのログエントリーを探します。

    kubectl logs <registration_agent_pod> -n open-cluster-management-agent

    registration_agent_pod は、手順 1 で特定した Pod 名に置き換えます。

  3. 返された結果に、ネットワーク接続の問題があったと示すテキストがないかどうかを検索します。たとえば、no such host です。

1.8.8.3. 問題の解決: ステータスが Pending Import クラスター

  1. ハブクラスターで以下のコマンドを実行して、問題のあるポート番号を取得します。

    oc get infrastructure cluster -o yaml | grep apiServerURL
  2. マネージドクラスターのホスト名が解決でき、ホストおよびポートへの送信接続が機能していることを確認します。

    マネージドクラスターで通信が確立できない場合は、クラスターのインポートが完了していません。マネージドクラスターのクラスターステータスは、Pending import になります。

1.8.9. 証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング

カスタムの apiserver 証明書のインストールはサポートされますが、証明書情報を変更する前にインポートされたクラスターの 1 つまたは複数でステータスが offline になる可能性があります。

1.8.9.1. 現象: 証明書の変更後にクラスターがオフラインになる

証明書シークレットを更新する手順を完了すると、オンラインだった 1 つ以上のクラスターがコンソールに offline ステータスを表示するようになります。

1.8.9.2. 問題の特定: 証明書の変更後にクラスターがオフラインになる

カスタムの API サーバー証明書の情報を更新すると、インポートされ、新しい証明書が追加される前に稼働していたクラスターのステータスが offline になります。

オフラインのマネージドクラスターの open-cluster-management-agent namespace にある Pod のログで、証明書に問題があるとのエラーが見つかります。以下の例のようなエラーがログに表示されます。

work-agent のログ:

E0917 03:04:05.874759       1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:05.874887       1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:37.245859       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority

registration-agent のログ:

I0917 02:27:41.525026       1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority

1.8.9.3. 問題の解決: 証明書の変更後にクラスターがオフラインになる

マネージドクラスターが local-cluster の場合、またはマネージドクラスターが Kubernetes Operator 用のマルチクラスターエンジンで作成された場合、マネージドクラスターを再インポートするには、10 分以上待つ必要があります。

マネージドクラスターをすぐに再インポートするには、ハブクラスター上のマネージドクラスターインポートシークレットを削除し、{mce-short} で再インポートします。以下のコマンドを実行します。

oc delete secret -n <cluster_name> <cluster_name>-import

<cluster_name> を、インポートするマネージドクラスターの名前に置き換えます。

{mce-short} でインポートされたマネージドクラスターを再インポートする場合は、次の手順を実行して、マネージドクラスターを再度インポートします。

  1. ハブクラスターで、次のコマンドを実行してマネージドクラスターのインポートシークレットを再作成します。

    oc delete secret -n <cluster_name> <cluster_name>-import

    <cluster_name> を、インポートするマネージドクラスターの名前に置き換えます。

  2. ハブクラスターで、次のコマンドを実行して、マネージドクラスターのインポートシークレットを YAML ファイルに公開します。

    oc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode  > import.yaml

    <cluster_name> を、インポートするマネージドクラスターの名前に置き換えます。

  3. マネージドクラスターで、次のコマンドを実行して import.yaml ファイルを適用します。

    oc apply -f import.yaml

注記: 前の手順では、マネージドクラスターがハブクラスターから切り離されません。この手順により、必要なマニフェストがマネージドクラスターの現在の設定 (新しい証明書情報を含む) で更新されます。

1.8.10. クラスターのステータスが offline から available に変わる場合のトラブルシューティング

マネージドクラスターのステータスは、環境またはクラスターを手動で変更することなく、offlineavailable との間で切り替わります。

1.8.10.1. 現象: クラスターのステータスが offline から available に変わる

マネージドクラスターからハブクラスターへのネットワーク接続が不安定な場合に、マネージドクラスターのステータスが offlineavailable との間で順に切り替わると、ハブクラスターにより報告されます。

1.8.10.2. 問題の解決: クラスターのステータスが offline から available に変わる

この問題を解決するには、以下の手順を実行します。

  1. 次のコマンドを入力して、ハブクラスターで ManagedCluster の仕様を編集します。

    oc edit managedcluster <cluster-name>

    cluster-name は、マネージドクラスターの名前に置き換えます。

  2. ManagedCluster 仕様の leaseDurationSeconds の値を増やします。デフォルト値は 5 分ですが、ネットワークの問題がある状態で接続を維持するには十分でない場合があります。リースの時間を長く指定します。たとえば、設定を 20 分に増やします。

1.8.11. VMware vSphere でのクラスター作成のトラブルシューティング

VMware vSphere で Red Hat OpenShift Container Platform クラスターを作成する時に問題が発生した場合は、以下のトラブルシューティング情報を参照して、この情報のいずれかが問題に対応しているかどうかを確認します。

注記: VMware vSphere でクラスター作成プロセスが失敗した場合に、リンクが有効にならずログが表示されないことがあります。上記が発生する場合は、hive-controllers Pod のログを確認して問題を特定できます。hive-controllers ログは hive namespace にあります。

1.8.11.1. 証明書 の IP SAN エラーでマネージドクラスターの作成に失敗する

1.8.11.1.1. 現象: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書 IP SAN エラーを示すエラーメッセージでクラスターに問題が発生します。

1.8.11.1.2. 問題の特定: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。

time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs"
time="2020-08-07T15:27:55Z" level=error
1.8.11.1.3. 問題の解決: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する

認証情報の IP アドレスではなく VMware vCenter サーバー完全修飾ホスト名を使用します。また、VMware vCenter CA 証明書を更新して、IP SAN を組み込むこともできます。

1.8.11.2. 不明な証明局のエラーでマネージドクラスターの作成に失敗する

1.8.11.2.1. 現象: 不明な証明局のエラーでマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書が不明な証明局により署名されているのでクラスターに問題が発生します。

1.8.11.2.2. 問題の特定: 不明な証明局のエラーでマネージドクラスターの作成に失敗する

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。

Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
1.8.11.2.3. 問題の解決: 不明な証明局のエラーでマネージドクラスターの作成に失敗する

認証情報の作成時に認証局の正しい証明書が入力されていることを確認します。

1.8.11.3. 証明書の期限切れでマネージドクラスターの作成に失敗する

1.8.11.3.1. 現象: 証明書の期限切れでマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書の期限が切れているか、有効にしていないため、クラスターに問題が発生します。

1.8.11.3.2. 問題の特定: 証明書の期限切れでマネージドクラスターの作成に失敗する

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。

x509: certificate has expired or is not yet valid
1.8.11.3.3. 問題の解決: 証明書の期限切れでマネージドクラスターの作成に失敗する

ESXi ホストの時間が同期されていることを確認します。

1.8.11.4. タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する

1.8.11.4.1. 現象: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、タグ付けの使用に十分な権限がないためクラスターに問題が発生します。

1.8.11.4.2. 問題の特定: タグ付けの権限が十分にないためにマネージドクラスターの作成に失敗する

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。

time="2020-08-07T19:41:58Z" level=debug msg="vsphere_tag_category.category: Creating..."
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="Error: could not create category: POST https://vspherehost.com/rest/com/vmware/cis/tagging/category: 403 Forbidden"
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="  on ../tmp/openshift-install-436877649/main.tf line 54, in resource \"vsphere_tag_category\" \"category\":"
time="2020-08-07T19:41:58Z" level=error msg="  54: resource \"vsphere_tag_category\" \"category\" {"
1.8.11.4.3. 問題の解決: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する

VMware vCenter が必要とするアカウントの権限が正しいことを確認します。詳細は、インストール時に削除されたイメージレジストリー を参照してください。

1.8.11.5. 無効な dnsVIP でマネージドクラスターの作成に失敗する

1.8.11.5.1. 現象: 無効な dnsVIP でマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、dnsVIP が無効であるため、クラスターに問題が発生します。

1.8.11.5.2. 問題の特定: 無効な dnsVIP でマネージドクラスターの作成に失敗する

VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform リリースイメージを使用しているためです。

failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP
1.8.11.5.3. 問題の解決: 無効な dnsVIP でマネージドクラスターの作成に失敗する

VMware インストーラーでプロビジョニングされるインフラストラクチャーをサポートする OpenShift Container Platform で、新しいバージョンのリリースイメージを選択します。

1.8.11.6. ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する

1.8.11.6.1. 現象: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、間違ったネットワークタイプが指定されているため、クラスターに問題が発生します。

1.8.11.6.2. 問題の特定: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する

VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform イメージを使用しているためです。

time="2020-08-11T14:31:38-04:00" level=debug msg="vsphereprivate_import_ova.import: Creating..."
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error msg="Error: rpc error: code = Unavailable desc = transport is closing"
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=fatal msg="failed to fetch Cluster: failed to generate asset \"Cluster\": failed to create cluster: failed to apply Terraform: failed to complete the change"
1.8.11.6.3. 問題の解決: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する

指定の VMware クラスターに対して有効な VMware vSphere ネットワークタイプを選択します。

1.8.11.7. ディスクの変更処理のエラーでマネージドクラスターの作成に失敗する

1.8.11.7.1. 現象: ディスクの変更処理のエラーが原因でマネージドクラスターの追加に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、ディスク変更処理時にエラーによりクラスターに問題が発生します。

1.8.11.7.2. 問題の特定: ディスクの変更処理のエラーが原因でマネージドクラスターの追加に失敗する

以下のようなメッセージがログに表示されます。

ERROR
ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)
1.8.11.7.3. 問題の解決: ディスクの変更処理のエラーが原因でマネージドクラスターの追加に失敗する

VMware vSphere クライアントを使用してユーザーに プロファイル駆動型のストレージ権限全権限 を割り当てます。

1.8.12. ステータスが Pending または Failed のクラスターのコンソールでのトラブルシューティング

作成してたクラスターのステータスがコンソールで Pending または Failed と表示されている場合は、以下の手順を実行して問題のトラブルシューティングを実行します。

1.8.12.1. 現象: コンソールでステータスが Pending または Failed のクラスターのトラブルシューティング

コンソールを使用して新しいクラスターを作成した後、クラスターは Pending のステータスを超えて進行しないか、Failed ステータスを表示します。

1.8.12.2. 問題の特定: コンソールでステータスが Pending または Failed のクラスター

クラスターのステータスが Failed と表示される場合は、クラスターの詳細ページに移動して、提供されたログへのリンクに進みます。ログが見つからない場合や、クラスターのステータスが Pending と表示される場合は、以下の手順を実行してログを確認します。

  • 手順 1

    1. ハブクラスターで以下のコマンドを実行し、新規クラスターの namespace に作成した Kubernetes Pod の名前を表示します。

      oc get pod -n <new_cluster_name>

      new_cluster_name は、作成したクラスター名に置き換えます。

    2. 名前に provision の文字列が含まれる Pod が表示されていない場合は、手順 2 に進みます。タイトルに provision が含まれる Pod があった場合は、ハブクラスターで以下のコマンドを実行して、その Pod のログを表示します。

      oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive

      new_cluster_name_provision_pod_name は、作成したクラスター名の後に provision が含まれる Pod 名を指定するように置き換えます。

    3. ログでエラーを検索してください。この問題の原因が解明する場合があります。
  • 手順 2

    名前に provision が含まれる Pod がない場合は、問題がプロセスの初期段階で発生しています。ログを表示するには、以下の手順を実行します。

    1. ハブクラスターで以下のコマンドを実行してください。

      oc describe clusterdeployments -n <new_cluster_name>

      new_cluster_name は、作成したクラスター名に置き換えます。クラスターのインストールログの詳細は、Red Hat OpenShift ドキュメントの インストールログの収集 を参照してください。

    2. リソースの Status.Conditions.MessageStatus.Conditions.Reason のエントリーに問題に関する追加の情報があるかどうかを確認します。

1.8.12.3. 問題の解決: コンソールでステータスが Pending または Failed のクラスター

ログでエラーを特定した後に、エラーの解決方法を決定してから、クラスターを破棄して、作り直してください。

以下の例では、サポート対象外のゾーンを選択している可能性を示すログエラーと、解決に必要なアクションが提示されています。

No subnets provided for zones

クラスターの作成時に、サポートされていないリージョンにあるゾーンを 1 つ以上選択しています。問題解決用にクラスターを再作成する時に、以下のアクションの 1 つを実行します。

  • リージョン内の異なるゾーンを選択します。
  • 他のゾーンをリストしている場合は、サポートを提供しないゾーンを省略します。
  • お使いのクラスターに、別のリージョンを選択します。

ログから問題を特定した後に、クラスターを破棄し、再作成します。

クラスターの作成に関する詳細は、クラスターの作成 を参照してください。

1.8.13. OpenShift Container Platform バージョン 3.11 クラスターのインポートの失敗時のトラブルシューティング

1.8.13.1. 現象: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する

Red Hat OpenShift Container Platform バージョン 3.11 クラスターのインポートを試行すると、以下の内容のようなログメッセージでインポートに失敗します。

customresourcedefinition.apiextensions.k8s.io/klusterlets.operator.open-cluster-management.io configured
clusterrole.rbac.authorization.k8s.io/klusterlet configured
clusterrole.rbac.authorization.k8s.io/open-cluster-management:klusterlet-admin-aggregate-clusterrole configured
clusterrolebinding.rbac.authorization.k8s.io/klusterlet configured
namespace/open-cluster-management-agent configured
secret/open-cluster-management-image-pull-credentials unchanged
serviceaccount/klusterlet configured
deployment.apps/klusterlet unchanged
klusterlet.operator.open-cluster-management.io/klusterlet configured
Error from server (BadRequest): error when creating "STDIN": Secret in version "v1" cannot be handled as a Secret:
v1.Secret.ObjectMeta:
v1.ObjectMeta.TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 1313, error found in #10 byte of ...|dhruy45="},"kind":"|..., bigger context ...|tye56u56u568yuo7i67i67i67o556574i"},"kind":"Secret","metadata":{"annotations":{"kube|...

1.8.13.2. 問題の特定: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する

この問題は多くの場合、インストールされている kubectl コマンドラインツールのバージョンが 1.11 以前であるために発生します。以下のコマンドを実行して、実行中の kubectl コマンドラインツールのバージョンを表示します。

kubectl version

返されたデータがバージョンが 1.11 以前の場合は、問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する に記載される修正のいずれかを実行します。

1.8.13.3. 問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する

この問題は、以下のいずれかの手順を実行して解決できます。

  • 最新バージョンの kubectl コマンドラインツールをインストールします。

    1. kubectl ツールの最新バージョンを、Kubernetes ドキュメントの kubectl のインストールとセットアップ からダウンロードします。
    2. kubectl ツールのアップグレード後にクラスターを再度インポートします。
  • import コマンドが含まれるファイルを実行します。

    1. CLI を使用したマネージドクラスターのインポート の手順を開始します。
    2. クラスターのインポートコマンドを作成する場合には、このインポートコマンドを import.yaml という名前の YAML ファイルにコピーします。
    3. 以下のコマンドを実行して、ファイルからクラスターを再度インポートします。

      oc apply -f import.yaml

1.8.14. degraded 状態にある Klusterlet のトラブルシューティング

Klusterlet の状態が Degraded の場合は、マネージドクラスターの Klusterlet エージェントの状態を診断しやすくなります。Klusterlet の状態が Degraded になると、マネージドクラスターの Klusterlet エージェントで発生する可能性のあるエラーに対応する必要があります。Klusterlet の degraded の状態が True に設定されている場合は、以下の情報を参照します。

1.8.14.1. 現象: Klusterlet の状態が degraded である

マネージドクラスターで Klusterlet をデプロイした後に、KlusterletRegistrationDegraded または KlusterletWorkDegraded の状態が True と表示されます。

1.8.14.2. 問題の特定: Klusterlet の状態が degraded である

  1. マネージドクラスターで以下のコマンドを実行して、Klusterlet のステータスを表示します

    kubectl get klusterlets klusterlet -oyaml
  2. KlusterletRegistrationDegraded または KlusterletWorkDegraded をチェックして、状態が True に設定されいるかどうかを確認します。記載されている Degraded の状態は、問題の解決 に進みます。

1.8.14.3. 問題の解決: Klusterlet の状態が degraded である

ステータスが Degraded のリストおよびこれらの問題の解決方法を参照してください。

  • KlusterletRegistrationDegraded の状態が True で、この状態の理由が BootStrapSecretMissing の場合は、open-cluster-management-agent namespace にブートストラップのシークレットを作成する必要があります。
  • KlusterletRegistrationDegraded の状態が True と表示され、状態の理由が BootstrapSecretError または BootstrapSecretUnauthorized の場合は、現在のブートストラップシークレットが無効です。現在のブートストラップシークレットを削除して、open-cluster-management-agent namespace で有効なブートストラップシークレットをもう一度作成します。
  • KlusterletRegistrationDegraded および KlusterletWorkDegradedTrue と表示され、状態の理由が HubKubeConfigSecretMissing の場合は、Klusterlet を削除して作成し直します。
  • KlusterletRegistrationDegraded および KlusterletWorkDegradedTrue と表示され、状態の理由が ClusterNameMissingKubeConfigMissingHubConfigSecretError、または HubConfigSecretUnauthorized の場合は、open-cluster-management-agent namespace からハブクラスターの kubeconfig シークレットを削除します。登録エージェントは再度ブートストラップして、新しいハブクラスターの kubeconfig シークレットを取得します。
  • KlusterletRegistrationDegradedTrue と表示され、状態の理由が GetRegistrationDeploymentFailed または UnavailableRegistrationPod の場合は、状態のメッセージを確認して、問題の詳細を取得して解決してみてください。
  • KlusterletWorkDegradedTrue と表示され、状態の理由が GetWorkDeploymentFailed または UnavailableWorkPod の場合は、状態のメッセージを確認して、問題の詳細を取得し、解決してみてください。

1.8.15. クラスターの削除後も namespace が残る

マネージドクラスターを削除すると、通常 namespace はクラスターの削除プロセスの一部として削除されます。まれに namespace は一部のアーティファクトが含まれた状態で残る場合があります。このような場合は、namaspace を手動で削除する必要があります。

1.8.15.1. 現象: クラスターの削除後も namespace が残る

マネージドクラスターの削除後に namespace が削除されません。

1.8.15.2. 問題の解決: クラスターの削除後も namespace が残る

namespace を手作業で削除するには、以下の手順を実行します。

  1. 次のコマンドを実行して、<cluster_name> namespace に残っているリソースのリストを作成します。

    oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks'|^clusteroauths' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>

    cluster_name は、削除を試みたクラスターの namespace 名に置き換えます。

  2. 以下のコマンドを入力してリストを編集し、ステータスが Delete ではないリストから特定したリソースを削除します。

    oc edit <resource_kind> <resource_name> -n <namespace>

    resource_kind は、リソースの種類に置き換えます。resource_name は、リソース名に置き換えます。namespace は、リソースの namespace に置き換えます。

  3. メタデータで finalizer 属性の場所を特定します。
  4. vi エディターの dd コマンドを使用して、Kubernetes 以外のファイナライザーを削除します。
  5. :wq コマンドを入力し、リストを保存して vi エディターを終了します。
  6. 以下のコマンドを入力して namespace を削除します。

    oc delete ns <cluster-name>

    cluster-name を、削除する namespace の名前に置き換えます。

1.8.16. クラスターのインポート時の auto-import-secret-exists エラー

クラスターのインポートは、auto import secret exists というエラーメッセージで失敗します。

1.8.16.1. 現象: クラスターのインポート時の Auto-import-secret-exists エラー

管理用のハイブクラスターをインポートすると、auto-import-secret already exists というエラーが表示されます。

1.8.16.2. 問題の解決: クラスターのインポート時の Auto-import-secret-exists エラー

この問題は、以前に管理されていたクラスターをインポートしようとすると発生します。これが生じると、クラスターを再インポートしようとすると、シークレットは競合します。

この問題を回避するには、以下の手順を実行します。

  1. 既存の auto-import-secret を手動で削除するには、ハブクラスターで以下のコマンドを実行します。

    oc delete secret auto-import-secret -n <cluster-namespace>

    namespace は、お使いのクラスターの namespace に置き換えます。

  2. ハブクラスターへのターゲットのマネージドクラスターのインポート の手順を使用して、クラスターを再度インポートします。

クラスターがインポートされました。

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.