リリースノート

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

Red Hat Advanced Cluster Management をアンインストールする場合は、再インストールしてアップグレードする前に、以前の StorageVersionMigration を手動で削除する必要があります。

たとえば、以前のバージョンの Red Hat Advanced Cluster Management を使用するために OpenShift Container Platform から Red Hat Advanced Cluster Management 2.10 をアンインストールし、再度 2.10 にアップグレードしようとすると、StorageVersionMigration リソースを削除しない限りアップグレードは失敗します。

infrastructure-operator をインストールすると、ARM を使用するコンバージドフローは機能しません。この問題を解決するには、ALLOW_CONVERGED_FLOW を false に設定します。

問題が解決されると、エージェントはインベントリーに表示されます。

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>

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

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

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

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

spec:
  clusterSelector:
    matchLabels:
      environment: dev

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

コンソールから 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" メッセージが繰り返し表示されることがあります。この問題にもかかわらず、クラスターの選択を入力することはできます。

OpenShift Container Platform 4.17 を使用している場合、search serviceaccount に、ユーザーに必要なパーミッションの一部が欠落しています。そのため、Argo CD プルモデルリソース同期コントローラーは、検索 API からアプリケーションリソースリストにアクセスできません。

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

注記: OpenShift Container Platform 3.11 の Red Hat Advanced Cluster Management のサポートは非推奨です。

OpenShift Container Platform 3.11 クラスターを対象とするサブスクリプションアプリケーションを作成した後、Kubernetes の不具合により、ReplicaSet および Pod リソースのアプリケーショントポロジーが正しく表示されません。この不具合は、pod-template-hash が ReplicaSet または Pod リソース名のハッシュと一致しない場合に発生します。以降の Kubernetes バージョンは修正されていますが、OpenShift Container Platform 3.11 は修正されていません。詳細は、Kubernetes バグリファレンス を参照してください。

このバグのため、トポロジーはリソースのステータスを反映しない可能性があります。たとえば、Pod と replicaset は反映されませんが、それらのリソースは存在します。

アプリケーションアドオンコンポーネントは、Kubernetes Lease API である leases.coordination.k8s.io を使用しますが、OpenShift Container Platform 3.11 を使用している場合にはこの API はありません。Kubernetes Lease API は Kubernetes 1.14 で導入されており、OpenShift Container Platform 3.11 は Kubernetes バージョン 1.11 をバンドルしています。

この問題を解決するには、以下の Kubernetes Lease API CustomResourceDefinition を OpenShift Container Platform 3.11 マネージドクラスターに手動で適用します。

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: leases.coordination.k8s.io
spec:
  group: coordination.k8s.io
  names:
    kind: Lease
    listKind: LeaseList
    plural: leases
    singular: lease
    shortNames:
    - ls
  scope: Namespaced
  versions:
  - name: v1
    served: true    storage: true    schema:
      openAPIV3Schema:
        description: Lease defines a lease concept.
        type: object
        properties:
          apiVersion:
            type: string
          kind:
            type: string
          metadata:
            type: object
          spec:
            type: object
            properties:
              acquireTime:
                format: date-time
                type: string
              holderIdentity:
                type: string
              leaseDurationSeconds:
                format: int64
                type: integer
              leaseTransitions:
                format: int64
                type: integer
              renewTime:
                format: date-time
                type: string
            required:
            - holderIdentity
            - leaseDurationSeconds
            - renewTime
        required:
        - kind
        - metadata
        - spec
  additionalPrinterColumns:
  - JSONPath: .metadata.creationTimestamp
    name: Age
    type: date
  subresources:
    status: {}

注記: OpenShift Container Platform 3.11 の Red Hat Advanced Cluster Management のサポートは非推奨です。

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

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

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

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

OpenShift Container Platform 3.11 マネージドクラスター上の Argo CD Push モデルに対してカスタマイズされたクラスターシークレットを作成できません。これは、マネージドサービスアカウントアドオンが OpenShift Container Platform 3.11 マネージドクラスターでサポートされていないために発生します。

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"

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

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

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

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

