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

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

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

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

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

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

ROKS クラスターおよび HyperShift クラスターの場合、Red Hat Advanced Cluster Management の可観測性は、ダッシュボードの etcd パネルにデータを表示しません。

1000 のクラスターを管理するハブクラスターで検索を無効にすると、メモリー不足 (OOM) が原因で search-collector Pod がクラッシュします。以下の手順を実行します。

まれに、検索 Pod は証明書の変更後に自動的に再デプロイされない場合があります。これにより、サービス Pod 全体で証明書が一致しなくなるため、転送レイヤーセキュリティー (TLS) ハンドシェイクが失敗します。この問題を修正するには、検索 Pod を再起動して証明書をリセットします。

デフォルトでは、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 秒に設定されている場合には、この問題は発生しません。

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

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

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

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

./setup-grafana-dev.sh --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

ベアメタルプロバイダーと切断されたインストールを使用してクラスターを作成する場合、切断されたインストールの設定 セクションの認証情報にすべての設定を保存する必要があります。クラスター作成コンソールエディターでそれらを入力することはできません。

VMware vSphere または Red Hat OpenStack Platform プロバイダーを使用してクラスターを作成し、切断されたインストールを行う場合、ミラーレジストリーにアクセスするために証明書が必要な場合は、切断されたインストールの設定セクションの認証情報の追加の信頼バンドルフィールドに証明書を入力する必要があります。.その証明書をクラスター作成コンソールエディターに入力すると、無視されます。

ベアメタル、VMware vSphere、または Red Hat OpenStack Platform プロバイダーの認証情報を作成する場合、インストーラーは証明書を区別しないため、切断されたインストールのプロキシーと設定の追加の信頼バンドルフィールドには同じ値が含まれていることに注意してください。これらの機能を個別に使用することもできます。また、プロキシーインストールと非接続インストールで異なる証明書が必要な場合は、フィールドに複数の証明書を入力できます。

ハブクラスターから VolSync ManagedClusterAddOn を削除すると、マネージドクラスターの VolSync Operator サブスクリプションが削除されますが、クラスターサービスバージョン (CSV) は削除されません。マネージドクラスターから CSV を削除するには、VolSync を削除する各マネージドクラスターで以下のコマンドを実行します。

oc delete csv -n openshift-operators volsync-product.v0.4.0

別のバージョンの VolSync がインストールされている場合は、v0.4.0 をインストール済みバージョンに置き換えます。

ManagedClusterSet を削除した後に、クラスターセットに関連付ける各マネージドクラスターに追加されるラベルは自動的に削除されません。削除したマネージドクラスターセットに含まれる各マネージドクラスターからラベルを手動で削除します。ラベルは cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> のようになります。

ClusterPool に対して Hive ClusterClaim を作成し、ClusterClaimspec の有効期限のフィールドを無効な golang タイム値に手動で設定すると、Red Hat Advanced Cluster Management は不正な要求だけでなく、すべての ClusterClaims の実行および調整を停止します。

このエラーが発生すると、clusterclaim-controller Pod ログに以下の内容が表示されます。これは、プール名と、無効な有効期限が含まれた特定の例です。

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...

無効な要求を削除できます。

不正な要求が削除されると、要求は追加の対話なしに正常に調整を開始します。

clusterimageset は fast チャネルに置かれますが、プロビジョニングされたクラスターは stable チャネルにあります。現時点で、製品は channel をプロビジョニングされた OpenShift Container Platform クラスターと同期しません。

OpenShift Container Platform コンソールで適切なチャネルに切り替えます。Administration > Cluster Settings > Details Channel の順にクリックします。

カスタム CA 証明書を使用してクラスターを管理したハブクラスターのバックアップを復元した後、マネージドクラスターとハブクラスター間の接続が失敗する場合があります。これは、復元されたハブクラスターで CA 証明書がバックアップされなかったためです。接続を復元するには、マネージドクラスターの namespace にあるカスタム CA 証明書情報を、復元されたハブクラスターの <managed_cluster>-admin-kubeconfig シークレットにコピーします。

