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) の問題を調査します。
