クラスター

ハブクラスターから VolSync ManagedClusterAddOn を削除すると、マネージドクラスターの VolSync Operator サブスクリプションが削除されますが、クラスターサービスバージョン (CSV) は削除されません。マネージドクラスターから CSV を削除するには、VolSync を削除する各マネージドクラスターで以下のコマンドを実行します。

oc delete csv -n openshift-operators volsync-product.v0.6.0

別のバージョンの VolSync がインストールされている場合は、v0.6.0 をインストール済みバージョンに置き換えます。

ManagedClusterSet を削除した後に、クラスターセットに関連付ける各マネージドクラスターに追加されるラベルは自動的に削除されません。削除したマネージドクラスターセットに含まれる各マネージドクラスターからラベルを手動で削除します。ラベルは cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> のようになります。

ClusterPool に対して Hive ClusterClaim を作成し、ClusterClaimspec ライフタイムフィールドを無効な golang 時間値に手動で設定すると、製品は不正な要求だけでなく、すべての ClusterClaims を満たし、調整を停止します。

このエラーが発生すると、clusterclaim-controller Pod ログに以下の内容が表示されます。これは、プール名と、無効な有効期限が含まれた特定の例です。

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...

無効な要求を削除できます。

不正な要求が削除されると、要求は追加の対話なしに正常に調整を開始します。

clusterimageset は fast チャネルに置かれますが、プロビジョニングされたクラスターは stable チャネルにあります。現時点で、製品は channel をプロビジョニングされた OpenShift Container Platform クラスターと同期しません。

OpenShift Container Platform コンソールで適切なチャネルに切り替えます。Administration > Cluster Settings > Details Channel の順にクリックします。

カスタム CA 証明書を使用してクラスターを管理したハブクラスターのバックアップを復元した後、マネージドクラスターとハブクラスター間の接続が失敗する場合があります。これは、復元されたハブクラスターで CA 証明書がバックアップされなかったためです。接続を復元するには、マネージドクラスターの namespace にあるカスタム CA 証明書情報を、復元されたハブクラスターの <managed_cluster>-admin-kubeconfig シークレットにコピーします。

ヒント: バックアップコピーを作成する前にこの CA 証明書をハブクラスターにコピーする場合は、バックアップコピーにシークレット情報が含まれます。将来、バックアップコピーを使用して復元する場合、ハブとマネージドクラスター間の接続は自動的に完了します。

disableHubSelfManagement が false に設定されている場合、local-cluster は MulticlusterHub Operator によって再作成されます。local-cluster をデタッチした後、local-cluster が自動的に再作成されない場合があります。

コンソールを使用してオンプレミスクラスターを作成する場合は、クラスターで利用可能なサブネットを選択する必要があります。必須フィールドとしてマークされていません。

Infrastructure Operator を使用して OpenShift Container Platform クラスターを作成する場合、ISO イメージのファイル名は長すぎる可能性があります。長いイメージ名により、イメージのプロビジョニングとクラスターのプロビジョニングが失敗します。この問題が生じるかどうかを確認するには、以下の手順を実行します。

この問題が発生する場合、これは通常 OpenShift Container Platform の以下のバージョンで発生します。インフラストラクチャー Operator がイメージサービスを使用していないためです。

このエラーを回避するには、OpenShift Container Platform をバージョン 4.8.18 以降、または 4.9.7 以降にアップグレードしてください。

local-cluster という名前のクラスターを、誤って別の名前のクラスターとして再インポートしようとすると、local-cluster と再インポートしたクラスターのステータスが offline と表示されます。

このケースから回復するには、以下の手順を行います。

マネージドクラスターを自動的にプロビジョニングするように設定された自動化テンプレートは、次の両方の条件が満たされた場合に失敗する可能性があります。

klusterlet Operator をインストールしてマネージドクラスターをインポートする場合には、klusterlet Operator のバージョンは、ハブクラスターのバージョンと同じでなければなりません。そうでないと、klusterlet Operator は動作しません。

マネージドクラスターの namespace を手動で削除できません。マネージドクラスター namespace は、マネージドクラスターの割り当てを解除した後に自動的に削除されます。マネージドクラスターの割り当てを解除する前に手動でマネージドクラスター namespace を削除する場合は、マネージドクラスターの削除後にマネージドクラスターに継続的な終了ステータスが表示されます。この終了マネージドクラスターを削除するには、割り当てを解除したマネージドクラスターからファイナライザーを手動で削除します。

ハブクラスターおよびマネージドクラスターの時間が同期されず、コンソールで unknown と表示され、最数的に、数分以内に available と表示されます。OpenShift Container Platform ハブクラスターの時間が正しく設定されていることを確認します。ノードのカスタマイズ を参照してください。