ただし、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 (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'

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

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

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

MultiClusterObservability は、Cluster Monitoring Operator の以前のバージョンを使用します。以前のバージョンでは、cluster-monitoring-config config map が監視可能性内の他の設定に更新されるのを防ぎます。設定はデフォルト値にリセットされます。

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

すべての解像度レベル (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"

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"

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

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

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

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

Red Hat Advanced Cluster Management 2.9 がデプロイされるか、インストールが 2.9 にアップグレードされると、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

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

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

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

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

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

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

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

Endpoint url cannot have fully qualified paths

endpoint: example.com:443

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

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

OpenShift Container Platform 3.11 マネージドクラスター (非推奨) からのメトリクスは、Red Hat Advanced Cluster Management ハブクラスターからメトリクスが収集されないため、ハブクラスターからは表示されません。

Container Security Operator は OpenShift Container Platform 3.11 では利用できません。したがって、ImageManifestVuln ポリシーの policy-imagemanifestvuln-sub のポリシーテンプレートを取得して、OpenShift Container Platform 3.11 クラスターに適用できません。

ImageManifestVuln ポリシーを適用しようとすると、次の違反メッセージが表示されます。

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

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

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

設定ポリシーで 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

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

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

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

既存の設定ポリシーを変更するときに pruneObjectBehavior が機能しないpruneObjectBehavior が機能しない可能性がある以下の理由を確認してください。

ポリシーが 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

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

データベースとポリシーコンプライアンス履歴 API の停止に対する復元力が組み込まれていますが、マネージドクラスターによって記録できないコンプライアンスイベントは、正常に記録されるまでメモリー内にキューに入れられます。つまり、停止が発生し、マネージドクラスター上の governance-policy-framework Pod が再起動すると、キューに入れられたコンプライアンスイベントはすべて失われます。

データベースの停止中に新しいポリシーを作成または更新すると、ポリシーとデータベース ID のマッピングを更新できないため、この新しいポリシーに対して送信されたコンプライアンスイベントは記録されません。データベースがオンラインに戻ると、マッピングが自動的に更新され、それらのポリシーからの将来のコンプライアンスイベントが記録されます。

最新データを含まないバックアップへの復元など、PostgreSQL サーバーでデータが失われた場合は、ポリシーとデータベース ID のマッピングを更新できるように、Red Hat Advanced Cluster Management ハブクラスターのガバナンスポリシープロパゲーターを再起動する必要があります。ガバナンスポリシープロパゲーターを再起動するまで、データベースに存在していたポリシーに関連付けられた新しいコンプライアンスイベントは記録されなくなります。

ガバナンスポリシープロパゲーターを再起動するには、Red Hat Advanced Cluster Management ハブクラスターで次のコマンドを実行します。

oc -n open-cluster-management rollout restart deployment/grc-policy-propagator

ポリシージェネレーターによって生成された 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

原因は、ジェネレーターの 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)

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

独自の Kafka には、spec、status、event という 3 つのトピックがあります。multicluster global hub を 1.3 以降にアップグレードすると、spec および status トピックのみが残ります。multicluster global hub オペランドを使用して、これらのトピックを設定します。持ち込んだトランスポートのデフォルトのトピックは gh-spec と gh-status です。

multicluster global hub オペランドはシステムの API またはリソースであり、multicluster global hub operator はコントローラーです。Multicluster Global Hub をアップグレードした後、独自の Kafka クラスターとマルチクラスターグローバルハブオペランドの間でトピックを調整します。Kafka クラスターで gh-spec および gh-status トピックを作成することも、multicluster global hub オペランドを変更して、既存の spec および status トピックを使用することもできます。

独自の Kafka トピックを使用するように multicluster global hub オペランドを更新するには、次の YAML サンプルを使用します。

apiVersion: operator.open-cluster-management.io/v1alpha4
kind: MulticlusterGlobalHub
spec:
  availabilityConfig: Basic
  dataLayer:
    kafka:
      topics:
        specTopic: spec
        statusTopic: status
    postgres:
      retention: 18m
  enableMetrics: false

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

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

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

Multicluster Global Hub Operator が OpenShift Container Platform 4.13 にインストールされている場合、マネージドクラスターのリストにリンクするすべてのハイパーリンクとダッシュボードの詳細ページが Red Hat Advanced Cluster Management ホームページにリダイレクトされる可能性があります。

手動で目的のページに移動する必要があります。

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

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

マネージドクラスターが OpenShift Container Platform 3.11 クラスター (非推奨) をマネージドクラスターとしてインポートする場合は、Global Hub > Overview ダッシュボードの Observability ページにリダイレクトできません。

対象のページに手動でナビゲートする必要があります。

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