13.13. OpenShift Virtualization の重大なアラート


OpenShift Virtualization には、問題が発生したときに通知するアラートがあります。重大なアラートには早急な対応が必要です。

各アラートには、問題に対する説明、アラートが発生した理由、問題の原因を診断するためのトラブルシューティングプロセス、およびアラートの解決手順が含まれます。

13.13.1. ネットワークアラート

ネットワークアラートは、OpenShift Virtualization Network Operator の問題についての情報を提供します。

13.13.1.1. KubeMacPoolDown アラート

説明

KubeMacPool コンポーネントは MAC アドレスを割り当て、MAC アドレスの競合を防ぎます。

理由

KubeMacPool-manager Pod が停止すると、VirtualMachine オブジェクトの作成に失敗します。

トラブルシューティング

  1. Kubemacpool-manager Pod の namespace および名前を把握します。

    $ export KMP_NAMESPACE="$(oc get pod -A --no-headers -l control-plane=mac-controller-manager | awk '{print $1}')"
    $ export KMP_NAME="$(oc get pod -A --no-headers -l control-plane=mac-controller-manager | awk '{print $2}')"
  2. Kubemacpool-manager Pod の説明およびログを確認して、問題の原因を判断します。

    $ oc describe pod -n $KMP_NAMESPACE $KMP_NAME
    $ oc logs -n $KMP_NAMESPACE $KMP_NAME

解決方法

サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.2. SSP アラート

SSP アラートは、OpenShift Virtualization SSP Operator の問題についての情報を提供します。

13.13.2.1. SSPFailingToReconcile アラート

説明

SSP Operator の Pod が起動しているが、Pod の調整サイクルが必ず失敗する。この失敗には、該当するリソースの更新の失敗、テンプレートバリデータのデプロイの失敗、共通テンプレートのデプロイまたは更新の失敗が含まれます。

理由

SSP Operator が調整に失敗すると、依存するコンポーネントのデプロイメントに失敗するか、コンポーネント変更の調整に失敗するか、あるいはその両方に失敗します。さらに、共通テンプレートおよびテンプレートバリデーターの更新がリセットされ、失敗します。

トラブルシューティング

  1. ssp-operator Pod のログでエラーの有無を確認します。

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | awk '{print $1}')"
    $ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
    $ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
  2. テンプレートバリデーターが起動していることを確認します。テンプレートバリデーターが起動していない場合は、Pod のログでエラーの有無を確認します。

    $ export NAMESPACE="$($ oc get deployment -A | grep ssp-operator | awk '{print $1}')"
    $ oc -n $NAMESPACE get pods -l name=virt-template-validator
    $ oc -n $NAMESPACE describe pods -l name=virt-template-validator
    $ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator

解決方法

サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.2.2. SSPOperatorDown アラート

説明

SSP Operator は、共通テンプレートおよびテンプレートバリデーターをデプロイし、調整します。

理由

SSP Operator が停止するると、依存するコンポーネントのデプロイメントに失敗するか、コンポーネント変更の調整に失敗するか、あるいはその両方に失敗します。さらに、共通テンプレートおよびテンプレートバリデーターの更新がリセットされ、失敗します。

トラブルシューティング

  1. ssp-operator の Pod の namespace を確認します。

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | awk '{print $1}')"
  2. ssp-operator の Pod が現在ダウンしていることを確認します。

    $ oc -n $NAMESPACE get pods -l control-plane=ssp-operator
  3. ssp-operator の Pod の説明およびログを確認します。

    $ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator
    $ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator

解決方法

サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.2.3. SSPTemplateValidatorDown アラート

説明

テンプレートバリデーターは、仮想マシン (VM) が割り当てられたテンプレートに違反していないことを検証します。

理由

すべてのテンプレートバリデーター Pod がダウンしている場合、テンプレートバリデーターは仮想マシンを割り当てられたテンプレートに対して検証するのに失敗します。

