トラブルシューティング

must-gather コマンドの使用を開始するには、以下の手順を参照してください。

非接続環境で must-gather コマンドを実行するには、次の手順を実行します。

現在サポートされているリリースのいずれか、製品ドキュメントで問題が発生した場合は、Red Hat サポート にアクセスして、さらにトラブルシューティングを行ったり、ナレッジベースの記事を表示したり、サポートチームに連絡したり、ケースを開いたりすることができます。Red Hat 認証情報でログインする必要があります。

Hosted Control Plane クラスターで問題が発生した場合は、must-gather コマンドを実行して、トラブルシューティングに役立つ情報を収集できます。

MultiClusterHub をインストールしてから、MultiClusterHub リソースの status.components フィールドからのコンポーネントの 1 つ以上で ProgressDeadlineExceeded と報告したまま 10 分以上経過しています。クラスターのリソース制約が問題となっている場合があります。

Multiclusterhub がインストールされている namespace の Pod を確認します。以下のようなステータスとともに Pending と表示される場合があります。

reason: Unschedulable
message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master:
        }, that the pod didn't tolerate.'

このような場合には、ワーカーノードにはクラスターでの製品実行に十分なリソースがありません。

この問題が発生した場合は、大規模なワーカーノードまたは複数のワーカーノードでクラスターを更新する必要があります。クラスターのサイジングのガイドラインについては、クラスターのサイジング を参照してください。

Red Hat Advanced Cluster Management のインストール後に Pod が起動しない場合は、Red Hat Advanced Cluster Management 以前にインストールされており、今回のインストールを試行する前にすべてのパーツが削除されていない可能性があります。

Pod はこのような場合に、インストールプロセスの完了後に起動しません。

この問題が発生した場合は、以下の手順を実行します。

ManagedClusterSet および ManagedClusterSetBinding カスタムリソース定義をリスト表示しようとすると、次のエラーメッセージが表示されます。

Error from server: request to convert CR from an invalid group/version: cluster.open-cluster-management.io/v1beta1

前のメッセージは、v1beta1 から v1beta2 への ManagedClusterSets および ManagedClusterSetBindings カスタムリソース定義の移行が失敗したことを示しています。

このエラーを解決するには、API の移行を手動で開始する必要があります。以下の手順を実行します。

oc get managedclusterset
oc get managedclustersetbinding -A

クラスターの作成手順を完了したら、Red Hat Advanced Cluster Management コンソールからアクセスできず、クラスターのステータスが offline と表示されます。

クラスターのインポート手順を完了したら、Red Hat Advanced Cluster Management for Kubernetes コンソールからアクセスできません。

インポートの試行後にインポートクラスターが利用できない場合には、いくつかの理由があります。クラスターのインポートに失敗した場合は、インポートに失敗した理由が見つかるまで以下の手順を実行します。

Red Hat Advanced Cluster Management コンソールを使用してクラスターをインポートした後に、コンソールで、クラスターのステータスが Pending import と表示されます。

OpenShift Container Platform クラスターを Red Hat Advanced Cluster Management MultiClusterHub にインポートすると、エラーログが表示されます。

error log:
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
Error from server (AlreadyExists): error when creating "STDIN": customresourcedefinitions.apiextensions.k8s.io "klusterlets.operator.open-cluster-management.io" already exists
The cluster cannot be imported because its Klusterlet CRD already exists.
Either the cluster was already imported, or it was not detached completely during a previous detach process.
Detach the existing cluster before trying the import again."

以下のコマンドを実行して、新しい Red Hat Advanced Cluster Management MultiClusterHub にインポートする Red Hat Advanced Cluster Management 関連のリソースがクラスター上にあるかどうかを確認します。

oc get all -n open-cluster-management-agent
oc get all -n open-cluster-management-agent-addon

次のコマンドを使用して、klusterlet カスタムリソースを削除します。

oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'

次のコマンドを実行して、既存のリソースを削除します。

oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false
oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'

自己署名証明書を使用して Red Hat OpenStack Platform で新しい Red Hat OpenShift Container Platform クラスターを作成した後、クラスターは失敗し、不明な権限エラーを示すエラーメッセージが表示されます。

