場合によっては、カスタマーポータルの Red Hat Advanced Cluster Management ドキュメントの他のセクションへの内部リンクが指定されたセクションに直接リンクしないことがあります。最上位のセクションにリンクされる場合もあります。

これが発生した場合は、指定されたセクションを手動で見つけるか、次の手順を実行して解決できます。

Red Hat Advanced Cluster Management を新しいバージョンにアップグレードした後、StatefulSet に属するいくつかの Pod が failed 状態のままになることがあります。このまれなイベントは、Kubernetes の既知の問題 が原因です。

この問題の回避策として、失敗した Pod を削除します。Kubernetes は、正しい設定で自動的に再起動します。

Openshift Container Platform クラスターがアップグレードの段階に入ると、クラスター Pod は再起動され、クラスターのステータスが 1-5 分ほど、upgrade failed のままになることがあります。この動作は想定されており、数分後に解決されます。

2.4.x から 2.5.0 にアップグレードした後、2 つのクラスターキュレーターコントローラーが同時に実行される場合があります。クラスターライフサイクル Ansible 統合の一部のプリフックおよびポストフックに対して、2 つ以上の AnsibleJob が作成されました。この問題を解決するには、次の手順を参照してください。

Red Hat OpenShift Container Platform コンソールに Red Hat Advanced Cluster Management for Kubernetes をインストールすると、ポップアップウィンドウに次のメッセージが表示されます。

MultiClusterEngine required

Create a MultiClusterEngine instance to use this Operator.

ポップアップウィンドウメッセージの Create MultiClusterEngine ボタンが機能しない場合があります。この問題を回避するには、提供された API セクションの MultiClusterEngine タイルで インスタンスの作成 を選択します。

Red Hat Advanced Cluster Management バージョン 2.5.2 以降の 2.5.x バージョンは Red Hat OpenShift Container Platform バージョン 4.11 でサポートされていますが、Red Hat Advanced Cluster Management 2.5.x ではダークモードはサポートされていません。設定でダークモードを無効にするか、Red Hat Advanced Cluster Management バージョン 2.6 にアップグレードしてダークモードを有効にします。

Kubernetes Operator バージョン 2.0.2 およびそれ以降の 2.0.x バージョンのマルチクラスターエンジンは Red Hat OpenShift Container Platform バージョン 4.11 でサポートされますが、ダークモードは Kubernetes Operator 2.0.x のマルチクラスターエンジンではサポートされません。設定でダークモードを無効にするか、Kubernetes Operator バージョン 2.1 のマルチクラスターエンジンにアップグレードしてダークモードを有効にします。

LDAP ユーザー名は、大文字と小文字が区別されます。LDAP ディレクトリーで設定したものと全く同じ名前を使用する必要があります。

この製品は、Linux、macOS、および Windows で利用可能な Mozilla Firefox 74.0 または最新バージョンをサポートします。コンソールの互換性を最適化するため、最新版にアップグレードしてください。

searchcustomization CR でストレージサイズを更新する場合、PVC 設定は変更されません。ストレージサイズを更新する必要がある場合は、以下のコマンドで PVC (<storageclassname>-search-redisgraph-0) を更新します。

oc edit pvc <storageclassname>-search-redisgraph-0

環境が大規模になり、スケーリングのためにさらに多くのテストが必要になると、検索クエリーがタイムアウトになり、解析エラーメッセージが表示されることがあります。このエラーは、検索クエリーを 30 秒間待機した後に表示されます。

次のコマンドでタイムアウト時間を延長します。

kubectl annotate route multicloud-console haproxy.router.openshift.io/timeout=Xs

admin ロールを使用してクラスターセットの namespace バインディングを編集すると、次のメッセージのようなエラーが発生する場合があります。

ResourceError: managedclustersetbindings.cluster.open-cluster-management.io "<cluster-set>" is forbidden: User "<user>" cannot create/delete resource "managedclustersetbindings" in API group "cluster.open-cluster-management.io" in the namespace "<namespace>".