ヒント: バックアップコピーを作成する前にこの CA 証明書をハブクラスターにコピーする場合は、バックアップコピーにシークレット情報が含まれます。将来、バックアップコピーを使用して復元する場合、ハブとマネージドクラスター間の接続は自動的に完了します。

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

Red Hat Advanced Cluster Management コンソールを使用してオンプレミスクラスターを作成する場合は、クラスターで使用可能なサブネットを選択する必要があります。必須フィールドとしてマークされていません。

Infrastructure Operator を使用して OpenShift Container Platform クラスターを作成する場合、ISO イメージのファイル名は長すぎる可能性があります。長いイメージ名により、イメージのプロビジョニングとクラスターのプロビジョニングが失敗します。この問題が生じるかどうかを確認するには、以下の手順を実行します。

この問題が発生する場合、これは通常 OpenShift Container Platform の以下のバージョンで発生します。インフラストラクチャー Operator がイメージサービスを使用していないためです。

このエラーを回避するには、OpenShift Container Platform をバージョン 4.8.18 以降、または 4.9.7 以降にアップグレードしてください。

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

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

マネージドクラスターを自動的にプロビジョニングするように設定された AnsibleJob テンプレートは、以下の条件の両方が満たされると失敗する可能性があります。

klusterlet Operator をインストールしてマネージドクラスターをインポートする場合には、klusterlet Operator のバージョンは、ハブクラスターのバージョンと同じでなければなりません。そうでないと、klusterlet Operator は動作しません。

マネージドクラスターの namespace を手動で削除できません。マネージドクラスター namespace は、マネージドクラスターの割り当てを解除した後に自動的に削除されます。マネージドクラスターの割り当てを解除する前に手動でマネージドクラスター namespace を削除する場合は、マネージドクラスターの削除後にマネージドクラスターに継続的な終了ステータスが表示されます。この終了マネージドクラスターを削除するには、割り当てを解除したマネージドクラスターからファイナライザーを手動で削除します。

Red Hat Advanced Cluster Management をバージョン 2.3 にアップグレードすると、アップグレード前に Red Hat Advanced Cluster Management で作成して管理されていたマネージドクラスターの認証情報シークレットが変更できなくなります。

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

IBM OpenShift Container Platform Kubernetes Service バージョン 3.11 のクラスターをインポートすることはできません。IBM OpenShift Kubernetes Service の 3.11 よりも後のバージョンはサポート対象です。

クラウドプロバイダー側でクラウドプロバイダーのアクセスキーを変更する場合は、Kubernetes Operator 用のマルチクラスターエンジンのコンソールで、クラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

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

マネージドクラスターを破棄してから 1 時間経過してもステータスが Destroying のままで、クラスターが破棄されません。この問題を解決するには、以下の手順を実行します。

Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform Dedicated 環境にある OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。

特定のマネージドクラスターにある特定のリソースの検索詳細ページで問題が発生する可能性があります。マネージドクラスターの work-manager アドオンが Available ステータスであることを確認してから検索する必要があります。

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

Red Hat OpenShift Container Platform および OpenShift Container Platform 以外のクラスターの両方は Pod ログ機能をサポートしますが、OpenShift Container Platform 以外のクラスターでは、この機能を使用できるように LoadBalancer が有効にされている必要があります。LoadBalancer を有効にするには、以下の手順を実行します。

LoadBalancer のタイプについての詳細は、Kubernetes のドキュメント のService ページを参照してください。

バージョン 2.4.x から 2.5.0 にアップグレードした後、cluster-proxy-addon が起動せず、cluster-proxy-addon-manager が nil ポインター例外を発生させます。

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

OpenShift Container Platform 4.10.z でクラスター全体のプロキシー設定を使用してホスティングサービスクラスターを作成すると、nodeip-configuration.service サービスがワーカーノードで開始されません。

