リリースノート

OpenShift Container Platform から Red Hat Advanced Cluster Management をアンインストールすると、後で以前のバージョンをインストールしてアップグレードする場合に問題が発生する可能性があります。たとえば、Red Hat Advanced Cluster Management をアンインストールしてから以前のバージョンの Red Hat Advanced Cluster Management をインストールし、そのバージョンをアップグレードすると、アップグレードが失敗する可能性があります。カスタムリソースが削除されなかった場合、アップグレードは失敗します。

この問題を回避するには、再インストールする前にアーティファクトをクリーンアップする に記載された手順に従ってください。

ACM-22366

Image-Based Break/Fix を使用してクラスターを再インストールするときに spec.nodes.<node-id>.bmcAddress フィールドを変更すると、SiteConfig Operator は元のマシンに接続できず、元のクラスターからデータイメージリソースを削除できません。この問題を回避するには、Image-Based Break/Fix を使用してクラスターを再インストールする前に、データイメージリソースからファイナライザーを削除します。

ACM-22366

バックアップと復元の既知の問題と制限事項が、利用可能な場合は回避策とともにここにリストされます。

BareMetalHosts を使用して、ホストをホストインベントリーに自動的に追加できます。デフォルトでは、BareMetalHost は バックアップに含まれません。

BareMetalHost をバックアップに含めるには、cluster.open-cluster-management.io/backup: cluster-activation ラベルを BareMetalHosts に追加します。詳細は、マネージドクラスターのアクティブ化時に復元されたリソース を参照してください。

ACM-26582

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

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

spec:
  clusterSelector:
    matchLabels:
      environment: dev

spec:
  clusterSelector:
    matchLabels:
      environment: dev

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

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

メモリー制限に達したため、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

ACM-22366

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

ACM-22366

コンソールから OpenShift Dedicated クラスターのアップグレードをリクエストできますが、アップグレードは失敗し、Cannot upgrade non openshift cluster というエラーメッセージが表示されます。現在、回避策はありません。

ACM-22366

search-postgres Pod は CrashLoopBackoff 状態です。Red Hat Advanced Cluster Management が hugepages パラメーターが有効になっているノードを含むクラスターにデプロイされており、これらのノードで search-postgres Pod がスケジュールされている場合、Pod は起動しません。

search-postgres Pod のメモリーを増やすには、次の手順を実行します。

512Mi の値が表示されます。

ACM-22366

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 にバインドすることしかできません。

ACM-22366

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

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

ACM-22366

OpenShift Cloud Manager コンソールで cluster-ID にアクセスしなかった場合でも、ターミナルから Red Hat OpenShift Service on AWS cluster-ID の記述を取得できます。Red Hat OpenShift Service on AWS コマンドラインインターフェイスが必要です。Red Hat OpenShift Service on AWS CLI ドキュメントの開始方法 を参照してください。

cluster-ID を取得するには、Red Hat OpenShift Service on AWS から次のコマンドを実行します。

rosa describe cluster --cluster=<cluster-name> | grep -o ’^ID:.*

rosa describe cluster --cluster=<cluster-name> | grep -o ’^ID:.*

ACM-22366

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

ACM-22366

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

ACM-22366

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

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

ACM-22366

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

ACM-22366

Red Hat OpenShift Virtualization 4.20 を使用した Red Hat Advanced Cluster Management 2.15 Virtualization はサポートされていません。Red Hat Advanced Cluster Management 2.15 で Red Hat OpenShift Virtualization 4.20.1 以降を使用する必要があります。

OpenShift GitOps Operator をバージョン 1.17 にアップグレードすると、ApplicationSet リソースステータスで権限エラーが発生します。

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

ACM-22366

サブスクリプションアプリケーション (非推奨) をデプロイすると、Application Topology ページのサブスクリプションノードに警告メッセージが表示されます。サブスクリプションノードの詳細を確認すると、local-cluster がオフラインであると誤って表示されます。