この問題を解決するには、バインドする namespace で ManagedClusterSetBinding リソースを作成または削除する権限も持っていることを確認してください。ロールバインディングでは、クラスターセットを namespace にバインドすることしかできません。

コンソールでクラスターの詳細を表示すると、ノード タブまたは マシンプール タブに次のメッセージが表示される場合があります。

Worker nodes are currently being removed from this cluster.Click the View machines button to see the status of the scaling operations (it may take a few minutes for the changes to be reflected on this console).

マシンプールが存在しない場合 (ユーザープロビジョニングインフラストラクチャー (UPI) インストールを使用するプロバイダーの場合) は、誤ったアラートを無視してください。コントロールプレーンの一部ではないワーカーノードがある場合に、このアラートが表示されます。マシンプールをスケーリングするのではなく、ワーカーノードが直接クラスターに追加された場合には、インストーラーでプロビジョニングされるインフラストラクチャー (IPI) のインストールを使用してプロビジョニングされたクラスターに対して、誤ったアラートが表示されることもあります。

さまざまなハブクラスターが同じ S3 ストレージを使用して Red Hat Advanced Cluster Management の可観測性をデプロイする場合、重複する local-clusters は Kubernetes/Service-Level Overview/API Server ダッシュボード内で検出および表示できます。重複クラスターは、Top Clusters、Number of clusters that has exceeded the SLO、および Number of clusters that are meeting the SLO のパネル内の結果に影響を及ぼします。local-clusters は、共有 S3 ストレージに関連付けられた一意のクラスターです。複数の local-clusters がダッシュボード内で表示しないようにするには、一意のハブクラスターごとに、ハブクラスター専用の S3 バケットを使用して可観測性をデプロイすることが推奨されます。

可観測性エンドポイント Operator は、MultiClusterObservability CustomResource (CR) へのデプロイにプルシークレットを作成したにもかかわらず、open-cluster-management-observability namespace にプルシークレットがない場合に問題が発生します。新しいクラスターをインポートする場合、または Red Hat Advanced Cluster Management で作成された Hive クラスターをインポートする場合は、マネージドクラスターにプルイメージシークレットを手動で作成する必要があります。

詳細は、可観測性の有効化 を参照してください。

Red Hat Advanced Cluster Management の可観測性は、組み込みダッシュボードで、ROKS クラスターおよび HyperShift クラスターのデータが表示されないパネルがあります。これは、ROKS および HyperShift が管理するサーバーからの API サーバーメトリックを公開しないためです。以下の Grafana ダッシュボードには、Kubernetes/API server、Kubernetes/Compute Resources/Workload、Kubernetes/Compute Resources/Namespace(Workload) の ROKS クラスターおよび HyperShift クラスターをサポートしないパネルが含まれます。

ROKS クラスターおよび HyperShift クラスターの場合、Red Hat Advanced Cluster Management の可観測性は、ダッシュボードの etcd パネルにデータを表示しません。

1000 のクラスターを管理するハブクラスターで検索を無効にすると、メモリー不足 (OOM) が原因で search-collector Pod がクラッシュします。以下の手順を実行します。

まれに、検索 Pod は証明書の変更後に自動的に再デプロイされない場合があります。これにより、サービス Pod 全体で証明書が一致しなくなるため、転送レイヤーセキュリティー (TLS) ハンドシェイクが失敗します。この問題を修正するには、検索 Pod を再起動して証明書をリセットします。

デフォルトでは、OpenShift の Prometheus は一時ストレージを使用します。Prometheus は、再起動されるたびにすべてのメトリクスデータを失います。

Red Hat Advanced Cluster Management が管理する OpenShift Container Platform マネージドクラスターで可観測性を有効または無効にすると、可観測性エンドポイント Operator は、ローカルの Prometheus を自動的に再起動する alertmanager 設定を追加して cluster-monitoring-config ConfigMap を更新します。

