type
status
date
slug
summary
tags
category
icon
password
书籍
ガイド付き演習
一般的な問題のトラブルシューティング
この演習では、OpenShift 上でアプリケーションのデプロイが失敗した場合に、問題を特定して修正する方法を学びます。
成果物
OpenShift 上でアプリケーションのデプロイが失敗した場合、その問題を特定し、修正できるようになることが目標です。
開始前の準備
第7章「OpenShift Container Platform のインストール」での全てのラボを完了し、マスターと 2 台のノードが稼働している OpenShift クラスターを用意する必要があります。もしクラスターが正しく構成されていない場合は、以下のコマンドを使用してマスター、ノード1、ノード2 をリセットし、ワークステーションホストで環境が正しく設定されていることを確認します：
その後、ワークステーションのターミナルで以下のコマンドを実行して、マスター、ノード1、ノード2 が起動していることを確認し、このガイド付き演習に必要なファイルをダウンロードします：
1. 新しいプロジェクトを作成する
1.1. ワークステーションホストで、OpenShift マスター（
https://master.lab.example.com）にアクセスし、OpenShift クライアントでログインします。セキュリティ証明書を承認します。1.2. 次に、
common-troubleshoot プロジェクトを作成します：2. Source-to-Image (S2I) アプリケーションをデプロイする
2.1. OpenShift で、
php-helloworld アプリケーションのソースコードを使用して新しいアプリケーションを作成します。ソースコードはサービス VM 上の Git リポジトリにあります。エラーが発生します：
このエラーメッセージは、
php:5.4 に一致する複数のイメージがあることを示しています。次に、正しいイメージストリームタグを確認します。2.2.
php イメージストリームの有効なタグを oc describe コマンドでリストします。出力には、
php:7.0 と php:5.6 が有効なタグであり、php:7.1 と php:5.5 は無効であることが示されています。これは、これらのイメージが利用できないためです。2.3. 正しいイメージストリームタグを使ってアプリケーションをデプロイします：
これで、次のように出力され、ビルドがスケジュールされます：
oc new-app コマンドは正常に成功しました。2.4. アプリケーションが正常にビルドおよびデプロイされたことを確認する
次に、アプリケーションが正常にビルドされ、デプロイされたかを確認します。以下のコマンドを実行して、ポッドの状態を確認します：
出力例：
この場合、
hello-1-build ポッドが Pending 状態で、アプリケーションのポッドが起動していません。この状態の理由を調査し、問題を修正する必要があります。3. ビルダーポッドのログを確認する
ビルダーポッドのログを確認するために、
oc logs コマンドを使用します：しかし、ログに有益な情報は表示されません。このコマンドは何も出力しないため、他の方法で調査を進めます。
4. プロジェクトのイベントログを確認する
プロジェクトのイベントログを確認する方法として、
oc get events コマンドを使用します：出力例：
このイベントログには、
FailedScheduling 警告が表示され、理由として「利用可能なノードが 0/3」であることが示されています。また、oc describe コマンドを使用してさらに詳細な情報を確認できます：出力例：
ここでも
FailedScheduling 警告が表示されており、イベントログからはノードが利用できないことがわかります。5. ノードの状態を調査する
次に、ノードの状態を確認します。
oc get nodes コマンドを実行して、クラスタ内のノードの状態を調査します。このコマンドは、マスターホストで root ユーザーとして実行する必要があります：出力例：
出力から、
node1 と node2 の両方が NotReady 状態であることが確認できます。Kubernetes は NotReady とマークされたノードでポッドをスケジュールできません。注意
もしこのステップで以下のようなエラーが表示された場合：
その場合は、マスターに root ユーザーでログインし、以下のコマンドを実行してから再度
oc get nodes を実行します：6. ノードが Ready 状態でない原因を調査する
ノードが
Ready 状態でない原因を調べます。OpenShift ノードは atomic-openshift-node サービスを実行している必要があります。このサービスは、マスターと通信し、マスターがスケジュールしたポッドを実行します。ワークステーションで 2 つの新しいターミナルを開き、
node1 と node2 に root ユーザーで SSH でログインします：各ノードで
atomic-openshift-node サービスの状態を確認します：出力例：
このエラーメッセージは、ノード上の Docker デーモンに接続できないことを示しています。
7. Docker サービスの状態を確認する
次に、ノード上で
docker サービスの状態を確認します：出力例：
両方のノードで Docker サービスが
inactive 状態であり、起動していないことが確認できます。これが原因で、ノードが NotReady 状態になっています。このように、ノードの状態とサービスを確認することで、問題の原因を特定し、解決に向けて進めることができます。
8. Docker サービスを両方のノードで開始する
まず、
node1 と node2 ノードで Docker サービスを起動します：9. ノードが Ready 状態であることを確認する
ワークステーションホストから、
oc get nodes コマンドを実行して、両方のノードが Ready 状態になったことを確認します：出力例：
注意: ノードが
Ready 状態に変わるまでに数分かかることがあります。10. ポッドが Running 状態であることを確認する
ワークステーション VM から、アプリケーションのポッドが
Running 状態であることを確認します：出力例：
アプリケーションポッドが
Running 状態であることが確認できれば、ビルドとデプロイは成功しています。注意: アプリケーションがビルドおよびデプロイされるまでに時間がかかる場合があるため、コマンドを繰り返し実行して状態を確認します。
追加の情報：ビルドログに関する警告
ビルド中に以下のような警告が表示される場合がありますが、アプリケーションポッドが
Running 状態であれば無視して問題ありません：これらの警告はアプリケーションのビルドが完了したことを示しています。
11. OpenShift 内部レジストリにアプリケーションがビルドされていることを確認
アプリケーションが OpenShift 内部レジストリに正常にビルドされ、プッシュされたことを確認するために、
oc describe is コマンドを実行します：出力例：
この結果から、アプリケーションが OpenShift 内部レジストリに正常にプッシュされていることがわかります。
12. プロジェクトのクリーンアップ
最後に、使用したプロジェクトを削除します：
これで、すべての作業が完了し、プロジェクトがクリーンアップされました。
このガイド付き演習はこれで終了です。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/1a7d7ae8-88e2-8002-9aa8-d592d208faf4
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
