1.13. トラブルシューティング
トラブルシューティングガイドをご使用の前に oc adm must-gather コマンドを実行して、詳細およびログを収集し、問題のデバッグ手順を行います。詳細は、must-gather コマンドを実行したトラブルシューティング を参照してください。
また、ロールベースのアクセス権限を確認してください。詳細は、multicluster engine Operator のロールベースのアクセス制御 を参照してください。
1.13.1. 文書化されたトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
multicluster engine Operator のトラブルシューティングトピックのリストをご覧ください。
インストール:
インストールタスクに関する主なドキュメントを確認するには、multicluster engine Operator のインストールとアップグレード を参照してください。
クラスター管理:
クラスターの管理に関する主要なドキュメントを表示するには、クラスターライフサイクルの概要 を参照してください。
- トラブルシューティング: 既存のクラスターに Day 2 ノードを追加すると、ユーザーアクションが保留中になり失敗する
- オフラインクラスターのトラブルシューティング
- マネージドクラスターのインポート失敗に関するトラブルシューティング
- クラスターの再インポートが不明な権限エラーで失敗する
- Pending Import ステータスのクラスターのトラブルシューティング
- 証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング
- クラスターのステータスが offline から available に変わる場合のトラブルシューティング
- VMware vSphere でのクラスター作成のトラブルシューティング
- ステータスが Pending または Failed のクラスターのコンソールでのトラブルシューティング
- degraded 状態にある Klusterlet のトラブルシューティング
- クラスターの削除後も namespace が残る
- クラスターのインポート時の auto-import-secret-exists エラー
- Troubleshooting missing PlacementDecision after creating Placement
- Dell ハードウェアにおけるベアメタルホストの検出エラーのトラブルシューティング
- 最小限の ISO の起動失敗に関するトラブルシューティング
- Hosted Control Plane クラスターで Red Hat OpenShift Service on AWS でマネージドクラスターが Unknown になる問題トラブルシューティング
- OpenShift Container Platform バージョンが欠落しているマネージドクラスターのアップグレード試行のトラブルシューティング
- Hive および Assisted Installer クラスターでの認証局更新エラーのトラブルシューティング
-
トラブルシューティング:
open-cluster-management-global-setnamespace が見つかりません
1.13.2. must-gather コマンドを実行したトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
トラブルシューティングを開始するには、問題のデバッグを行う must-gather コマンドを実行する場合のトラブルシューティングシナリオを確認し、このコマンドの使用を開始する手順を参照してください。
必要なアクセス権: クラスター管理者
1.13.2.1. Must-gather のシナリオ リンクのコピーリンクがクリップボードにコピーされました!
シナリオ 1: 文書化されたトラブルシューティング セクションを使用して、問題の解決策がまとめられているかどうかを確認します。このガイドは、製品の主な機能別に設定されています。
このシナリオでは、解決策がこのドキュメントにまとめられているかどうかを、このガイドで確認します。
-
シナリオ 2: 問題の解決策の手順が文書にまとめられていない場合は、
must-gatherコマンドを実行し、その出力を使用して問題をデバッグします。 -
シナリオ 3:
must-gatherコマンドの出力を使用して問題をデバッグできない場合は、出力を Red Hat サポートに共有します。
1.13.2.2. Must-gather の手順 リンクのコピーリンクがクリップボードにコピーされました!
must-gather コマンドの使用を開始するには、以下の手順を参照してください。
-
must-gatherコマンドについて確認し、OpenShift Container Platform の クラスターに関するデータの収集 に必要な前提条件を インストールします。 クラスターにログインします。通常のユースケースでは、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.10 --dest-dir=<directory>
指定したディレクトリーに移動し、以下のレベルに整理されている出力を確認します。
-
ピアレベル 2 つ:
cluster-scoped-resourcesとnamespaceのリソース - それぞれに対するサブレベル: クラスタースコープおよび namespace スコープの両方のリソースに対するカスタムリソース定義の API グループ。
-
それぞれに対する次のレベル:
kindでソートされた YAML ファイル
-
ピアレベル 2 つ:
1.13.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.13.3. トラブルシューティング: 既存のクラスターに Day 2 ノードを追加すると、ユーザーアクションが保留中になり失敗する リンクのコピーリンクがクリップボードにコピーされました!
インストール中に、ゼロタッチプロビジョニング方式またはホストインベントリー作成方式を使用して、multicluster engine for Kubernetes Operator によって作成された既存のクラスターに、ノードを追加したりスケールアウトしたりすることできません。インストールプロセスは、検出フェーズでは正しく機能しますが、インストールフェーズでは失敗します。
ネットワークの設定に失敗しています。統合コンソールのハブクラスターから、Pending のユーザーアクションが表示されます。説明から、再起動ステップで失敗していることがわかります。
インストールするホストで実行されているエージェントは情報を報告できないため、失敗に関するエラーメッセージはあまり正確ではありません。
1.13.3.1. 現象: Day 2 ワーカーのインストールが失敗する リンクのコピーリンクがクリップボードにコピーされました!
検出フェーズの後、ホストは再起動してインストールを続行しますが、ネットワークを設定できません。以下の現象およびメッセージを確認します。
統合コンソールのハブクラスターから、追加ノード上で
Pendingユーザーアクションがないか、Rebootingインジケーターが付いているかどうかを確認します。This host is pending user action. Host timed out when pulling ignition. Check the host console... RebootingRed 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.13.3.2. 問題の解決: ネットワーク設定をマージするノードを再作成します。 リンクのコピーリンクがクリップボードにコピーされました!
インストール中に適切なネットワーク設定を使用するには、次のタスクを実行します。
- ハブクラスターからノードを削除します。
- 同じようにノードをインストールするには、前のプロセスを繰り返します。
次のアノテーションを使用してノードの
BareMetalHostオブジェクトを作成します。"bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"
ノードがインストールを開始します。検出フェーズの後、ノードは既存のクラスター上の変更と初期設定の間でネットワーク設定をマージします。
1.13.4. エージェントプラットフォーム上の Hosted Control Plane クラスター削除失敗のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
エージェントプラットフォーム上の Hosted Control Plane クラスターを破棄すると、通常、すべてのバックエンドリソースが削除されます。マシンリソースが正しく削除されていない場合、クラスターの削除が失敗します。この場合、残りのマシンリソースを手動で削除する必要があります。
1.13.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.13.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.x.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.13.5. インストールステータスがインストールまたは保留中の状態のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
multicluster engine Operator をインストールするときに、MultiClusterEngine が Installing フェーズのままになるか、複数の Pod が Pending ステータスのままになります。
1.13.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.13.5.2. 問題の解決: ワーカーノードのサイズの調整 リンクのコピーリンクがクリップボードにコピーされました!
この問題が発生した場合は、大規模なワーカーノードまたは複数のワーカーノードでクラスターを更新する必要があります。クラスターのサイジングのガイドラインは、クラスターのサイジング を参照してください。
1.13.6. 再インストールに失敗する場合のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
multicluster engine Operator を再インストールすると、Pod が起動しません。
1.13.6.1. 現象: 再インストールの失敗 リンクのコピーリンクがクリップボードにコピーされました!
multicluster engine Operator をインストールした後に Pod が起動しないのは、多くの場合、multicluster engine Operator の以前のインストールからの項目が、アンインストール時に正しく削除されなかったことが原因です。
Pod はこのような場合に、インストールプロセスの完了後に起動しません。
1.13.6.2. 問題の解決: 再インストールの失敗 リンクのコピーリンクがクリップボードにコピーされました!
この問題が発生した場合は、以下の手順を実行します。
- アンインストール の手順に従い、現在のコンポーネントを削除し、アンインストールプロセスを実行します。
-
ocコマンドが実行できるように、Red Hat OpenShift Container Platform CLI が設定されていることを確認してください。ocコマンド の設定方法に関する詳細は、OpenShift Container Platform ドキュメントの OpenShift CLI の使用 方法 を参照してください。 次のスクリプトをファイルにコピーします。スクリプト内の
<namespace>値を、以前に multicluster engine Operator をインストールした namespace の名前に置き換えます。重要: スクリプトを実行すると namespace もクリーンアップされて削除されるため、正しい namespace を指定していることを確認してください。
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- スクリプトを実行します。リソースが見つからないというメッセージが表示されたら、インストールを続行できます。
- インストールを実行します。ネットワーク接続時のオンラインインストール を参照してください。
1.13.7. オフラインクラスターのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
クラスターのステータスがオフラインと表示される一般的な原因がいくつかあります。
1.13.7.1. 現象: クラスターのステータスがオフライン状態である リンクのコピーリンクがクリップボードにコピーされました!
クラスターの作成手順を完了したら、Red Hat Advanced Cluster Management コンソールからアクセスできず、クラスターのステータスが offline と表示されます。
1.13.7.2. 問題の解決: クラスターのステータスがオフライン状態になっている リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターが利用可能かどうかを確認します。これは、Red Hat Advanced Cluster Management コンソールの Clusters エリアで確認できます。
利用不可の場合は、マネージドクラスターの再起動を試行します。
マネージドクラスターのステータスがオフラインのままの場合は、以下の手順を実行します。
-
ハブクラスターで
oc get managedcluster <cluster_name> -o yamlコマンドを実行します。<cluster_name>は、クラスター名に置き換えます。 -
status.conditionsセクションを見つけます。 -
type: ManagedClusterConditionAvailableのメッセージを確認して、問題を解決します。
-
ハブクラスターで
1.13.8. マネージドクラスターのインポート失敗に関するトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインポートに失敗した場合は、クラスターのインポートが失敗した理由を判別するためにいくつかの手順を実行できます。
1.13.8.1. 現象: インポートされたクラスターを利用できない リンクのコピーリンクがクリップボードにコピーされました!
クラスターをインポートする手順を完了すると、コンソールからクラスターにアクセスできなくなります。
1.13.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 ManagedClusterImportSucceededManagedClusterImportSucceededがtrueでない場合には、コマンドの結果で失敗の理由が表示されます。- マネージドクラスターの Klusterlet ステータスが degraded 状態でないかを確認します。Klusterlet のパフォーマンスが低下した理由を特定するには、degraded 状態にある Klusterlet のトラブルシューティング を参照してください。
1.13.9. クラスターの再インポートが不明な権限エラーで失敗する リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターを multicluster engine Operator に再インポートするときに問題が発生した場合は、手順に従って問題をトラブルシューティングします。
1.13.9.1. 現象: クラスターの再インポートが不明な権限エラーで失敗する リンクのコピーリンクがクリップボードにコピーされました!
multicluster engine Operator を使用して OpenShift Container Platform クラスターをプロビジョニングした後に、API サーバー証明書を変更したり、OpenShift Container Platform クラスターに追加したりすると、x509: certificate signed by unknown authority エラーでクラスターの再インポートが失敗する場合があります。
1.13.9.2. 問題の特定: クラスターの再インポートが不明な権限エラーで失敗する リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターの再インポートに失敗した後、次のコマンドを実行して、multicluster engine 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.oldexport KUBECONFIG=kubeconfig.old次のコマンドを実行して、
kubeconfigを使用してマネージドクラスターから namespace を取得します。oc get ns
次のメッセージのようなエラーが表示された場合は、クラスター API サーバーの証明書が変更になっており、kubeconfig ファイルが無効です。
Unable to connect to the server: x509: certificate signed by unknown authority
1.13.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.13.10. Pending Import ステータスのクラスターのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
クラスターのコンソールで継続的に Pending import と表示される場合は、以下の手順を実行して問題をトラブルシューティングしてください。
1.13.10.1. 現象: ステータスが Pending Import クラスター リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management コンソールを使用してクラスターをインポートした後に、コンソールで、クラスターのステータスが Pending import と表示されます。
1.13.10.2. 問題の特定: ステータスが Pending Import クラスター リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターで以下のコマンドを実行し、問題のある Kubernetes Pod 名を表示します。
kubectl get pod -n open-cluster-management-agent | grep klusterlet-agentマネージドクラスターで以下のコマンドを実行し、エラーのログエントリーを探します。
kubectl logs <klusterlet_agent_pod> -n open-cluster-management-agentregistration_agent_pod は、手順 1 で特定した Pod 名に置き換えます。
-
返された結果に、ネットワーク接続の問題があったと示すテキストがないかどうかを検索します。たとえば、
no such hostです。
1.13.10.3. 問題の解決: ステータスが Pending Import クラスター リンクのコピーリンクがクリップボードにコピーされました!
ハブクラスターで以下のコマンドを実行して、問題のあるポート番号を取得します。
oc get infrastructure cluster -o yaml | grep apiServerURLマネージドクラスターのホスト名が解決でき、ホストおよびポートへの送信接続が機能していることを確認します。
マネージドクラスターで通信が確立できない場合は、クラスターのインポートが完了していません。マネージドクラスターのクラスターステータスは、Pending import になります。
1.13.11. 証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
カスタムの apiserver 証明書のインストールはサポートされますが、証明書情報を変更する前にインポートされたクラスターの 1 つまたは複数でステータスが offline になる可能性があります。
1.13.11.1. 現象: 証明書の変更後にクラスターがオフラインになる リンクのコピーリンクがクリップボードにコピーされました!
証明書シークレットを更新する手順を完了すると、オンラインだった 1 つ以上のクラスターがコンソールに offline ステータスを表示するようになります。
1.13.11.2. 問題の特定: 証明書の変更後にクラスターがオフラインになる リンクのコピーリンクがクリップボードにコピーされました!
カスタムの API サーバー証明書の情報を更新すると、インポートされ、新しい証明書が追加される前に稼働していたクラスターのステータスが offline になります。
オフラインのマネージドクラスターの open-cluster-management-agent namespace にある Pod のログで、証明書に問題があるとのエラーが見つかります。以下の例のようなエラーがログに表示されます。
次の klusterlet-agent ログを参照してください。
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
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
1.13.11.3. 問題の解決: 証明書の変更後にクラスターがオフラインになる リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターを回復する場合は、次の手順を実行して、マネージドクラスターを再度インポートします。
ハブクラスターで、次のコマンドを実行してマネージドクラスターのインポートシークレットを再作成します。
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.13.12. クラスターのステータスが offline から available に変わる場合のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターのステータスは、環境またはクラスターを手動で変更することなく、offline と available との間で切り替わります。
1.13.12.1. 現象: クラスターのステータスが offline から available に変わる リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターからハブクラスターへのネットワーク接続が不安定な場合に、マネージドクラスターのステータスが offline と available との間で順に切り替わると、ハブクラスターにより報告されます。
1.13.12.2. 問題の解決: クラスターのステータスが offline から available に変わる リンクのコピーリンクがクリップボードにコピーされました!
この問題を解決するには、以下の手順を実行します。
次のコマンドを入力して、ハブクラスターで
ManagedClusterの仕様を編集します。oc edit managedcluster <cluster-name>cluster-name は、マネージドクラスターの名前に置き換えます。
-
ManagedCluster仕様のleaseDurationSecondsの値を増やします。デフォルト値は 60 秒です。マネージドクラスターのオフライン猶予期間は、5 分 (leaseDurationSecondsの 5 倍) です。この値は、ネットワークの問題が発生したときに接続を維持するのに十分でない可能性があります。リースの時間を長く指定します。たとえば、leaseDurationSecondsを 240 秒に設定すると、オフライン猶予期間が 20 分間になります。
1.13.13. VMware vSphere でのクラスター作成のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere で Red Hat OpenShift Container Platform クラスターを作成する時に問題が発生した場合は、以下のトラブルシューティング情報を参照して、この情報のいずれかが問題に対応しているかどうかを確認します。
注記: VMware vSphere でクラスター作成プロセスが失敗した場合に、リンクが有効にならずログが表示されないことがあります。上記が発生する場合は、hive-controllers Pod のログを確認して問題を特定できます。hive-controllers ログは hive namespace にあります。
1.13.13.1. 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
1.13.13.1.1. 現象: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書 IP SAN エラーを示すエラーメッセージでクラスターに問題が発生します。
1.13.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.13.13.1.3. 問題の解決: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
認証情報の IP アドレスではなく VMware vCenter サーバー完全修飾ホスト名を使用します。また、VMware vCenter CA 証明書を更新して、IP SAN を組み込むこともできます。
1.13.13.2. 不明な証明局のエラーでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
1.13.13.2.1. 現象: 不明な証明局のエラーでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書が不明な証明局により署名されているのでクラスターに問題が発生します。
1.13.13.2.2. 問題の特定: 不明な証明局のエラーでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
1.13.13.2.3. 問題の解決: 不明な証明局のエラーでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
認証情報の作成時に認証局の正しい証明書が入力されていることを確認します。
1.13.13.3. 証明書の期限切れでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
1.13.13.3.1. 現象: 証明書の期限切れでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書の期限が切れているか、有効にしていないため、クラスターに問題が発生します。
1.13.13.3.2. 問題の特定: 証明書の期限切れでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。
x509: certificate has expired or is not yet valid
1.13.13.3.3. 問題の解決: 証明書の期限切れでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
ESXi ホストの時間が同期されていることを確認します。
1.13.13.4. タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
1.13.13.4.1. 現象: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、タグ付けの使用に十分な権限がないためクラスターに問題が発生します。
1.13.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.13.13.4.3. 問題の解決: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vCenter が必要とするアカウントの権限が正しいことを確認します。詳細は、インストール時に削除されたイメージレジストリー を参照してください。
1.13.13.5. 無効な dnsVIP でマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
1.13.13.5.1. 現象: 無効な dnsVIP でマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、dnsVIP が無効であるため、クラスターに問題が発生します。
1.13.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.13.13.5.3. 問題の解決: 無効な dnsVIP でマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware インストーラーでプロビジョニングされるインフラストラクチャーをサポートする OpenShift Container Platform で、新しいバージョンのリリースイメージを選択します。
1.13.13.6. ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
1.13.13.6.1. 現象: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、間違ったネットワークタイプが指定されているため、クラスターに問題が発生します。
1.13.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.13.13.6.3. 問題の解決: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
指定の VMware クラスターに対して有効な VMware vSphere ネットワークタイプを選択します。
1.13.13.7. ディスクの変更処理のエラーでマネージドクラスターの作成に失敗する リンクのコピーリンクがクリップボードにコピーされました!
1.13.13.7.1. 現象: ディスク変更の処理中にエラーが発生するため、VMware vSphere マネージドクラスターの追加が失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、ディスク変更処理時にエラーによりクラスターに問題が発生します。
1.13.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.13.13.7.3. 問題の解決: ディスク変更の処理中にエラーが発生したため、VMware vSphere マネージドクラスターの追加に失敗する リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere クライアントを使用してユーザーに プロファイル駆動型のストレージ権限 の 全権限 を割り当てます。
1.13.14. ステータスが Pending または Failed のクラスターのコンソールでのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
作成したクラスターのステータスがコンソールで Pending または Failed と表示されている場合は、以下の手順を実行して問題のトラブルシューティングを実行します。
1.13.14.1. 現象: コンソールでステータスが Pending または Failed のクラスターのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
コンソールを使用して新しいクラスターを作成した後、クラスターは Pending のステータスを超えて進行しないか、Failed ステータスを表示します。
1.13.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 hivenew_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.13.14.3. 問題の解決: コンソールでステータスが Pending または Failed のクラスター リンクのコピーリンクがクリップボードにコピーされました!
ログでエラーを特定した後に、エラーの解決方法を決定してから、クラスターを破棄して、作り直してください。
以下の例では、サポート対象外のゾーンを選択している可能性を示すログエラーと、解決に必要なアクションが提示されています。
No subnets provided for zones
クラスターの作成時に、サポートされていないリージョンにあるゾーンを 1 つ以上選択しています。問題解決用にクラスターを再作成する時に、以下のアクションの 1 つを実行します。
- リージョン内の異なるゾーンを選択します。
- 他のゾーンをリストしている場合は、サポートを提供しないゾーンを省略します。
- お使いのクラスターに、別のリージョンを選択します。
ログから問題を特定した後に、クラスターを破棄し、再作成します。
クラスターの作成に関する詳細は、クラスターの作成 を参照してください。
1.13.15. degraded 状態にある Klusterlet のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Klusterlet の状態が Degraded の場合は、マネージドクラスターの klusterlet エージェントの状態を診断しやすくなります。Klusterlet の状態が Degraded になると、マネージドクラスターの klusterlet エージェントで発生する可能性のあるエラーに対応する必要があります。Klusterlet の degraded の状態が True に設定されている場合は、以下の情報を参照します。
1.13.15.1. 現象: Klusterlet の状態が degraded である リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターに Klusterlet をデプロイすると、RegistrationDesiredDegraded または WorkDesiredDegraded 状態に True のステータスが表示されます。
1.13.15.2. 問題の特定: Klusterlet の状態が degraded である リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターで以下のコマンドを実行して、Klusterlet のステータスを表示します
kubectl get klusterlets klusterlet -oyaml-
RegistrationDesiredDegradedまたはWorkDesiredDegradedをチェックして、状態がTrueに設定されているかどうかを確認します。記載されている Degraded の状態は、問題の解決 に進みます。
1.13.15.3. 問題の解決: Klusterlet の状態が degraded である リンクのコピーリンクがクリップボードにコピーされました!
ステータスが Degraded のリストおよびこれらの問題の解決方法を参照してください。
-
RegistrationDesiredDegraded状態のステータスが True で、状態の理由が BootStrapSecretMissing である場合は、open-cluster-management-agentnamespace にブートストラップシークレットを作成する必要があります。 -
RegistrationDesiredDegraded状態に True と表示され、状態の理由が BootstrapSecretError または BootstrapSecretUnauthorized である場合は、現在のブートストラップシークレットが無効です。現在のブートストラップシークレットを削除して、open-cluster-management-agentnamespace で有効なブートストラップシークレットをもう一度作成します。 -
RegistrationDesiredDegradedとWorkDesiredDegradedに True と表示され、状態の理由が HubKubeConfigSecretMissing である場合は、Klusterlet を削除して再作成します。 -
RegistrationDesiredDegradedとWorkDesiredDegradedに True と表示され、状態の理由が ClusterNameMissing、KubeConfigMissing、HubConfigSecretError、または HubConfigSecretUnauthorized である場合は、open-cluster-management-agentnamespace からハブクラスターの kubeconfig シークレットを削除します。klusterlet エージェントは、新しいハブクラスター kubeconfig シークレットを作成します。 -
RegistrationDesiredDegradedに True と表示され、状態の理由が GetRegistrationDeploymentFailed または UnavailableRegistrationPod である場合は、状態のメッセージを確認して問題の詳細を取得し、解決を試みてください。 -
WorkDesiredDegradedに True と表示され、状態の理由が GetWorkDeploymentFailed または UnavailableWorkPod である場合は、状態メッセージを確認して問題の詳細を取得し、解決を試みてください。
1.13.16. クラスターの削除後も namespace が残る リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターを削除すると、通常 namespace はクラスターの削除プロセスの一部として削除されます。まれに namespace は一部のアーティファクトが含まれた状態で残る場合があります。このような場合は、namespace を手動で削除する必要があります。
1.13.16.1. 現象: クラスターの削除後も namespace が残る リンクのコピーリンクがクリップボードにコピーされました!
マネージドクラスターの削除後に namespace が削除されません。
1.13.16.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.13.17. クラスターのインポート時の auto-import-secret-exists エラー リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインポートは、auto import secret exists というエラーメッセージで失敗します。
1.13.17.1. 現象: クラスターのインポート時の auto-import-secret-exists エラー リンクのコピーリンクがクリップボードにコピーされました!
管理用のハイブクラスターをインポートすると、auto-import-secret already exists というエラーが表示されます。
1.13.17.2. 問題の解決: クラスターのインポート時の Auto-import-secret-exists エラー リンクのコピーリンクがクリップボードにコピーされました!
この問題は、以前に管理されていたクラスターをインポートしようとすると発生します。これが生じると、クラスターを再インポートしようとすると、シークレットは競合します。
この問題を回避するには、以下の手順を実行します。
既存の
auto-import-secretを手動で削除するには、ハブクラスターで以下のコマンドを実行します。oc delete secret auto-import-secret -n <cluster-namespace>namespaceは、お使いのクラスターの namespace に置き換えます。- クラスターインポートの概要 の手順を使用して、クラスターを再度インポートします。
1.13.18. Troubleshooting missing PlacementDecision after creating Placement リンクのコピーリンクがクリップボードにコピーされました!
Placement の作成後に PlacementDescision が生成されない場合は、手順に従って問題をトラブルシューティングしてください。
1.13.18.1. 事象: Placement の作成後に PlacementDecision が見つからない リンクのコピーリンクがクリップボードにコピーされました!
Placement を作成した後、PlacementDescision は自動的に生成されません。
1.13.18.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: 0PlacementMisconfiguredおよびPlacementSatisfiedのStatusの出力を確認します。-
PlacementMisconfiguredStatusが true の場合、Placementに設定エラーがあります。設定エラーの詳細とその解決方法は、含まれているメッセージを確認してください。 -
PlacementSatisfiedStatusが 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.13.19. Dell ハードウェアにおけるベアメタルホストの検出エラーのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Dell ハードウェアでベアメタルホストの検出が失敗した場合、Integrated Dell Remote Access Controller (iDRAC) が不明な認証局からの証明書を許可しないように設定されている可能性があります。
1.13.19.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.13.19.2. 問題の解決: Dell ハードウェアでのベアメタルホストの検出の失敗 リンクのコピーリンクがクリップボードにコピーされました!
iDRAC は、不明な認証局からの証明書を受け入れないように設定されています。
この問題を回避するには、次の手順を実行して、ホスト iDRAC のベースボード管理コントローラーで証明書の検証を無効にします。
- iDRAC コンソールで、Configuration > Virtual media > Remote file share に移動します。
-
Expired or invalid certificate action の値を
Yesに変更します。
1.13.20. 最小限の ISO の起動失敗に関するトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
最小限の ISO を起動しようとすると問題が発生する可能性があります。
1.13.20.1. 現象: 最小限の ISO が起動に失敗する リンクのコピーリンクがクリップボードにコピーされました!
ブート画面には、ホストがルートファイルシステムイメージのダウンロードに失敗したことが示されます。
1.13.20.2. 問題の解決: 最小限の ISO が起動に失敗する リンクのコピーリンクがクリップボードにコピーされました!
問題のトラブルシューティング方法は、Assisted Installer for OpenShift Container Platform ドキュメントの 最小限の検出 ISO の問題をトラブルシューティングする を参照してください。
1.13.21. RHCOS イメージミラーリングのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
非接続環境の Red Hat OpenShift Virtualization 上の Hosted Control Plane の場合、oc-mirror で、Red Hat Enterprise Linux CoreOS (RHCOS) イメージを内部レジストリーに自動的にミラーリングできません。最初のホステッドクラスターを作成するときに、ブートイメージを内部レジストリーで利用できないため、Kubevirt 仮想マシンが起動しません。
1.13.21.1. 現象: oc-mirror で RHCOS イメージのミラーリングを試行できない リンクのコピーリンクがクリップボードにコピーされました!
oc-mirror プラグインは、リリースペイロードから内部レジストリーに {op-system-first} イメージをミラーリングしません。
1.13.21.2. 問題の解決: oc-mirror で RHCOS イメージのミラーリングを試行できない リンクのコピーリンクがクリップボードにコピーされました!
この問題を解決するには、RHCOS イメージを手動で内部レジストリーにミラーリングします。以下の手順を実行します。
次のコマンドを実行して内部レジストリー名を取得します。
oc get imagecontentsourcepolicy -o json | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'次のコマンドを実行してペイロードイメージを取得します。
oc get clusterversion version -ojsonpath='{.status.desired.image}'ホステッドクラスター上のペイロードイメージからブートイメージを含む
0000_50_installer_coreos-bootimages.yamlファイルを抽出します。<payload_image>は、ペイロードイメージの名前に置き換えます。以下のコマンドを実行します。oc image extract --file /release-manifests/0000_50_installer_coreos-bootimages.yaml <payload_image> --confirm次のコマンドを実行して RHCOS イメージを取得します。
cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'RHCOS イメージを内部レジストリーにミラーリングします。
<rhcos_image>は、RHCOS イメージに置き換えます (例:quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d9643ead36b1c026be664c9c65c11433c6cdf71bfd93ba229141d134a4a6dd94)。<internal_registry>は、内部レジストリーの名前に置き換えます (例:virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev)。以下のコマンドを実行します。oc image mirror <rhcos_image> <internal_registry>ImageDigestMirrorSetオブジェクトを定義するrhcos-boot-kubevirt.yamlという名前の YAML ファイルを作成します。次の設定例を参照してください。apiVersion: config.openshift.io/v1 kind: ImageDigestMirrorSet metadata: name: rhcos-boot-kubevirt spec: repositoryDigestMirrors: - mirrors: - <rhcos_image_no_digest>1 source: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev2 次のコマンドを実行して、
rhcos-boot-kubevirt.yamlファイルを適用し、ImageDigestMirrorSetオブジェクトを作成します。oc apply -f rhcos-boot-kubevirt.yaml
1.13.22. トラブルシューティング: 非ベアメタルクラスターを遅延バインディングプールに戻す リンクのコピーリンクがクリップボードにコピーされました!
BareMetalHosts なしで遅延バインディングマネージドクラスターを使用している場合は、遅延バインディングクラスターを破棄し、ノードを Discovery ISO に戻すための追加の手動手順を実行する必要があります。
1.13.22.1. 現象: 非ベアメタルクラスターを遅延バインディングプールに戻す リンクのコピーリンクがクリップボードにコピーされました!
BareMetalHosts のない遅延バインディングマネージドクラスターの場合、クラスター情報を削除しても、すべてのノードが自動的に Discovery ISO に戻されるわけではありません。
1.13.22.2. 問題の解決: 非ベアメタルクラスターを遅延バインディングプールに戻す リンクのコピーリンクがクリップボードにコピーされました!
遅延バインディングを使用する非ベアメタルノードのバインドを解除するには、次の手順を実行します。
- クラスター情報を削除します。詳細は、管理からのクラスターの削除 を参照してください。
- ルートディスクをクリーンアップします。
- Discovery ISO を使用して手動で再起動します。
1.13.23. Hosted Control Plane クラスターを使用した Red Hat OpenShift Service on AWS でマネージドクラスターが Unknown になる問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS 上のすべてのマネージドクラスターのステータスが突然 Unknown になります。
マネージドクラスターの open-cluster-management-agent namespace にある klusterlet-agent Pod のログを確認すると、次のようなエラーが表示されます。
E0809 18:45:29.450874 1 reflector.go:147] k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: Failed to watch *v1.CertificateSigningRequest: failed to list *v1.CertificateSigningRequest: Get "https://api.xxx.openshiftapps.com:443/apis/certificates.k8s.io/v1/certificatesigningrequests?limit=500&resourceVersion=0": tls: failed to verify certificate: x509: certificate signed by unknown authority
1.13.23.2. Red Hat OpenShift Service on AWS with Hosted Control Plane クラスターで、すべてのマネージドクラスターが Unknown ステータスになる リンクのコピーリンクがクリップボードにコピーされました!
-
globalという名前のKlusterletConfigリソースを作成します (リソースがない場合)。 spec.hubKubeAPIServerConfig.serverVerificationStrategyをUseSystemTruststoreに設定します。以下の例を参照してください。apiVersion: config.open-cluster-management.io/v1alpha1 kind: KlusterletConfig metadata: name: global spec: hubKubeAPIServerConfig: serverVerificationStrategy: UseSystemTruststoreハブクラスターで次のコマンドを実行してリソースを適用します。
<filename>はファイル名に置き換えます。oc apply -f <filename>マネージドクラスターによっては、状態が回復することがあります。
Unknownステータスのままのマネージドクラスターがある場合は、このプロセスを続行します。ハブクラスターで次のコマンドを実行して、ハブクラスターから
import.yaml` ファイルをエクスポートしてデコードします。`<cluster_name>は、クラスター名に置き換えます。oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\.yaml} | base64 --decode > <cluster_name>-import.yamlマネージドクラスターで次のコマンドを実行してファイルを適用します。
oc apply -f <cluster_name>-import.yaml
1.13.24. OpenShift Container Platform バージョンが欠落しているマネージドクラスターのアップグレード試行のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
コンソールでマネージドクラスターをアップグレードしようとすると、コンソールに必要な OpenShift Container Platform バージョンが表示されません。
1.13.24.1. 現象: OpenShift Container Platform バージョンが欠落している状態でマネージドクラスターをアップグレードしようとする リンクのコピーリンクがクリップボードにコピーされました!
コンソールからマネージドクラスターをアップグレードしようとし、Cluster details ビューで Upgrade available をクリックしてドロップダウンリストから OpenShift Container Platform のバージョンを選択すると、バージョンが見つかりません。
1.13.24.2. 問題の解決: OpenShift Container Platform バージョンが欠落しているマネージドクラスターのアップグレードを試みる リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を参照してください。
マネージドクラスターの
ClusterVersionリソースのステータスに必要なバージョンが含まれていることを確認します。以下のコマンドを実行します。oc get clusterversion version -o jsonpath='{.status.availableUpdates[*].version}'必要とされるバージョンが表示されない場合、そのバージョンはこのマネージドクラスターには適用されません。
ManagedClusterInfoリソースにハブクラスターのバージョンが含まれているかどうかを確認します。以下のコマンドを実行します。oc -n <cluster_name> get managedclusterinfo <cluster_name> -o jsonpath='{.status.distributionInfo.ocp.availableUpdates[*]}'バージョンが含まれている場合は、ハブクラスターに障害のある
ClusterCuratorリソースがあるかどうかを確認します。以下のコマンドを実行します。oc -n <cluster_name> get ClusterCurator <cluster_name> -o yamlClusterCuratorリソースが存在し、そのclustercurator-job条件のステータスがFalseの場合は、ハブクラスターからClusterCuratorリソースを削除します。以下のコマンドを実行します。oc -n <cluster_name> delete ClusterCurator <cluster_name>ManagedClusterInfoリソースにバージョンが含まれていない場合は、マネージドクラスターのwork-managerアドオンログを確認し、報告されたエラーを修正します。次のコマンドを実行し、Pod 名を環境内の実際の名前に置き換えます。oc -n open-cluster-management-agent-addon logs klusterlet-addon-workmgr-<your_pod_name>
1.13.25. Hive および Assisted Installer クラスターでの認証局更新エラーのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Hive でプロビジョニングされたクラスターまたは Assisted Installer クラスターでクラスター認証局 (CA) を更新した後に表示される接続エラーメッセージをトラブルシューティングします。
1.13.25.1. 現象: Hive および Assisted Installer クラスターでの認証局更新エラー リンクのコピーリンクがクリップボードにコピーされました!
Hive でプロビジョニングされたクラスターまたは Assisted Installer クラスターでクラスター CA をエンタープライズ CA で更新すると、ハブクラスター上の対応するクラスターデプロイメントに次の接続エラーメッセージが表示されます。
x509: certificate signed by unknown authority
この状態でクラスターをバックアップして復元しても、復元されたハブクラスターにマネージドクラスターを自動的にインポートできません。
1.13.25.2. 問題の解決: Hive および Assisted Installer クラスターでの認証局更新エラー リンクのコピーリンクがクリップボードにコピーされました!
エラーを解決するには、次の手順を使用します。
システム内のグローバル変数を使用してカスタム CA を定義します。以下のコマンドを実行します。
export CA=<your_customized_CA>次のコマンドを実行して、カスタマイズした CA を使用して新しいシークレットを生成します。
oc create secret generic additional-ca \ --from-literal=ca.crt="$CA" \ --namespace hive新しいシークレットを使用してクラスターを更新します。追加の CA パッチを使用して次のコマンドを実行します。
oc patch hiveconfig hive --type=merge -p ' { "spec": { "additionalCertificateAuthoritiesSecretRef": [ { "name": "additional-ca" } ] } }'
1.13.26. トラブルシューティング: open-cluster-management-global-set namespace が見つらない リンクのコピーリンクがクリップボードにコピーされました!
open-cluster-management-global-set namespace には、cluster-proxy、managed-serviceaccount、および work-manager などのアドオンをデプロイするために必要な グローバル Placement が含まれます。
open-cluster-management-global-set namespace が見つからないか、削除された場合、アドオンはマネージドクラスターにインストールされません。以前にアドオンをインストールしていた場合、namespace が見つからないか削除されると、アドオンも削除されます。
1.13.26.1. 現象: open-cluster-management-global-set namespace が見つらない リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management のインストール後に、ハブクラスターに open-cluster-management-global-set namespace がありません。その結果、cluster-proxy、managed-serviceaccount、および work-manager アドオンの ManagedClusterAddOn リソースは作成されません。
1.13.26.2. 問題の特定: open-cluster-management-global-set namespace が見つからない リンクのコピーリンクがクリップボードにコピーされました!
open-cluster-management-global-set namespace がなく、global と呼ばれる ManagedClusterSet には open-cluster-management.io/ns-create: "true" アノテーションが含まれます。multicluster-engine namespace の 'ocm-controller' ログに、次のメッセージを見つけることもできます。
I0904 04:50:09.628951 1 globalset_controller.go:202] GlobalSet Namespace open-cluster-management-global-set does not exist, skip applying binding and placement
1.13.26.3. 問題の解決: open-cluster-management-global-set namespace が見つからない リンクのコピーリンクがクリップボードにコピーされました!
この問題を解決するには、ManagedClusterSet から global というアノテーションを削除します。以下のコマンドを実行して、namespace と グローバル Placement を再作成します。
oc annotate managedclusterset global open-cluster-management.io/ns-create- --overwrite