1.4. マルチクラスターエンジン Operator を使用したクラスターライフサイクルのリリースノート

新機能および拡張機能、サポート、非推奨、削除、およびエラータバグ修正について確認してください。

重要: このドキュメントに、OpenShift Container Platform のリリースノートは含まれていません。OpenShift Container Platform クラスターについては、OpenShift Container Platform リリースノートを参照してください。

非推奨: マルチクラスターエンジン Operator 2.2 以前のバージョンはサポートされなくなりました。ドキュメントはそのまま利用できますが、エラータやその他の更新は提供されません。

ベストプラクティス: 最新バージョンにアップグレードします。

このドキュメントでは、特定のコンポーネントまたは機能が OpenShift Container Platform のより新しいバージョンでのみデプロイおよびテストされている場合を除き、サポートされている最も古い OpenShift Container Platform バージョンを参照します。
完全なサポート情報については、マルチクラスターエンジン Operator のサポートマトリックスを参照してください。ライフサイクルの情報については、Red Hat OpenShift Container Platform ライフサイクルポリシーを参照してください。
現在サポートされているリリースのいずれか、製品ドキュメントで問題が発生した場合は、Red Hat サポートにアクセスして、トラブルシューティングを行ったり、ナレッジベース の記事を表示したり、サポートチームに連絡したり、ケースを開いたりすることができます。認証情報でログインする必要があります。
Red Hat Customer Portal FAQ で、カスタマーポータルのドキュメントの詳細を確認することもできます。

1.4.1. マルチクラスターエンジン Operator を使用したクラスターライフサイクルの新機能

さまざまなインフラストラクチャークラウドプロバイダー、プライベートクラウド、オンプレミスデータセンターにわたる Kubernetes クラスターを作成、インポート、管理、破棄するための新機能を説明します。

完全なサポート情報については、マルチクラスターエンジン Operator のサポートマトリックスを参照してください。ライフサイクルの情報については、Red Hat OpenShift Container Platform ライフサイクルポリシーを参照してください。

重要: クラスター管理で、Cloud Native Computing Foundation (CNCF) Kubernetes Conformance Program を通じて認定されたすべてのプロバイダーがサポートされるようになりました。ハイブリッドクラウドマルチクラスター管理には、CNFC が認定したベンダーを選択してください。

CNFC プロバイダーの使用は、次の情報を参照してください。

Certified Kubernetes Conformance で CNFC プロバイダーがどのように認定されるかを学びます。
CNFC サードパーティープロバイダーに関する Red Hat サポート情報は、サードパーティーコンポーネントに関する Red Hat サポートを参照するか、Red Hat サポートへのお問い合わせを参照してください。
独自の CNFC 適合認定クラスターを使用する場合は、OpenShift Container Platform CLI の oc コマンドを Kubernetes CLI コマンドの kubectl に変更する必要があります。

1.4.1.1. コンポーネントの新機能と機能拡張

特定のコンポーネントの新機能について詳しく説明します。

注記: 一部の機能とコンポーネントは、テクノロジープレビューとして指定およびリリースされています。

重要： ホストされたコントロールプレーンのドキュメントは、OpenShift Container Platform ドキュメントにあるようになりました。OpenShift Container Platform ドキュメントのホストされたコントロールプレーンの概要を参照してください。

マルチクラスターエンジン Operator 2.6 以前を使用している場合、ホストされたコントロールプレーンのドキュメントは Red Hat Advanced Cluster Management 製品ドキュメントにあります。Red Hat Advanced Cluster Management ホストされたコントロールプレーンを参照してください。

1.4.1.2. クラスター管理

マルチクラスターエンジン Operator を使用したクラスターライフサイクルの新機能と機能拡張を説明します。

klusterlet マニフェストの kubeconfig ブートストラップの有効期限が切れる期間を設定できるようになりました。詳細は、クラスターのインポートを参照してください。
すべてのクラスターリソースをインポートし、アシステッドインストーラーによってインストールされたマネージドクラスターを別のハブクラスターに移動しても、引き続き使用できます。詳細は、クラスターリソースのインポートを参照してください。
サービスアカウント認証情報を使用して OpenShift Cluster Manager に接続できるようになりました。詳細は、Red Hat OpenShift Cluster Manager の認証情報の作成を参照してください。
マネージドクラスターのインポート時に CA バンドルを指定できるようになりました。詳細は、マネージドクラスターのインポート時のハブクラスター API サーバーのサーバー URL および CA バンドルのカスタマイズ（テクノロジープレビュー）を参照してください。
ハブクラスター KubeAPIServer 検証ストラテジーを手動で設定できるようになりました。詳細は、ハブクラスター KubeAPIServer 検証戦略の設定を参照してください。

