1.9. トラブルシューティング
トラブルシューティングガイドをご使用の前に oc adm must-gather
コマンドを実行して、詳細およびログを収集し、問題のデバッグ手順を行います。詳細は、must-gather コマンドを実行したトラブルシューティング を参照してください。
また、ロールベースのアクセス権限を確認してください。詳細は、マルチクラスターエンジン Operator のロールベースのアクセス制御 を参照してください。
1.9.1. 文書化されたトラブルシューティング
マルチクラスターエンジン Operator のトラブルシューティングトピックのリストを表示します。
インストール:
インストールタスクに関する主要なドキュメントを表示するには、マルチクラスターエンジンオペレータのインストールとアップグレード を参照してください。
クラスター管理:
クラスターの管理に関する主要なドキュメントを表示するには、クラスターライフサイクルの概要 を参照してください。
- トラブルシューティング: 既存のクラスターに Day-2 ノードを追加すると、ユーザー捜査が保留中になり失敗する
- オフラインクラスターのトラブルシューティング
- マネージドクラスターのインポート失敗に関するトラブルシューティング
- クラスターの再インポートが不明な権限エラーで失敗する
- Pending Import ステータスのクラスターのトラブルシューティング
- 証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング
- クラスターのステータスが offline から available に変わる場合のトラブルシューティング
- VMware vSphere でのクラスター作成のトラブルシューティング
- ステータスが Pending または Failed のクラスターのコンソールでのトラブルシューティング
- OpenShift Container Platform バージョン 3.11 クラスターのインポートの失敗時のトラブルシューティング
- degraded 状態にある Klusterlet のトラブルシューティング
- クラスターの削除後も namespace が残る
- クラスターのインポート時の auto-import-secret-exists エラー
- Troubleshooting missing PlacementDecision after creating Placement
- Dell ハードウェアにおけるベアメタルホストの検出エラーのトラブルシューティング
- 最小限の ISO の起動失敗に関するトラブルシューティング
1.9.2. must-gather コマンドを実行したトラブルシューティング
トラブルシューティングを開始するには、問題のデバッグを行う must-gather
コマンドを実行する場合のトラブルシューティングシナリオについて確認し、このコマンドの使用を開始する手順を参照してください。
必要なアクセス権限: クラスターの管理者
1.9.2.1. Must-gather のシナリオ
シナリオ 1: 文書化されたトラブルシューティング セクションを使用して、問題の解決策がまとめられているかどうかを確認します。本ガイドは、製品の主な機能別に設定されています。
このシナリオでは、解決策がこのドキュメントにまとめられているかどうかを、このガイドで確認します。
-
シナリオ 2: 問題の解決策の手順が文書にまとめられていない場合は、
must-gather
コマンドを実行し、その出力を使用して問題をデバッグします。 -
シナリオ 3:
must-gather
コマンドの出力を使用して問題をデバッグできない場合は、出力を Red Hat サポートに共有します。
1.9.2.2. Must-gather の手順
must-gather
コマンドの使用を開始するには、以下の手順を参照してください。
-
OpenShift Container Platform ドキュメントの クラスターに関するデータの収集 で、
must-gather
コマンドについて確認し、必要なものをインストールします。 クラスターにログインします。通常のユースケースでは、engine クラスターにログインして、
must-gather
を実行する必要があります。注記: マネージドクラスターを確認する場合は、
cluster-scoped-resources
ディレクトリーにあるgather-managed.log
ファイルを検索します。<your-directory>/cluster-scoped-resources/gather-managed.log>
JOINED および AVAILABLE 列に
True
が設定されていないマネージドクラスターがないかを確認します。must-gather
コマンドは、ステータスがTrue
として関連付けられていないクラスター上で、実行できます。- データとディレクトリーの収集に使用される Kubernetes イメージのマルチクラスターエンジンを追加します。以下のコマンドを実行します。
oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v2.5 --dest-dir=<directory>
指定したディレクトリーに移動し、以下のレベルに整理されている出力を確認します。
-
ピアレベル 2 つ:
cluster-scoped-resources
とnamespace
のリソース - それぞれに対するサブレベル: クラスタースコープおよび namespace スコープの両方のリソースに対するカスタムリソース定義の API グループ。
-
それぞれに対する次のレベル:
kind
でソートされた YAML ファイル
-
ピアレベル 2 つ:
1.9.2.3. 非接続環境での must-gather
非接続環境で must-gather
コマンドを実行するには、次の手順を実行します。
- 非接続環境では、Red Hat Operator のカタログイメージをミラーレジストリーにミラーリングします。詳細は、ネットワーク切断状態でのインストール を参照してください。
-
次のコマンドを実行して、ミラーレジストリーからイメージを参照するログを抽出します。
sha256
はm現在のイメージに置き換えます。
REGISTRY=registry.example.com:5000 IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel9@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8> oc adm must-gather --image=$IMAGE --dest-dir=./data
ここ で製品チーム向けの Jira バグを作成できます。
1.9.2.4. ホステッドクラスターの must-gather
Hosted Control Plane クラスターで問題が発生した場合は、must-gather
コマンドを実行して、トラブルシューティングに役立つ情報を収集できます。
1.9.2.4.1. ホステッドクラスターの must-gather コマンドについて
このコマンドは、管理クラスターとホストされたクラスターの出力を生成します。
マルチクラスターエンジン Operator ハブクラスターからのデータ:
- クラスタースコープのリソース: これらのリソースは、管理クラスターのノード定義です。
-
hypershift-dump
圧縮ファイル: このファイルは、コンテンツを他の人と共有する必要がある場合に役立ちます。 - namespace リソース: これらのリソースには、config map、サービス、イベント、ログなど、関連する namespace のすべてのオブジェクトが含まれます。
- ネットワークログ: これらのログには、OVN ノースバウンドデータベースとサウスバウンドデータベース、およびそれぞれのステータスが含まれます。
- ホストされたクラスター: このレベルの出力には、ホストされたクラスター内のすべてのリソースが含まれます。
ホストされたクラスターからのデータ:
- クラスタースコープのリソース: これらのリソースには、ノードや CRD などのクラスター全体のオブジェクトがすべて含まれます。
- namespace リソース: これらのリソースには、config map、サービス、イベント、ログなど、関連する namespace のすべてのオブジェクトが含まれます。
出力にはクラスターからのシークレットオブジェクトは含まれませんが、シークレットの名前への参照が含まれる可能性があります。
1.9.2.4.2. 前提条件
must-gather コマンドを実行して情報を収集するには、次の前提条件を満たす必要があります。
-
kubeconfig
ファイルが読み込まれ、マルチクラスターエンジン Operator ハブクラスターを指している。 - マルチクラスターエンジン Operator ハブクラスターへの cluster-admin アクセスがある。
-
HostedCluster
リソースの name 値と、カスタムリソースがデプロイされる namespace がある。
1.9.2.4.3. ホステッドクラスターの must-gather コマンドの入力
次のコマンドを入力して、ホステッドクラスターに関する情報を収集します。このコマンドでは、
hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE
パラメーターはオプションです。これを含めない場合、コマンドは、ホストされたクラスターがデフォルトの namespace (clusters
) 内にあるかのように実行されます。oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.x /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME
コマンドの結果を圧縮ファイルに保存するには、
--dest-dir=NAME
パラメーターを含めて、NAME
は、結果を保存するディレクトリーの名前に置き換えます。oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.x /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME --dest-dir=NAME ; tar -cvzf NAME.tgz NAME
1.9.2.4.4. 非接続環境での must-gather コマンドの入力
非接続環境で must-gather
コマンドを実行するには、次の手順を実行します。
- 非接続環境では、Red Hat Operator のカタログイメージをミラーレジストリーにミラーリングします。詳細は、ネットワーク切断状態でのインストール を参照してください。
次のコマンドを実行して、ミラーレジストリーからイメージを参照するログを抽出します。
REGISTRY=registry.example.com:5000 IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8 oc adm must-gather --image=$IMAGE /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE hosted-cluster-name=HOSTEDCLUSTERNAME --dest-dir=./data
1.9.2.4.5. 関連情報
- Hosted Control Plane のトラブルシューティングの詳細は、OpenShift Container Platform ドキュメントの Hosted Control Plane のトラブルシューティング を参照してください。
1.9.3. 既存のクラスターに Day-2 ノードを追加するトラブルシューティングが保留中のユーザー操作で失敗する
インストール時に、ゼロタッチプロビジョニングまたはホストのインベントリー作成メソッドで Kubernetes Operator のマルチクラスターエンジンが作成した既存のクラスターにノードを追加したり、スケールアウトできません。インストールプロセスは、検出フェーズでは正しく機能しますが、インストールフェーズでは失敗します。
ネットワークの設定に失敗しています。統合コンソールのハブクラスターから、Pending
のユーザーアクションが表示されます。説明から、再起動ステップで失敗していることがわかります。
インストールするホストで実行されているエージェントは情報を報告できないため、失敗に関するエラーメッセージはあまり正確ではありません。
1.9.3.1. 現象: Day 2 ワーカーのインストールが失敗する
検出フェーズの後、ホストは再起動してインストールを続行しますが、ネットワークを設定できません。以下の現象およびメッセージを確認します。
統合コンソールのハブクラスターから、追加ノード上で
Pending
ユーザーアクションがないか、Rebooting
インジケーターが付いているかどうかを確認します。This host is pending user action. Host timed out when pulling ignition. Check the host console... Rebooting
Red Hat OpenShift Container Platform 設定のマネージドクラスターから、既存のクラスターの
MachineConfig
を確認します。MachineConfig
のいずれかが次のディレクトリーにファイルを作成しているかどうかを確認します。-
/sysroot/etc/NetworkManager/system-connections/
-
/sysroot/etc/sysconfig/network-scripts/
-
-
インストールするホストの端末から、障害が発生したホストに次のメッセージが表示されているかどうかを確認します。
journalctl
を使用してログメッセージを確認できます。
info: networking config is defined in the real root info: will not attempt to propagate initramfs networking
ログに最後のメッセージが表示された場合、現象 に記載されているフォルダーで既存のネットワーク設定がすでに見つかっているため、ネットワーク設定は伝播されません。
1.9.3.2. 問題の解決: ネットワーク設定をマージするノードを再作成します。
インストール中に適切なネットワーク設定を使用するには、次のタスクを実行します。
- ハブクラスターからノードを削除します。
- 同じようにノードをインストールするには、前のプロセスを繰り返します。
次のアノテーションを使用してノードの
BareMetalHost
オブジェクトを作成します。"bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"
ノードがインストールを開始します。検出フェーズの後、ノードは既存のクラスター上の変更と初期設定の間でネットワーク設定をマージします。
1.9.4. エージェントプラットフォーム上の Hosted Control Plane クラスター削除失敗のトラブルシューティング
エージェントプラットフォーム上の Hosted Control Plane クラスターを破棄すると、通常、すべてのバックエンドリソースが削除されます。マシンリソースが正しく削除されていない場合、クラスターの削除が失敗します。この場合、残りのマシンリソースを手動で削除する必要があります。
1.9.4.1. 現象: Hosted Control Plane クラスターを破棄するとエラーが発生する
エージェントプラットフォーム上の 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"}
1.9.4.2. 問題の解決: 残りのマシンリソースを手動で削除する
エージェントプラットフォーム上の Hosted Control Plane クラスターを正常に破棄するには、次の手順を実行します。
次のコマンドを実行して、残りのマシンリソースのリストを表示します。
<hosted_cluster_namespace>
は、ホストされたクラスターの namespace の名前に置き換えます。oc get machine -n <hosted_cluster_namespace>
以下の出力例を参照してください。
NAMESPACE NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION clusters-hosted-0 hosted-0-9gg8b hosted-0-nhdbp Deleting 10h 4.15.0-rc.8
次のコマンドを実行して、マシンリソースに割り当てられている
machine.cluster.x-k8s.io
ファイナライザーを削除します。oc edit machines -n <hosted_cluster_namespace>
次のコマンドを実行して、ターミナルに
No resources found
というメッセージが表示されることを確認します。oc get agentmachine -n <hosted_cluster_namespace>
次のコマンドを実行して、エージェントプラットフォーム上の Hosted Control Plane クラスターを破棄します。
hcp destroy cluster agent --name <cluster_name>
<cluster_name>
は、クラスター名に置き換えます。
1.9.5. インストールステータスがインストールまたは保留中の状態のトラブルシューティング
マルチクラスターエンジン Operator をインストールするときに、MultiClusterEngine
が Installing
フェーズのままであるか、複数の Pod が Pending
ステータスを維持します。
1.9.5.1. 現象: Pending 状態で止まる
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.'
このような場合には、ワーカーノードにはクラスターでの製品実行に十分なリソースがありません。
1.9.5.2. 問題の解決: ワーカーノードのサイズの調整
この問題が発生した場合は、大規模なワーカーノードまたは複数のワーカーノードでクラスターを更新する必要があります。クラスターのサイジングのガイドラインについては、クラスターのサイジング を参照してください。
1.9.6. 再インストールに失敗する場合のトラブルシューティング
マルチクラスターエンジン Operator を再インストールすると、Pod が起動しません。
1.9.6.1. 現象: 再インストールの失敗
マルチクラスターエンジン Operator をインストールした後に Pod が起動しない場合は、マルチクラスターエンジン Operator の以前のインストールからの項目が、アンインストール時に正しく削除されなかったことが原因であることが多いです。
Pod はこのような場合に、インストールプロセスの完了後に起動しません。
1.9.6.2. 問題の解決: 再インストールの失敗
この問題が発生した場合は、以下の手順を実行します。
- アンインストール の手順に従い、現在のコンポーネントを削除し、アンインストールプロセスを実行します。
- Helm のインストール の手順に従い、Helm CLI バイナリーバージョン 3.2.0 以降をインストールします。
-
oc
コマンドが実行できるように、Red Hat OpenShift Container Platform CLI が設定されていることを確認してください。oc
コマンドの設定方法の詳細は、OpenShift Container Platform ドキュメントの OpenShift CLI スタートガイド を参照してください。 以下のスクリプトをファイルにコピーします。
#!/bin/bash MCE_NAMESPACE=<namespace> oc delete multiclusterengine --all oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io oc delete crd discoveredclusters.discovery.open-cluster-management.io discoveryconfigs.discovery.open-cluster-management.io oc delete mutatingwebhookconfiguration ocm-mutating-webhook managedclustermutators.admission.cluster.open-cluster-management.io oc delete validatingwebhookconfiguration ocm-validating-webhook oc delete ns $MCE_NAMESPACE
スクリプト内の
<namespace>
をマルチクラスターエンジン Operator がインストールされた namespace の名前に置き換えます。namespace が消去され削除されるため、正しい namespace を指定するようにしてください。- スクリプトを実行して、アーティファクトを以前のインストールから削除します。
- インストールを実行します。ネットワーク接続時のオンラインインストール を参照してください。
1.9.7. オフラインクラスターのトラブルシューティング
クラスターのステータスがオフラインと表示される一般的な原因がいくつかあります。
1.9.7.1. 現象: クラスターのステータスがオフライン状態である
クラスターの作成手順を完了したら、Red Hat Advanced Cluster Management コンソールからアクセスできず、クラスターのステータスが offline
と表示されます。
1.9.7.2. 問題の解決: クラスターのステータスがオフライン状態になっている
マネージドクラスターが利用可能かどうかを確認します。これは、Red Hat Advanced Cluster Management コンソールの Clusters エリアで確認できます。
利用不可の場合は、マネージドクラスターの再起動を試行します。
マネージドクラスターのステータスがオフラインのままの場合は、以下の手順を実行します。
-
ハブクラスターで
oc get managedcluster <cluster_name> -o yaml
コマンドを実行します。<cluster_name>
は、クラスター名に置き換えます。 -
status.conditions
セクションを見つけます。 -
type: ManagedClusterConditionAvailable
のメッセージを確認して、問題を解決します。
-
ハブクラスターで
1.9.8. マネージドクラスターのインポート失敗に関するトラブルシューティング
クラスターのインポートに失敗した場合は、クラスターのインポートが失敗した理由を判別するためにいくつかの手順を実行できます。
1.9.8.1. 現象: インポートされたクラスターを利用できない
クラスターをインポートする手順を完了すると、コンソールからクラスターにアクセスできなくなります。
1.9.8.2. 問題の解決: インポートされたクラスターが利用できない
インポートの試行後にインポートクラスターが利用できない場合には、いくつかの理由があります。クラスターのインポートに失敗した場合は、インポートに失敗した理由が見つかるまで以下の手順を実行します。
ハブクラスターで、次のコマンドを実行して、インポートコントローラーが実行していることを確認します。
kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2
実行中の Pod が 2 つ表示されるはずです。Pod のいずれかが実行されていない場合には、以下のコマンドを実行してログを表示して理由を判別します。
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1
ハブクラスターで次のコマンドを実行して、マネージドクラスターのインポートシークレットがインポートコントローラーによって正常に生成されたかどうかを確認します。
kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import
インポートシークレットが存在しない場合は、以下のコマンドを実行してインポートコントローラーのログエントリーを表示し、作成されていない理由を判断します。
kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller
ハブクラスターで、マネージドクラスターが
local-cluster
であるか、Hive によってプロビジョニングされているか、自動インポートシークレットがある場合は、次のコマンドを実行して、マネージドクラスターのインポートステータスを確認します。kubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceeded
ManagedClusterImportSucceeded
がtrue
でない場合には、コマンドの結果で失敗の理由が表示されます。- マネージドクラスターの Klusterlet ステータスが degraded 状態でないかを確認します。Klusterlet のパフォーマンスが低下した理由を特定するには、degraded 状態にある Klusterlet のトラブルシューティング を参照してください。
1.9.9. クラスターの再インポートが不明な権限エラーで失敗する
マネージドクラスターをマルチクラスターエンジン Operator に再インポートするときに問題が発生した場合は、手順に従って問題をトラブルシューティングします。
1.9.9.1. 現象: クラスターの再インポートが不明な権限エラーで失敗する
マルチクラスターエンジン Operator を使用して OpenShift Container Platform クラスターをプロビジョニングした後に、API サーバー証明書を変更したり、OpenShift Container Platform クラスターに追加したりすると、x509: certificate signed by unknown authority
エラーでクラスターの再インポートが失敗する場合があります。
1.9.9.2. 問題の特定: クラスターの再インポートが不明な権限エラーで失敗する
マネージドクラスターの再インポートに失敗した後、次のコマンドを実行して、マルチクラスターエンジン 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 サーバー証明書が変更されたかどうかを確認するには、次の手順を実行します。
次のコマンドを実行して、
your-managed-cluster-name
をマネージドクラスターの名前に置き換えて、マネージドクラスターの名前を指定します。cluster_name=<your-managed-cluster-name>
次のコマンドを実行して、マネージドクラスター
kubeconfig
シークレット名を取得します。kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
次のコマンドを実行して、
kubeconfig
を新しいファイルにエクスポートします。oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.old
export KUBECONFIG=kubeconfig.old
次のコマンドを実行して、
kubeconfig
を使用してマネージドクラスターから namespace を取得します。oc get ns
次のメッセージのようなエラーが表示された場合は、クラスター API サーバーの証明書が変更になっており、kubeconfig
ファイルが無効です。
Unable to connect to the server: x509: certificate signed by unknown authority
1.9.9.3. 問題の解決: クラスターの再インポートが不明な権限エラーで失敗する
マネージドクラスター管理者は、マネージドクラスター用に新しい有効な kubeconfig
ファイルを作成する必要があります。
新しい kubeconfig
を作成したら、次の手順を実行して、マネージドクラスターの新しい kubeconfig
を更新します。
次のコマンドを実行して、
kubeconfig
ファイルパスとクラスター名を設定します。<path_to_kubeconfig>
を新しいkubeconfig
ファイルへのパスに置き換えます。<managed_cluster_name>
をマネージドクラスターの名前に置き換えます。cluster_name=<managed_cluster_name> kubeconfig_file=<path_to_kubeconfig>
次のコマンドを実行して、新しい
kubeconfig
をエンコードします。kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)
注記: macOS では、代わりに次のコマンドを実行します。
kubeconfig=$(cat ${kubeconfig_file} | base64)
次のコマンドを実行して、JSON パッチ
kubeconfig
を定義します。kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"
次のコマンドを実行して、マネージドクラスターから管理者の
kubeconfig
シークレット名を取得します。kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
次のコマンドを実行して、管理者の
kubeconfig
シークレットに新しいkubeconfig
を適用します。oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"
1.9.10. Pending Import ステータスのクラスターのトラブルシューティング
クラスターのコンソールで継続的に Pending import と表示される場合は、以下の手順を実行して問題をトラブルシューティングしてください。
1.9.10.1. 現象: ステータスが Pending Import クラスター
Red Hat Advanced Cluster Management コンソールを使用してクラスターをインポートした後に、コンソールで、クラスターのステータスが Pending import と表示されます。
1.9.10.2. 問題の特定: ステータスが Pending Import クラスター
マネージドクラスターで以下のコマンドを実行し、問題のある Kubernetes Pod 名を表示します。
kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent
マネージドクラスターで以下のコマンドを実行し、エラーのログエントリーを探します。
kubectl logs <registration_agent_pod> -n open-cluster-management-agent
registration_agent_pod は、手順 1 で特定した Pod 名に置き換えます。
-
返された結果に、ネットワーク接続の問題があったと示すテキストがないかどうかを検索します。たとえば、
no such host
です。
1.9.10.3. 問題の解決: ステータスが Pending Import クラスター
ハブクラスターで以下のコマンドを実行して、問題のあるポート番号を取得します。
oc get infrastructure cluster -o yaml | grep apiServerURL
マネージドクラスターのホスト名が解決でき、ホストおよびポートへの送信接続が機能していることを確認します。
マネージドクラスターで通信が確立できない場合は、クラスターのインポートが完了していません。マネージドクラスターのクラスターステータスは、Pending import になります。
1.9.11. 証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング
カスタムの apiserver
証明書のインストールはサポートされますが、証明書情報を変更する前にインポートされたクラスターの 1 つまたは複数でステータスが offline
になる可能性があります。
1.9.11.1. 現象: 証明書の変更後にクラスターがオフラインになる
証明書シークレットを更新する手順を完了すると、オンラインだった 1 つ以上のクラスターがコンソールに offline
ステータスを表示するようになります。
1.9.11.2. 問題の特定: 証明書の変更後にクラスターがオフラインになる
カスタムの 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
1.9.11.3. 問題の解決: 証明書の変更後にクラスターがオフラインになる
マネージドクラスターが local-cluster
の場合、またはマルチクラスターエンジン Operator でマネージドクラスターが作成された場合に、マネージドクラスターを再インポートするには 10 分以上待つ必要があります。
マネージドクラスターをすぐに再インポートするには、ハブクラスター上のマネージドクラスターのインポートシークレットを削除し、マルチクラスターエンジン Operator を使用して復元します。以下のコマンドを実行します。
oc delete secret -n <cluster_name> <cluster_name>-import
<cluster_name>
は、復元するマネージドクラスターの名前に置き換えます。
マルチクラスターエンジン Operator を使用してインポートされたマネージドクラスターを再インポートする場合は、次の手順を実行して、マネージドクラスターを復元します。
ハブクラスターで、次のコマンドを実行してマネージドクラスターのインポートシークレットを再作成します。
oc delete secret -n <cluster_name> <cluster_name>-import
<cluster_name>
を、インポートするマネージドクラスターの名前に置き換えます。ハブクラスターで、次のコマンドを実行して、マネージドクラスターのインポートシークレットを YAML ファイルに公開します。
oc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode > import.yaml
<cluster_name>
を、インポートするマネージドクラスターの名前に置き換えます。マネージドクラスターで、次のコマンドを実行して
import.yaml
ファイルを適用します。oc apply -f import.yaml
注記: 前の手順では、マネージドクラスターがハブクラスターから切り離されません。この手順により、必要なマニフェストがマネージドクラスターの現在の設定 (新しい証明書情報を含む) で更新されます。
1.9.12. クラスターのステータスが offline から available に変わる場合のトラブルシューティング
マネージドクラスターのステータスは、環境またはクラスターを手動で変更することなく、offline
と available
との間で切り替わります。
1.9.12.1. 現象: クラスターのステータスが offline から available に変わる
マネージドクラスターからハブクラスターへのネットワーク接続が不安定な場合に、マネージドクラスターのステータスが offline
と available
との間で順に切り替わると、ハブクラスターにより報告されます。
1.9.12.2. 問題の解決: クラスターのステータスが offline から available に変わる
この問題を解決するには、以下の手順を実行します。
次のコマンドを入力して、ハブクラスターで
ManagedCluster
の仕様を編集します。oc edit managedcluster <cluster-name>
cluster-name は、マネージドクラスターの名前に置き換えます。
-
ManagedCluster
仕様のleaseDurationSeconds
の値を増やします。デフォルト値は 5 分ですが、ネットワークの問題がある状態で接続を維持するには十分でない場合があります。リースの時間を長く指定します。たとえば、設定を 20 分に増やします。
1.9.13. VMware vSphere でのクラスター作成のトラブルシューティング
VMware vSphere で Red Hat OpenShift Container Platform クラスターを作成する時に問題が発生した場合は、以下のトラブルシューティング情報を参照して、この情報のいずれかが問題に対応しているかどうかを確認します。
注記: VMware vSphere でクラスター作成プロセスが失敗した場合に、リンクが有効にならずログが表示されないことがあります。上記が発生する場合は、hive-controllers
Pod のログを確認して問題を特定できます。hive-controllers
ログは hive
namespace にあります。
1.9.13.1. 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
1.9.13.1.1. 現象: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書 IP SAN エラーを示すエラーメッセージでクラスターに問題が発生します。
1.9.13.1.2. 問題の特定: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs" time="2020-08-07T15:27:55Z" level=error
1.9.13.1.3. 問題の解決: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
認証情報の IP アドレスではなく VMware vCenter サーバー完全修飾ホスト名を使用します。また、VMware vCenter CA 証明書を更新して、IP SAN を組み込むこともできます。
1.9.13.2. 不明な証明局のエラーでマネージドクラスターの作成に失敗する
1.9.13.2.1. 現象: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書が不明な証明局により署名されているのでクラスターに問題が発生します。
1.9.13.2.2. 問題の特定: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
1.9.13.2.3. 問題の解決: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
認証情報の作成時に認証局の正しい証明書が入力されていることを確認します。
1.9.13.3. 証明書の期限切れでマネージドクラスターの作成に失敗する
1.9.13.3.1. 現象: 証明書の期限切れでマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書の期限が切れているか、有効にしていないため、クラスターに問題が発生します。
1.9.13.3.2. 問題の特定: 証明書の期限切れでマネージドクラスターの作成に失敗する
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
x509: certificate has expired or is not yet valid
1.9.13.3.3. 問題の解決: 証明書の期限切れでマネージドクラスターの作成に失敗する
ESXi ホストの時間が同期されていることを確認します。
1.9.13.4. タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する
1.9.13.4.1. 現象: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、タグ付けの使用に十分な権限がないためクラスターに問題が発生します。
1.9.13.4.2. 問題の特定: タグ付けの権限が十分にないためにマネージドクラスターの作成に失敗する
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
time="2020-08-07T19:41:58Z" level=debug msg="vsphere_tag_category.category: Creating..." time="2020-08-07T19:41:58Z" level=error time="2020-08-07T19:41:58Z" level=error msg="Error: could not create category: POST https://vspherehost.com/rest/com/vmware/cis/tagging/category: 403 Forbidden" time="2020-08-07T19:41:58Z" level=error time="2020-08-07T19:41:58Z" level=error msg=" on ../tmp/openshift-install-436877649/main.tf line 54, in resource \"vsphere_tag_category\" \"category\":" time="2020-08-07T19:41:58Z" level=error msg=" 54: resource \"vsphere_tag_category\" \"category\" {"
1.9.13.4.3. 問題の解決: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する
VMware vCenter が必要とするアカウントの権限が正しいことを確認します。詳細は、インストール時に削除されたイメージレジストリー を参照してください。
1.9.13.5. 無効な dnsVIP でマネージドクラスターの作成に失敗する
1.9.13.5.1. 現象: 無効な dnsVIP でマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、dnsVIP が無効であるため、クラスターに問題が発生します。
1.9.13.5.2. 問題の特定: 無効な dnsVIP でマネージドクラスターの作成に失敗する
VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform リリースイメージを使用しているためです。
failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP
1.9.13.5.3. 問題の解決: 無効な dnsVIP でマネージドクラスターの作成に失敗する
VMware インストーラーでプロビジョニングされるインフラストラクチャーをサポートする OpenShift Container Platform で、新しいバージョンのリリースイメージを選択します。
1.9.13.6. ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
1.9.13.6.1. 現象: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、間違ったネットワークタイプが指定されているため、クラスターに問題が発生します。
1.9.13.6.2. 問題の特定: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform イメージを使用しているためです。
time="2020-08-11T14:31:38-04:00" level=debug msg="vsphereprivate_import_ova.import: Creating..." time="2020-08-11T14:31:39-04:00" level=error time="2020-08-11T14:31:39-04:00" level=error msg="Error: rpc error: code = Unavailable desc = transport is closing" time="2020-08-11T14:31:39-04:00" level=error time="2020-08-11T14:31:39-04:00" level=error time="2020-08-11T14:31:39-04:00" level=fatal msg="failed to fetch Cluster: failed to generate asset \"Cluster\": failed to create cluster: failed to apply Terraform: failed to complete the change"
1.9.13.6.3. 問題の解決: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
指定の VMware クラスターに対して有効な VMware vSphere ネットワークタイプを選択します。
1.9.13.7. ディスクの変更処理のエラーでマネージドクラスターの作成に失敗する
1.9.13.7.1. 現象: ディスク変更の処理中にエラーが発生するため、VMware vSphere マネージドクラスターの追加が失敗する
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、ディスク変更処理時にエラーによりクラスターに問題が発生します。
1.9.13.7.2. 問題の特定: ディスク変更処理エラーのため、VMware vSphere マネージドクラスターの追加に失敗する
以下のようなメッセージがログに表示されます。
ERROR ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)
1.9.13.7.3. 問題の解決: ディスク変更の処理中にエラーが発生したため、VMware vSphere マネージドクラスターの追加に失敗する
VMware vSphere クライアントを使用してユーザーに プロファイル駆動型のストレージ権限 の 全権限 を割り当てます。
1.9.14. ステータスが Pending または Failed のクラスターのコンソールでのトラブルシューティング
作成してたクラスターのステータスがコンソールで Pending または Failed と表示されている場合は、以下の手順を実行して問題のトラブルシューティングを実行します。
1.9.14.1. 現象: コンソールでステータスが Pending または Failed のクラスターのトラブルシューティング
コンソールを使用して新しいクラスターを作成した後、クラスターは Pending のステータスを超えて進行しないか、Failed ステータスを表示します。
1.9.14.2. 問題の特定: コンソールでステータスが Pending または Failed のクラスター
クラスターのステータスが Failed と表示される場合は、クラスターの詳細ページに移動して、提供されたログへのリンクに進みます。ログが見つからない場合や、クラスターのステータスが Pending と表示される場合は、以下の手順を実行してログを確認します。
手順 1
ハブクラスターで以下のコマンドを実行し、新規クラスターの namespace に作成した Kubernetes Pod の名前を表示します。
oc get pod -n <new_cluster_name>
new_cluster_name
は、作成したクラスター名に置き換えます。名前に
provision
の文字列が含まれる Pod が表示されていない場合は、手順 2 に進みます。タイトルにprovision
が含まれる Pod があった場合は、ハブクラスターで以下のコマンドを実行して、その Pod のログを表示します。oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive
new_cluster_name_provision_pod_name
は、作成したクラスター名の後にprovision
が含まれる Pod 名を指定するように置き換えます。- ログでエラーを検索してください。この問題の原因が解明する場合があります。
手順 2
名前に
provision
が含まれる Pod がない場合は、問題がプロセスの初期段階で発生しています。ログを表示するには、以下の手順を実行します。ハブクラスターで以下のコマンドを実行してください。
oc describe clusterdeployments -n <new_cluster_name>
new_cluster_name
は、作成したクラスター名に置き換えます。クラスターのインストールログの詳細は、Red Hat OpenShift ドキュメントの インストールログの収集 を参照してください。- リソースの Status.Conditions.Message と Status.Conditions.Reason のエントリーに問題に関する追加の情報があるかどうかを確認します。
1.9.14.3. 問題の解決: コンソールでステータスが Pending または Failed のクラスター
ログでエラーを特定した後に、エラーの解決方法を決定してから、クラスターを破棄して、作り直してください。
以下の例では、サポート対象外のゾーンを選択している可能性を示すログエラーと、解決に必要なアクションが提示されています。
No subnets provided for zones
クラスターの作成時に、サポートされていないリージョンにあるゾーンを 1 つ以上選択しています。問題解決用にクラスターを再作成する時に、以下のアクションの 1 つを実行します。
- リージョン内の異なるゾーンを選択します。
- 他のゾーンをリストしている場合は、サポートを提供しないゾーンを省略します。
- お使いのクラスターに、別のリージョンを選択します。
ログから問題を特定した後に、クラスターを破棄し、再作成します。
クラスター作成の詳細は、クラスター作成の概要 を参照してください。
1.9.15. OpenShift Container Platform バージョン 3.11 クラスターのインポートの失敗時のトラブルシューティング
1.9.15.1. 現象: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する
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|...
1.9.15.2. 問題の特定: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する
この問題は多くの場合、インストールされている kubectl
コマンドラインツールのバージョンが 1.11 以前であるために発生します。以下のコマンドを実行して、実行中の kubectl
コマンドラインツールのバージョンを表示します。
kubectl version
返されたデータがバージョンが 1.11 以前の場合は、問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する に記載される修正のいずれかを実行します。
1.9.15.3. 問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する
この問題は、以下のいずれかの手順を実行して解決できます。
最新バージョンの
kubectl
コマンドラインツールをインストールします。-
kubectl
ツールの最新バージョンを、Kubernetes ドキュメントの kubectl のインストールとセットアップ からダウンロードします。 -
kubectl
ツールのアップグレード後にクラスターを再度インポートします。
-
import コマンドが含まれるファイルを実行します。
- CLI を使用したマネージドクラスターのインポート の手順を開始します。
-
クラスターの import コマンドを作成する場合には、この import コマンドを
import.yaml
という名前の YAML ファイルにコピーします。 以下のコマンドを実行して、ファイルからクラスターを再度インポートします。
oc apply -f import.yaml
1.9.16. degraded 状態にある Klusterlet のトラブルシューティング
Klusterlet の状態が Degraded の場合は、マネージドクラスターの Klusterlet エージェントの状態を診断しやすくなります。Klusterlet の状態が Degraded になると、マネージドクラスターの Klusterlet エージェントで発生する可能性のあるエラーに対応する必要があります。Klusterlet の degraded の状態が True
に設定されている場合は、以下の情報を参照します。
1.9.16.1. 現象: Klusterlet の状態が degraded である
マネージドクラスターで Klusterlet をデプロイした後に、KlusterletRegistrationDegraded
または KlusterletWorkDegraded
の状態が True と表示されます。
1.9.16.2. 問題の特定: Klusterlet の状態が degraded である
マネージドクラスターで以下のコマンドを実行して、Klusterlet のステータスを表示します
kubectl get klusterlets klusterlet -oyaml
-
KlusterletRegistrationDegraded
またはKlusterletWorkDegraded
をチェックして、状態がTrue
に設定されいるかどうかを確認します。記載されている Degraded の状態は、問題の解決 に進みます。
1.9.16.3. 問題の解決: Klusterlet の状態が degraded である
ステータスが Degraded のリストおよびこれらの問題の解決方法を参照してください。
-
KlusterletRegistrationDegraded
の状態が True で、この状態の理由が BootStrapSecretMissing の場合は、open-cluster-management-agent
namespace にブートストラップのシークレットを作成する必要があります。 -
KlusterletRegistrationDegraded
の状態が True と表示され、状態の理由が BootstrapSecretError または BootstrapSecretUnauthorized の場合は、現在のブートストラップシークレットが無効です。現在のブートストラップシークレットを削除して、open-cluster-management-agent
namespace で有効なブートストラップシークレットをもう一度作成します。 -
KlusterletRegistrationDegraded
およびKlusterletWorkDegraded
が True と表示され、状態の理由が HubKubeConfigSecretMissing の場合は、Klusterlet を削除して作成し直します。 -
KlusterletRegistrationDegraded
およびKlusterletWorkDegraded
が True と表示され、状態の理由が ClusterNameMissing、KubeConfigMissing、HubConfigSecretError、または HubConfigSecretUnauthorized の場合は、open-cluster-management-agent
namespace からハブクラスターの kubeconfig シークレットを削除します。登録エージェントは再度ブートストラップして、新しいハブクラスターの kubeconfig シークレットを取得します。 -
KlusterletRegistrationDegraded
が True と表示され、状態の理由が GetRegistrationDeploymentFailed または UnavailableRegistrationPod の場合は、状態のメッセージを確認して、問題の詳細を取得して解決してみてください。 -
KlusterletWorkDegraded
が True と表示され、状態の理由が GetWorkDeploymentFailed または UnavailableWorkPod の場合は、状態のメッセージを確認して、問題の詳細を取得し、解決してみてください。
1.9.17. クラスターの削除後も namespace が残る
マネージドクラスターを削除すると、通常 namespace はクラスターの削除プロセスの一部として削除されます。まれに namespace は一部のアーティファクトが含まれた状態で残る場合があります。このような場合は、namespace を手動で削除する必要があります。
1.9.17.1. 現象: クラスターの削除後も namespace が残る
マネージドクラスターの削除後に namespace が削除されません。
1.9.17.2. 問題の解決: クラスターの削除後も namespace が残る
namespace を手作業で削除するには、以下の手順を実行します。
次のコマンドを実行して、<cluster_name> namespace に残っているリソースのリストを作成します。
oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks'|^clusteroauths' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>
cluster_name
は、削除を試みたクラスターの namespace 名に置き換えます。以下のコマンドを入力してリストを編集し、ステータスが
Delete
ではないリストから特定したリソースを削除します。oc edit <resource_kind> <resource_name> -n <namespace>
resource_kind
は、リソースの種類に置き換えます。resource_name
は、リソース名に置き換えます。namespace
は、リソースの namespace に置き換えます。-
メタデータで
finalizer
属性の場所を特定します。 -
vi エディターの
dd
コマンドを使用して、Kubernetes 以外のファイナライザーを削除します。 -
:wq
コマンドを入力し、リストを保存してvi
エディターを終了します。 以下のコマンドを入力して namespace を削除します。
oc delete ns <cluster-name>
cluster-name
を、削除する namespace の名前に置き換えます。
1.9.18. クラスターのインポート時の auto-import-secret-exists エラー
クラスターのインポートは、auto import secret exists というエラーメッセージで失敗します。
1.9.18.1. 現象: クラスターのインポート時の Auto-import-secret-exists エラー
管理用のハイブクラスターをインポートすると、auto-import-secret already exists
というエラーが表示されます。
1.9.18.2. 問題の解決: クラスターのインポート時の Auto-import-secret-exists エラー
この問題は、以前に管理されていたクラスターをインポートしようとすると発生します。これが生じると、クラスターを再インポートしようとすると、シークレットは競合します。
この問題を回避するには、以下の手順を実行します。
既存の
auto-import-secret
を手動で削除するには、ハブクラスターで以下のコマンドを実行します。oc delete secret auto-import-secret -n <cluster-namespace>
namespace
は、お使いのクラスターの namespace に置き換えます。- クラスターインポートの概要 の手順を使用して、クラスターを再度インポートします。
1.9.19. Troubleshooting missing PlacementDecision after creating Placement
Placement
の作成後に PlacementDescision
が生成されない場合は、手順に従って問題をトラブルシューティングしてください。
1.9.19.1. 事象: Placement の作成後に PlacementDecision が見つからない
Placement
を作成した後、PlacementDescision
は自動的に生成されません。
1.9.19.2. 問題の解決: Placement の作成後に PlacementDecision が見つからない
この問題を解決するには、以下の手順を実行します。
次のコマンドを実行して
Placement
条件を確認します。kubectl describe placement <placement-name>
placement-name
をPlacement
の名前に置き換えます。出力は次の例のような内容になります。
Name: demo-placement Namespace: default Labels: <none> Annotations: <none> API Version: cluster.open-cluster-management.io/v1beta1 Kind: Placement Status: Conditions: Last Transition Time: 2022-09-30T07:39:45Z Message: Placement configurations check pass Reason: Succeedconfigured Status: False Type: PlacementMisconfigured Last Transition Time: 2022-09-30T07:39:45Z Message: No valid ManagedClusterSetBindings found in placement namespace Reason: NoManagedClusterSetBindings Status: False Type: PlacementSatisfied Number Of Selected Clusters: 0
PlacementMisconfigured
およびPlacementSatisfied
のStatus
の出力を確認します。-
PlacementMisconfigured
Status
が true の場合、Placement
に設定エラーがあります。設定エラーの詳細とその解決方法については、含まれているメッセージを確認してください。 -
PlacementSatisfied
Status
が false の場合、Placement
を満たすマネージドクラスターはありません。詳細とエラーの解決方法については、含まれているメッセージを確認してください。前の例では、placement namespace にManagedClusterSetBindings
が見つかりませんでした。
-
Events
で各クラスターのスコアを確認して、スコアの低い一部のクラスターが選択されていない理由を確認できます。出力は次の例のような内容になります。Name: demo-placement Namespace: default Labels: <none> Annotations: <none> API Version: cluster.open-cluster-management.io/v1beta1 Kind: Placement Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal DecisionCreate 2m10s placementController Decision demo-placement-decision-1 is created with placement demo-placement in namespace default Normal DecisionUpdate 2m10s placementController Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default Normal ScoreUpdate 2m10s placementController cluster1:0 cluster2:100 cluster3:200 Normal DecisionUpdate 3s placementController Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default Normal ScoreUpdate 3s placementController cluster1:200 cluster2:145 cluster3:189 cluster4:200
注記: 配置コントローラーはスコアを割り当て、フィルター処理された
ManagedCluster
ごとにイベントを生成します。クラスタースコアが変化すると、配置コントローラーは新しいイベントを生成します。
1.9.20. Dell ハードウェアにおけるベアメタルホストの検出エラーのトラブルシューティング
Dell ハードウェアでベアメタルホストの検出が失敗した場合、Integrated Dell Remote Access Controller (iDRAC) が不明な認証局からの証明書を許可しないように設定されている可能性があります。
1.9.20.1. 現象: Dell ハードウェアでのベアメタルホストの検出エラー
ベースボード管理コントローラーを使用してベアメタルホストを検出する手順を完了すると、次のようなエラーメッセージが表示されます。
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"} ]
1.9.20.2. 問題の解決: Dell ハードウェアでのベアメタルホストの検出の失敗
iDRAC は、不明な認証局からの証明書を受け入れないように設定されています。
この問題を回避するには、次の手順を実行して、ホスト iDRAC のベースボード管理コントローラーで証明書の検証を無効にします。
- iDRAC コンソールで、Configuration > Virtual media > Remote file share に移動します。
-
Expired or invalid certificate action の値を
Yes
に変更します。
1.9.21. 最小限の ISO の起動失敗に関するトラブルシューティング
最小限の ISO を起動しようとすると問題が発生する可能性があります。
1.9.21.1. 現象: 最小限の ISO が起動に失敗する
ブート画面には、ホストがルートファイルシステムイメージのダウンロードに失敗したことが示されます。
1.9.21.2. 問題の解決: 最小限の ISO が起動に失敗する
問題のトラブルシューティング方法は、OpenShift Container Platform の Assisted Installer ドキュメントの 最小限の ISO の起動失敗に関するトラブルシューティング を参照してください。
1.9.22. Red Hat OpenShift Virtualization 上のホステッドクラスターのトラブルシューティング
Red Hat OpenShift Virtualization でホストされたクラスターのトラブルシューティングを行う場合は、トップレベルの HostedCluster
リソースと NodePool
リソースから始めて、根本原因が見つかるまでスタックを下位に向かって作業します。以下の手順は、一般的な問題の根本原因を検出するのに役立ちます。
1.9.22.1. 現象: HostedCluster リソースが部分的な状態でスタックする
HostedCluster
リソースが保留中であるため、Hosted Control Plane が完全にオンラインになりません。
1.9.22.1.1. 問題の特定: 前提条件、リソースの状態、ノードと Operator のステータスを確認します。
- Red Hat OpenShift Virtualization 上のホステッドクラスターのすべての前提条件を満たしていることを確認します。
-
進行を妨げる検証エラーがないか、
HostedCluster
リソースとNodePool
リソースの状態を表示します。 ホステッドクラスターの
kubeconfig
ファイルを使用して、ホステッドクラスターのステータスを検査します。-
oc get clusteroperators
コマンドの出力を表示して、保留中のクラスター Operator を表示します。 -
oc get nodes
コマンドの出力を表示して、ワーカーノードの準備ができていることを確認します。
-
1.9.22.2. 現象: ワーカーノードが登録されない
Hosted Control Plane にはワーカーノードが登録されていないため、Hosted Control Plane は完全にオンラインになりません。
1.9.22.2.1. 問題の特定: Hosted Control Plane のさまざまな部分のステータスを確認します。
-
HostedCluster
とNodePool
の障害の状態を表示して、問題の内容を示します。 次のコマンドを入力して、
NodePool
リソースの KubeVirt ワーカーノード仮想マシン (VM) のステータスを表示します。oc get vm -n <namespace>
仮想マシンがプロビジョニング状態でスタックしている場合は、次のコマンドを入力して、仮想マシン namespace 内の CDI インポート Pod を表示し、インポーター Pod が完了していない理由を調べます。
oc get pods -n <namespace> | grep "import"
仮想マシンが開始状態でスタックしている場合は、次のコマンドを入力して、virt-launcher Pod のステータスを表示します。
oc get pods -n <namespace> -l kubevirt.io=virt-launcher
virt-launcher Pod が保留状態にある場合は、Pod がスケジュールされていない理由を調査してください。たとえば、virt-launcher Pod の実行に必要なリソースが十分存在しない可能性があります。
- 仮想マシンが実行されていてもワーカーノードとして登録されていない場合は、Web コンソールを使用して、影響を受ける仮想マシンの 1 つへの VNC アクセスを取得します。VNC 出力は ignition 設定が適用されたかどうかを示します。仮想マシンが起動時に Hosted Control Plane Ignition サーバーにアクセスできない場合、仮想マシンは正しくプロビジョニングできません。
- Ignition 設定が適用されても、仮想マシンがノードとして登録されていない場合は、問題の特定: 仮想マシンコンソールログへのアクセス で、起動時に仮想マシンコンソールログにアクセスする方法を確認してください。
1.9.22.3. 現象: ワーカーノードが NotReady 状態でスタックする
クラスターの作成中、ネットワークスタックがロールアウトされる間、ノードは一時的に NotReady
状態になります。プロセスのこの部分は正常です。ただし、プロセスのこの部分に 15 分以上かかる場合は、問題が発生している可能性があります。
1.9.22.3.1. 問題の特定: ノードオブジェクトと Pod を調査する
次のコマンドを入力して、ノードオブジェクトの状態を表示し、ノードの準備ができていない理由を特定します。
oc get nodes -o yaml
次のコマンドを入力して、クラスター内で障害が発生している Pod を探します。
oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded
1.9.22.4. 現象: Ingress およびコンソールクラスター Operator がオンラインにならない
Ingress およびコンソールクラスター Operator がオンラインではないため、Hosted Control Plane は完全にはオンラインになりません。
1.9.22.4.1. 問題の特定: ワイルドカード DNS ルートとロードバランサーを確認する
クラスターがデフォルトの Ingress 動作を使用する場合は、次のコマンドを入力して、仮想マシン (VM) がホストされている OpenShift Container Platform クラスターでワイルドカード DNS ルートが有効になっていることを確認します。
oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
Hosted Control Plane にカスタムベースドメインを使用する場合は、次の手順を実行します。
- ロードバランサーが仮想マシン Pod を正しくターゲットにしていることを確認してください。
- ワイルドカード DNS エントリーがロードバランサー IP をターゲットにしていることを確認してください。
1.9.22.5. 現象: ホステッドクラスターのロードバランサーサービスが利用できない
ロードバランサーサービスは利用できないため、Hosted Control Plane は完全にオンラインになりません。
1.9.22.5.1. 問題の特定: イベント、詳細、kccm Pod を確認します。
- ホステッドクラスター内のロードバランサーサービスに関連付けられたイベントおよび詳細を探します。
デフォルトでは、ホステッドクラスターのロードバランサーは、Hosted Control Plane の namespace 内の kubevirt-cloud-controller-manager によって処理されます。kccm Pod がオンラインであることを確認し、そのログにエラーや警告がないか確認してください。Hosted Control Plane namespace で kccm Pod を特定するには、次のコマンドを入力します。
oc get pods -n <hosted-control-plane-namespace> -l app=cloud-controller-manager
1.9.22.6. 現象: ホステッドクラスター PVC が使用できない
ホステッドクラスターの永続ボリューム要求 (PVC) が使用できないため、Hosted Control Plane は完全にはオンラインになりません。
1.9.22.6.1. 問題の特定:PVC イベントおよび詳細、およびコンポーネントログを確認します。
- PVC に関連するイベントと詳細を探して、どのエラーが発生しているかを把握します。
PVC が Pod に割り当てられていない場合、ホステッドクラスター内の kubevirt-csi-node daemonset コンポーネントのログを表示して問題をさらに調査します。各ノードの kubevirt-csi-node Pod を識別するには、次のコマンドを入力します。
oc get pods -n openshift-cluster-csi-drivers -o wide -l app=kubevirt-csi-driver
PVC が永続ボリューム (PV) にバインドできない場合は、Hosted Control Plane の namespace 内の kubevirt-csi-controller コンポーネントのログを表示します。Hosted Control Plane の namespace 内の kubevirt-csi-controller Pod を識別するには、次のコマンドを入力します。
oc get pods -n <hcp namespace> -l app=kubevirt-csi-driver
1.9.22.7. 現象: 仮想マシンノードがクラスターに正しく参加していない。
仮想マシンノードがクラスターに正しく参加していないため、Hosted Control Plane が完全にオンラインになりません。
1.9.22.7.1. 問題の特定: 仮想マシンコンソールログにアクセスします。
仮想マシンコンソールログにアクセスするには、How to get serial console logs for VMs part of OpenShift Virtualization Hosted Control Plane clusters の手順を実行します。
1.9.22.8. トラブルシューティング: 非ベアメタルクラスターを遅延バインディングプールに戻す
BareMetalHosts
なしで遅延バインディングマネージドクラスターを使用している場合は、遅延バインディングクラスターを破棄し、ノードを Discovery ISO に戻すための追加の手動手順を実行する必要があります。
1.9.22.8.1. 現象: 非ベアメタルクラスターを遅延バインディングプールに戻す
BareMetalHosts
のない遅延バインディングマネージドクラスターの場合、クラスター情報を削除しても、すべてのノードが自動的に Discovery ISO に戻されるわけではありません。
1.9.22.8.2. 問題の解決: 非ベアメタルクラスターを遅延バインディングプールに戻す
遅延バインディングを使用する非ベアメタルノードのバインドを解除するには、次の手順を実行します。
- クラスター情報を削除します。詳細は、マネージメントからのクラスターの削除 を参照してください。
- ルートディスクをクリーンアップします。
- Discovery ISO を使用して手動で再起動します。