リリースノート

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

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

Red Hat Advanced Cluster Management バージョン 2.7 にアップグレードすると、apps.open-cluster-management.io グループ内のリソースに対するユーザー権限が利用できなくなります。Red Hat Advanced Cluster Management バージョン 2.7 以降、これらのカスタムリソース定義が OLM によってデプロイされなくなり、以下の変更が行われました。

RBAC ユーザーがこれらのリソースにアクセスする必要がある場合は、適切な権限を付与する必要があります。

2.4.x から 2.5.x にアップグレードしてから 2.6.x にアップグレードした後、マネージドクラスターの namespace に非推奨のリソースが残る場合があります。バージョン 2.6.x が 2.4.x からアップグレードされた場合、これらの非推奨のリソースを手動で削除する必要があります。

注記: バージョン 2.5.x からバージョン 2.6.x にアップグレードする前に、30 分以上待つ必要があります。

コンソールから削除するか、削除するリソースに対して次の例のようなコマンドを実行できます。

oc delete -n <managed cluster namespace> managedclusteraddons.addon.open-cluster-management.io <resource-name>

oc delete -n <managed cluster namespace> managedclusteraddons.addon.open-cluster-management.io <resource-name>

残っている可能性のある非推奨のリソースのリストを参照してください。

managedclusteraddons.addon.open-cluster-management.io:
policy-controller
manifestworks.work.open-cluster-management.io:
-klusterlet-addon-appmgr
-klusterlet-addon-certpolicyctrl
-klusterlet-addon-crds
-klusterlet-addon-iampolicyctrl
-klusterlet-addon-operator
-klusterlet-addon-policyctrl
-klusterlet-addon-workmgr

managedclusteraddons.addon.open-cluster-management.io:
policy-controller
manifestworks.work.open-cluster-management.io:
-klusterlet-addon-appmgr
-klusterlet-addon-certpolicyctrl
-klusterlet-addon-crds
-klusterlet-addon-iampolicyctrl
-klusterlet-addon-operator
-klusterlet-addon-policyctrl
-klusterlet-addon-workmgr

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

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

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

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 タイルで インスタンスの作成 を選択します。

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

以前のバージョンの Firefox のダークテーマスタイルには、既知の問題があります。コンソールの互換性を最適化するため、最新版にアップグレードしてください。

詳しくは、サポートされているブラウザー を参照してください。

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

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

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

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

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

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

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

admin または bind ロールを使用してクラスターセットの 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 にバインドすることしかできません。

Hosted Control Plane クラスターをプロビジョニングした後、ClusterVersionUpgradeable パラメーターが長すぎると、Red Hat Advanced Cluster Management コンソールのクラスター概要を水平方向にスクロールできない場合があります。結果として、非表示のデータを表示することはできません。

この問題を回避するには、ブラウザーのズームコントロールを使用してズームアウトするか、Red Hat Advanced Cluster Management コンソールウィンドウのサイズを大きくするか、テキストをコピーして別の場所に貼り付けます。

Ansible Automation Platform Operator に依存する統合を使用していて、Red Hat OpenShift Container Platform クラスターにインストールされている Operator を表示する権限がない場合は、次のようなエラーメッセージが表示される場合があります。

The Ansible Automation Platform Operator is required to use automation templates.Version 2.2.1 or greater is required to use workflow job templates in automation templates.

Operator がインストールされていることをシステム管理者に確認した場合は、エラーメッセージを無視しても問題ありません。

さまざまなハブクラスターが同じ 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 クラスターのデータが表示されないパネルがあります。これは、ROKS が、管理対象サーバーからの API サーバーメトリクスを公開しないためです。以下の Grafana ダッシュボードには、Kubernetes/API server、Kubernetes/Compute Resources/Workload、Kubernetes/Compute Resources/Namespace(Workload) の ROKS クラスターをサポートしないパネルが含まれます。

ROKS クラスターの場合に、Red Hat Advanced Cluster Management の可観測性のダッシュボードの etcd パネルでデータが表示されません。

デフォルトでは、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

Error on ingesting out-of-order samples

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

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

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

2.6 より前の以前のバージョンでデプロイされた grafana-dev インスタンスがあり、環境を 2.6 にアップグレードすると、grafana-dev は機能しません。次のコマンドを実行して、既存の grafana-dev インスタンスを削除する必要があります。

./setup-grafana-dev.sh --clean

./setup-grafana-dev.sh --clean

次のコマンドでインスタンスを再作成します。

./setup-grafana-dev.sh --deploy

./setup-grafana-dev.sh --deploy