1.4.2. マルチクラスターエンジン Operator を使用したクラスターライフサイクルのエラータ更新

マルチクラスターエンジン Operator の場合、エラータの更新はリリース時に自動的に適用されます。

リリースノートが記載されていない場合は、現時点で製品にエラータリリースがありません。

重要: 参考までに、Jira リンクと Jira 番号がコンテンツに追加され、内部で使用される可能性があります。ユーザーは、アクセス権が必要なリンクを利用できない可能性があります。

1.4.2.1. エラータ 2.7.1

1 つ以上の製品コンテナーイメージに更新を配信します。

1.4.2.2. Errata 2.7.2

1 つ以上の製品コンテナーイメージに更新を配信します。
Clear all filters ボタンのエラーを修正します。(ACM-15277)
クラスターのデタッチ アクションによるホストされたクラスターの削除を停止します。(ACM-15018)
有効な OpenShift Cluster Manager 認証情報を無効な値に更新した後、コンソールの Discovery タブにマネージドクラスターが表示されないようにします。(ACM-15010)
cluster-proxy-addon が Progressing 状態でスタックしないようにします。(ACM-14863)

1.4.3. マルチクラスターエンジン Operator を使用したクラスターライフサイクルの既知の問題と制限

本リリースの マルチクラスターエンジン Operator を使用したクラスターライフサイクル の既知の問題と制限、または以前のリリースから継続した既知の問題を確認してください。