Azure で OpenShift Container Platform 4.11 クラスターをプロビジョニングすると、認証 Operator のタイムアウトエラーが原因で失敗します。この問題を回避するには、install-config.yaml ファイルで別のワーカーノードタイプを使用するか、vmNetworkingType パラメーターを Basic に設定します。次の install-config.yaml の 例を参照してください。

compute:
- hyperthreading: Enabled
  name: 'worker'
  replicas: 3
  platform:
    azure:
      type:  Standard_D2s_v3
      osDisk:
        diskSizeGB: 128
      vmNetworkingType: 'Basic'

iPXE は、オープンソースのネットワークブートファームウェアです。詳細は、iPXE を参照してください。

ノードの起動時に、一部の DHCP サーバーの URL の長さ制限により、InfraEnv カスタムリソース定義の ipxeScript URL が切り取られ、コンソールに次のエラーメッセージが表示されます。

起動可能なデバイスがありません

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

マネージドクラスターのインストール中に ClusterDeployment リソースを使用してカスタム Ingress ドメインを指定できますが、変更はインストール後に SyncSet リソースを使用してのみ適用されます。その結果、clusterdeployment.yaml ファイルの spec フィールドには、指定したカスタム Ingress ドメインが表示されますが、status には引き続きデフォルトのドメインが表示されます。

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

Infrastructure.config.openshift.io API は 3.x では使用できないため、コンソールから Argo ApplicationSet を 3.x OpenShift Container Platform マネージドクラスターにデプロイすることはできません。

マネージドクラスターで実行している application-manager アドオンは、以前は klusterlet Operator により処理されていましたが、サブスクリプション Operator により処理されるようになりました。サブスクリプション Operator は multicluster-hub で管理されていないため、multicluster-hub イメージマニフェスト ConfigMap の multicluster_operators_subscription イメージへの変更は自動的に有効になりません。

サブスクリプション Operator が使用するイメージが、multicluster-hub イメージマニフェスト ConfigMap の multicluster_operators_subscription イメージを変更することによってオーバーライドされた場合、マネージドクラスターの application-manager アドオンは、サブスクリプション Operator Pod が再起動するまで新しいイメージを使用しません。Pod を再起動する必要があります。

Red Hat Advanced Cluster Management バージョン 2.4 では、デフォルトで policy.open-cluster-management.io/v1 リソースがアプリケーションサブスクリプションによってデプロイされなくなりました。

サブスクリプション管理者は、このデフォルトの動作を変更するためにアプリケーションサブスクリプションをデプロイする必要があります。

詳細は、サブスクリプション管理者としての許可リストおよび拒否リストの作成 を参照してください。以前の Red Hat Advanced Cluster Management バージョンの既存のアプリケーションサブスクリプションによってデプロイされた policy.open-cluster-management.io/v1 リソースは、サブスクリプション管理者がアプリケーションサブスクリプションをデプロイしていない限り、ソースリポジトリーに合わせて調整されません。

Ansible フックのスタンドアロンモードはサポートされていません。サブスクリプションを使用してハブクラスターに Ansible フックをデプロイするには、次のサブスクリプション YAML を使用できます。

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true

ただし、spec.placement.local:true ではサブスクリプションが standalone モードで実行されているため、この設定では Ansible インストールが作成されない可能性があります。ハブモードでサブスクリプションを作成する必要があります。

両方を適用すると、ハブクラスターに作成された Ansible インスタンスが表示されます。

Editor ロールで実行するユーザーは、アプリケーションで read または update の権限のみが割り当てられているはずにもかかわらず、誤ってアプリケーションの create および delete の操作ができてしまいます。OpenShift Container Platform Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

Editor ロールで実行するユーザーは、配置ルールで read または update の権限のみが割り当てられているはずにもかかわらず、誤って create および delete の操作もできてしまいます。OpenShift Container Platform Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

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

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

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

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

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

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

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