Observability receive Pod では、以下のエラーをレポートします。

Error on ingesting out-of-order samples

このエラーメッセージは、マネージドクラスターがメトリック収集間隔中に送信した時系列データが、以前の収集間隔中に送信した時系列データよりも古いことを意味します。この問題が発生した場合には、データは Thanos レシーバーによって破棄され、Grafana ダッシュボードに表示されるデータにギャップが生じる場合があります。エラーが頻繁に発生する場合は、メトリクスコレクションの間隔をより大きい値に増やすことが推奨されます。たとえば、間隔を 60 秒に増やすことができます。

この問題は、時系列の間隔が 30 秒などの低い値に設定されている場合にのみ見られます。メトリクス収集の間隔がデフォルト値の 300 秒に設定されている場合には、この問題は発生しません。

マニフェストのサイズが 50,000 バイトを超えると、Grafana インスタンスはマネージドクラスターにデプロイされません。可観測性をデプロイした後、local-cluster のみが Grafana に表示されます。

ベアメタルプロバイダーと切断されたインストールを使用してクラスターを作成する場合、切断されたインストールの設定 セクションの資格情報にすべての設定を保存する必要があります。クラスター作成コンソールエディターでそれらを入力することはできません。

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

ベアメタル、VMware vSphere、または Red Hat OpenStack Platform プロバイダーの資格情報を作成する場合、インストーラーは証明書を区別しないため、切断されたインストールのプロキシーと設定の追加の信頼バンドルフィールドには同じ値が含まれていることに注意してください。これらの機能を個別に使用することもできます。また、プロキシーインストールと非接続インストールで異なる証明書が必要な場合は、フィールドに複数の証明書を入力できます。

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

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

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

sushy-tools を使用してベアメタルにマネージドクラスターをプロビジョニングすると、virtual media cd query return 500 エラーでプロビジョニングに失敗する場合があります。sushy-tools の使用は、長時間稼働するクラスターでの信頼性を保証するものではありません。

sushy-tools が最新バージョンであることを確認して、sushy エミュレーターを再起動して問題を回避します。

OpenShift Container Platform バージョン 4.10 を実行しているデュアルスタックハブでベアメタルクラスターをプロビジョニングすると、プロビジョニングが失敗し、ノードの検査中に 'timeout reached during the node' というエラーメッセージが表示されます。この問題を回避するには、以下の例にあるように、install-config.yaml ファイルでプロビジョニングネットワークを無効にします。

platform:
  baremetal:
    provisioningNetwork: "Disabled"

プロビジョニングネットワークの詳細は、OpenShift Container Platform ドキュメントの プロビジョニングネットワークなしでのデプロイ を参照してください。

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

ClusterPool に対して Hive ClusterClaim を作成し、ClusterClaimspec の有効期限のフィールドを無効な golang タイム値に手動で設定すると、Red Hat Advanced Cluster Management は不正な要求だけでなく、すべての 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 によって再作成されます。ローカルクラスターをデタッチした後、ローカルクラスターが自動的に再作成されない場合があります。

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

Google Cloud Platform(GCP) でのクラスターのプロビジョニングを試みると、以下のエラーが発生して失敗する可能性があります。

Cluster initialization failed because one or more operators are not functioning properly.
The cluster should be accessible for troubleshooting as detailed in the documentation linked below,
https://docs.openshift.com/container-platform/latest/support/troubleshooting/troubleshooting-installations.html
The 'wait-for install-complete' subcommand can then be used to continue the installation

GCP プロジェクトで ネットワークセキュリティー API を有効にして、このエラーを回避することができます。これにより、クラスターのインストールを継続できます。

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

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

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

Azure Government クラスターを休止状態にしようとすると、以下のエラーがプロビジョニング Pod ログに追加されてハイバネートに失敗します。

Confidential Client is not supported in Cross Cloud request

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

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

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

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

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