クラスター管理の既知の問題と制限は、マルチクラスターエンジン Operator のドキュメントを使用したクラスターライフサイクル の一部です。Red Hat Advanced Cluster Management と統合された {mce-short の既知の問題は、Red Hat Advanced Cluster Management のリリースノートに記載されています。

1.4.3.1. インストール

マルチクラスターエンジン Operator のインストール時に既知の問題と制限について説明します。

1.4.3.1.1. ホステッドコントロールプレーンクラスターを備えた OpenShift Service on AWS にインストールするときにステータスが停止する

ホステッドコントロールプレーンクラスターを使用して OpenShift Service on AWS にマルチクラスターエンジン Operator をインストールすると、インストールステータスが Installing 状態でスタックする場合があります。local-cluster も Unknown 状態になる可能性があります。

ハブクラスターの open-cluster-management-agent namespace で klusterlet-agent Pod ログを確認すると、次のようなエラーが表示されます。

E0809 18:45:29.450874       1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority

この問題を解決するには、ハブクラスター API サーバー検証ストラテジーを設定します。以下の手順を実行します。

KlusterletConfig リソースが存在しない場合は、global という名前で作成します。

spec.hubKubeAPIServerConfig.serverVerificationStrategy を UseSystemTruststore に設定します。以下の例を参照してください。

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

ハブクラスターで次のコマンドを実行してリソースを適用します。&lt ;filename& gt; をファイルの名前に置き換えます。
```
oc apply -f <filename>
```
local-cluster の状態が 1 分間にリカバリーされない場合は、ハブクラスターで以下のコマンドを実行して、import.yaml ファイルをエクスポートおよびデコードします。
```
oc get secret local-cluster-import -n local-cluster -o jsonpath={.data.import\.yaml} | base64 --decode > import.yaml
```
ハブクラスターで次のコマンドを実行して、ファイルを適用します。
```
oc apply -f import.yaml
```

1.4.3.1.2. installNamespace フィールドには値を 1 つだけ指定できる

managed-serviceaccount アドオンを有効にする場合、ManagedClusterAddOn リソースの installNamespace フィールドの値として open-cluster-management-agent-addon が必要です。その他の値は無視されます。managed-serviceaccount アドオンエージェントは、マネージドクラスターの open-cluster-management-agent-addon namespace に常にデプロイされます。

1.4.3.2. クラスター

マルチクラスターエンジン Operator を使用したクラスターライフサイクルの既知の問題と制限事項（クラスターの作成、検出、インポート、および削除に関する問題、マルチクラスターエンジン Operator のクラスター管理問題など）について説明します。

1.4.3.2.1. nmstate の制限事項

コピーアンドペースト機能を設定することで、開発を迅速化します。assisted-installer で copy-from-mac 機能を設定するには、nmstate 定義インターフェイスと mac-mapping インターフェイスに mac-address を追加する必要があります。mac-mapping インターフェイスは、nmstate 定義インターフェイスの外部で提供されます。そのため、同じ mac-address を 2 回指定する必要があります。

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

1.4.3.2.2. マネージドクラスターセットを削除してもそのラベルが自動的に削除されない

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

1.4.3.2.3. ClusterClaim エラー

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

clusterclaim-controller Pod ログに次のエラーが表示されます。これは、PoolName と無効な lifetime が含まれている具体的な例です。

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

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

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

1.4.3.2.4. 製品チャネルが、プロビジョニングされたクラスターと同期されない

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

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

1.4.3.2.5. オンプレミスクラスターを作成する場合は、サブネットを選択する必要がある

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

1.4.3.2.6. Ansible 自動化を使用したクラスタープロビジョニングがプロキシー環境で失敗する

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

ハブクラスターで、クラスター全体のプロキシーが有効になっている。
Ansible Automation Platform には、プロキシー経由でのみアクセスできます。

1.4.3.2.7. マネージドクラスター namespace を手動で削除できない

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

1.4.3.2.8. プロビジョニングされたクラスターのシークレットの自動更新はサポートされていない

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

1.4.3.2.9. クラスターを破棄するプロセスが完了しない

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

クラウドに孤立したリソースがなく、マネージドクラスターに関連付けられたプロバイダーリソースがすべて消去されていることを確認します。
以下のコマンドを入力して、削除するマネージドクラスターの ClusterDeployment 情報を開きます。
```
oc edit clusterdeployment/<mycluster> -n <namespace>
```
mycluster は、破棄するマネージドクラスターの名前に置き換えます。
namespace は、マネージドクラスターの namespace に置き換えます。
hive.openshift.io/deprovision ファイナライザーを削除し、クラウドのクラスターリソースを消去しようとするプロセスを強制的に停止します。
変更を保存して、ClusterDeployment が削除されていることを確認します。
以下のコマンドを実行してマネージドクラスターの namespace を手動で削除します。
```
oc delete ns <namespace>
```
namespace は、マネージドクラスターの namespace に置き換えます。

1.4.3.2.10. OpenShift Container Platform Dedicated でコンソールを使用して OpenShift Container Platform マネージドクラスターをアップグレードできない

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

1.4.3.2.11. ワークマネージャーのアドオン検索の詳細

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

1.4.3.2.12. OpenShift Container Platform 以外のマネージドクラスターには、Pod ログ用に ManagedServiceAccount または LoadBalancer が必要です

ManagedServiceAccount とクラスタープロキシーアドオンは、Red Hat Advanced Cluster Management バージョン 2.10 以降でデフォルトで有効になっています。アップグレード後にアドオンが無効になっている場合は、ManagedServiceAccount とクラスタープロキシーアドオンを手動で有効にして、OpenShift Container Platform 以外のマネージドクラスターで Pod ログ機能を使用する必要があります。

ManagedServiceAccount を有効にする方法は、ManagedServiceAccount アドオンを参照してください。また、クラスタープロキシーアドオンを有効にする方法は、クラスタープロキシーアドオンの使用を参照してください。

1.4.3.2.13. OpenShift Container Platform 4.10.z では、プロキシー設定を使用する Hosted Control Plane クラスターはサポートされません

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

1.4.3.2.14. クライアントが iPXE スクリプトにアクセスできない

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

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

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

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

自動インストールを使用して bootArtifacts を公開する場合は、InfraEnv カスタムリソース定義を適用します。これは次のファイルのようになります。

status:
  agentLabelSelector:
    matchLabels:
      infraenvs.agent-install.openshift.io: qe2
  bootArtifacts:
    initrd: https://assisted-image-service-multicluster-engine.redhat.com/images/0000/pxe-initrd?api_key=0000000&arch=x86_64&version=4.11
    ipxeScript: https://assisted-service-multicluster-engine.redhat.com/api/assisted-install/v2/infra-envs/00000/downloads/files?api_key=000000000&file_name=ipxe-script
    kernel: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-kernel-x86_64
    rootfs: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12/latest/rhcos-live-rootfs.x86_64.img

短い URL で bootArtifacts を公開するプロキシーサーバーを作成します。

次のコマンドを実行して、bootArtifacts をコピーし、プロキシーに追加します。

for artifact in oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts}" | jq ". | keys[]" | sed "s/\"//g"
do curl -k oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts.${artifact}}"` -o $artifact