Helm Argo アプリケーションを作成して編集すると、YAML ファイルが正しい間、テンプレート情報は空で表示されます。エラーを修正するには、エラータ 2.4.1 にアップグレードしてください。

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

ApplicationSet YAML で定義された namespace とは異なる namespace にリソースをデプロイする ApplicationSet アプリケーションを作成すると、リソースのステータスがトポロジーに表示されません。

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

ApplicationSet アプリケーションがデプロイされているが、Argo アプリケーションが関連付けられていない場合に、ApplicationSet トポロジーステータスアイコンが継続的に回転します。

ハブクラスターを 2.5 より前のバージョンから 2.6 にアップグレードした後、サポートされていない OpenShift Container Platform バージョンの一部がコンソールの クラスター ページに一覧表示されます。

2.5 サブスクリプションコントローラーより前のバージョンでデプロイされた古い clusterImageSet リソースは、アップグレード後に削除されません。これを解決するには、OpenShift Container Platform のバージョンがサポートされていない clusterImageSet リソースを手動で削除します。たとえば、次のコマンドを実行して img4.7.0-x86-64-appsub clusterImageSet を削除します。

oc delete clusterimageset img4.7.0-x86-64-appsub

ハブクラスターデータを新しいハブクラスターに復元する場合、マネージドクラスターが配置クラスター決定リストから削除された後でも、マネージドクラスター上の既存のアプリケーションサブスクリプションは削除されません。

次の手順を実行することで、この問題を回避できます。

以前に作成した ApplicationSet と同じ URL とブランチで新しい ApplicationSet を作成すると、ApplicationSet ウィザードはパスを自動的にフェッチしません。

この問題を回避するには、Path フィールドにパスを手動で入力します。

外部アイデンティティープロバイダーを使用して 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 機能の DeleteAll または DeleteIfCreated では、変更前に作成された古いリソースは消去されません。設定ポリシーを削除すると、ポリシーの作成およびポリシーの更新による新しいリソースのみが追跡および削除されます。

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

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

ハブクラスターのバックアップおよび復元機能には、Data Protection (OADP) Operator の OpenShift API が必要です。OADP Operator は、IBM Power または IBM Z アーキテクチャーでは使用できません。

ハブクラスターは passive から primary クラスターに戻されると、異なるクラスターが同じストレージの場所にあるデータをバックアップできます。これにより、バックアップの競合が発生します。つまり、最新のバックアップが passive ハブクラスターによって生成されたことを意味します。

BackupSchedule.cluster.open-cluster-management.io リソースがハブクラスターで有効になっているため、passive ハブクラスターはバックアップを生成しますが、このハブクラスターは primary ハブクラスターでなくなったため、バックアップデータは書き込みできるべきではありません。以下のコマンドを実行して、バックアップの競合があるかどうかを確認します。

oc get backupschedule -A

以下のステータスが返される場合があります。

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.

BackupSchedule.cluster.open-cluster-management.io リソースの status を BackupCollision に設定して、バックアップの競合を回避します。BackupSchedule リソースによって作成される Schedule.velero.io リソースは自動的に削除されます。

バックアップの競合は、hub-backup-pod ポリシーにより報告されます。管理者は、どのハブクラスターが対象のストレージの場所にデータを書き込んでいるかを確認する必要があります。次に、passive ハブクラスターから BackupSchedule.cluster.open-cluster-management.io リソースを削除し、primary ハブクラスターに新しい BackupSchedule.cluster.open-cluster-management.io リソースを再作成して、バックアップを再開します。

詳細は、バックアップおよびリストア Operator の有効化 を参照してください。

以下の復元の制限を確認してください。

前述の制限に対応するために、restore.cluster.open-cluster-management.io リソースが作成されると、クラスターのバックアップおよび復元 Operator は、Velero 復元の開始前にハブクラスターを削除して復元の準備を行う一連の手順を実行します。

詳細は、バックアップおよびリストア Operator の有効化 トピックの リストア前のハブクラスターの消去 を参照してください。