トラブルシューティング

  1. ssp-operator Pod および virt-template-validator Pod の namespace を確認します。

    $ export NAMESPACE_SSP="$(oc get deployment -A | grep ssp-operator | awk '{print $1}')"
    $ export NAMESPACE="$(oc get deployment -A | grep virt-template-validator | awk '{print $1}')"
  2. virt-template-validator の Pod が現在ダウンしていることを確認します。

    $ oc -n $NAMESPACE get pods -l name=virt-template-validator
  3. ssp-operator および virt-template-validator の Pod の説明およびログを確認します。

    $ oc -n $NAMESPACE_SSP describe pods -l name=ssp-operator
    $ oc -n $NAMESPACE_SSP logs --tail=-1 -l name=ssp-operator
    $ oc -n $NAMESPACE describe pods -l name=virt-template-validator
    $ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator

解決方法

サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3. virt アラート

virt アラートは、OpenShift Virtualization Virt Operator の問題についての情報を提供します。

13.13.3.1. NoLeadingVirtOperator アラート

説明

過去 10 分間、1 つまたは複数の virt-operator Pod が Ready 状態にあるにもかかわらず、どの virt-operator Pod もリーダーリースを保持しない。アラートは動作している virt-operator Pod が存在しないことを示唆します。

理由

virt-operator は、OpenShift Container Platform クラスターでアクティブな最初の Kubernetes Operator です。その主なロールは以下のとおりです。

  • インストール
  • ライブ更新
  • クラスターのライブアップグレード
  • virt-controller、virt-handler、virt-launcher などの最上位のコントローラーのライフサイクルの監視
  • 最上位のコントローラーの調整の管理

さらに、virt-operator は、証明書のローテーションや一部のインフラストラクチャー管理などのクラスター全体のタスクを行います。

virt-operator デプロイメントには、2 つの Pod のデフォルトレプリカが設定されます。1 つのリーダー Pod はリーダーリースを保持し、動作中の virt-operator Pod であることを示します。

このアラートは、クラスターレベルでの失敗を示します。証明書のローテーション、アップグレード、およびコントローラーの調整などの重要なクラスター全体の管理機能は、一時的に利用できなくなる可能性があります。

トラブルシューティング

Pod のログから virt-operator Pod のリーダーのステータスを判断します。Started leading および acquire leader が含まれるログメッセージは、その virt-operator Pod のリーダーステータスを示します。

さらに、以下のコマンドで、動作中の virt-operator Pod の有無、および Pod のステータスを常に確認します。

$ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
$ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
$ oc -n $NAMESPACE logs <pod-name>
$ oc -n $NAMESPACE describe pod <pod-name>

リーダー Pod の例:

$ oc -n $NAMESPACE logs <pod-name> |grep lead

出力例

{"component":"virt-operator","level":"info","msg":"Attempting to acquire leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:18.635387Z"}
I1130 12:15:18.635452       1 leaderelection.go:243] attempting to acquire leader lease <namespace>/virt-operator...
I1130 12:15:19.216582       1 leaderelection.go:253] successfully acquired lease <namespace>/virt-operator

{"component":"virt-operator","level":"info","msg":"Started leading","pos":"application.go:385","timestamp":"2021-11-30T12:15:19.216836Z"}

リーダー以外の Pod の例:

$ oc -n $NAMESPACE logs <pod-name> |grep lead

出力例

{"component":"virt-operator","level":"info","msg":"Attempting to acquire leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:20.533696Z"}
I1130 12:15:20.533792       1 leaderelection.go:243] attempting to acquire leader lease <namespace>/virt-operator...

解決方法

さまざまな理由により、1 つまたは複数の virt-operator Pod が Ready 状態にあるにもかかわらず、どの virt-operator Pod もリーダーリースを保持しない状況になります。根本原因を特定し、適切なアクションを実行します。

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.2. NoReadyVirtController アラート

説明

virt-controller は、仮想マシンインスタンス (VMI) を監視します。virt-controller は、VMI オブジェクトに関連付けられた Pod のライフサイクルを作成し、管理して、関連付けられた Pod の管理も行います。

VMI オブジェクトは、有効期間中に常に Pod に関連付けられます。ただし、Pod インスタンスは VMI の移行により時間の経過とともに変更される可能性があります。

このアラートは、準備ができている virt-controller が 5 分間検出されなかった場合に発生します。

理由

virt-controller が失敗すると、仮想マシンのライフサイクル管理は完全に失敗します。ライフサイクルの管理タスクには、新規 VMI の起動や既存の VMI のシャットダウンなどが含まれます。

