リリースノート

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

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

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

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

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

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

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

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

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

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 コンソールウィンドウのサイズを大きくするか、テキストをコピーして別の場所に貼り付けます。

複数のラベル式を追加するか、ApplicationSet のクラスターセレクターに入ろうとすると、"Expand to enter expression" メッセージが繰り返し表示されることがあります。この問題にもかかわらず、クラスターの選択を入力することはできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 チャートをデプロイできません。

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

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

その結果、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

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 リソースが示されます。

マネージドクラスターで実行している 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 インスタンスが表示されます。

配置ルールの更新後にアプリケーションがデプロイされない場合は、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 を手動で作成するには、以下の手順を実行します。

同じ 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.14 では、アプリケーション の コンソール と トポロジー が変更されます。コンソールの Topology ページにフィルタリング機能はありません。

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

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

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

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

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

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 に表示され始めます。

定義済みの 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 に存在しなくなります。

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

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

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

さまざまなハブクラスターが同じ 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 秒に設定されている場合には、この問題は発生しません。

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

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

Endpoint url cannot have fully qualified paths

Endpoint url cannot have fully qualified paths

endpoint: example.com:443

endpoint: example.com:443

addonDeploymentConfig を使用して設定したマネージドクラスター内のプロキシー設定は、メトリックコレクターによって検出されません。回避策として、マネージドクラスター ManifestWork を削除してプロキシーを有効化できます。ManifestWork を削除すると、addonDeploymentConfig の変更が強制的に適用されます。

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

ConfigurationPolicy リソースで objectSelector フィールドと namespaceSelector フィールドの両方を使用すると、objectSelector が返すオブジェクトは、namespaceSelector が返すすべての namespace に適用されます。ConfigurationPolicy が結果を正しく処理しません。この問題を回避するには、object-templates-raw フィールドを適用してオブジェクトを反復処理します。

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

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

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": []}}'

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

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

同じポリシーテンプレート名でポリシーを作成すると、検出されない一貫性のない結果が返されますが、原因がわからない場合があります。たとえば、create-pod という名前の複数の設定ポリシーを含むポリシーを定義すると、一貫性のない結果が発生します。Best practice: ポリシーテンプレートに重複した名前を使用しないようにします。

ポリシージェネレーターによって生成された 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 がデプロイしたものと一致しないことです。

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

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

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

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

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

元の Multicluster Global Hub クラスターがクラッシュすると、Multicluster Global Hub では、生成されたイベントと cron ジョブがなくなります。新しい Multicluster Global Hub クラスターを復元しても、イベントと cron ジョブは復元されません。この問題を回避するには、cron ジョブを手動で実行します。要約プロセスの手動実行 を参照してください。

マネージドクラスターが正常に作成されなかった場合、つまり、clusterclaim id.k8s.io がマネージドクラスターに存在せず、ポリシーコンプライアンスダッシュボードにはカウントされないにも関わらず、ポリシーコンソールには表示されます。

Kafka メッセージサイズの制限が原因で、Grafana ダッシュボードに完全なデータが表示されない場合があります。デフォルトの制限は 1 megabyte (MB) です。ポリシーまたはマネージドクラスターデータの合計サイズが 1 MB を超えるかどうかを確認します。その場合は、要件に合わせて Kafka メッセージのサイズ制限を増やします。

次の手順を実行して、Kafka 設定を変更します。

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

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

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