Red Hat Advanced Cluster Management をバージョン 2.3 にアップグレードすると、アップグレード前に Red Hat Advanced Cluster Management で作成して管理されていたマネージドクラスターの認証情報シークレットが変更できなくなります。

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

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

クラウドプロバイダーのアクセスキーを変更しても、プロビジョニングされたクラスターのアクセスキーは、namespace で更新されません。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。このような場合は、以下のコマンドを実行して、クラウドプロバイダーでアクセスキーを更新します。

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

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

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

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

Ansible Automation Platform Resource Operator では ppc64le イメージまたは s390x イメージが提供されないので、IBM Power または IBM Z システムで Red Hat Advanced Cluster Management for Kubernetes ハブクラスターが実行されている場合には、Ansible Tower 統合を使用できません。

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

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

バージョン 2.4.x から 2.5.0 にアップグレードした後、cluster-proxy-addon が起動せず、cluster-proxy-addon-manager が nil ポインター例外を発生させます。

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

subscription-admin ロールの ObjectBucket チャネルタイプで許可リストと拒否リストを指定することはできません。他の種類のチャネルでは、サブスクリプションの許可リストと拒否リストによって、デプロイできる Kubernetes リソースとデプロイできない Kubernetes リソースが示されます。

Infrastructure.config.openshift.io API は 3.x では使用できないため、コンソールから Argo ApplicationSet を 3.x OpenShift Container Platform 管理対象クラスターにデプロイすることはできません。

マネージドクラスターで実行している application-manager アドオンは、以前は klusterlet Operator により処理されていましたが、サブスクリプション Operator により処理されるようになりました。サブスクリプション Operator は multicluster-hub で管理されていないため、multicluster-hub イメージマニフェスト ConfigMap の multicluster_operators_subscription イメージへの変更は自動的に有効になりません。

サブスクリプション Operator が使用するイメージが、multicluster-hub イメージマニフェスト ConfigMap の multicluster_operators_subscription イメージを変更することによってオーバーライドされた場合、マネージドクラスターの application-manager アドオンは、サブスクリプション Operator Pod が再起動するまで新しいイメージを使用しません。。Pod を再起動する必要があります。

同じ名前の ApplicationSet が異なる Gitops インスタンスに作成されると、アプリケーショントポロジーは誤ったアプリケーションを表示します。複数の Gitops インスタンスがインストールされている場合に、各 Gitops インスタンスに同じ名前の ApplicationSets が設定され、ApplicationSets のトポロジーが正しく表示されません。これは、作成される ApplicationSets の namespace をトポロジーで区別していないことが原因です。

各 Gitops インスタンスに異なる名前で ApplicationSet を作成し、トポロジーを正しく表示できるようにします。

Red Hat Advanced Cluster Management バージョン 2.4 では、デフォルトで policy.open-cluster-management.io/v1 リソースがアプリケーションサブスクリプションによってデプロイされなくなりました。

サブスクリプション管理者は、このデフォルトの動作を変更するためにアプリケーションサブスクリプションをデプロイする必要があります。

詳細は、サブスクリプション管理者としての許可リストおよび拒否リストの作成 を参照してください。以前の Red Hat Advanced Cluster Management バージョンの既存のアプリケーションサブスクリプションによってデプロイされた policy.open-cluster-management.io/v1 リソースは、サブスクリプション管理者がアプリケーションサブスクリプションをデプロイしていない限り、ソースリポジトリーに合わせて調整されません。

Ansible フックのスタンドアロンモードはサポートされていません。サブスクリプションを使用してハブクラスターに Ansible フックをデプロイするには、次のサブスクリプション YAML を使用できます。

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true

ただし、spec.placement.local:true ではサブスクリプションが standalone モードで実行されているため、この設定では Ansible インストールが作成されない可能性があります。ハブモードでサブスクリプションを作成する必要があります。

両方を適用すると、ハブクラスターに作成された Ansible インスタンスが表示されます。

