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 CLI (oc) の問題: ログレベルを増やすことで OpenShift CLI (oc) の問題を調査します。