1.4. multicluster engine Operator を使用したクラスターライフサイクルのリリースノート

OpenShift Service on AWS with Hosted Control Plane クラスターに multicluster engine 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

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 サーバー検証ストラテジーを設定します。以下の手順を実行します。

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

インフラストラクチャーノードで NoExecute 効果を持つ node-role.kubernetes.io/infra taint を使用すると、アドオン Pod がスタックする可能性があります。

この問題を回避するには、node-role.kubernetes.io/infra taint に対して NoExecute ではなく NoSchedule 効果を使用するか、インフラストラクチャーノードから node-role.kubernetes.io/infra taint を削除します。

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

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

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

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

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 の順にクリックします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ManagedClusterAddOn で設定を定義して ClusterManagementAddon の一部の設定をオーバーライドすると、ManagedClusterAddOn が次のステータスで停止する可能性があります。

progressing... mca and work configs mismatch

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

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 を再インストールして回復します。<cluster-name> は、ManagedClusterAddOn の namespace に置き換えます。<addon-name> は、ManagedClusterAddOn の名前に置き換えます。

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

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

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

この問題は、多くの場合、OpenShift Container Platform の次のバージョンで発生します。Red Hat OpenShift のインフラストラクチャー Operator がイメージサービスを使用していなかったためです。

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

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

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

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

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

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

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

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

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

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

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