Editor ロールで実行するユーザーは、アプリケーションで read または update の権限のみが割り当てられているはずにもかかわらず、誤ってアプリケーションの create および delete の操作ができてしまいます。OpenShift Container Platform Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

Editor ロールで実行するユーザーは、配置ルールで read または update の権限のみが割り当てられているはずにもかかわらず、誤って create および delete の操作もできてしまいます。OpenShift Container Platform Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

配置ルールの更新後にアプリケーションがデプロイされない場合には、klusterlet-addon-appmgr Pod が実行されていることを確認します。サブスクリプションコンテナーである klusterlet-addon-appmgr は、エンドポイントクラスターで実行する必要があります。

oc get pods -n open-cluster-management-agent-addon を実行して確認します。

また、コンソールで kind:pod cluster:yourcluster を検索し、klusterlet-addon-appmgr が実行中であることを確認できます。

検証できない場合は、もう一度、クラスターのインポートを試行して検証を行います。

Red Hat OpenShift Container Platform SCC の詳細は、Security Context Constraints (SCC) の管理 を参照してください。これは、マネージドクラスターで必要な追加設定です。

デプロイメントごとにセキュリティーコンテキストとサービスアカウントが異なります。サブスクリプション Operator は SCC を自動的に作成できず、管理者が Pod のパーミッションを制御します。Security Context Constraints (SCC) CR は、関連のあるサービスアカウントに適切なパーミッションを有効化して、デフォルトではない namespace で Pod を作成する必要があります。

使用している namespace で SCC CR を手動で作成するには、以下を実行します。

同じ namespace に複数のチャネルを作成すると、ハブクラスターでエラーが発生する可能性があります。

たとえば、namespace charts-v1 は、Helm タイプのチャネルとしてインストーラーで使用するので、charts-v1 に追加のチャネルを作成します。一意の namespace でチャネルを作成するようにしてください。すべてのチャネルには個別の namespace が必要ですが、GitHub チャネルは例外で、別 GitHub のチャネルと namespace を共有できます。

互換性のないオプションを選択すると、Ansible ジョブの実行に失敗します。Ansible Automation Platform は、-cluster-scoped のチャネルオプションが選択されている場合にのみ機能します。これは、Ansible ジョブを実行する必要があるすべてのコンポーネントに影響します。

Ansible Automation Platform(AAP)Operator は、プロキシー対応の OpenShift Container Platform クラスター外の Ansible Tower にアクセスできません。解決するには、Ansible tower をプロキシー内にインストールします。Ansible Tower が提供するインストール手順を参照してください。

Helm Argo アプリケーションを作成して編集すると、YAML ファイルが正しい間、テンプレート情報は空で表示されます。エラーを修正するには、エラータ 2.4.1 にアップグレードしてください。

アプリケーション名は 37 文字を超えることができません。この数を超えた場合、アプリケーションのデプロイメント時に以下のエラーが表示されます。

status:
  phase: PropagationFailed
  reason: 'Deployable.apps.open-cluster-management.io "_long_lengthy_name_" is invalid: metadata.labels: Invalid value: "_long_lengthy_name_": must be no more than 63 characters/n'

コンソールのさまざまな アプリケーション の表に対する以下の制限を確認してください。

2.5 では Application の Console と Topology が変更されています。コンソールの Topology ページにフィルターリング機能はありません。

ApplicationSet YAML で定義された namespace とは異なる namespace にリソースをデプロイする ApplicationSet アプリケーションを作成すると、リソースのステータスがトポロジーに表示されません。

allow リストおよび deny リストの機能は、オブジェクトストレージアプリケーションのサブスクリプションでは機能しません。

以前に作成した ApplicationSet と同じ URL とブランチで新しい ApplicationSet を作成すると、ApplicationSet ウィザードはパスを自動的にフェッチしません。

この問題を回避するには、Path フィールドにパスを手動で入力します。

