リリースノート

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

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

E0430 19:11:20.810624 1 clientset.go:188] "cannot connect once" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\""

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.

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

spec:
  clusterSelector:
    matchLabels:
      environment: dev

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

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

spec:
  clusterSelector:
    matchLabels:
      environment: dev

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

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

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

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

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

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

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

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

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

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

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

admin または 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 からアプリケーションリソースリストにアクセスできません。

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

アプリケーションアドオンコンポーネントは、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 のサポートは非推奨です。

IBM VMware や Bare Metal などの一部のクラウドプロバイダーによってプロビジョニングされた Red Hat OpenShift Container Platform 4.15 でサービスアカウントを作成すると、アカウントによってシークレットが自動的に作成されません。したがって、Red Hat Advanced Cluster Management gitopsCluster コントローラーは、Argo CD プッシュモデルのマネージドクラスターシークレットを生成できません。

この問題は、AWS によってプロビジョニングされた Red Hat OpenShift Container Platform 4.15 では発生しません。ただし、他のクラウドプロバイダーによってプロビジョニングされた Red Hat OpenShift Container Platform 4.15 でもこの問題が発生する可能性があります。この問題は、Red Hat Advanced Cluster Management 2.10.3 および Red Hat Advanced Cluster Management 2.9.4 で発生します。

この問題を回避するには、シークレットを手動で作成し、それをサービスアカウント open-cluster-management-agent-addon/application-manager にアタッチする必要があります。これを行うには、次の手順を実行します。

シークレットが正常に作成され、サービスアカウントにアタッチされたことを確認するには、次の手順を実行します。

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

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

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 の変更が強制的に適用されます。

カスタム CA バンドルが必要な場合、マネージドクラスターのプロキシー設定は機能しません。

ガバナンスリソースが適切にクリーンアップされないコンポーネントが false に設定されているか、MultiClusterHub Operator で無効になっている場合、ガバナンスコンポーネントは、管理するアドオンをクリーンアップする前に削除されます。

外部アイデンティティープロバイダーを使用して 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

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

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

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

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

ポリシーが remediationAction: enforce に設定されていて、繰り返し更新されている場合、Red Hat Advanced Cluster Management コンソールには、更新が成功しても繰り返し違反が表示されます。このエラーについては、次の 2 つの考えられる原因と解決策を参照してください。

たとえば、Secret リソース内の stringData マップは、Kubernetes によって、base64 でエンコードされた値を持つ data に変換されます。stringData を使用する代わりに、文字列の代わりに base64 でエンコードされた値を含む data を直接使用します。

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: ポリシーテンプレートに重複した名前を使用しないようにします。

MultiClusterHub オブジェクトでガバナンスデプロイメントを無効にすると、デプロイメントはエラーなしでクリーンアップされません。次の手順を実行してガバナンスを無効にし、デプロイメントもクリーンアップされるようにします。

設定ポリシー内の構文が正しくないなど、テンプレートエラーがある場合、オブジェクトは削除されます。削除されたオブジェクトを正しい構文で再作成します。

Run once モードおよび無効に設定された PolicyAutomation がある場合は、追加の Ansible ジョブが作成されます。追加の Ansible ジョブを削除できます。以下の手順を実行します。

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

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

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

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

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

グローバルハブポリシーグループコンプライアンスの概要 ハブダッシュボードでは、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 での操作またはアクセス権をクラスターレベルで制御できるように設定します。