【OpenShift】一般的な問題のトラブルシューティング
0.はじめに
OpenShift Container Platform（以下、OCP）入門者向けに、OpenShiftの一般的なトラブルシューティングついて解説します。
OpenShiftの一般的なトラブルシューティングには、特定のリソースが正常に動作しない場合に、原因を特定し問題を解決するための調査が必要です。
代表的なトラブルシナリオとその調査・対応方法について、主なCLIコマンドとその例を交えながら説明します。
では、次の章から具体的な解説を進めます！
1. コンテナの起動失敗/クラッシュ
主な原因
- イメージの取得失敗
- コンテナ内アプリケーションのエラー
- リソース不足（メモリ不足など）
調査方法とコマンド
コマンド例1: コンテナのログ確認
oc logs コマンドでログを確認し、アプリケーションエラーの詳細を確認します。
oc logs pod/<pod-name>
実行結果の例:
Error: Failed to pull image "my-image": rpc error: code = Unknown desc = Error response from daemon
- イメージのプルに失敗していることが確認できます。この場合、イメージのパスやレジストリの設定を見直す必要があります。
コマンド例2: Podの詳細情報
oc describe コマンドでPodの詳細とイベントを確認します。
oc describe pod <pod-name>
実行結果の例:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Failed 1m kubelet Error: CrashLoopBackOff
-
CrashLoopBackOffなどの状態が表示される場合は、リソース不足やアプリケーションエラーの可能性が高いです。原因の特定にあたり、コンテナログの確認やリソース割り当ての見直しが必要です。
コマンド例3: リソース使用状況の確認
リソース不足が原因でコンテナがクラッシュしている可能性を調べるには、oc adm top コマンドでリソース使用状況を確認します。
oc adm top pod <pod-name>
2. Podのステータス異常（Pendingなど）
主な原因
- スケジューリングリソース不足（CPUやメモリ）
- ボリュームがアタッチされていない
- ネットワークの問題
調査方法とコマンド
コマンド例1: Podの詳細情報
oc describe コマンドでPodがスケジューリングされない理由を確認します。
oc describe pod <pod-name>
実行結果の例:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 1m default-scheduler 0/3 nodes are available: 3 Insufficient memory.
-
Insufficient memoryやInsufficient cpuなどのメッセージがある場合は、ノードのリソース不足が原因です。ノードにリソースを追加するか、Podのリソース要求を調整します。
コマンド例2: リソース使用状況の確認
ノードのリソース状況を確認し、リソース不足を特定します。
oc adm top nodes
3. クラスター（etcdの問題）
主な原因
- etcdのデータストアが過負荷
- etcdクラスターノード間の通信不具合
- ディスクのI/O遅延
調査方法とコマンド
コマンド例1: etcdのPod状態確認
etcdのPodが正常に稼働しているか確認します。
oc get pods -n openshift-etcd
実行結果の例:
NAME READY STATUS RESTARTS AGE
etcd-crc 1/1 Running 0 5d
-
STATUS が
Runningでない場合は、etcdのPodが正常に稼働していない可能性があります。
コマンド例2: etcdの詳細ログ確認
etcdのログを確認し、詳細なエラーを調査します。
oc logs -n openshift-etcd etcd-crc
コマンド例3: etcdの健康状態確認
etcdctl コマンドを使用して、etcdの健康状態を確認します。
oc -n openshift-etcd rsh etcd-crc
etcdctl endpoint health
-
is healthyが表示されれば正常ですが、異常がある場合は負荷や接続の問題が考えられます。
4. クラスター（ネットワークの問題）
主な原因
- ノード間の通信エラー
- ネットワークポリシーによるアクセス制限
- Pod内のDNS設定エラー
調査方法とコマンド
コマンド例1: ノード間通信の確認
oc exec でPingテストを行い、Pod間で通信が正常に行えるか確認します。
oc exec <pod-name> -- ping <another-pod>
実行結果の例:
PING <another-pod> (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=0.063 ms
- 応答がない場合は、ネットワーク接続に問題がある可能性があります。ネットワークポリシーやDNS設定を確認してください。
コマンド例2: トレースルートで通信経路確認
トレースルートを使って、ネットワーク経路に問題がないか確認します。
oc exec <pod-name> -- traceroute <another-pod>
コマンド例3: Podのイベントログを確認
ネットワーク関連のエラーがないかイベントを調査します。
oc get events --field-selector involvedObject.name=<pod-name>
5.おわりに
今回はOpenShiftの一般的なトラブルシューティングについて理解を深めるために、以下を学びました。
-
コンテナの起動失敗/クラッシュ:
oc logsとoc describeコマンドでエラーを確認し、リソース使用量やコンテナ内アプリケーションの問題を特定します。 -
Podのステータス異常:
oc describeコマンドでPendingの原因を確認し、リソースの割り当てやノードのリソース状況を調査します。 -
クラスター（etcdの問題）: etcdのPodやログを確認し、
etcdctlで健康状態を確認します。 -
クラスター（ネットワークの問題）:
oc execでPingやトレースルートを実行し、ノードやPod間のネットワーク接続を確認します。
これらのコマンドと調査方法を使い分けることで、OpenShiftのトラブルシューティングが効果的に行えます。
1回で覚えるのは難しいと思うので、何度かトライして覚えるで全然大丈夫です。
今後もOpenShiftについて解説していきます。
おわりっ！
Discussion