14.4. OpenShift Virtualization でのホステッドクラスターのトラブルシューティング
OpenShift Virtualization でホステッドクラスターのトラブルシューティングを行う場合は、トップレベルの HostedCluster リソースと NodePool リソースから始めて、根本原因が見つかるまでスタックを下位に向かって作業します。以下の手順は、一般的な問題の根本原因を検出するのに役立ちます。
14.4.1. HostedCluster リソースが partial 状態でスタックする リンクのコピーリンクがクリップボードにコピーされました!
HostedCluster リソースが保留中であるために Hosted Control Plane が完全にオンラインにならない場合は、前提条件、リソースの状態、ノードと Operator のステータスを確認して問題を特定します。
手順
- OpenShift Virtualization 上のホステッドクラスターの前提条件をすべて満たしていることを確認します。
-
進行を妨げる検証エラーがないか、
HostedClusterリソースとNodePoolリソースの状態を表示します。 ホステッドクラスターの
kubeconfigファイルを使用して、ホステッドクラスターのステータスを検査します。-
oc get clusteroperatorsコマンドの出力を表示して、保留中のクラスター Operator を表示します。 -
oc get nodesコマンドの出力を表示して、ワーカーノードの準備ができていることを確認します。
-
14.4.2. ワーカーノードが登録されない リンクのコピーリンクがクリップボードにコピーされました!
Hosted Control Plane にワーカーノードが登録されないために Hosted Control Plane が完全にオンラインにならない場合は、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-launchervirt-launcher Pod が保留状態にある場合は、Pod がスケジュールされていない理由を調査してください。たとえば、virt-launcher Pod の実行に必要なリソースが十分存在しない可能性があります。
- 仮想マシンが実行されていてもワーカーノードとして登録されていない場合は、Web コンソールを使用して、影響を受ける仮想マシンの 1 つへの VNC アクセスを取得します。VNC 出力は ignition 設定が適用されたかどうかを示します。仮想マシンが起動時に Hosted Control Plane Ignition サーバーにアクセスできない場合、仮想マシンは正しくプロビジョニングできません。
- Ignition 設定が適用されても、仮想マシンがノードとして登録されない場合は、問題の特定: 仮想マシンコンソールログへのアクセス で、起動時に仮想マシンコンソールログにアクセスする方法を確認してください。
14.4.3. ワーカーノードが NotReady 状態でスタックする リンクのコピーリンクがクリップボードにコピーされました!
クラスターの作成中、ネットワークスタックがロールアウトされる間、ノードは一時的に NotReady 状態になります。プロセスのこの部分は正常です。ただし、このプロセス部分にかかる時間が 15 分を超える場合は、ノードオブジェクトと Pod を調査して問題を特定します。
手順
次のコマンドを入力して、ノードオブジェクトの状態を表示し、ノードの準備ができていない理由を特定します。
$ oc get nodes -o yaml次のコマンドを入力して、クラスター内で障害が発生している Pod を探します。
$ oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded
14.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"}}]'Hosted Control Plane にカスタムベースドメインを使用する場合は、次の手順を実行します。
- ロードバランサーが仮想マシン Pod を正しくターゲットにしていることを確認します。
- ワイルドカード DNS エントリーがロードバランサー IP をターゲットにしていることを確認します。
14.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
14.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-driverPVC が永続ボリューム (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
14.4.7. 仮想マシンノードがクラスターに正しく参加していない リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンノードがクラスターに正しく参加していないために Hosted Control Plane が完全にオンラインにならない場合は、仮想マシンコンソールログにアクセスします。
手順
- 仮想マシンコンソールログにアクセスするには、How to get serial console logs for VMs part of OpenShift Virtualization Hosted Control Plane clusters の手順を実行します。
14.4.8. RHCOS イメージのミラーリングが失敗する リンクのコピーリンクがクリップボードにコピーされました!
非接続環境の OpenShift Virtualization 上の Hosted Control Plane の場合、oc-mirror で、Red Hat Enterprise Linux CoreOS (RHCOS) イメージを内部レジストリーに自動的にミラーリングできません。最初のホステッドクラスターを作成するときに、ブートイメージを内部レジストリーで利用できないため、Kubevirt 仮想マシンが起動しません。
この問題を解決するには、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: - virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev1 source: quay.io/openshift-release-dev/ocp-v4.0-art-dev2 次のコマンドを実行して、
rhcos-boot-kubevirt.yamlファイルを適用し、ImageDigestMirrorSetオブジェクトを作成します。$ oc apply -f rhcos-boot-kubevirt.yaml
14.4.9. 非ベアメタルクラスターを遅延バインディングプールに戻す リンクのコピーリンクがクリップボードにコピーされました!
BareMetalHosts なしで遅延バインディングマネージドクラスターを使用している場合は、遅延バインディングクラスターを削除し、ノードを Discovery ISO に戻すための追加の手動手順を実行する必要があります。
BareMetalHosts のない遅延バインディングマネージドクラスターの場合、クラスター情報を削除しても、すべてのノードが自動的に Discovery ISO に戻されるわけではありません。
手順
遅延バインディングを使用する非ベアメタルノードのバインドを解除するには、次の手順を実行します。
- クラスター情報を削除します。詳細は、マネージメントからのクラスターの削除 を参照してください。
- ルートディスクをクリーンアップします。
- Discovery ISO を使用して手動で再起動します。