local-cluster の実際のステータスを確認するには、コンソールナビゲーションから Infrastructure > Clusters をクリックします。

ACM-22366

ハブクラスターでアプリケーションリソースが更新されると、アプリケーションページのテーブルも更新されます。アプリケーションテーブルのメニューを開いている場合、アプリケーションページのテーブルが更新されるたびにメニューが閉じます。メニューが頻繁に閉じるため、メニューをクリックするのが難しい場合があります。

この問題を回避するには、アプリケーション名をクリックしてアプリケーションの詳細ページに移動します。詳細ページでも同じアクションメニューをクリックできます。更新のたびにメニューが閉じることはありません。

ACM-22366

Placement リソースで Exist または DoesNotExist Operator を使用すると、アプリケーショントポロジーノードの詳細に式が \#invalidExpr として表示されます。この表示は間違っていますが、式は引き続き有効であり、Placement リソースで機能します。この問題を回避するには、Placement リソース YAML 内の式を編集します。

ACM-22366

PlacementRule リソースを参照するサブスクリプションアプリケーションを作成した後、サブスクリプション YAML はコンソールの YAML エディターに表示されません。ターミナルを使用してサブスクリプション YAML ファイルを編集します。

ACM-22366

Helm Chart を使用すると、Kubernetes シークレットでプライバシーデータを定義し、Helm チャートの value.yaml ファイルでこのシークレットを参照できます。

ユーザー名とパスワードは、参照される Kubernetes シークレットリソース dbsecret によって指定されます。たとえば、以下の value.yaml ファイルの例を参照してください。

credentials:
  secretName: dbsecret
  usernameSecretKey: username
  passwordSecretKey: password

credentials:
  secretName: dbsecret
  usernameSecretKey: username
  passwordSecretKey: password

シークレットの依存関係を含む Helm チャートは、Helm バイナリー CLI でのみサポートされます。Operator SDK Helm ライブラリーではサポートされていません。Red Hat Advanced Cluster Management サブスクリプションコントローラーは、Operator SDK Helm ライブラリーを適用して、Helm チャートをインストールおよびアップグレードします。そのため、Red Hat Advanced Cluster Management サブスクリプションは、シークレットの依存関係が含まれる Helm チャートをデプロイできません。

ACM-22366

Argo CD プルモデルを使用して ApplicationSet アプリケーションをデプロイし、アプリケーションのリソース名がカスタマイズされている場合、リソース名がクラスターごとに異なって表示される場合があります。これが発生すると、トポロジーではアプリケーションが正しく表示されません。

ACM-22366

ハブクラスターアプリケーションセットはターゲットマネージドクラスターにデプロイされますが、マネージドハブクラスターであるローカルクラスターはターゲットマネージドクラスターとして除外されます。

その結果、Argo CD アプリケーションが Argo CD プルモデルによってローカルクラスターに伝播される場合に、ローカルクラスターが Argo CD ApplicationSet リソースの配置決定から削除されても、ローカルクラスターの Argo CD アプリケーションは削除されません。

問題を回避し、ローカルクラスターの Argo CD アプリケーションを削除するには、ローカルクラスターの Argo CD アプリケーションから skip-reconcile アノテーションを削除します。以下のアノテーションを参照してください。

annotations:
    argocd.argoproj.io/skip-reconcile: "true"

annotations:
    argocd.argoproj.io/skip-reconcile: "true"

さらに、Argo CD コンソールの Applications セクションでプルモデルの Argo CD アプリケーションを手動で更新すると、更新は処理されず、Argo CD コンソールの REFRESH ボタンが無効になります。

この問題を回避するには、Argo CD アプリケーションから refresh アノテーションを削除します。以下のアノテーションを参照してください。

annotations:
    argocd.argoproj.io/refresh: normal

annotations:
    argocd.argoproj.io/refresh: normal

ACM-22366