外部アイデンティティープロバイダーを使用して Red Hat Advanced Cluster Management にログインする場合は、Red Hat Advanced Cluster Management からログアウトできない可能性があります。これは、Red Hat Advanced Cluster Management に IBM Cloud および Keycloak をアイデンティティープロバイダーとしてインストールして使用する場合に発生します。

Red Hat Advanced Cluster Management からログアウトするには、外部アイデンティティープロバイダーからログアウトしておく必要があります。

Red Hat OpenShift Container Platform バージョン 4.9 に gatekeeper Operator をインストールする場合、インストールに失敗します。OpenShift Container Platform をバージョン 4.9.0. にアップグレードする前に、gatekeeper Operator をバージョン 0.2.0 にアップグレードする必要があります。詳細は、gatekeeper および gatekeeper Operator のアップグレード を参照してください。

設定ポリシーで complianceType のパラメーターに mustnothave、remediationAction のパラメーターに enforce が設定されている場合に、ポリシーは Kubernetes API に削除要求が送信されてから、準拠と表示されます。そのため、ポリシーが準拠と表示されているにも関わらず、Kubernetes オブジェクトは、Terminating の状態のままになってしまう可能性があります。

ARM 環境へのインストールはサポートされますが、ポリシーを使用してデプロイされる Operator は ARM 環境をサポートしない可能性があります。Operator をインストールする以下のポリシーは ARM 環境をサポートしません。

設定ポリシーのポリシーテンプレートを編集すると、次の問題が発生する場合があります。

ハブクラスターのバックアップおよび復元機能には、Data Protection (OADP) Operator の OpenShift API が必要です。OADP Operator は、IBM Power または IBM Z アーキテクチャーでは使用できません。

ハブクラスターは passive から primary クラスターに戻されると、異なるクラスターが同じストレージの場所にあるデータをバックアップできます。これにより、バックアップの競合が発生します。つまり、最新のバックアップが passive ハブクラスターによって生成されたことを意味します。

BackupSchedule.cluster.open-cluster-management.io リソースがハブクラスターで有効になっているため、passive ハブクラスターはバックアップを生成しますが、このハブクラスターは primary ハブクラスターでなくなったため、バックアップデータは書き込みできるべきではありません。以下のコマンドを実行して、バックアップの競合があるかどうかを確認します。

oc get backupschedule -A

以下のステータスが返される場合があります。

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.

BackupSchedule.cluster.open-cluster-management.io リソースの status を BackupCollision に設定して、バックアップの競合を回避します。BackupSchedule リソースによって作成される Schedule.velero.io リソースは自動的に削除されます。

バックアップの競合は、hub-backup-pod ポリシーにより報告されます。管理者は、どのハブクラスターが対象のストレージの場所にデータを書き込んでいるかを確認する必要があります。次に、passive ハブクラスターから BackupSchedule.cluster.open-cluster-management.io リソースを削除し、primary ハブクラスターに新しい BackupSchedule.cluster.open-cluster-management.io リソースを再作成して、バックアップを再開します。

詳細は、クラスターのバックアップおよび復元オペレーター を参照してください。

以下の復元の制限を確認してください。

前述の制限に対応するために、restore.cluster.open-cluster-management.io リソースが作成されると、クラスターのバックアップおよび復元 Operator は、Velero 復元の開始前にハブクラスターを削除して復元の準備を行う一連の手順を実行します。詳細は、復元前にハブクラスターのクリーニング を参照してください。

プライマリーハブクラスターに手動でインポートされたマネージドクラスターは、パッシブハブクラスターでアクティベーションデータが復元された場合にのみ表示されます。

enableClusterBackup パラメーターを true に設定してクラスターを 2.4 から 2.5 にアップグレードすると、次のメッセージが表示されます。

When upgrading from version 2.4 to 2.5, cluster backup must be disabled