メモリー制限に達したため、klusterlet-addon-search Pod が失敗します。マネージドクラスターで klusterlet-addon-search デプロイメントをカスタマイズして、メモリーの失われると制限を更新する必要があります。ハブクラスターで、search-collector という名前の ManagedclusterAddon カスタムリソースを編集します。search-collector に以下のアノテーションを追加し、メモリー addon.open-cluster-management.io/search_memory_request=512Mi および addon.open-cluster-management.io/search_memory_limit=1024Mi を更新します。

たとえば、foobar という名前のマネージドクラスターがある場合、次のコマンドを実行して、メモリーリクエストを 512Mi に変更し、メモリー制限を 1024Mi に変更します。

oc annotate managedclusteraddon search-collector -n foobar \
addon.open-cluster-management.io/search_memory_request=512Mi \
addon.open-cluster-management.io/search_memory_limit=1024Mi

oc annotate managedclusteraddon search-collector -n foobar \
addon.open-cluster-management.io/search_memory_request=512Mi \
addon.open-cluster-management.io/search_memory_limit=1024Mi

mulitclusterengine カスタムリソースで disableHubSelfManagement パラメーターが true に設定されている場合、Grafana ダッシュボードには空のラベルリストが表示されます。ラベルリストを表示するには、パラメーターを false に設定するか、パラメーターを削除する必要があります。詳細は、disableHubSelfManagement を参照してください。

endpoint パラメーターに FQDN またはプロトコルを使用すると、可観測性 Pod は有効になりません。次のエラーメッセージが表示されます。

Endpoint url cannot have fully qualified paths

Endpoint url cannot have fully qualified paths

プロトコルなしで URL を入力します。endpoint 値は、シークレットの次の URL に似ている必要があります。

endpoint: example.com:443

endpoint: example.com:443

履歴データをクエリーしようとしたときに、計算されたステップ値とダウンサンプリングされたデータの間に不一致がある場合、結果は空になります。たとえば、計算されたステップ値が 5m で、ダウンサンプリングされたデータが 1 時間間隔の場合、データは Grafana から表示されません。

この不一致は、URL クエリーパラメーターが Thanos Query フロントエンドデータソースを介して渡される必要があるために発生します。その後、データが欠落している場合、URL クエリーは他のダウンサンプリングレベルに対して追加のクエリーを実行できます。

Thanos Query フロントエンドデータソース設定を手動で更新する必要があります。以下の手順を実行します。

Grafana ダッシュボードからクエリーデータが表示されます。

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

アプリケーションが blocked 状態にある場合、サブスクリプションにはクラスターがオフラインであると表示されますが、クラスターは healthy および ready 状態にあります。

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 を再起動する必要があります。

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

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 のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

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

oc get pods -n open-cluster-management-agent-addon |grep application-manager を実行して確認できます。

コンソールで kind:pod cluster:yourcluster を検索して、application-manager が実行されているかどうかを確認することもできます。

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

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

デプロイメントごとにセキュリティーコンテキストとサービスアカウントが異なります。サブスクリプション Operator は SCC CR を自動的に作成できず、管理者が 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 ジョブを実行する必要があるすべてのコンポーネントに影響します。

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

アプリケーション名は 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'

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.7 では Application の Console と Topology が変更されています。コンソールの Topology ページにフィルタリング機能はありません。

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

外部アイデンティティープロバイダーを使用して 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 環境をサポートしません。

KlusterletAddonConfig でポリシーコントローラーを無効にするか、クラスターをデタッチして、管理対象クラスターから config-policy-controller アドオンを削除すると、ConfigurationPolicy CRD が中断状態でスタックする場合があります。ConfigurationPolicy CRD が中断状態でスタックしている場合に、アドオンを後で再インストールしても、新しいポリシーがクラスターに追加されない可能性があります。次のエラーが表示されることもあります。

template-error; Failed to create policy template: create not allowed while custom resource definition is terminating

template-error; Failed to create policy template: create not allowed while custom resource definition is terminating

次のコマンドを使用して、CRD がスタックしているかどうかを確認します。

oc get crd configurationpolicies.policy.open-cluster-management.io -o=jsonpath='{.metadata.deletionTimestamp}'

oc get crd configurationpolicies.policy.open-cluster-management.io -o=jsonpath='{.metadata.deletionTimestamp}'

削除のタイムスタンプがリソースにある場合に、CRD はスタックします。この問題を解決するには、クラスターに残っている設定ポリシーからすべてのファイナライザーを削除します。マネージドクラスターで次のコマンドを使用し、<cluster-namespace> をマネージドクラスターの namespace に置き換えます。

oc get configurationpolicy -n <cluster-namespace> -o name | xargs oc patch -n <cluster-namespace> --type=merge -p '{"metadata":{"finalizers": []}}'

oc get configurationpolicy -n <cluster-namespace> -o name | xargs oc patch -n <cluster-namespace> --type=merge -p '{"metadata":{"finalizers": []}}'