Argo CD コントローラーと伝播コントローラーの両方が同じアプリケーションリソース上で調整し、マネージドクラスター上で異なるデプロイメントモデルからのアプリケーションデプロイメントの重複インスタンスが発生する可能性があります。

Pull モデルを使用してアプリケーションをデプロイする場合、Argo CD argocd.argoproj.io/skip-reconcile アノテーションが ApplicationSet のテンプレートセクションに追加されると、Argo CD コントローラーはこれらのアプリケーションリソースを無視します。

argocd.argoproj.io/skip-reconcile アノテーションは、GitOps operator バージョン 1.9.0 以降でのみ使用できます。競合を防ぐには、プルモデルを実装する前に、ハブクラスターとすべてのマネージドクラスターが GitOps operator バージョン 1.9.0 にアップグレードされるまで待ってください。

MulticlusterApplicationSetReport にリストされているすべてのリソースは、実際にはマネージドクラスターにデプロイされます。リソースのデプロイに失敗した場合、そのリソースはリソースリストには含まれませんが、原因はエラーメッセージにリストされます。

1,000 を超えるマネージドクラスターと、数百のマネージドクラスターにデプロイされた Argo CD アプリケーションセットがある大規模環境の場合、ハブクラスターでの Argo CD アプリケーションの作成には数分かかる場合があります。次のファイル例に示されているように、アプリケーションセットの clusterDecisionResource ジェネレーターで requeueAfterSeconds を zero に設定できます。

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cm-allclusters-app-set
  namespace: openshift-gitops
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: ocm-placement-generator
      labelSelector:
        matchLabels:
          cluster.open-cluster-management.io/placement: app-placement
      requeueAfterSeconds: 0

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cm-allclusters-app-set
  namespace: openshift-gitops
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: ocm-placement-generator
      labelSelector:
        matchLabels:
          cluster.open-cluster-management.io/placement: app-placement
      requeueAfterSeconds: 0

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

ACM-22366

マネージドクラスターで実行している 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 リソースは、サブスクリプション管理者がアプリケーションサブスクリプションをデプロイしていない限り、ソースリポジトリーに合わせて調整されません。

ACM-22366

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 インスタンスが表示されます。

ACM-22366

配置ルールの更新後にアプリケーションがデプロイされない場合は、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 の管理 を参照してください。これは、マネージドクラスターで必要な追加設定です。

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

ACM-22366

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

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

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

ACM-22366

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

ACM-22366

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

ACM-22366

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

ACM-22366

2.15 では、アプリケーション の コンソール と トポロジー が変更されます。コンソールの Topology ページにフィルタリング機能はありません。

ACM-22366

同じ namespace 内に多数のロールバインディングを含む ClusterPermission リソースを作成し、オプションの name フィールドを設定しないと、失敗します。このエラーは、namespace 内のロールバインディングに同じ名前が使用されているために発生します。

この問題を回避するには、各ロールバインディングのオプションの name フィールドに一意の名前を設定します。

ACM-22366

Pod がハブクラスターのすべての設定マップとシークレットを監視し、それほど多くのリソースが使用されるため、multicluster-observability-addon-manager Pod は OOMKilled 状態にあります。マルチクラスター可観測性アドオンを有効にすると、メトリックコレクションに失敗します。

この問題を回避するには、マルチクラスター可観測性アドオンを有効にしないでください。マルチクラスター可観測性アドオンはデフォルトで無効になっています。マルチクラスター可観測性アドオンを有効にした場合は、MulticlusterObservability カスタムリソースで enabled を false に設定してアドオンを無効にします。次の MultiClusterObservability カスタムリソースの例を参照してください。

+

apiVersion: observability.open-cluster-management.io/v1beta2
kind: MultiClusterObservability
metadata:
  name: observability
spec:
  capabilities:
    platform:
      metrics:
        default:
          enabled: false
    userWorkloads:
      metrics:
        default:
          enabled: false

apiVersion: observability.open-cluster-management.io/v1beta2
kind: MultiClusterObservability
metadata:
  name: observability
