1.9. トラブルシューティング

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

oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v2.5 --dest-dir=<directory>

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

REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel9@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8>

oc adm must-gather --image=$IMAGE --dest-dir=./data

ここ で製品チーム向けの Jira バグを作成できます。

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

検出フェーズの後、ホストは再起動してインストールを続行しますが、ネットワークを設定できません。以下の現象およびメッセージを確認します。

info: networking config is defined in the real root

info: will not attempt to propagate initramfs networking

ログに最後のメッセージが表示された場合、現象 に記載されているフォルダーで既存のネットワーク設定がすでに見つかっているため、ネットワーク設定は伝播されません。

インストール中に適切なネットワーク設定を使用するには、次のタスクを実行します。

ノードがインストールを開始します。検出フェーズの後、ノードは既存のクラスター上の変更と初期設定の間でネットワーク設定をマージします。

エージェントプラットフォーム上の Hosted Control Plane クラスターを破棄しようとすると、hcp destroy コマンドが次のエラーで失敗します。

+

2024-02-22T09:56:19-05:00    ERROR    HostedCluster deletion failed    {"namespace": "clusters", "name": "hosted-0", "error": "context deadline exceeded"}
2024-02-22T09:56:19-05:00    ERROR    Failed to destroy cluster    {"error": "context deadline exceeded"}

エージェントプラットフォーム上の Hosted Control Plane クラスターを正常に破棄するには、次の手順を実行します。

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

MultiClusterEngine がインストールされた 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.'

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

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

マルチクラスターエンジン Operator をインストールした後に Pod が起動しない場合は、マルチクラスターエンジン Operator の以前のインストールからの項目が、アンインストール時に正しく削除されなかったことが原因であることが多いです。

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

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

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

クラスターをインポートする手順を完了すると、コンソールからクラスターにアクセスできなくなります。

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

マルチクラスターエンジン Operator を使用して OpenShift Container Platform クラスターをプロビジョニングした後に、API サーバー証明書を変更したり、OpenShift Container Platform クラスターに追加したりすると、x509: certificate signed by unknown authority エラーでクラスターの再インポートが失敗する場合があります。

マネージドクラスターの再インポートに失敗した後、次のコマンドを実行して、マルチクラスターエンジン Operator ハブクラスターのインポートコントローラーログを取得します。

kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f

次のエラーログが表示される場合は、マネージドクラスター API サーバーの証明書が変更されている可能性があります。

ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace":"awscluster1"}, "namespace": "awscluster1", "name": "awscluster1", "reconcileID": "a2cccf24-2547-4e26-95fb-f258a6710d80", "error": "Get \"https://api.awscluster1.dev04.red-chesterfield.com:6443/api?timeout=32s\": x509: certificate signed by unknown authority"}

マネージドクラスター API サーバー証明書が変更されたかどうかを確認するには、次の手順を実行します。

次のメッセージのようなエラーが表示された場合は、クラスター API サーバーの証明書が変更になっており、kubeconfig ファイルが無効です。

Unable to connect to the server: x509: certificate signed by unknown authority

マネージドクラスター管理者は、マネージドクラスター用に新しい有効な kubeconfig ファイルを作成する必要があります。

新しい kubeconfig を作成したら、次の手順を実行して、マネージドクラスターの新しい kubeconfig を更新します。

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

証明書シークレットを更新する手順を完了すると、オンラインだった 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 の場合、またはマルチクラスターエンジン Operator でマネージドクラスターが作成された場合に、マネージドクラスターを再インポートするには 10 分以上待つ必要があります。

マネージドクラスターをすぐに再インポートするには、ハブクラスター上のマネージドクラスターのインポートシークレットを削除し、マルチクラスターエンジン Operator を使用して復元します。以下のコマンドを実行します。

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

<cluster_name> は、復元するマネージドクラスターの名前に置き換えます。

マルチクラスターエンジン Operator を使用してインポートされたマネージドクラスターを再インポートする場合は、次の手順を実行して、マネージドクラスターを復元します。

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

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

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

コンソールを使用して新しいクラスターを作成した後、クラスターは Pending のステータスを超えて進行しないか、Failed ステータスを表示します。

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

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

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

No subnets provided for zones

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

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

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

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 クラスターのインポートに失敗する に記載される修正のいずれかを実行します。

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

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

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

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

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

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

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

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

Placement を作成した後、PlacementDescision は自動的に生成されません。

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

ベースボード管理コントローラーを使用してベアメタルホストを検出する手順を完了すると、次のようなエラーメッセージが表示されます。

ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [
{"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"}
]

iDRAC は、不明な認証局からの証明書を受け入れないように設定されています。

この問題を回避するには、次の手順を実行して、ホスト iDRAC のベースボード管理コントローラーで証明書の検証を無効にします。

ブート画面には、ホストがルートファイルシステムイメージのダウンロードに失敗したことが示されます。

問題のトラブルシューティング方法は、OpenShift Container Platform の Assisted Installer ドキュメントの 最小限の ISO の起動失敗に関するトラブルシューティング を参照してください。

HostedCluster リソースが保留中であるため、Hosted Control Plane が完全にオンラインになりません。

Hosted Control Plane にはワーカーノードが登録されていないため、Hosted Control Plane は完全にオンラインになりません。

クラスターの作成中、ネットワークスタックがロールアウトされる間、ノードは一時的に NotReady 状態になります。プロセスのこの部分は正常です。ただし、プロセスのこの部分に 15 分以上かかる場合は、問題が発生している可能性があります。

Ingress およびコンソールクラスター Operator がオンラインではないため、Hosted Control Plane は完全にはオンラインになりません。

ロードバランサーサービスは利用できないため、Hosted Control Plane は完全にオンラインになりません。

ホステッドクラスターの永続ボリューム要求 (PVC) が使用できないため、Hosted Control Plane は完全にはオンラインになりません。

仮想マシンノードがクラスターに正しく参加していないため、Hosted Control Plane が完全にオンラインになりません。

BareMetalHosts なしで遅延バインディングマネージドクラスターを使用している場合は、遅延バインディングクラスターを破棄し、ノードを Discovery ISO に戻すための追加の手動手順を実行する必要があります。