IBM OpenShift Container Platform Kubernetes Service バージョン 3.11 のクラスターをインポートすることはできません。IBM OpenShift Kubernetes Service の 3.11 よりも後のバージョンはサポート対象です。

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

検索で、ハブクラスターのリソース用の RBAC がマッピングされます。ユーザー RBAC の設定によっては、マネージドクラスターからのノードデータが表示されない場合があります。また検索の結果は、クラスターの Nodes ページに表示される内容と異なる場合があります。

マネージドクラスターを破棄してから 1 時間経過してもステータスが Destroying のままで、クラスターが破棄されません。この問題を解決するには、以下の手順を実行します。

Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform Dedicated 環境にある OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。

特定のマネージドクラスターにある特定のリソースの検索詳細ページで問題が発生する可能性があります。マネージドクラスターの work-manager アドオンが Available ステータスであることを確認してから検索する必要があります。

Red Hat OpenShift Container Platform および OpenShift Container Platform 以外のクラスターの両方は Pod ログ機能をサポートしますが、OpenShift Container Platform 以外のクラスターでは、この機能を使用できるように LoadBalancer が有効にされている必要があります。LoadBalancer を有効にするには、以下の手順を実行します。

LoadBalancer のタイプについての詳細は、Kubernetes のドキュメント のService ページを参照してください。

OpenShift Container Platform 4.10.z でクラスター全体のプロキシー設定を使用してホスティングサービスクラスターを作成すると、nodeip-configuration.service サービスがワーカーノードで開始されません。

Azure で OpenShift Container Platform 4.11 クラスターをプロビジョニングすると、認証 Operator のタイムアウトエラーが原因で失敗します。この問題を回避するには、install-config.yaml ファイルで別のワーカーノードタイプを使用するか、vmNetworkingType パラメーターを Basic に設定します。次の install-config.yaml の例を参照してください。

compute:
- hyperthreading: Enabled
  name: 'worker'
  replicas: 3
  platform:
    azure:
      type:  Standard_D2s_v3
      osDisk:
        diskSizeGB: 128
      vmNetworkingType: 'Basic'

iPXE は、オープンソースのネットワークブートファームウェアです。詳細は、iPXE を参照してください。

ノードの起動時に、一部の DHCP サーバーの URL の長さ制限により、InfraEnv カスタムリソース定義の ipxeScript URL が切り取られ、コンソールに次のエラーメッセージが表示されます。

起動可能なデバイスがありません

この問題を回避するには、以下の手順を実行します。

Red Hat Advanced Cluster Management 2.6 で削除された BareMetalAssets API を使用している場合、BareMetalAssets API が ClusterDeployment にバインドされているため、Red Hat Advanced Cluster Management 2.7 にアップグレードした後に ClusterDeployment を削除することはできません。

この問題を回避するには、以下のコマンドを実行して、Red Hat Advanced Cluster Management 2.7 にアップグレードする前に finalizers を削除します。

oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge

Central Infrastructure Management サービスを使用して非接続環境でクラスターをデプロイすると、クラスターノードのインストールが開始されない場合があります。

この問題は、OpenShift Container Platform バージョン 4.12.0 から 4.12.2 に同梱されている Red Hat Enterprise Linux CoreOS ライブ ISO イメージから作成された検出 ISO イメージをクラスターが使用するために発生します。イメージには、registry.redhat.io および registry.access.redhat.com から取得したイメージの署名を必要とする制限付きの /etc/containers/policy.json ファイルが含まれています。非接続環境では、ミラーリングされたイメージにミラーリングされた署名がない場合があり、その結果、クラスターノードの検出時にイメージのプルが失敗します。Agent イメージがクラスターノードとの接続に失敗するため、Assisted Service との通信が失敗します。

この問題を回避するには、/etc/containers/policy.json ファイルを制限なしに設定する ignition オーバーライドをクラスターに適用します。ignition オーバーライドは、InfraEnv カスタムリソース定義で設定できます。次の例は、オーバーライドを使用した InfraEnv カスタムリソース定義を示しています。

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: cluster
  namespace: cluster
spec:
  ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"files":[{"path":"/etc/containers/policy.json","mode":420,"overwrite":true,"contents":{"source":"data:text/plain;charset=utf-8;base64,ewogICAgImRlZmF1bHQiOiBbCiAgICAgICAgewogICAgICAgICAgICAidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIgogICAgICAgIH0KICAgIF0sCiAgICAidHJhbnNwb3J0cyI6CiAgICAgICAgewogICAgICAgICAgICAiZG9ja2VyLWRhZW1vbiI6CiAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIiI6IFt7InR5cGUiOiJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9"}}]}}'

次の例は、作成される制限なしのファイルを示しています。