spec:
  capabilities:
    platform:
      metrics:
        default:
          enabled: false
    userWorkloads:
      metrics:
        default:
          enabled: false

MultiClusterObservability カスタムリソースで mco-disable-alerting: true を設定して自動設定を無効にし、アラート転送を手動で設定した場合に、Red Hat Advanced Cluster Management 2.15 アラート転送にアップグレードすると、Red Hat Advanced Cluster Management 2.15 アラート転送が失敗します。observability-alertmanager-accessor および hub-alertmanager-router-ca シークレットの名前が変更され、ハブクラスター名の postfix が含まれるように変更されているため、アップグレード後にエラーが発生します。

この問題を修正するには、シークレットの新しい名前を使用するように手動で設定したアラート転送設定を更新します。

プラットフォームアラートの場合は、openshift-monitoring namespace の cluster-monitoring-config config map のシークレット名を更新します。ユーザーワークロードアラートの場合は、openshift-user-workload-monitoring namespace の user-workload-monitoring-config config map のシークレット名を更新します。openshift-monitoring および openshift-user-workload-monitoring namespace で新規シークレット名を見つけます。

ACM-26604

すべての解像度レベル (retentionResolutionRaw、retentionResolution5m、retentionResolution1h など) のデフォルトの保持期間は 365 日 (365d) です。この 365d のデフォルトの保持期間は、1 時間の解像度のデフォルトの保持期間が無期限 0d から 365d に短縮されたことを意味します。この保持の変更により、データが失われる可能性があります。MultiClusterObservability spec.advanced.retentionConfig パラメーターで解像度保持の明示的な値を設定していない場合は、データが失われる可能性があります。

詳細は、保持の詳細設定の追加 を参照してください。

ACM-22366

Kubernetes の制限が原因で、復元されたハブクラスター内の Observatorium API ゲートウェイ Pod には、バックアップおよび復元手順の後に古いテナントデータが含まれる可能性があります。制限の詳細は Mounted ConfigMaps are updated automatically を参照してください。

その結果、Observatorium API と Thanos ゲートウェイはコレクターからのメトリクスを拒否し、Red Hat Advanced Cluster Management Grafana ダッシュボードにはデータが表示されません。

Observatorium API ゲートウェイ Pod ログから、次のエラーを参照してください。

level=error name=observatorium caller=logchannel.go:129 msg="failed to forward metrics" returncode="500 Internal Server Error" response="no matching hashring to handle tenant\n"

level=error name=observatorium caller=logchannel.go:129 msg="failed to forward metrics" returncode="500 Internal Server Error" response="no matching hashring to handle tenant\n"

Thanos は、以下のエラーを出して Pod ログを受信します。

caller=handler.go:551 level=error component=receive component=receive-handler tenant=xxxx err="no matching hashring to handle tenant" msg="internal server error"

caller=handler.go:551 level=error component=receive component=receive-handler tenant=xxxx err="no matching hashring to handle tenant" msg="internal server error"

この問題を解決するには、次の手順を参照してください。

注記: デフォルトでは N = 2 ですが、一部のカスタム設定環境では 2 より大きくなる場合があります。

これにより、すべての Observatorium API ゲートウェイ Pod が正しいテナント情報で再起動され、コレクターからのデータが 5 ～ 10 分以内に Grafana に表示され始めます。

ACM-22366

定義済みの Red Hat Advanced Cluster Management ハブクラスター namespace 内のラベルを使用する必要があります。openshift.io/cluster-monitoring: "true" のラベルを指定して、Cluster Monitoring Operator はメトリクスの namespace を取得します。

Red Hat Advanced Cluster Management がデプロイされるか、インストールがアップグレードされると、Red Hat Advanced Cluster Management Observability ServiceMonitors および PrometheusRule リソースは openshift-monitoring namespace に存在しなくなります。

ACM-22366