クラスターをアップグレードする前に、enableClusterBackup パラメーターを false に設定して、クラスターのバックアップおよび復元を無効にします。MultiClusterHub リソースの components セクションは、次の YAML ファイルのようになります。

アップグレードが完了したら、バックアップおよび復元のコンポーネントを再度有効にすることができます。以下のサンプルを参照してください。

overrides:
      components:
        - enabled: true
          name: multiclusterhub-repo
        - enabled: true
          name: search
        - enabled: true
          name: management-ingress
        - enabled: true
          name: console
        - enabled: true
          name: insights
        - enabled: true
          name: grc
        - enabled: true
          name: cluster-lifecycle
        - enabled: true
          name: volsync
        - enabled: true
          name: multicluster-engine
        - enabled: false
          name: cluster-proxy-addon
        - enabled: true <<<<<<<<
          name: cluster-backup
    separateCertificateManagement: false

OADP を手動でインストールした場合は、アップグレードする前に OADP を手動でアンインストールする必要があります。アップグレードが成功し、バックアップおよび復元が再度有効になると、OADP が自動的にインストールされます。

local-cluster 管理対象クラスター リソースの設定を復元し、新しいハブクラスターで local-cluster データを上書きすると、設定が正しく設定されません。リソースにはクラスター URL の詳細など、local-cluster 固有の情報が含まれているため、以前のハブクラスター local-cluster のコンテンツはバックアップされません。

復元されたクラスターの local-cluster リソースに関連するすべての設定変更を手動で適用する必要があります。詳細については、新しいハブクラスターの準備 を参照してください。

prepareForBackup 関数で定義されたラベルは、スケジュールの作成後に作成されたリソースには追加されません。これは、バックアップが開始する前にラベル付けされている Red Hat OpenShift シークレットの Hive および Infrastructure Operator に影響します。

影響を受けるリソースのリストを表示します。

BackupSchedule、veleroSchedule、または veleroTTL の値を更新して、新しい一連のスケジュールを開始します。次に、結果のバックアップを復元に使用します。これは、バックアップの最新のリソースにラベルを付けるように定義されています。

Hive マネージドクラスターの変更またはローテーションされた認証局 (CA) のバックアップを新しいハブクラスターで復元すると、マネージドクラスターは新しいハブクラスターへの接続に失敗します。このマネージドクラスターの admin kubeconfig シークレット (バックアップで使用可能) が無効になっているため、接続は失敗します。

新しいハブクラスター上のマネージドクラスターの復元された admin kubeconfig シークレットを手動で更新する必要があります。

OpenShiftSDN のみが CNI ネットワークプロバイダーとしてサポートされています。OVN は現在サポートされていません。

カーネルバージョンが 4.18.0-359.el8.x86_64 から 4.18.0-372.11.1.el8_6.x86_64 の Red Hat Enterprise Linux ワーカー ノードを含むクラスターに Submariner をデプロイすると、アプリケーションワークロードがリモートクラスターとの通信に失敗します。

Submariner は、Red Hat Advanced Cluster Management が管理できるすべてのインフラストラクチャープロバイダーでサポートされているわけではありません。サポートされているプロバイダーの一覧は、Red Hat Advanced Cluster Management のサポートマトリックス を参照してください。

Red Hat OpenStack クラスターの自動クラウド準備は、product-title-short} コンソールの Submariner ではサポートされていません。Red Hat Advanced Cluster Management API を使用して、クラウドを手動で準備できます。

Submariner は、Globalnet でヘッドレスサービスをサポートします。ただし、clusterset.local ドメイン名を使用して、同じクラスター内に存在するクライアントからエクスポートされたヘッドレスサービスにアクセスすると、ヘッドレスサービスに関連付けられている globalIP がクライアントに返され、クラスター内でルーティングできません。

cluster.local ドメイン名を使用して、ローカルのヘッドレスサービスにアクセスできます。

Submariner は、エアギャップ環境でプロビジョニングされたクラスターに対して検証されていません。

複数のゲートウェイを展開することはできません。