トラブルシューティング

  1. virt-controller のデプロイメントステータスで、利用可能なレプリカおよび条件を確認します。

    $ oc -n $NAMESPACE get deployment virt-controller -o yaml
  2. virt-controller Pod が存在するかどうかを確認し、それらのステータスを確認します。

    get pods -n $NAMESPACE |grep virt-controller
  3. virt-controller Pod のイベントを確認します。

    $ oc -n $NAMESPACE describe pods <virt-controller pod>
  4. virt-controller Pod のログを確認します。

    $ oc -n $NAMESPACE logs <virt-controller pod>
  5. ノードが NotReady 状態にあるなど、ノードに問題があるかどうかを確認します。

    $ oc get nodes

解決方法

Ready 状態にある virt-controller Pod が存在しない理由はいくつかあります。根本原因を特定し、適切なアクションを実行します。

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.3. NoReadyVirtOperator アラート

説明

過去 10 分間、Ready 状態の virt-operator Pod が検出されない。virt-operator デプロイメントには、2 つの Pod のデフォルトレプリカが設定されます。

理由

virt-operator は、OpenShift Container Platform クラスターでアクティブな最初の Kubernetes Operator です。その主なロールは以下のとおりです。

  • インストール
  • ライブ更新
  • クラスターのライブアップグレード
  • virt-controller、virt-handler、virt-launcher などの最上位のコントローラーのライフサイクルの監視
  • 最上位のコントローラーの調整の管理

さらに、virt-operator は、証明書のローテーションや一部のインフラストラクチャー管理などのクラスター全体のタスクを行います。

注記

virt-operator には、クラスター内の仮想マシンに対する直接のロールりはありません。virt-operator が使用できないことは、カスタムワークロードには影響しません。

このアラートは、クラスターレベルでの失敗を示します。証明書のローテーション、アップグレード、およびコントローラーの調整などの重要なクラスター全体の管理機能は、一時的に利用できなくなります。

トラブルシューティング

  1. virt-operator のデプロイメントステータスで、利用可能なレプリカおよび条件を確認します。

    $ oc -n $NAMESPACE get deployment virt-operator -o yaml
  2. virt-controller Pod のイベントを確認します。

    $ oc -n $NAMESPACE describe pods <virt-operator pod>
  3. virt-operator Pod のログを確認します。

    $ oc -n $NAMESPACE logs <virt-operator pod>
  4. NotReady 状態にあるなど、コントロールプレーンおよびマスターのノードに問題があるかどうかを確認します。

    $ oc get nodes

解決方法

Ready 状態にある virt-operator Pod が存在しない理由はいくつかあります。根本原因を特定し、適切なアクションを実行します。

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.4. VirtAPIDown アラート

説明

すべての OpenShift Container Platform API サーバーが停止している。

理由

すべての OpenShift Container Platform API サーバーがダウンしている場合、OpenShift Container Platform エンティティーの API 呼び出しは行われません。

トラブルシューティング

  1. 環境変数 NAMESPACE を変更します。

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
  2. 動作中の virt-api Pod があるかどうかを確認します。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
  3. oc logsを使用して Pod のログを表示し、oc describe を使用して Pod のステータスを表示します。
  4. virt-api デプロイメントのステータスを確認します。以下のコマンドを使用して関連するイベントについて確認し、イメージのプルに関する問題、クラッシュしている Pod、またはその他の同様の問題の有無を表示します。

    $ oc -n $NAMESPACE get deployment virt-api -o yaml
    $ oc -n $NAMESPACE describe deployment virt-api
  5. ノードが NotReady 状態にあるなど、ノードに問題があるかどうかを確認します。

    $ oc get nodes

解決方法

virt-api Pod は、いくつかの理由でダウンする可能性があります。根本原因を特定し、適切なアクションを実行します。

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.5. VirtApiRESTErrorsBurst アラート

説明

過去 5 分間、virt-api で 80% を超える REST 呼び出しが失敗する。

理由

virt-api への REST 呼び出しの失敗率が非常に高くなると、応答が遅くなるか、API 呼び出しの実行が遅くなるか、API 呼び出しがすべて破棄されます。

