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

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

Red Hat Advanced Cluster Management を新しいバージョンにアップグレードした後、StatefulSet に属するいくつかの Pod が failed 状態のままになることがあります。このまれなイベントは、Kubernetes の既知の問題 が原因です。

この問題の回避策として、失敗した Pod を削除します。Kubernetes は、正しい設定で自動的に再起動します。

Red Hat Advanced Cluster Management をバージョン 2.2.x から 2.3.1 にアップグレードすると、アップグレードに失敗します。Multiclusterhub ステータスは、コンポーネントエラーメッセージに failed to download chart from helm repo を表示します。no endpoints available for service "ocm-webhook" 問題を参照するエラーも表示される場合があります。

ハブクラスターで、Red Hat Advanced Cluster Management がインストールされている namespace で以下のコマンドを実行し、デプロイメントを再起動してバージョン 2.3.1 にアップグレードします。

oc delete deploy ocm-proxyserver ocm-controller ocm-webhook multiclusterhub-repo

注記: エラーは解決しますが、調整プロセスはすぐに開始されない可能性があります。これは、製品がインストールされているのと同じ namespace で multicluster-operators-standalone-subscription を再起動して高速化できます。

Openshift Container Platform クラスターがアップグレードの段階に入ると、クラスター Pod は再起動され、クラスターのステータスが 1-5 分ほど、upgrade failed のままになることがあります。この動作は想定されており、数分後に解決されます。

Cluster ページに表示されているノード数と Search の結果で差異が生じる場合があります。

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

この製品は、Linux、macOS、および Windows で利用可能な Mozilla Firefox 74.0 または最新バージョンをサポートします。コンソールの互換性を最適化するため、最新版にアップグレードしてください。

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

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

さまざまなハブクラスターが同じ 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 パネルでデータが表示されません。

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

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

Google Cloud Platform(GCP) でのクラスターのプロビジョニングを試みると、以下のエラーが発生して失敗する可能性があります。

Cluster initialization failed because one or more operators are not functioning properly.
The cluster should be accessible for troubleshooting as detailed in the documentation linked below,
https://docs.openshift.com/container-platform/latest/support/troubleshooting/troubleshooting-installations.html
The 'wait-for install-complete' subcommand can then be used to continue the installation

GCP プロジェクトで ネットワークセキュリティー API を有効にして、このエラーを回避することができます。これにより、クラスターのインストールを継続できます。

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

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

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

Azure Government クラスターを休止状態にしようとすると、以下のエラーがプロビジョニング Pod ログに追加されてハイバネートに失敗します。

Confidential Client is not supported in Cross Cloud request

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 よりも後のバージョンはサポート対象です。

クラウドプロバイダーのアクセスキーを変更しても、プロビジョニングされたクラスターのアクセスキーは、namespace で更新されません。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。このような場合は、以下のコマンドを実行して、クラウドプロバイダーでアクセスキーを更新します。

検索で、ハブクラスターのリソース用の 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 ステータスであることを確認してから検索する必要があります。

ハブクラスターのアーキテクチャーとは異なるアーキテクチャーでマネージドクラスターを作成するには、両方のアーキテクチャーのファイルが含まれるリリースイメージ (ClusterImageSet) を作成する必要があります。たとえば、ppc64le、または s390x ハブクラスターから x86_64 クラスターを作成する場合は、リリースイメージを作成する必要があります。両方のファイルセットでリリースイメージを作成する場合に、新規のリリースイメージにより OpenShift Container Platform リリースレジストリーがマルチアーキテクチャーイメージマニフェストを提供できるので、クラスターの作成は成功します。

この問題を回避するには、アーキテクチャータイプについて次の例のような手順を実行します。

作成プロセスでは、マージされたリリースイメージを使用してクラスターを作成します。

Red Hat Advanced Cluster Management との Argo CD の統合は、利用可能な ppc64le イメージまたは s390x イメージがないため、IBM Power で実行されている Red Hat Advanced Cluster Management ハブクラスターでは機能しません。

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 ページを参照してください。

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

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

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

クラスターが複数のサブスクリプションを使用している場合は、クラスターが アプリケーショントポロジー で適切にグループされない可能性があります。

複数のサブスクリプションでアプリケーションをデプロイする場合、すべてのサブスクリプションビュー がクラスターノードを適切にグループ化していない可能性があります。

たとえば、Helm リポジトリーと Git リポジトリーの組み合わせを含む複数のサブスクリプションでアプリケーションをデプロイする場合、すべてのサブスクリプション ビューは Helm サブスクリプション内のリソースに対するステータスを適切に表示しません。

代わりに、個別のサブスクリプションビューからトポロジーを表示して、正しいクラスターノードをグループ化する情報を表示します。

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 のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

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

oc get pods -n open-cluster-management-agent-addon を実行して確認します。

また、コンソールで kind:pod cluster:yourcluster を検索し、klusterlet-addon-appmgr が実行中であることを確認できます。

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

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'

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

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

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

リマインダーとして、ポリシーは PlacementRule または Placement リソースを使用して、特定のマネージドクラスターへのポリシーのデプロイを制御する必要があります。Placement リソースを使用するポリシーを作成する場合には、以下の制限事項があります。

Placement リソースの使用時には、コマンドラインインターフェイス (CLI) を使用してポリシーの更新を行います。

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 の状態のままになってしまう可能性があります。

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

別のハブクラスターからバックアップされたデータを使用して、新しいハブクラスターで復元操作を実行すると、アプリケーションとポリシーは、管理対象クラスター上のリソースのステータスを表示しません。これは、検索アドオンとポリシーアドオンが新しいハブクラスターを指すようにリセットされていないために発生します。

新規ハブクラスターから、全マネージドクラスターの addon-certpolicyctrl および addon-search を再起動する必要があります。次のコマンドを実行して、Pod を再起動します。

oc get pods -n open-cluster-management-agent-addon | grep search | awk '{print $1}' | xargs kubectl delete pod

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