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

15.4. OpenShift Virtualization でのホステッドクラスターのトラブルシューティング

OpenShift Virtualization でホステッドクラスターのトラブルシューティングを行う場合は、トップレベルの HostedCluster リソースと NodePool リソースから始めて、根本原因が見つかるまでスタックを下位に向かって作業します。以下の手順は、一般的な問題の根本原因を検出するのに役立ちます。

15.4.1. HostedCluster リソースが partial 状態でスタックする
リンクのコピー

HostedCluster リソースが保留中であるために Hosted Control Plane が完全にオンラインにならない場合は、前提条件、リソースの状態、ノードと Operator のステータスを確認して問題を特定します。

手順

  • OpenShift Virtualization 上のホステッドクラスターの前提条件をすべて満たしていることを確認します。
  • 進行を妨げる検証エラーがないか、HostedCluster リソースと NodePool リソースの状態を表示します。

  • ホステッドクラスターの kubeconfig ファイルを使用して、ホステッドクラスターのステータスを検査します。

    • oc get clusteroperators コマンドの出力を表示して、保留中のクラスター Operator を表示します。
    • oc get nodes コマンドの出力を表示して、ワーカーノードの準備ができていることを確認します。

15.4.2. ワーカーノードが登録されない
リンクのコピー

Hosted Control Plane にワーカーノードが登録されないために Hosted Control Plane が完全にオンラインにならない場合は、Hosted Control Plane のさまざまな部分のステータスを確認して問題を特定します。

手順

  • HostedCluster と NodePool の障害の状態を表示して、問題の内容を示します。

  • 次のコマンドを入力して、NodePool リソースの KubeVirt ワーカーノード仮想マシン (VM) のステータスを表示します。 

    $ oc get vm -n <namespace>
    Copy to Clipboard Toggle word wrap

  • 仮想マシンがプロビジョニング状態でスタックしている場合は、次のコマンドを入力して、仮想マシン namespace 内の CDI インポート Pod を表示し、インポーター Pod が完了していない理由を調べます。 

    $ oc get pods -n <namespace> | grep "import"
    Copy to Clipboard Toggle word wrap

  • 仮想マシンが開始状態でスタックしている場合は、次のコマンドを入力して、virt-launcher Pod のステータスを表示します。 

    $ oc get pods -n <namespace> -l kubevirt.io=virt-launcher
    Copy to Clipboard Toggle word wrap

    virt-launcher Pod が保留状態にある場合は、Pod がスケジュールされていない理由を調査してください。たとえば、virt-launcher Pod の実行に必要なリソースが十分存在しない可能性があります。

  • 仮想マシンが実行されていてもワーカーノードとして登録されていない場合は、Web コンソールを使用して、影響を受ける仮想マシンの 1 つへの VNC アクセスを取得します。VNC 出力は ignition 設定が適用されたかどうかを示します。仮想マシンが起動時に Hosted Control Plane Ignition サーバーにアクセスできない場合、仮想マシンは正しくプロビジョニングできません。
  • Ignition 設定が適用されても、仮想マシンがノードとして登録されない場合は、問題の特定: 仮想マシンコンソールログへのアクセス で、起動時に仮想マシンコンソールログにアクセスする方法を確認してください。

15.4.3. ワーカーノードが NotReady 状態でスタックする
リンクのコピー

クラスターの作成中、ネットワークスタックがロールアウトされる間、ノードは一時的に NotReady 状態になります。プロセスのこの部分は正常です。ただし、このプロセス部分にかかる時間が 15 分を超える場合は、ノードオブジェクトと Pod を調査して問題を特定します。

手順

  1. 次のコマンドを入力して、ノードオブジェクトの状態を表示し、ノードの準備ができていない理由を特定します。 

    $ oc get nodes -o yaml
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、クラスター内で障害が発生している Pod を探します。 

    $ oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded
    Copy to Clipboard Toggle word wrap

15.4.4. Ingress およびコンソールクラスター Operator がオンラインにならない
リンクのコピー