ipxeScript アーティファクトプロキシー URL を libvirt.xml の bootp パラメーターに追加します。

1.4.3.2.15. Red Hat Advanced Cluster Management のアップグレード後に ClusterDeployment を削除できない

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

1.4.3.2.16. マネージドクラスターがデプロイ後に Pending ステータスのままになる

デフォルトのプロビジョニングプロセスは、コンバージドフローです。Bare Metal Operator (BMO) の BareMetalHost リソースを使用してホストをライブ ISO に接続すると、Ironic Python Agent が次のアクションを実行します。

ベアメタル installer-provisioned-infrastructure の手順を実行します。
Assisted Installer エージェントを起動します。エージェントが残りのインストールおよびプロビジョニングプロセスを処理します。

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

重要: コンバージドフローを無効にすると、ライブ ISO で Assisted Installer エージェントのみが実行されるため、開いているポートの数が減り、Ironic Python Agent で有効にした以下の機能がすべて無効になります。

プロビジョニング前のディスククリーニング
iPXE ブートファームウェア
BIOS 設定

コンバージドフローを無効にせずに有効または無効にするポート番号を決定するには、ネットワーク設定を参照してください。

コンバージドフローを無効にするには、次の手順を実行します。

ハブクラスター上に次の ConfigMap を作成します。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-assisted-service-config
  namespace: multicluster-engine
data:
  ALLOW_CONVERGED_FLOW: "false" 1