VXLAN ケーブルドライバーを使用する Submariner は、現在、非 NAT 展開でのみサポートされています。

Globalnet は、Red Hat OpenShift Data Foundation ディザスターリカバリーソリューションではサポートされていません。局地的なディザスターリカバリーシナリオでは、各クラスター内のクラスターとサービスネットワークに重複しない範囲のプライベート IP アドレスを使用するようにしてください。

GDPR は、各自の個人データを処理するにあたり、強力なデータ保護規制フレームワークを確立します。GDPR は以下を提供します。

Red Hat Advanced Cluster Management for Kubernetes は、プラットフォームとして複数のカテゴリーの技術データを扱いますが、その中には管理者ユーザー ID とパスワード、サービスユーザー ID とパスワード、Kubernetes ノード名など、個人データとみなされる可能性があるものも含まれます。また、Red Hat Advanced Cluster Management for Kubernetes プラットフォームは、プラットフォームの管理ユーザーに関する情報も扱います。プラットフォームで実行されるアプリケーションにより、プラットフォームではまだ知られていない、他のカテゴリーの個人データが取り込まれる可能性があります。

このような技術データの収集/作成、保存、アクセス、セキュリティー設定、ロギング、削除の方法に関する情報は、本書で後述します。

お客様は、以下のような情報をさまざまな方法でオンラインからコメント/フィードバック/依頼を送信できます。

通常は、連絡先フォームの件名への個人返信を有効にすると、お客様名とメールアドレスのみが使用され、個人データを使用する場合は Red Hat オンラインプライバシーステートメント に準拠します。

Red Hat Advanced Cluster Management for Kubernetes プラットフォームの認証マネージャーは、コンソールからのユーザーの認証情報を受け入れ、バックエンドの OIDC プロバイダーに認証情報を転送し、OIDC プロバイダーはエンタープライズディレクトリーに対してユーザーの認証情報を検証します。次に OIDC プロバイダーは認証クッキー (auth-cookie) を、JSON Web Token (JWT) のコンテンツと合わせて、認証マネージャーに返します。JWT トークンは、認証要求時にグループのメンバーシップに加え、ユーザー ID やメールアドレスなどの情報を永続化します。この認証クッキーはその後コンソールに返されます。クッキーはセッション時に更新されます。クッキーは、コンソールをサインアウトしてから、または Web ブラウザーを閉じてから 12 時間有効です。

コンソールから次回認証要求を送信すると、フロントエンドの NGIX サーバーが、要求で利用可能な認証クッキーをデコードし、認証マネージャーを呼び出して要求を検証します。

Red Hat Advanced Cluster Management for Kubernetes プラットフォーム CLI では、ユーザーはログインに認証情報が必要です。

kubectl と oc CLI でも、クラスターへのアクセスに認証情報が必要です。このような認証情報は、管理コンソールから取得でき、12 時間後に有効期限が切れます。サービスアカウント経由のアクセスは、サポートされています。

Red Hat Advanced Cluster Management for Kubernetes プラットフォームは、ロールベースのアクセス制御 (RBAC) をサポートします。ロールマッピングのステージでは、認証ステージで提示されたユーザー名がユーザーまたはグループロールにマッピングされます。認可時にロールを使用して、認証ユーザーがどのような管理者アクティビティーを実行できるか判断します。

Red Hat Advanced Cluster Management for Kubernetes プラットフォームのロールを使用して、クラスター設定アクション、カタログや Helm リソース、Kubernetes リソースへのアクセスを制御します。クラスター管理者、管理者、Operator、エディター、ビューワーなど、IAM (Identity and Access Management) ロールが複数含まれています。ロールは、チームへの追加時に、ユーザーまたはユーザーグループに割り当てられます。リソースへのチームアクセスは、namespace で制御できます。

Pod のセキュリティーポリシーを使用して、Pod での操作またはアクセス権をクラスターレベルで制御できるように設定します。