マネージドクラスターのデプロイが失敗し、次のエラーメッセージが返されます。

x509: certificate signed by unknown authority

次のファイルが正しく設定されていることを確認します。

Red Hat OpenShift Container Platform バージョン 3.11 クラスターのインポートを試行すると、以下の内容のようなログメッセージでインポートに失敗します。

customresourcedefinition.apiextensions.k8s.io/klusterlets.operator.open-cluster-management.io configured
clusterrole.rbac.authorization.k8s.io/klusterlet configured
clusterrole.rbac.authorization.k8s.io/open-cluster-management:klusterlet-admin-aggregate-clusterrole configured
clusterrolebinding.rbac.authorization.k8s.io/klusterlet configured
namespace/open-cluster-management-agent configured
secret/open-cluster-management-image-pull-credentials unchanged
serviceaccount/klusterlet configured
deployment.apps/klusterlet unchanged
klusterlet.operator.open-cluster-management.io/klusterlet configured
Error from server (BadRequest): error when creating "STDIN": Secret in version "v1" cannot be handled as a Secret:
v1.Secret.ObjectMeta:
v1.ObjectMeta.TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 1313, error found in #10 byte of ...|dhruy45="},"kind":"|..., bigger context ...|tye56u56u568yuo7i67i67i67o556574i"},"kind":"Secret","metadata":{"annotations":{"kube|...

この問題は多くの場合、インストールされている kubectl コマンドラインツールのバージョンが 1.11 以前であるために発生します。以下のコマンドを実行して、実行中の kubectl コマンドラインツールのバージョンを表示します。

kubectl version

返されたデータがバージョンが 1.11 以前の場合は、問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する に記載される修正のいずれかを実行します。

この問題は、以下のいずれかの手順を実行して解決できます。

証明書シークレットを更新する手順を完了すると、オンラインだった 1 つ以上のクラスターがコンソールに offline ステータスを表示するようになります。

カスタムの API サーバー証明書の情報を更新すると、インポートされ、新しい証明書が追加される前に稼働していたクラスターのステータスが offline になります。

オフラインのマネージドクラスターの open-cluster-management-agent namespace にある Pod のログで、証明書に問題があるとのエラーが見つかります。以下の例のようなエラーがログに表示されます。

以下の work-agent ログを参照してください。

E0917 03:04:05.874759       1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:05.874887       1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:37.245859       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority

以下の registration-agent ログを確認してください。

I0917 02:27:41.525026       1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority

マネージドクラスターが local-cluster であるか、Red Hat Advanced Cluster Management for Kubernetes を使用して作成された場合、マネージドクラスターを再インポートするには、10 分以上待つ必要があります。

マネージドクラスターをすぐに再インポートするには、ハブクラスター上のマネージドクラスターのインポートシークレットを削除し、Red Hat Advanced Cluster Management を使用して再インポートします。以下のコマンドを実行します。

oc delete secret -n <cluster_name> <cluster_name>-import

<cluster_name> を、インポートするマネージドクラスターの名前に置き換えます。

Red Hat Advanced Cluster Management を使用してインポートされたマネージドクラスターを再インポートする場合は、以下の手順を実行してマネージドクラスターを再度インポートします。

注記: 前の手順では、マネージドクラスターがハブクラスターから切り離されません。この手順により、必要なマニフェストがマネージドクラスターの現在の設定 (新しい証明書情報を含む) で更新されます。

マネージドクラスターの削除後に namespace が削除されません。

namespace を手作業で削除するには、以下の手順を実行します。

管理用のハイブクラスターをインポートすると、auto-import-secret already exists というエラーが表示されます。

この問題は、Red Hat Advanced Cluster Management で以前に管理されていたクラスターをインポートしようとすると発生します。これが生じると、クラスターを再インポートしようとすると、シークレットは競合します。

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

スナップショットを使用するように VolSync ReplicationSource または ReplicationDestination を設定できます。また、ReplicationSource および ReplicationDestination で storageclass および volumesnapshotclass を設定できます。cinder volumesnapshotclass には、デフォルト値が false の、force-create というパラメーターがあります。volumesnapshotclass でこの force-create パラメーターを指定すると、cinder が使用中の PVC から volumesnapshot を取得できません。その結果、volumesnapshot はエラー状態になります。