{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports": {
        "docker-daemon": {
        "": [
        {
            "type": "insecureAcceptAnything"
        }
        ]
    }
    }
}

この設定を変更すると、クラスターがインストールされます。

Assisted Installer エージェントの起動が遅く、マネージドクラスターをデプロイすると、マネージドクラスターが Pending ステータスのままになり、エージェントリソースがなくなる可能性があります。この問題は、統合フローを無効にすることで回避できます。以下の手順を実行します。

ハブクラスターがマネージドクラスターにアクセスできない、またはマネージドクラスターと通信できない場合、次の制限が発生します。

マネージドクラスターのインストール中に ClusterDeployment リソースを使用してカスタム Ingress ドメインを指定できますが、変更はインストール後に SyncSet リソースを使用してのみ適用されます。その結果、clusterdeployment.yaml ファイルの spec フィールドには、指定したカスタム Ingress ドメインが表示されますが、status には引き続きデフォルトのドメインが表示されます。

アノテーションと ManagedCluster 名が一致しない場合、コンソールはクラスターを Pending import と表示します。クラスターはマルチクラスターエンジン Operator では使用できません。アノテーションがなく、ManagedCluster 名が HostedCluster リソースの Infra-ID 値と一致しない場合は、同じ問題が発生します。

コンソールを使用して既存のホステッドクラスターに新規ノードプールを追加すると、同じバージョンの OpenShift Container Platform がオプションの一覧に複数回、表示される可能性があります。必要なバージョンの一覧で任意のインスタンスを選択できます。

ManagedClusterSet API を使用する場合、selectorType: LaberSelector 設定はサポートされません。selectorType: ExclusiveClusterSetLabel 設定がサポートされています。

重要:

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

以下のクラスタープール RBAC 操作を確認します。

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

認証情報へのアクセスは Kubernetes で制御されます。認証情報は Kubernetes Secret として保存され、セキュリティーを確保します。以下の権限は、Red Hat Advanced Cluster Management for Kubernetes のシークレットのアクセスに関係します。

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

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

metadata:
  labels:
    node-role.kubernetes.io/infra: ""
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra

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

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

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

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

ハブクラスターとマネージドクラスターが同じ CPU アーキテクチャーを使用している場合は、次の手順を実行して、Ironic エージェントイメージを手動でミラーリングします。

ハブクラスターとマネージドクラスターが異なる CPU アーキテクチャーを使用している場合は、デフォルトの Ironic エージェントイメージが使用されます。正しいデフォルトの Ironic エージェントイメージを手動でミラーリングするには、次の手順を実行します。

Amazon Simple Storage Service (S3) シークレットを作成するには、コンソールから次のタスクを実行します。

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

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

最新のリリースイメージでクラスターを作成することが推奨されるため、コンソールには最新バージョンのみがあります。特定バージョンのクラスター作成が必要となる場合があります。そのため、古いバージョンが利用可能となっています。

注意: コンソールでクラスターを作成するときに選択できるのは 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 を実行します。

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

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

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

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

たとえば、ppc64le、aarch64、または 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.13.0-multi-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.0-multi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新しいクラスターを作成するには、次の手順を参照してください。代わりに import したい既存のクラスターがある場合は、ハブクラスターへのターゲットマネージドクラスターのインポート を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

単一ノードの OpenShift クラスターをインストールする場合は、Install single-node OpenShift (SNO) を選択します。シングルノード OpenShift クラスターには、コントロールプレーンサービスとユーザーワークロードをホストするシングルノードが含まれます。

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

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

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

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

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

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

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

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

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

クラスターにアクセスするには、クラスターへのアクセス に進みます。

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

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

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

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

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

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

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

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

コンソールを使用して、multicluster engine Operator によって作成されたクラスターを休止状態にするには、次の手順を実行します。

Clusters ページのクラスターのステータスは、プロセスが完了すると Hibernating になります。

ヒント: Clusters ページで休止するするクラスターを選択し、Actions > Hibernate clusters を選択して、複数のクラスターを休止できます。

選択したクラスターが休止状態になりました。

CLI を使用して、multicluster engine Operator によって作成されたクラスターを休止状態にするには、次の手順を実行します。

選択したクラスターが休止状態になりました。

コンソールを使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。

プロセスを完了すると、Clusters ページのクラスターのステータスは Ready になります。

ヒント: Clusters ページで、再開するクラスターを選択し、Actions > Resume cluster の順に選択して、複数のクラスターを再開できます。

選択したクラスターで通常の操作が再開されました。

CLI を使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。

選択したクラスターで通常の操作が再開されました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

oc delete managedcluster <cluster_name>

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

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

実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加するには、以下の手順を実行します。

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

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

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

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

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

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

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