設定ポリシーリソースはクラスターから自動的に削除され、CRD は中断状態を終了します。アドオンがすでに再インストールされている場合には、CRD は削除タイムスタンプなしで自動的に再作成されます。

ポリシーが remediationAction: enforce に設定されていて、繰り返し更新されている場合、Red Hat Advanced Cluster Management コンソールには、更新が成功しても繰り返し違反が表示されます。これは、次の 2 つの場合に発生する可能性があります。

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

これを解決するには、ポリシーを無効にしてから再度有効にします。ポリシー全体を削除することもできます。

Pod セキュリティーポリシーのサポートは、OpenShift Container Platform 4.12 以降、および Kubernetes v1.25 以降から削除されました。PodSecurityPolicy リソースを適用すると、次の非準拠メッセージを受け取る場合があります。

violation - couldn't find mapping resource with kind PodSecurityPolicy, please check if you have CRD deployed

violation - couldn't find mapping resource with kind PodSecurityPolicy, please check if you have CRD deployed

Red Hat Advanced Cluster Management のバックアップおよび復元コンポーネントを有効にし、DataProtectionApplication リソースを正常に作成すると、BackupStorageLocation リソースが Available のステータスで作成されます。OADP バージョン 1.1.2 以降を使用している場合、BackupSchedule リソースを作成すると、次のメッセージが表示されてステータスが FailedValidation になることがあります。

oc get backupschedule -n open-cluster-management-backup
NAME PHASE MESSAGE
rosa-backup-schedule FailedValidation Backup storage location is not available. Check velero.io.BackupStorageLocation and validate storage credentials.

oc get backupschedule -n open-cluster-management-backup
NAME PHASE MESSAGE
rosa-backup-schedule FailedValidation Backup storage location is not available. Check velero.io.BackupStorageLocation and validate storage credentials.

このエラーは、BackupStorageLocation リソースの ownerReference の値がないために発生します。DataProtectionApplication リソースの値は、ownerReference の値として使用する必要があります。

この問題を回避するには、ownerReference を BackupStorageLocation に手動で追加します。

データが復元される新しいハブクラスターにユーザーが作成したリソースがある場合、新しいハブクラスターはアクティブなハブクラスターとは異なる設定を持つことができます。たとえば、バックアップデータが新しいハブクラスターで復元される前に、新しいハブクラスターで作成された既存のポリシーを含めることができます。

既存のリソースが復元されたバックアップの一部でない場合、Velero はそれらをスキップするため、新しいハブクラスターのポリシーは変更されず、新しいハブクラスターとアクティブなハブクラスターの間で異なる設定が生じます。

この制限に対処するために、クラスターのバックアップと復元のオペレーターは、restore.cluster.open-cluster-management.io リソースが作成されたときに、ユーザーが作成したリソースをクリーンアップする復元後の操作、または別の復元操作を実行します。

詳細については、バックアップおよび復元 Operator の管理 トピックの 復元前のハブクラスターのクリーニング を参照してください。

マネージドクラスターは、アクティブ化データがパッシブハブクラスターで復元された場合にのみ表示されます。

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

復元されたクラスターの local-cluster リソースに関連するすべての設定変更を手動で適用する必要があります。バックアップおよび復元 Operator の管理 トピックの 新しいハブクラスターの準備 を参照してください。

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

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

プライマリーハブクラスターに手動でインポートされたマネージドクラスターは、アクティブ化データがパッシブハブクラスターで復元されると、Pending Import のステータスを示します。詳細については、マネージドサービスアカウントを使用してクラスターを自動的に接続する を参照してください。

ハブクラスターデータが新しいハブクラスターで復元されるとき、appliedmanifestwork は固定クラスターセットではないアプリケーションサブスクリプションの配置規則を持つマネージドクラスターから削除されません。

固定クラスターセットではないアプリケーションサブスクリプションの配置ルールの例を次に示します。

spec:
  clusterReplicas: 1
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterReplicas: 1
  clusterSelector:
    matchLabels:
      environment: dev

その結果、マネージドクラスターが復元されたハブクラスターから切り離されると、アプリケーションは孤立します。

この問題を回避するには、配置ルールで固定クラスターセットを指定します。以下の例を参照してください。

spec:
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterSelector:
    matchLabels:
      environment: dev

次のコマンドを実行して、残りの appliedmanifestwork を手動で削除することもできます。

oc delete appliedmanifestwork <the-left-appliedmanifestwork-name>

oc delete appliedmanifestwork <the-left-appliedmanifestwork-name>

ハブクラスターデータが新しいハブクラスターで復元されるとき、appliedmanifestwork は固定クラスターセットではないアプリケーションサブスクリプションの配置規則を持つマネージドクラスターから削除されません。その結果、マネージドクラスターが復元されたハブクラスターから切り離されると、アプリケーションは孤立します。