must-gather コマンドを実行するには、次の前提条件を満たす必要があります。

must-gather コマンドを使用して情報を収集するには、次の手順を実行します。

以下の情報は、must-gather コマンドから収集されます。

問題をデバッグするために、Multicluster Global Hub データベースに出力をダンプする必要がある場合があります。PostgreSQL データベースには、データベースの内容をダンプするための pg_dump コマンドラインツールが用意されています。localhost データベースサーバーからデータをダンプするには、次のコマンドを実行します。

pg_dump hoh > hoh.sql

リモートサーバー上にある Multicluster Global Hub データベースを圧縮形式でダンプするには、次の例に示すように、コマンドラインオプションを使用して接続の詳細を制御します。

pg_dump -h my.host.com -p 5432 -U postgres -F t hoh -f hoh-$(date +%d-%m-%y_%H-%M).tar

PostgreSQL データベースを復元するには、psql または pg_restore コマンドラインツールを使用できます。psql ツールは、pg_dump によって作成されたプレーンテキストファイルを復元するために使用されます。

psql -h another.host.com -p 5432 -U postgres -d hoh < hoh.sql

pg_restore ツールは、pg_dump によって非プレーンテキスト形式 (カスタム、tar、またはディレクトリー) のいずれかで作成されたアーカイブから PostgreSQL データベースを復元するために使用されます。

pg_restore -h another.host.com -p 5432 -U postgres -d hoh hoh-$(date +%d-%m-%y_%H-%M).tar

GA より前に Multicluster Global Hub の初期バージョンをインストールしている場合は、現在の Multicluster Global Hub Operator と互換性があるようにテーブルをアップグレードする必要があります。アップグレードの主な目的は、event.local_policies、event.local_root_policies、および history.local_compliance テーブルをパーティション化されたテーブルに変換することです。

次の例は、日付が 2023-08 に設定された event.local_policies テーブルの変換を示しています。他の 2 つのテーブルのアップグレード手順は同様です。

マネージドクラスターからハブクラスターへのネットワーク接続が不安定な場合に、マネージドクラスターのステータスが offline と available との間で順に切り替わると、ハブクラスターにより報告されます。

ハブクラスターとマネージドクラスター間の接続は、leaseDurationSeconds の間隔値で検証されるリースを通じて維持されます。連続 5 回の leaseDurationSeconds 値の試行以内にリースが検証されない場合、クラスターは offline としてマークされます。

たとえば、クラスターは 60 seconds の leaseDurationSeconds の間隔で 5 分後に offline としてマークされます。この設定は、接続の問題や遅延などの理由により不適切であり、不安定になる可能性があります。

5 回の検証試行はデフォルトであり変更できませんが、leaseDurationSeconds の間隔は変更できます。

クラスターを offline としてマークする時間を分単位で決定し、その値を 60 倍にして秒に変換します。次に、デフォルトの試行回数 5 で割ります。その結果が leaseDurationSeconds 値になります。

Red Hat Advanced Cluster Management for Kubernetes コンソールで新規クラスターを作成した後に、コンソールでクラスターのステータスが Pending または Failed と表示されてそれ以上進みません。

クラスターのステータスが Failed と表示される場合は、クラスターの詳細ページに移動して、提供されたログへのリンクに進みます。ログが見つからない場合や、クラスターのステータスが Pending と表示される場合は、以下の手順を実行してログを確認します。

ログでエラーを特定した後に、エラーの解決方法を決定してから、クラスターを破棄して、作り直してください。

以下の例では、サポート対象外のゾーンを選択している可能性を示すログエラーと、解決に必要なアクションが提示されています。

No subnets provided for zones

クラスターの作成時に、サポートされていないリージョンにあるゾーンを 1 つ以上選択しています。問題解決用にクラスターを再作成する時に、以下のアクションの 1 つを実行します。

ログから問題を特定した後に、クラスターを破棄し、再作成します。

クラスター作成の詳細は、クラスター作成の概要 を参照してください。