Ingress およびコンソールクラスター Operator がオンラインでないために Hosted Control Plane が完全にオンラインにならない場合は、ワイルドカード 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"}}]'
    Copy to Clipboard Toggle word wrap

  • Hosted Control Plane にカスタムベースドメインを使用する場合は、次の手順を実行します。

    • ロードバランサーが仮想マシン Pod を正しくターゲットにしていることを確認します。
    • ワイルドカード DNS エントリーがロードバランサー IP をターゲットにしていることを確認します。

15.4.5. ホステッドクラスターのロードバランサーサービスが利用できない
リンクのコピー

ロードバランサーサービスが利用できないために Hosted Control Plane が完全にオンラインにならない場合は、イベント、詳細、Kubernetes Cluster Configuration Manager (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
    Copy to Clipboard Toggle word wrap

15.4.6. ホステッドクラスターの PVC が利用できない
リンクのコピー

ホステッドクラスターの永続ボリューム要求 (PVC) が利用できないために Hosted Control Plane が完全にオンラインにならない場合は、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
    Copy to Clipboard Toggle word wrap

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

15.4.7. 仮想マシンノードがクラスターに正しく参加していない
リンクのコピー

仮想マシンノードがクラスターに正しく参加していないために Hosted Control Plane が完全にオンラインにならない場合は、仮想マシンコンソールログにアクセスします。

手順

15.4.8. RHCOS イメージのミラーリングが失敗する
リンクのコピー

非接続環境の OpenShift Virtualization 上の Hosted Control Plane の場合、oc-mirror で、Red Hat Enterprise Linux CoreOS (RHCOS) イメージを内部レジストリーに自動的にミラーリングできません。最初のホステッドクラスターを作成するときに、ブートイメージを内部レジストリーで利用できないため、Kubevirt 仮想マシンが起動しません。

この問題を解決するには、RHCOS イメージを手動で内部レジストリーにミラーリングします。

手順

  1. 次のコマンドを実行して内部レジストリー名を取得します。 

    $ oc get imagecontentsourcepolicy -o json \
  | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行してペイロードイメージを取得します。 

    $ oc get clusterversion version -ojsonpath='{.status.desired.image}'
    Copy to Clipboard Toggle word wrap

  3. ホステッドクラスター上のペイロードイメージからブートイメージを含む 0000_50_installer_coreos-bootimages.yaml ファイルを抽出します。<payload_image> は、ペイロードイメージの名前に置き換えます。以下のコマンドを実行します。 

    $ oc image extract \
  --file /release-manifests/0000_50_installer_coreos-bootimages.yaml \
  <payload_image> --confirm
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して RHCOS イメージを取得します。 

    $ cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream \
  | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'
    Copy to Clipboard Toggle word wrap

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

  6. ImageDigestMirrorSet オブジェクトを定義する rhcos-boot-kubevirt.yaml という名前の YAML ファイルを作成します。次の設定例を参照してください。 

    apiVersion: config.openshift.io/v1
kind: ImageDigestMirrorSet
metadata:
  name: rhcos-boot-kubevirt
spec:
  repositoryDigestMirrors:
    - mirrors:
        - virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev
    1 
    
      source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    2
    Copy to Clipboard Toggle word wrap
    1
    内部レジストリーの名前を指定します (例: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev)。
    2
    ダイジェストなしで RHCOS イメージを指定します (例: quay.io/openshift-release-dev/ocp-v4.0-art-dev)。

  7. 次のコマンドを実行して、rhcos-boot-kubevirt.yaml ファイルを適用し、ImageDigestMirrorSet オブジェクトを作成します。 

    $ oc apply -f rhcos-boot-kubevirt.yaml
    Copy to Clipboard Toggle word wrap

15.4.9. 非ベアメタルクラスターを遅延バインディングプールに戻す
リンクのコピー

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

BareMetalHosts のない遅延バインディングマネージドクラスターの場合、クラスター情報を削除しても、すべてのノードが自動的に Discovery ISO に戻されるわけではありません。

手順

遅延バインディングを使用する非ベアメタルノードのバインドを解除するには、次の手順を実行します。

  1. クラスター情報を削除します。詳細は、マネージメントからのクラスターの削除 を参照してください。
  2. ルートディスクをクリーンアップします。
  3. Discovery ISO を使用して手動で再起動します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat