Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

トラブルシューティングガイドをご使用の前に oc adm must-gather コマンドを実行して、詳細およびログを収集し、問題のデバッグ手順を行います。詳細は、must-gather コマンドを実行したトラブルシューティング を参照してください。

また、ロールベースのアクセス権限を確認してください。詳細は、multicluster engine Operator のロールベースのアクセス制御 を参照してください。

1.9.1. 文書化されたトラブルシューティング
リンクのコピー

multicluster engine Operator のトラブルシューティングトピックのリストをご覧ください。

インストール:

インストールタスクに関する主なドキュメントを確認するには、multicluster engine Operator のインストールとアップグレード を参照してください。

クラスター管理:

クラスターの管理に関する主要なドキュメントを表示するには、クラスターライフサイクルの概要 を参照してください。

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 コマンドの使用を開始するには、以下の手順を参照してください。

  1. must-gather コマンドについて確認し、Red Hat OpenShift Container Platform の クラスターに関するデータの収集 に必要な前提条件をインストールします。

  2. クラスターにログインします。通常のユースケースでは、engine クラスターにログインして、must-gather を実行する必要があります。

    注記: マネージドクラスターを確認する場合は、cluster-scoped-resources ディレクトリーにある gather-managed.log ファイルを検索します。 

    <your-directory>/cluster-scoped-resources/gather-managed.log>
    Copy to Clipboard Toggle word wrap

    JOINED および AVAILABLE 列に True が設定されていないマネージドクラスターがないかを確認します。must-gather コマンドは、ステータスが True として関連付けられていないクラスター上で、実行できます。

  3. データとディレクトリーの収集に使用される Kubernetes イメージのマルチクラスターエンジンを追加します。以下のコマンドを実行して、出力用にイメージとディレクトリーを挿入します。 

    oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.3 --dest-dir=<directory>
    Copy to Clipboard Toggle word wrap

  4. 指定したディレクトリーに移動し、以下のレベルに整理されている出力を確認します。

    • ピアレベル 2 つ: cluster-scoped-resources と namespace のリソース
    • それぞれに対するサブレベル: クラスタースコープおよび namespace スコープの両方のリソースに対するカスタムリソース定義の API グループ。
    • それぞれに対する次のレベル: kind でソートされた YAML ファイル

1.9.2.3. 非接続環境での must-gather
リンクのコピー

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

  1. 非接続環境では、Red Hat Operator のカタログイメージをミラーレジストリーにミラーリングします。詳細は、ネットワーク切断状態でのインストール を参照してください。
  2. 次のコマンドを実行して、ミラーレジストリーからイメージを参照するログを抽出します。 
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8

oc adm must-gather --image=$IMAGE --dest-dir=./data
Copy to Clipboard Toggle word wrap

ここ で製品チームのバグを開くことができます。

インストール中に、ゼロタッチプロビジョニング方式またはホストインベントリー作成方式を使用して、multicluster engine for 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
    Copy to Clipboard Toggle word wrap

  • 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
Copy to Clipboard Toggle word wrap

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

1.9.3.2. 問題の解決: ネットワーク設定をマージするノードを再作成します。
リンクのコピー

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

  1. ハブクラスターからノードを削除します。
  2. 同じようにノードをインストールするには、前のプロセスを繰り返します。
  3. 次のアノテーションを使用してノードの BareMetalHost オブジェクトを作成します。 
"bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"
Copy to Clipboard Toggle word wrap

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

multicluster engine Operator をインストールするときに、MultiClusterEngine が Installing フェーズのままになるか、複数の Pod が Pending ステータスのままになります。

1.9.4.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.'
Copy to Clipboard Toggle word wrap

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

1.9.4.2. 問題の解決: ワーカーノードのサイズの調整
リンクのコピー

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

1.9.5. 再インストールに失敗する場合のトラブルシューティング
リンクのコピー

multicluster engine Operator を再インストールすると、Pod が起動しません。

1.9.5.1. 現象: 再インストールの失敗
リンクのコピー

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

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

1.9.5.2. 問題の解決: 再インストールの失敗
リンクのコピー

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

  1. アンインストール の手順に従い、現在のコンポーネントを削除し、アンインストールプロセスを実行します。
  2. Helm のインストール の手順に従い、Helm CLI バイナリーバージョン 3.2.0 以降をインストールします。
  3. oc コマンドが実行できるように、Red Hat OpenShift Container Platform CLI が設定されていることを確認してください。oc コマンドの設定方法の詳細は、OpenShift Container Platform ドキュメントの OpenShift CLI スタートガイド を参照してください。

  4. 以下のスクリプトをファイルにコピーします。 

    #!/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
    Copy to Clipboard Toggle word wrap

    スクリプト内の <namespace> は、multicluster engine Operator がインストールされている namespace の名前に置き換えます。namespace が消去され削除されるため、正しい namespace を指定するようにしてください。

  5. スクリプトを実行して、アーティファクトを以前のインストールから削除します。
  6. インストールを実行します。ネットワーク接続時のオンラインインストール を参照してください。

1.9.6. オフラインクラスターのトラブルシューティング
リンクのコピー

クラスターのステータスがオフラインと表示される一般的な原因がいくつかあります。

1.9.6.1. 現象: クラスターのステータスがオフライン状態である
リンクのコピー

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

1.9.6.2. 問題の解決: クラスターのステータスがオフライン状態になっている
リンクのコピー

  1. マネージドクラスターが利用可能かどうかを確認します。これは、Red Hat Advanced Cluster Management コンソールの Clusters エリアで確認できます。

    利用不可の場合は、マネージドクラスターの再起動を試行します。

  2. マネージドクラスターのステータスがオフラインのままの場合は、以下の手順を実行します。

    1. ハブクラスターで oc get managedcluster <cluster_name> -o yaml コマンドを実行します。<cluster_name> は、クラスター名に置き換えます。
    2. status.conditions セクションを見つけます。
    3. type: ManagedClusterConditionAvailable のメッセージを確認して、問題を解決します。

1.9.7. マネージドクラスターのインポート失敗に関するトラブルシューティング
リンクのコピー

クラスターのインポートに失敗した場合は、クラスターのインポートが失敗した理由を判別するためにいくつかの手順を実行できます。

1.9.7.1. 現象: インポートされたクラスターを利用できない
リンクのコピー

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

1.9.7.2. 問題の解決: インポートされたクラスターが利用できない
リンクのコピー

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

  1. ハブクラスターで、次のコマンドを実行して、インポートコントローラーが実行していることを確認します。 

    kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2
    Copy to Clipboard Toggle word wrap

    実行中の Pod が 2 つ表示されるはずです。Pod のいずれかが実行されていない場合には、以下のコマンドを実行してログを表示して理由を判別します。 

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1
    Copy to Clipboard Toggle word wrap

  2. ハブクラスターで次のコマンドを実行して、マネージドクラスターのインポートシークレットがインポートコントローラーによって正常に生成されたかどうかを確認します。 

    kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import
    Copy to Clipboard Toggle word wrap

    インポートシークレットが存在しない場合は、以下のコマンドを実行してインポートコントローラーのログエントリーを表示し、作成されていない理由を判断します。 

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller
    Copy to Clipboard Toggle word wrap

  3. ハブクラスターで、マネージドクラスターが local-cluster であるか、Hive によってプロビジョニングされているか、自動インポートシークレットがある場合は、次のコマンドを実行して、マネージドクラスターのインポートステータスを確認します。 

    kubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceeded
    Copy to Clipboard Toggle word wrap

    ManagedClusterImportSucceeded が true でない場合には、コマンドの結果で失敗の理由が表示されます。

  4. マネージドクラスターの Klusterlet ステータスが degraded 状態でないかを確認します。Klusterlet のパフォーマンスが低下した理由を特定するには、degraded 状態にある Klusterlet のトラブルシューティング を参照してください。

1.9.8. クラスターの再インポートが不明な権限エラーで失敗する
リンクのコピー

マネージドクラスターを multicluster engine Operator に再インポートするときに問題が発生した場合は、手順に従って問題をトラブルシューティングします。

1.9.8.1. 現象: クラスターの再インポートが不明な権限エラーで失敗する
リンクのコピー

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

1.9.8.2. 問題の特定: クラスターの再インポートが不明な権限エラーで失敗する
リンクのコピー

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

kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f
Copy to Clipboard Toggle word wrap

次のエラーログが表示される場合は、マネージドクラスター 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 サーバー証明書が変更されたかどうかを確認するには、次の手順を実行します。

  1. 次のコマンドを実行して、your-managed-cluster-name をマネージドクラスターの名前に置き換えて、マネージドクラスターの名前を指定します。 

    cluster_name=<your-managed-cluster-name>
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、マネージドクラスター kubeconfig シークレット名を取得します。 

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、kubeconfig を新しいファイルにエクスポートします。 

    oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.old
    Copy to Clipboard Toggle word wrap 
    export KUBECONFIG=kubeconfig.old
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、kubeconfig を使用してマネージドクラスターから namespace を取得します。 

    oc get ns
    Copy to Clipboard Toggle word wrap

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

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

1.9.8.3. 問題の解決: クラスターの再インポートが不明な権限エラーで失敗する
リンクのコピー

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

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

  1. 次のコマンドを実行して、kubeconfig ファイルパスとクラスター名を設定します。<path_to_kubeconfig> を新しい kubeconfig ファイルへのパスに置き換えます。<managed_cluster_name> をマネージドクラスターの名前に置き換えます。 

    cluster_name=<managed_cluster_name>
kubeconfig_file=<path_to_kubeconfig>
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、新しい kubeconfig をエンコードします。 

    kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)
    Copy to Clipboard Toggle word wrap

    注記: macOS では、代わりに次のコマンドを実行します。 

    kubeconfig=$(cat ${kubeconfig_file} | base64)
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、JSON パッチ kubeconfig を定義します。 

    kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、マネージドクラスターから管理者の kubeconfig シークレット名を取得します。 

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、管理者の kubeconfig シークレットに新しい kubeconfig を適用します。 

    oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"
    Copy to Clipboard Toggle word wrap

1.9.9. Pending Import ステータスのクラスターのトラブルシューティング
リンクのコピー

クラスターのコンソールで継続的に Pending import と表示される場合は、以下の手順を実行して問題をトラブルシューティングしてください。

1.9.9.1. 現象: ステータスが Pending Import クラスター
リンクのコピー

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

1.9.9.2. 問題の特定: ステータスが Pending Import クラスター
リンクのコピー

  1. マネージドクラスターで以下のコマンドを実行し、問題のある Kubernetes Pod 名を表示します。 

    kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent
    Copy to Clipboard Toggle word wrap

  2. マネージドクラスターで以下のコマンドを実行し、エラーのログエントリーを探します。 

    kubectl logs <registration_agent_pod> -n open-cluster-management-agent
    Copy to Clipboard Toggle word wrap

    registration_agent_pod は、手順 1 で特定した Pod 名に置き換えます。

  3. 返された結果に、ネットワーク接続の問題があったと示すテキストがないかどうかを検索します。たとえば、no such host です。

1.9.9.3. 問題の解決: ステータスが Pending Import クラスター
リンクのコピー

  1. ハブクラスターで以下のコマンドを実行して、問題のあるポート番号を取得します。 

    oc get infrastructure cluster -o yaml | grep apiServerURL
    Copy to Clipboard Toggle word wrap

  2. マネージドクラスターのホスト名が解決でき、ホストおよびポートへの送信接続が機能していることを確認します。

    マネージドクラスターで通信が確立できない場合は、クラスターのインポートが完了していません。マネージドクラスターのクラスターステータスは、Pending import になります。

カスタムの apiserver 証明書のインストールはサポートされますが、証明書情報を変更する前にインポートされたクラスターの 1 つまたは複数でステータスが offline になる可能性があります。

1.9.10.1. 現象: 証明書の変更後にクラスターがオフラインになる
リンクのコピー

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

1.9.10.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
Copy to Clipboard Toggle word wrap

以下の 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
Copy to Clipboard Toggle word wrap

1.9.10.3. 問題の解決: 証明書の変更後にクラスターがオフラインになる
リンクのコピー

マネージドクラスターが local-cluster である場合、またはマネージドクラスターが multicluster engine Operator によって作成された場合は、マネージドクラスターを回復するのに 10 分以上待つ必要があります。

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

oc delete secret -n <cluster_name> <cluster_name>-import
Copy to Clipboard Toggle word wrap

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

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

  1. ハブクラスターで、次のコマンドを実行してマネージドクラスターのインポートシークレットを再作成します。 

    oc delete secret -n <cluster_name> <cluster_name>-import
    Copy to Clipboard Toggle word wrap

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

  2. ハブクラスターで、次のコマンドを実行して、マネージドクラスターのインポートシークレットを YAML ファイルに公開します。 

    oc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode  > import.yaml
    Copy to Clipboard Toggle word wrap

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

  3. マネージドクラスターで、次のコマンドを実行して import.yaml ファイルを適用します。 

    oc apply -f import.yaml
    Copy to Clipboard Toggle word wrap

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

マネージドクラスターのステータスは、環境またはクラスターを手動で変更することなく、offline と available との間で切り替わります。

1.9.11.1. 現象: クラスターのステータスが offline から available に変わる
リンクのコピー

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

1.9.11.2. 問題の解決: クラスターのステータスが offline から available に変わる
リンクのコピー

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

  1. 次のコマンドを入力して、ハブクラスターで ManagedCluster の仕様を編集します。 

    oc edit managedcluster <cluster-name>
    Copy to Clipboard Toggle word wrap

    cluster-name は、マネージドクラスターの名前に置き換えます。

  2. ManagedCluster 仕様の leaseDurationSeconds の値を増やします。デフォルト値は 5 分ですが、ネットワークの問題がある状態で接続を維持するには十分でない場合があります。リースの時間を長く指定します。たとえば、設定を 20 分に増やします。

1.9.12. VMware vSphere でのクラスター作成のトラブルシューティング
リンクのコピー

VMware vSphere で Red Hat OpenShift Container Platform クラスターを作成する時に問題が発生した場合は、以下のトラブルシューティング情報を参照して、この情報のいずれかが問題に対応しているかどうかを確認します。

注記: VMware vSphere でクラスター作成プロセスが失敗した場合に、リンクが有効にならずログが表示されないことがあります。上記が発生する場合は、hive-controllers Pod のログを確認して問題を特定できます。hive-controllers ログは hive namespace にあります。

1.9.12.1. 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
リンクのコピー

1.9.12.1.1. 現象: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書 IP SAN エラーを示すエラーメッセージでクラスターに問題が発生します。

1.9.12.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
Copy to Clipboard Toggle word wrap
1.9.12.1.3. 問題の解決: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する
リンクのコピー

認証情報の IP アドレスではなく VMware vCenter サーバー完全修飾ホスト名を使用します。また、VMware vCenter CA 証明書を更新して、IP SAN を組み込むこともできます。

1.9.12.2. 不明な証明局のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

1.9.12.2.1. 現象: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書が不明な証明局により署名されているのでクラスターに問題が発生します。

1.9.12.2.2. 問題の特定: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。 

Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
Copy to Clipboard Toggle word wrap
1.9.12.2.3. 問題の解決: 不明な証明局のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

認証情報の作成時に認証局の正しい証明書が入力されていることを確認します。

1.9.12.3. 証明書の期限切れでマネージドクラスターの作成に失敗する
リンクのコピー

1.9.12.3.1. 現象: 証明書の期限切れでマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書の期限が切れているか、有効にしていないため、クラスターに問題が発生します。

1.9.12.3.2. 問題の特定: 証明書の期限切れでマネージドクラスターの作成に失敗する
リンクのコピー

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。 

x509: certificate has expired or is not yet valid
Copy to Clipboard Toggle word wrap
1.9.12.3.3. 問題の解決: 証明書の期限切れでマネージドクラスターの作成に失敗する
リンクのコピー

ESXi ホストの時間が同期されていることを確認します。

1.9.12.4. タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する
リンクのコピー

1.9.12.4.1. 現象: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、タグ付けの使用に十分な権限がないためクラスターに問題が発生します。

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。 

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\" {"
Copy to Clipboard Toggle word wrap

VMware vCenter が必要とするアカウントの権限が正しいことを確認します。詳細は、インストール時に削除されたイメージレジストリー を参照してください。

1.9.12.5. 無効な dnsVIP でマネージドクラスターの作成に失敗する
リンクのコピー

1.9.12.5.1. 現象: 無効な dnsVIP でマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、dnsVIP が無効であるため、クラスターに問題が発生します。

1.9.12.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
Copy to Clipboard Toggle word wrap
1.9.12.5.3. 問題の解決: 無効な dnsVIP でマネージドクラスターの作成に失敗する
リンクのコピー

VMware インストーラーでプロビジョニングされるインフラストラクチャーをサポートする OpenShift Container Platform で、新しいバージョンのリリースイメージを選択します。

1.9.12.6. ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、間違ったネットワークタイプが指定されているため、クラスターに問題が発生します。

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"
Copy to Clipboard Toggle word wrap

指定の VMware クラスターに対して有効な VMware vSphere ネットワークタイプを選択します。

1.9.12.7. ディスクの変更処理のエラーでマネージドクラスターの作成に失敗する
リンクのコピー

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、ディスク変更処理時にエラーによりクラスターに問題が発生します。

以下のようなメッセージがログに表示されます。 

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)
Copy to Clipboard Toggle word wrap

