1.4. 問題のトラブルシューティング

クラスター管理者は、以下の OpenShift Container Platform コンポーネントの問題を監視し、トラブルシューティングできます。

  • インストールの問題: OpenShift Container Platform のインストールは段階をおって進められます。以下を実行できます。

    • インストールステージの監視。
    • インストールのどの段階で発生するかの判断。
    • 複数のインストールの問題調査。
    • 失敗したインストールからのログ収集。
  • ノードの問題: クラスター管理者は、ノードのステータス、リソースの使用状況、およびノードの設定を確認して、ノード関連の問題をトラブルシューティングできます。以下に対してクエリーを実行できます。

    • ノード上の kubelet のステータス。
    • クラスターノードジャーナルログ。
  • crio の問題: クラスター管理者は、各クラスターノードで CRI-O コンテナーランタイムエンジンのステータスを確認できます。コンテナーランタイムの問題が発生した場合には、以下を実行します。

    • CRI-O journald ユニットログを収集します。
    • CRI-O ストレージをクリーンアップします。
  • オペレーティングシステムの問題: OpenShift Container Platform は Red Hat Enterprise Linux CoreOS で実行されます。オペレーティングシステムの問題が発生した場合は、カーネルクラッシュの手順を調査してください。以下の点を行うようにしてください。

    • kdump が有効である。
    • kdump 設定をテストする。
    • コアダンプを分析する。
  • ネットワークの問題: Open vSwitch の問題のトラブルシューティングを行うには、クラスター管理者は以下を行うことができます。

    • Open vSwitch のログレベルを一時的に設定する。
    • Open vSwitch のログレベルを永続的に設定する。
    • Open vSwitch のログを表示する。
  • Operator の問題: クラスター管理者は以下を実行して Operator の問題を解決できます。

    • Operator サブスクリプションのステータスを確認する。
    • Operator Pod の正常性を確認する。
    • Operator ログを収集する。
  • Pod の問題: クラスター管理者は、Pod のステータスを確認して以下を実行し、Pod 関連の問題のトラブルシューティングを行うことができます。

    • Pod およびコンテナーのログを確認する。
    • root アクセスでデバッグ Pod を起動する。
  • Source-to-Image の問題: クラスター管理者は S2I ステージを確認し、S2I プロセスで障害が発生する場所を判別できます。Source-to-Image(S2I) の問題を解決するには、以下を収集します。

    • Source-to-Image 診断データ。
    • アプリケーションの障害を調査するためのアプリケーション診断データ。
  • ストレージの問題: 障害のあるノードがアタッチしたボリュームをアンマウントできないことが原因で新規ノードへのマウントができない場合に、複数割り当てのストレージエラーが発生します。クラスター管理者は、以下を実行して、複数アタッチされているストレージの問題を解決できます。

    • RWX ボリュームを使用して、複数割り当てを有効にします。
    • RWO ボリュームの使用時に障害が発生したノードを回復するか、または削除します。
  • モニターリングの問題: クラスター管理者は、モニターリングのトラブルシューティングページの手順を実行してください。ユーザー定義プロジェクトのメトリクスが利用できない場合や、Prometheus が大量のディスク領域を消費している場合は、以下を確認します。

    • ユーザー定義のメトリクスが利用できない理由を調べる。
    • Prometheus が大量のディスク領域を消費している理由を特定する。
  • ロギングの問題: クラスター管理者は、OpenShift Logging の問題のトラブルシューティングページの手順に従います。以下を参照して、ロギングの問題を解決します。

  • OpenShift CLI(oc) の問題: ログレベルを増やすことで OpenShift CLI(oc) の問題を調査します。