```
1
パラメーター値を "false" に設定すると、Ironic Python Agent によって有効になっている機能もすべて無効になります。

次のコマンドを実行して、ConfigMap を適用します。

oc annotate --overwrite AgentServiceConfig agent unsupported.agent-install.openshift.io/assisted-service-configmap=my-assisted-service-config

1.4.3.2.17. ManagedClusterSet API 仕様の制限

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

1.4.3.2.18. クラスターキュレーターが OpenShift Container Platform Dedicated クラスターをサポートしていない

ClusterCurator リソースを使用して OpenShift Container Platform Dedicated クラスターをアップグレードすると、クラスターキュレーターが OpenShift Container Platform Dedicated クラスターをサポートしていないため、アップグレードが失敗します。

1.4.3.2.19. カスタム Ingress ドメインが正しく適用されない

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

1.4.3.2.20. `ManagedClusterAddOn の` ステータスがスタックする

ClusterManagementAddon の一部の設定を上書きするために ManagedClusterAddon で設定を定義すると、ManagedClusterAddon が次のステータスで停止する可能性があります。

progressing... mca and work configs mismatch

ManagedClusterAddon ステータスを確認すると、設定が存在する場合でも、設定の一部に空の spec ハッシュがあります。以下の例を参照してください。

status:
  conditions:
  - lastTransitionTime: "2024-09-09T16:08:42Z"
    message: progressing... mca and work configs mismatch
    reason: Progressing
    status: "True"
    type: Progressing
...
  configReferences:
  - desiredConfig:
      name: deploy-config
      namespace: open-cluster-management-hub
      specHash: b81380f1f1a1920388d90859a5d51f5521cecd77752755ba05ece495f551ebd0
    group: addon.open-cluster-management.io
    lastObservedGeneration: 1
    name: deploy-config
    namespace: open-cluster-management-hub
    resource: addondeploymentconfigs
  - desiredConfig:
      name: cluster-proxy
      specHash: ""
    group: proxy.open-cluster-management.io
    lastObservedGeneration: 1
    name: cluster-proxy
    resource: managedproxyconfigurations

この問題を解決するには、次のコマンドを実行して ManagedClusterAddon を削除し、ManagedClusterAddon を再インストールして復元します。&lt ;cluster-name&gt; は ManagedClusterAddon namespace に置き換えます。&lt ;addon-name&gt; を ManagedClusterAddon 名に置き換えます。

oc -n <cluster-name> delete managedclusteraddon <addon-name>

1.4.3.3. Central infrastructure management

1.4.3.3.1. Red Hat OpenShift のインフラストラクチャー Operator を使用したクラスタープロビジョニングが失敗する

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

以下のコマンドを実行して、プロビジョニングするクラスターのベアメタルホスト情報を表示します。
```
oc get bmh -n <cluster_provisioning_namespace>
```
describe コマンドを実行して、エラー情報を表示します。
```
oc describe bmh -n <cluster_provisioning_namespace> <bmh_name>
```

以下の例と同様のエラーは、ファイル名の長さが問題であることを示します。

Status:
  Error Count:    1
  Error Message:  Image provisioning failed: ... [Errno 36] File name too long ...

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

4.8.17 以前
4.9.6 以前

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

1.4.3.3.2. ホストインベントリーを使用して検出イメージで起動し、ホストを自動的に追加できません

ホストインベントリーまたは InfraEnv カスタムリソースを使用して、検出イメージで起動し、ホストを自動的に追加することはできません。以前の InfraEnv リソースを BareMetalHost リソースに使用していて、イメージを自分で起動する場合は、新しい InfraEnv リソースを作成することで問題を回避できます。

1.4.3.3.3. シングルノードの OpenShift クラスターのインストールには、一致する OpenShift Container Platform と Red Hat OpenShift のインフラストラクチャー Operator が必要です。

4.16 より前の Red Hat OpenShift Container Platform バージョンを使用してシングルノード OpenShift クラスターをインストールする場合は、InfraEnv カスタムリソースと起動ホストが、単一ノードの OpenShift クラスターのインストールに使用するのと同じ OpenShift Container Platform バージョンを使用する必要があります。バージョンが一致しない場合は、インストールに失敗します。

この問題を回避するには、Discovery ISO を使用してホストを起動する前に InfraEnv リソースを編集し、次のコンテンツを含めます。

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
spec:
  osImageVersion: 4.15

osImageVersion フィールドは、インストールする Red Hat OpenShift Container Platform クラスターのバージョンと一致する必要があります。

1.4.3.3.4. マネージドサービスアカウントエージェントは tolerations と nodeSelector の設定による影響を受けない

MultiClusterEngine および MultiClusterHub リソースに設定された tolerations と nodeSelector 設定は、ローカルクラスターにデプロイされた managed-serviceaccount エージェントには影響しません。マネージドサービスアカウント アドオンは、ローカルクラスターでは必ずしも必要というわけではありません。

managed-serviceaccount アドオンが必要な場合は、次の手順を実行することで問題を回避できます。

addonDeploymentConfig カスタムリソースを作成します。
ローカルクラスターおよび managed-serviceaccount エージェントの tolerations および nodeSelector の値を設定します。
作成した addonDeploymentConfig カスタムリソースを使用するように、ローカルクラスター namespace で managed-serviceaccount ManagedClusterAddon を更新します。

addonDeploymentConfig カスタムリソースを使用してアドオンの tolerations と nodeSelector を設定する方法の詳細は、klusterlet アドオンの nodeSelectors と tolerations の設定を参照してください。

1.4.3.3.5. `BareMetalHost` リソースを削除した後、ノードはシャットダウンします

ハブクラスターから BareMetalHost リソースを削除すると、ノードはシャットダウンします。手動でノードの電源をオンにすることができます。

1.4.4. マルチクラスターエンジン Operator を使用したクラスターライフサイクルの非推奨と削除

製品の一部が非推奨になる、またはマルチクラスターエンジン Operator から削除されるタイミングを説明します。推奨アクション および詳細にある、代わりのアクションを検討してください。これについては、現在のリリースおよび、1 つ前のリリースと 2 つ前のリリースの表に記載されています。このリリースで該当するセクションに追加する項目がなかった場合、テーブルは削除されています。