Grafana エクスプローラーで時間のかかるメトリックをクエリーするときに Gateway Time-out エラーが発生した場合は、open-cluster-management-observability namespace の Grafana が原因でタイムアウトが発生した可能性があります。

この問題が発生した場合は、以下の手順を実行します。

Grafana ページを更新し、再度メトリクスのクエリーを試行します。Gateway Time-out エラーが表示されなくなりました。

すべてのマネージドクラスターは配置ルールで選択されますが、local-cluster は選択されません。配置ルールユーザーには、local-cluster namespace の managedcluster リソースを取得するためのパーミッションは付与されません。

非推奨: PlacementRule

この問題を解決するには、local-cluster namespace に managedcluster 管理パーミッションを付与する必要があります。以下の手順を実行します。

サブスクリプションの YAML ファイルのアプリケーションリソースの 1 つまたは複数で、非推奨の API が使用されている場合に、以下のようなエラーが発生する可能性があります。

failed to install release: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for
kind "Deployment" in version "extensions/v1beta1"

または、old.yaml などの名前で YAML ファイルに新しい Kubernetes API バージョンを追加している場合は、以下のエラーが発生する可能性があります。

error: unable to recognize "old.yaml": no matches for kind "Deployment" in version "deployment/v1beta1"

マネージドクラスターで Klusterlet をデプロイした後に、KlusterletRegistrationDegraded または KlusterletWorkDegraded の状態が True と表示されます。

ステータスが Degraded のリストおよびこれらの問題の解決方法を参照してください。

オブジェクトストレージチャネルのサブスクリプションは、更新されたシークレットを自動的に取得できません。そのため、サブスクリプションオペレーターが調整できなくなり、オブジェクトストレージからマネージドクラスターにリソースがデプロイされなくなります。

シークレットを作成するには、認証情報を手動で入力してから、チャネル内のシークレットを参照する必要があります。

コマンドの実行後に、アプリケーションコンソールに移動して、リソースがマネージドクラスターにデプロイされていることを確認してください。または、マネージドクラスターにログインして、アプリケーションリソースが特定の namespace で作成されているかどうかを確認できます。

可観測性のカスタムリソース定義 (CRD) をインストールして作成した後に可観測性のステータスが Installing で停止すると、spec:storageConfig:storageClass パラメーターに値が定義されていない場合があります。または、可観測性コンポーネントは自動的にデフォルトの storageClass を検索しますが、ストレージの値が指定されていないと、コンポーネントが Installing ステータスのままになります。

この問題が発生した場合は、以下の手順を実行します。

storageclass.kubernetes.io/is-default-class: "true"

インストールが完了すると、可観測性コンポーネントのステータスが Ready に更新されます。インストールの完了に失敗すると、ステータスが Fail と表示されます。

endpoint-observability-operator-x Pod は、prometheus-k8s サービスが openshift-monitoring namespace で利用可能かどうかを確認します。このサービスが openshift-monitoring namespace に存在しない場合は、metrics-collector はデプロイされません。Failed to get prometheus resource というエラーメッセージが表示される可能性があります。

この問題が発生した場合は、以下の手順を実行します。

メトリックを利用できないマネージドクラスターが存在する可能性があります。この場合は、metrics-collector デプロイメントから以下のエラーが発生することがあります。

error: response status code is 500 Internal Server Error, response body is x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "observability-client-ca-certificate")

この問題が発生した場合は、以下の手順を実行します。

metrics-collector-deployment デプロイメントが再度作成され、observability-controller-open-cluster-management.io-observability-signer-client-cert シークレットが更新されます。

search-api ログに ERROR: could not resize shared memory segment "/PostgreSQL.1083654800" to 25031264 bytes: No space left on device (SQLSTATE 53100) のようなエラーメッセージが表示されます。

この問題を解決するには、search-postgres ConfigMap にある PostgreSQL リソースを更新します。リソースを更新するには、次の手順を実行します。

環境変数の追加について、詳しくは 検索のカスタマイズと設定 を参照してください。