可観測性アドオンの Prometheus AdditionalAlertManagerConfig リソースは、プロキシー設定をサポートしていません。可観測性アラート転送機能を無効にする必要があります。

アラート転送を無効にするには、次の手順を実行します。

自己署名 CA 証明書を使用する HTTPS プロキシーはサポートされていません。

ACM-22366

カスタム Observatorium API と Alertmanager URL は、TLS パススルーを備えた中間コンポーネントのみをサポートします。両方のカスタム URL が同じ中間コンポーネントを指している場合、OpenShift Container Platform ルーターは同じホストを持つ 2 つの別個のルートオブジェクトをサポートしていないため、別々のサブドメインを使用する必要があります。

ACM-22366

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

ACM-22366

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

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

次のコマンドを使用して、カスタムリソース定義がスタックしているかどうかを確認します。

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}'

リソースに削除タイムスタンプがある場合、カスタムリソース定義は停止します。この問題を解決するには、クラスターに残っている設定ポリシーからすべてのファイナライザーを削除します。マネージドクラスターで次のコマンドを使用し、<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": []}}'

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

ACM-22366

ポリシーが remediationAction: enforce に設定されていて、繰り返し更新されている場合、Red Hat Advanced Cluster Management コンソールには、更新が成功しても繰り返し違反が表示されます。更新を繰り返すと複数のポリシーイベントが生成され、governance-policy-framework-addon Pod のメモリーが不足してクラッシュすることがあります。このエラーは、次の 2 つの考えられる原因と解決策を参照してください。

ACM-22366

ポリシージェネレーターによって生成された Kyverno ポリシーが、Red Hat Advanced Cluster Management クラスターで次のメッセージを報告します。

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

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

原因は、ジェネレーターの PolicyReport API バージョンが正しくなく、Kyverno がデプロイしたものと一致しないことです。

ACM-22366

ネットワーク機能の使用中に発生する可能性がある次の既知の問題と制限事項を参照してください。

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)

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

Multicluster Global Hub をアップグレードし、Multicluster Global Hub クラスター内に ManagedClusterMigration リソースがいくつかある場合、次のエラーが発生する可能性があります。

error validating existing CRs against new CRD''s schema for "managedclustermigrations.global-hub.open-cluster-management.io":
      error validating global-hub.open-cluster-management.io/v1alpha1, Kind=ManagedClusterMigration
      "multicluster-global-hub/xxx": updated validation is
      too restrictive: [].spec.from: Required value'

error validating existing CRs against new CRD''s schema for "managedclustermigrations.global-hub.open-cluster-management.io":
      error validating global-hub.open-cluster-management.io/v1alpha1, Kind=ManagedClusterMigration
      "multicluster-global-hub/xxx": updated validation is
      too restrictive: [].spec.from: Required value'

この問題を回避するには、Multicluster Global Hub をアップグレードする前に、すべての ManagedClusterMigration リソースを削除します。以下のコマンドを実行します。

oc delete mcm --all

oc delete mcm --all

ACM-22366

マネージドハブクラスターをホステッドモードでインポートし、それをデタッチすると、open-cluster-management-agent-addon namespace が削除され、再作成されます。マネージドハブクラスターをデタッチすると、この namespace に関連付けられたすべての addon リソースも削除され、再作成されます。

現在、この問題に対する回避策はありません。

ACM-22366

連邦情報処理標準 (FIPS) 環境では、メモリー不足 (OOM) 状態のため、Kafka Operator が再起動し続けます。この問題を解決するには、リソース制限を少なくとも 512M に設定します。この制限を設定する詳細な手順は、amq ストリームドキュメント を参照してください。

ACM-22366

Global Hub Policy Group Compliancy Overview ハブダッシュボードで、View Offending Policies for standard group をクリックすると、1 つのデータポイントを確認できます。しかし、このリンクをクリックして違反ページに移動すると、標準グループのフィルターを新しいページに渡すことができません。

これは、Cluster Group Compliancy Overview の問題でもあります。

ACM-22366

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