固定クラスターセットではないアプリケーションサブスクリプションの配置ルールの例を次に示します。

spec:
  clusterReplicas: 1
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterReplicas: 1
  clusterSelector:
    matchLabels:
      environment: dev

この問題を回避するには、配置ルールで固定クラスターセットを指定します。以下の例を参照してください。

spec:
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterSelector:
    matchLabels:
      environment: dev

次のコマンドを実行して、残りの appliedmanifestwork を手動で削除できます。

oc delete appliedmanifestwork <the-left-appliedmanifestwork-name>

oc delete appliedmanifestwork <the-left-appliedmanifestwork-name>

Red Hat Advanced Cluster Management 2.6 をプライマリーハブクラスターとして使用しているが、リストアハブクラスターがバージョン 2.7 以降である場合、このフィールドは 2.7 リリースで導入されたため、appliedmanifestworks の仕様に agentID がありません。これにより、マネージドクラスターのプライマリーハブに追加の appliedmanifestworks が生成されます。

この問題を回避するには、プライマリーハブクラスターを Red Hat Advanced Cluster Management 2.7 にアップグレードしてから、新しいハブクラスターにバックアップを復元します。

appliedmanifestwork ごとに spec.agentID を手動で設定して、マネージドクラスターを修正します。

マネージドクラスター appliedmanifestwork addon-managed-serviceaccount-deploy は、新しいハブクラスターの Kubernetes Operator リソースのマルチクラスターエンジンで有効にせずに Managed Service Account を使用している場合は、インポートされたマネージドクラスターから削除されます。

マネージドクラスターは引き続き新しいハブクラスターにインポートされますが、managed-serviceaccount アドオンのステータスは Unknown と表示されます。

マルチクラスターエンジン Operator リソースで Managed Service Account を有効にした後、managed-serviceaccount アドオンを回復できます。Managed Service Account を有効にする方法は、自動インポートの有効化 を参照してください。

バージョン 2.8 以前の場合、Red Hat Advanced Cluster Management をインストールするときに、Operator Lifecycle Manager を使用して submariner-addon コンポーネントもデプロイします。MultiClusterHub カスタムリソースを作成しなかった場合、submariner-addon Pod はエラーを送信し、Operator はインストールできません。

ClusterManagementAddon カスタムリソース定義がないため、次の通知が発生します。

graceful termination failed, controllers failed with error: the server could not find the requested resource (post clustermanagementaddons.addon.open-cluster-management.io)

graceful termination failed, controllers failed with error: the server could not find the requested resource (post clustermanagementaddons.addon.open-cluster-management.io)

ClusterManagementAddon リソースは cluster-manager デプロイメントによって作成されますが、このデプロイメントが使用可能になるのは MultiClusterEngine コンポーネントがクラスターにインストールされてからです。

MultiClusterHub カスタムリソースの作成時にクラスター上ですでに使用可能な MultiClusterEngine リソースが存在しない場合、MultiClusterHub Operator は MultiClusterEngine インスタンスと必要な Operator をデプロイし、前のエラーを解決します。

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

Globalnet を使用する場合、セレクターを使用しないヘッドレスサービスのサービスディスカバリーはサポートされません。

NAT 以外のデプロイメントのみが VXLAN ケーブルドライバーを使用した Submariner デプロイメントをサポートします。

OVN Kubernetes CNI ネットワークを使用している場合は、Red Hat OpenShift 4.11 以降が必要です。

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

ブローカーの自己署名証明書により、結合されたクラスターがブローカーに接続できない場合があります。接続は証明書の検証エラーで失敗します。関連する SubmarinerConfig オブジェクトで InsecureBrokerConnection を true に設定すると、ブローカー証明書の検証を無効にできます。以下の例を参照してください。

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
   name: submariner
   namespace: <managed-cluster-namespace>
spec:
   insecureBrokerConnection: true

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
   name: submariner
   namespace: <managed-cluster-namespace>
spec:
   insecureBrokerConnection: true

Submariner は、OpenShift SDN または OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーを使用する Red Hat OpenShift Container Platform クラスターのみをサポートします。

subctl diagnose firewall inter-cluster コマンドは、Microsoft Azure クラスターでは機能しません。

Red Hat Advanced Cluster Management for Kubernetes がアップグレードされると、Submariner は自動的にアップグレードされます。カスタムの CatalogSource または Subscription を使用している場合、自動アップグレードは失敗する可能性があります。

マネージドクラスターに Submariner をインストールするときに自動アップグレードが確実に機能するようにするには、各マネージドクラスターの SubmarinerConfig カスタムリソースで spec.subscriptionConfig.channel フィールドを stable-0.14 に設定する必要があります。

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 時間有効です。

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

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 での操作またはアクセス権をクラスターレベルで制御できるように設定します。