Red Hat Advanced Cluster Management for Kubernetes をアップグレードし、oc logs observability-thanos-compact-0 コマンドを使用して Thanos コンパクターのログを確認すると、ログに次のエラーメッセージが表示されます。

ts=2024-01-24T15:34:51.948653839Z caller=compact.go:491 level=error msg="critical error detected; halting" err="compaction: group 0@15699422364132557315: compact blocks [/var/thanos/compact/compact/0@15699422364132557315/01HKZGQGJCKQWF3XMA8EXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HKZQK7TD06J2XWGR5EXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HKZYEZ2DVDQXF1STVEXAMPLE /var/thanos/compact/compact/0@15699422364132557315/01HM05APAHXBQSNC0N5EXAMPLE]: populate block: chunk iter: cannot populate chunk 8 from block 01HKZYEZ2DVDQXF1STVEXAMPLE: segment index 0 out of range"

オブジェクトストレージ設定に thanos bucket verify コマンドを追加します。以下の手順を実行します。

インストール後、Submariner ネットワークが通信していません。

Submariner のデプロイ後にネットワーク接続が確立されない場合は、トラブルシューティング手順を開始します。Submariner をデプロイすると、プロセスが完了するまでに数分かかる場合があることに注意してください。

デプロイメントした後で Submariner が正常に実行できない場合は、次の手順を実行します。

クラスターセット内のクラスターに Submariner アドオンを追加すると、クラスターの Gateway nodes、Agent status、および Connection status に次のステータスが表示されます。

また、接続されているクラスターと切断されているクラスターも表示されます。

Red Hat Advanced Cluster Management は FinishedWithErrors ステータスを示し、Red Hat Advanced Cluster Management の復元で作成された 1 つ以上の Velero 復元リソースは PartiallyFailed ステータスを示します。

空のバックアップから復元する場合は、FinishedWithErrors ステータスを無視しても安全です。

Red Hat Advanced Cluster Management for Kubernetes の復元では、すべての Velero リストアリソースの累積ステータスが表示されます。1 つのステータスが PartiallyFailed で、他のステータスが Completed の場合、少なくとも 1 つの問題があることが示すために累積ステータスとして PartiallyFailed が表示されます。

この問題を解決するには、ステータスが PartiallyFailed になっているすべての Velero 復元リソースのステータスを個別に確認し、さらにログで詳細を確認します。ログはオブジェクトストレージから直接取得するか、DownloadRequest カスタムリソースを使用して OADP Operator からダウンロードできます。

コンソールから DownloadRequest を作成するには、次の手順を実行します。

acm-resources-generic-schedule バックアップでバックアップされたリソースは、復元されたハブクラスターには表示されません。バックアップオペレーターのログを確認すると、次のようなメッセージが表示されます。

_2023-06-08T13:42:48.066572033Z 2023-06-08T13:42:48.066Z    INFO    Deleting resource DRPlacementControl [c1-helloworld-placement-1-drpc.c1-helloworld]    {"controller": "restore", "controllerGroup": "cluster.open-cluster-management.io", "controllerKind": "Restore", "restore":
{"name":"restore-acm","namespace":"open-cluster-management-backup"}

次の状況が発生した場合、リソースは削除されます。

この問題を解決するには、復元操作を再度実行して、cleanupBeforeRestore: 値を None に設定します。

マネージドクラスターとハブクラスターが同じクラスターである場合、証明書データは編集されるため、内容はテンプレート JSON 文字列として解析されません。次のエラーメッセージが表示される場合があります。

message: >-
            [spec.tls.caCertificate: Invalid value: "redacted ca certificate
            data": failed to parse CA certificate: data does not contain any
            valid RSA or ECDSA certificates, spec.tls.certificate: Invalid
            value: "redacted certificate data": data does not contain any valid
            RSA or ECDSA certificates, spec.tls.key: Invalid value: "": no key specified]

ハブクラスターとマネージドクラスターの fromSecret 値を取得するように証明書ポリシーを設定します。autoindent 機能を使用して、次の内容で証明書ポリシーを更新します。

                 tls:
                    certificate: |
                      {{ print "{{hub fromSecret "open-cluster-management" "minio-cert" "tls.crt" hub}}" | base64dec | autoindent }}