VMware vSphere クライアントを使用してユーザーに プロファイル駆動型のストレージ権限 の 全権限 を割り当てます。

作成してたクラスターのステータスがコンソールで Pending または Failed と表示されている場合は、以下の手順を実行して問題のトラブルシューティングを実行します。

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

1.9.13.2. 問題の特定: コンソールでステータスが Pending または Failed のクラスター
リンクのコピー

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

  • 手順 1

    1. ハブクラスターで以下のコマンドを実行し、新規クラスターの namespace に作成した Kubernetes Pod の名前を表示します。 

      oc get pod -n <new_cluster_name>
      Copy to Clipboard Toggle word wrap

      new_cluster_name は、作成したクラスター名に置き換えます。

    2. 名前に provision の文字列が含まれる Pod が表示されていない場合は、手順 2 に進みます。タイトルに provision が含まれる Pod があった場合は、ハブクラスターで以下のコマンドを実行して、その Pod のログを表示します。 

      oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive
      Copy to Clipboard Toggle word wrap

      new_cluster_name_provision_pod_name は、作成したクラスター名の後に provision が含まれる Pod 名を指定するように置き換えます。

    3. ログでエラーを検索してください。この問題の原因が解明する場合があります。

  • 手順 2

    名前に provision が含まれる Pod がない場合は、問題がプロセスの初期段階で発生しています。ログを表示するには、以下の手順を実行します。

    1. ハブクラスターで以下のコマンドを実行してください。 

      oc describe clusterdeployments -n <new_cluster_name>
      Copy to Clipboard Toggle word wrap

      new_cluster_name は、作成したクラスター名に置き換えます。クラスターのインストールログの詳細は、Red Hat OpenShift ドキュメントの インストールログの収集 を参照してください。

    2. リソースの Status.Conditions.Message と Status.Conditions.Reason のエントリーに問題に関する追加の情報があるかどうかを確認します。

1.9.13.3. 問題の解決: コンソールでステータスが Pending または Failed のクラスター
リンクのコピー

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

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

No subnets provided for zones
Copy to Clipboard Toggle word wrap

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

  • リージョン内の異なるゾーンを選択します。
  • 他のゾーンをリストしている場合は、サポートを提供しないゾーンを省略します。
  • お使いのクラスターに、別のリージョンを選択します。

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

クラスターの作成に関する詳細は、クラスターの作成 を参照してください。

1.9.14.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|...
Copy to Clipboard Toggle word wrap

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

kubectl version
Copy to Clipboard Toggle word wrap

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

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

  • 最新バージョンの kubectl コマンドラインツールをインストールします。

    1. kubectl ツールの最新バージョンを、Kubernetes ドキュメントの kubectl のインストールとセットアップ からダウンロードします。
    2. kubectl ツールのアップグレード後にクラスターを再度インポートします。

  • import コマンドが含まれるファイルを実行します。

    1. CLI を使用したマネージドクラスターのインポート の手順を開始します。
    2. クラスターの import コマンドを作成する場合には、この import コマンドを import.yaml という名前の YAML ファイルにコピーします。

    3. 以下のコマンドを実行して、ファイルからクラスターを再度インポートします。 

      oc apply -f import.yaml
      Copy to Clipboard Toggle word wrap

1.9.15. degraded 状態にある Klusterlet のトラブルシューティング
リンクのコピー

Klusterlet の状態が Degraded の場合は、マネージドクラスターの Klusterlet エージェントの状態を診断しやすくなります。Klusterlet の状態が Degraded になると、マネージドクラスターの Klusterlet エージェントで発生する可能性のあるエラーに対応する必要があります。Klusterlet の degraded の状態が True に設定されている場合は、以下の情報を参照します。

1.9.15.1. 現象: Klusterlet の状態が degraded である
リンクのコピー

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

1.9.15.2. 問題の特定: Klusterlet の状態が degraded である
リンクのコピー

  1. マネージドクラスターで以下のコマンドを実行して、Klusterlet のステータスを表示します 

    kubectl get klusterlets klusterlet -oyaml
    Copy to Clipboard Toggle word wrap
  2. KlusterletRegistrationDegraded または KlusterletWorkDegraded をチェックして、状態が True に設定されいるかどうかを確認します。記載されている Degraded の状態は、問題の解決 に進みます。

1.9.15.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.16. クラスターの削除後も namespace が残る
リンクのコピー

マネージドクラスターを削除すると、通常 namespace はクラスターの削除プロセスの一部として削除されます。まれに namespace は一部のアーティファクトが含まれた状態で残る場合があります。このような場合は、namespace を手動で削除する必要があります。