プライマリーハブクラスターに手動でインポートされたマネージドクラスターは、パッシブハブクラスターでアクティベーションデータが復元された場合にのみ表示されます。

enableClusterBackup パラメーターを true に設定してクラスターを 2.5 から 2.6 にアップグレードすると、次のメッセージが表示されます。

When upgrading from version 2.4 to 2.5, cluster backup must be disabled

クラスターをアップグレードする前に、enableClusterBackup パラメーターを false に設定して、クラスターのバックアップおよび復元を無効にします。MultiClusterHub リソースの components セクションは、次の YAML ファイルのようになります。

アップグレードが完了したら、バックアップおよび復元のコンポーネントを再度有効にすることができます。以下のサンプルを参照してください。

overrides:
      components:
        - enabled: true
          name: multiclusterhub-repo
        - enabled: true
          name: search
        - enabled: true
          name: management-ingress
        - enabled: true
          name: console
        - enabled: true
          name: insights
        - enabled: true
          name: grc
        - enabled: true
          name: cluster-lifecycle
        - enabled: true
          name: volsync
        - enabled: true
          name: multicluster-engine
        - enabled: false
          name: cluster-proxy-addon
        - enabled: true
          name: cluster-backup
    separateCertificateManagement: false

OADP を手動でインストールした場合は、アップグレードする前に OADP を手動でアンインストールする必要があります。アップグレードが成功し、バックアップおよび復元が再度有効になると、OADP が自動的にインストールされます。

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

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

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

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

OADP 1.0 で DataProtectionApplication リソースを作成すると、リソースのステータスによって次のようなエラーメッセージが作成される場合があります。

Route.route.openshift.io "oadp-dpa-sample-1-aws-registry-route" is invalid: spec.host: Invalid value: "oadp-dpa-sample-1-aws-registry-route-open-cluster-management-backup.dns.name.here": must be no more than 63 characters

この問題を解決するには、backupImages パラメーターを false に設定します。以下の例を参照してください。

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: oadp-dpa-sample-1
  namespace: open-cluster-management-backup
spec:
  backupImages: false
  backupLocations:

Globalnet を使用していない限り、OpenShift SDN と OVN Kubernetes CNI ネットワークの両方を Submariner で使用できます。Globalnet を使用する場合には、OpenShift SDN のみがサポートされます。

カーネルバージョンが 4.18.0-359.el8.x86_64 から 4.18.0-372.11.1.el8_6.x86_64 の Red Hat Enterprise Linux ワーカー ノードを含むクラスターに Submariner をデプロイすると、アプリケーションワークロードがリモートクラスターとの通信に失敗します。

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

Red Hat OpenStack クラスターの自動クラウド準備は、product-title-short} コンソールの Submariner ではサポートされていません。Red Hat Advanced Cluster Management API を使用して、クラウドを手動で準備できます。

clusterset.local ドメイン名を使用して、同じクラスターに存在するクライアントからエクスポートされたヘッドレスサービスにアクセスする場合を除き、Globalnet でヘッドレスサービスを使用できます。clusterset.local ドメイン名を使用してヘッドレスサービスにアクセスすると、ヘッドレスサービスに関連付けられている globalIP はクラスター内でルーティングできず、クライアントに返されます。

cluster.local ドメイン名を使用して、ローカルのヘッドレスサービスにアクセスできます。

Submariner は、エアギャップ環境でプロビジョニングされたクラスターに対して検証されていません。

複数のゲートウェイをデプロイできません。

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

OVN Kubernetes CNI ネットワークプロバイダーを使用するには、Red Hat OpenShift 4.11 以降が必要です。OVN Kubernetes は Globalnet をサポートしていません。

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

Microsoft Azure マネージドクラスターセット名の長さは 20 文字以下にする必要があります。

Microsoft Azure 上の OpenShift Container Platform 4.12 は、ゲートウェイノードの問題によりサポートされていません。

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

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

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