トラブルシューティング

  1. 環境変数 NAMESPACE を変更します。

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
  2. 動作中の virt-api Pod がいくつあるかを確認します。

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api
  3. oc logsを使用して Pod のログを表示し、oc describe を使用して Pod のステータスを表示します。
  4. virt-api デプロイメントのステータスをチェックして、詳細情報を確認します。以下のコマンドは関連するイベントを提供し、イメージのプルに関する問題またはクラッシュしている Pod があるかどうかを表示します。

    $ oc -n $NAMESPACE get deployment virt-api -o yaml
    $ oc -n $NAMESPACE describe deployment virt-api
  5. ノードがオーバーロード状態にある、または NotReady 状態にあるなど、ノードに問題があるかどうかを確認します。

    $ oc get nodes

解決方法

REST 呼び出しの失敗率が高い理由はいくつかあります。根本原因を特定し、適切なアクションを実行します。

  • ノードリソースの枯渇
  • クラスターに十分なメモリーがない
  • ノードがダウンしている
  • スケジューラーが 100% 利用できない場合など、API サーバーのオーバーロード
  • ネットワークの問題

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.6. VirtControllerDown アラート

説明

過去 5 分間 virt-controller が検出されない場合、virt-controller デプロイメントには 2 つの Pod のデフォルトレプリカが設定されます。

理由

virt-controller が失敗すると、新規 VMI の起動や既存 VMI のシャットダウンなどの仮想マシンのライフサイクル管理タスクが完全に失敗します。

トラブルシューティング

  1. 環境変数 NAMESPACE を変更します。

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
  2. virt-controller デプロイメントのステータスを確認します。

    $ oc get deployment -n $NAMESPACE virt-controller -o yaml
  3. virt-controller Pod のイベントを確認します。

    $ oc -n $NAMESPACE describe pods <virt-controller pod>
  4. virt-controller Pod のログを確認します。

    $ oc -n $NAMESPACE logs <virt-controller pod>
  5. マネージャー Pod のログを確認して、virt-controller Pod の作成に失敗した理由を判断します。

    $ oc get logs <virt-controller-pod>

ログの virt-controller Pod 名の例は virt-controller-7888c64d66-dzc9p です。ただし、virt-controller を実行する Pod が複数存在する場合があります。

解決方法

動作中の virt-controller が検出されない既知の理由がいくつかあります。考えられる理由のリストから根本原因を特定し、適切なアクションを実行します。

  • ノードリソースの枯渇
  • クラスターに十分なメモリーがない
  • ノードがダウンしている
  • スケジューラーが 100% 利用できない場合など、API サーバーのオーバーロード
  • ネットワークの問題

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.7. VirtControllerRESTErrorsBurst アラート

説明

過去 5 分間、virt-controller で 80% を超える REST 呼び出しが失敗する。

理由

virt-controller が、API サーバーへの接続を完全に失った可能性があります。接続の喪失は実行中のワークロードには影響しませんが、ステータス更新の反映や移行などのアクションは実行できません。

トラブルシューティング

virt-controller REST 呼び出しの失敗には、以下の 2 つの一般的なエラータイプがあります。

  • API サーバーのオーバーロードにより、タイムアウトを引き起こす。応答時間や全体の呼び出しなど、API サーバーメトリックと詳細を確認します。
  • virt-controller Pod が API サーバーに到達できない。一般的な原因は以下のとおりです。

    • ノード上の DNS の問題
    • ネットワーク接続の問題

解決方法

virt-controller ログをチェックして、virt-controller Pod が API サーバーにまったく接続できないかどうかを判断します。その場合、Pod を削除して強制的に再起動します。

さらに、ノードリソースが使い切られるか、クラスターに十分なメモリーがないため、接続に失敗しているかどうかを確認します。

通常、問題は、このアラートの範囲外の DNS または CNI の問題に関連しています。

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.8. VirtHandlerRESTErrorsBurst アラート

説明

過去 5 分間、virt-handler で 80% を超える REST 呼び出しが失敗する。

理由

virt-handler が API サーバーへの接続を失った。影響を受けるノードで実行中のワークロードは実行し続けますが、ステータスの更新を反映できず、移行などのアクションを実行できません。

トラブルシューティング

virt-operator REST 呼び出しの失敗には、以下の 2 つの一般的なエラータイプがあります。

  • API サーバーのオーバーロードにより、タイムアウトを引き起こす。応答時間や全体の呼び出しなど、API サーバーメトリックと詳細を確認します。
  • virt-operator Pod が API サーバーに到達できない。一般的な原因は以下のとおりです。

    • ノード上の DNS の問題
    • ネットワーク接続の問題

解決方法

virt-handler が API サーバーに接続できない場合、Pod を削除して強制的に再起動します。通常、問題は、このアラートの範囲外の DNS または CNI の問題に関連しています。根本原因を特定し、適切なアクションを実行します。

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.9. VirtOperatorDown アラート

説明

このアラートは、過去 10 分間 Running 状態の virt-operator Pod が存在しない場合に発生します。virt-operator デプロイメントには、2 つの Pod のデフォルトレプリカが設定されます。

理由

virt-operator は、OpenShift Container Platform クラスターでアクティブな最初の Kubernetes Operator です。その主なロールは以下のとおりです。

  • インストール
  • ライブ更新
  • クラスターのライブアップグレード
  • virt-controller、virt-handler、virt-launcher などの最上位のコントローラーのライフサイクルの監視
  • 最上位のコントローラーの調整の管理

さらに、virt-operator は、証明書のローテーションや一部のインフラストラクチャー管理などのクラスター全体のタスクを行います。

注記

virt-operator には、クラスター内の仮想マシンに対する直接のロールりはありません。virt-operator が使用できないことは、カスタムワークロードには影響しません。

このアラートは、クラスターレベルでの失敗を示します。証明書のローテーション、アップグレード、およびコントローラーの調整などの重要なクラスター全体の管理機能は、一時的に利用できなくなります。

トラブルシューティング

  1. 環境変数 NAMESPACE を変更します。

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
  2. virt-operator デプロイメントのステータスを確認します。

    $ oc get deployment -n $NAMESPACE virt-operator -o yaml
  3. virt-operator Pod のイベントを確認します。

    $ oc -n $NAMESPACE describe pods <virt-operator pod>
  4. virt-operator Pod のログを確認します。

    $ oc -n $NAMESPACE logs <virt-operator pod>
  5. マネージャー Pod のログを確認して、virt-operator Pod の作成に失敗した理由を判断します。

    $ oc get logs <virt-operator-pod>

ログの virt-operator Pod 名の例は virt-operator-7888c64d66-dzc9p です。ただし、virt-operator を実行する Pod が複数存在する場合があります。

解決方法

動作中の virt-operator が検出されない既知の理由がいくつかあります。考えられる理由のリストから根本原因を特定し、適切なアクションを実行します。

  • ノードリソースの枯渇
  • クラスターに十分なメモリーがない
  • ノードがダウンしている
  • スケジューラーが 100% 利用できない場合など、API サーバーのオーバーロード
  • ネットワークの問題

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.3.10. VirtOperatorRESTErrorsBurst アラート

説明

過去 5 分間、virt-operator で 80% を超える REST 呼び出しが失敗する。

理由

virt-operator が API サーバーへの接続を失った。アップグレードおよびコントローラーの調整などのクラスターレベルのアクションは機能しません。仮想マシンや VMI などのお客様のワークロードには影響がありません。

トラブルシューティング

virt-operator REST 呼び出しの失敗には、以下の 2 つの一般的なエラータイプがあります。

  • API サーバーのオーバーロードにより、タイムアウトを引き起こす。応答時間や全体の呼び出しなど、API サーバーメトリックと詳細を確認します。
  • virt-operator Pod が API サーバーに到達できない。一般的な原因は、ネットワークの接続性の問題や、ノードでの DNS の問題です。virt-operator ログをチェックして、Pod が API サーバーに接続できることを確認します。

    $ export NAMESPACE="$(oc get kubevirt -A -o custom-columns="":.metadata.namespace)"
    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator
    $ oc -n $NAMESPACE logs <pod-name>
    $ oc -n $NAMESPACE describe pod <pod-name>

解決方法

virt-operator が API サーバーに接続できない場合、Pod を削除して強制的に再起動します。通常、問題は、このアラートの範囲外の DNS または CNI の問題に関連しています。根本原因を特定し、適切なアクションを実行します。

それ以外には、サポートケースを作成し、トラブルシューティングのプロセスで収集された情報を提供します。

13.13.4. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.