1.9.16.1. 現象: クラスターの削除後も namespace が残る
リンクのコピー

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

1.9.16.2. 問題の解決: クラスターの削除後も namespace が残る
リンクのコピー

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

  1. 次のコマンドを実行して、<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>
    Copy to Clipboard Toggle word wrap

    cluster_name は、削除を試みたクラスターの namespace 名に置き換えます。

  2. 以下のコマンドを入力してリストを編集し、ステータスが Delete ではないリストから特定したリソースを削除します。 

    oc edit <resource_kind> <resource_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    resource_kind は、リソースの種類に置き換えます。resource_name は、リソース名に置き換えます。namespace は、リソースの namespace に置き換えます。

  3. メタデータで finalizer 属性の場所を特定します。
  4. vi エディターの dd コマンドを使用して、Kubernetes 以外のファイナライザーを削除します。
  5. :wq コマンドを入力し、リストを保存して vi エディターを終了します。

  6. 以下のコマンドを入力して namespace を削除します。 

    oc delete ns <cluster-name>
    Copy to Clipboard Toggle word wrap

    cluster-name を、削除する namespace の名前に置き換えます。

1.9.17. クラスターのインポート時の auto-import-secret-exists エラー
リンクのコピー

クラスターのインポートは、auto import secret exists というエラーメッセージで失敗します。

1.9.17.1. 現象: クラスターのインポート時の Auto-import-secret-exists エラー
リンクのコピー

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

1.9.17.2. 問題の解決: クラスターのインポート時の Auto-import-secret-exists エラー
リンクのコピー

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

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

  1. 既存の auto-import-secret を手動で削除するには、ハブクラスターで以下のコマンドを実行します。 

    oc delete secret auto-import-secret -n <cluster-namespace>
    Copy to Clipboard Toggle word wrap

    namespace は、お使いのクラスターの namespace に置き換えます。

  2. ハブクラスターへのターゲットのマネージドクラスターのインポート の手順を使用して、クラスターを再度インポートします。

クラスターがインポートされました。

1.9.18. Troubleshooting missing PlacementDecision after creating Placement
リンクのコピー

Placement の作成後に PlacementDescision が生成されない場合は、手順に従って問題をトラブルシューティングしてください。

1.9.18.1. 事象: Placement の作成後に PlacementDecision が見つからない
リンクのコピー

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

1.9.18.2. 問題の解決: Placement の作成後に PlacementDecision が見つからない
リンクのコピー

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

  1. 次のコマンドを実行して Placement 条件を確認します。 

    kubectl describe placement <placement-name>
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

  2. PlacementMisconfigured および PlacementSatisfied の Status の出力を確認します。

    • PlacementMisconfigured Status が true の場合、Placement に設定エラーがあります。設定エラーの詳細とその解決方法については、含まれているメッセージを確認してください。
    • PlacementSatisfied Status が false の場合、Placement を満たすマネージドクラスターはありません。詳細とエラーの解決方法については、含まれているメッセージを確認してください。前の例では、placement namespace に ManagedClusterSetBindings が見つかりませんでした。

  3. 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
    Copy to Clipboard Toggle word wrap

    注記: 配置コントローラーはスコアを割り当て、フィルター処理された ManagedCluster ごとにイベントを生成します。クラスタースコアが変化すると、配置コントローラーは新しいイベントを生成します。

1.9.19. Dell ハードウェアにおけるベアメタルホストの検出エラーのトラブルシューティング
リンクのコピー

Dell ハードウェアでベアメタルホストの検出が失敗した場合、Integrated Dell Remote Access Controller (iDRAC) が不明な認証局からの証明書を許可しないように設定されている可能性があります。

1.9.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"}
]
Copy to Clipboard Toggle word wrap

1.9.19.2. 問題の解決: Dell ハードウェアでのベアメタルホストの検出の失敗
リンクのコピー

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

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

  1. iDRAC コンソールで、Configuration > Virtual media > Remote file share に移動します。
  2. Expired or invalid certificate action の値を Yes に変更します。

1.9.20. 最小限の ISO の起動失敗に関するトラブルシューティング
リンクのコピー

最小限の ISO を起動しようとすると問題が発生する可能性があります。

1.9.20.1. 現象: 最小限の ISO が起動に失敗する
リンクのコピー

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

1.9.20.2. 問題の解決: 最小限の ISO が起動に失敗する
リンクのコピー

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat