7.8. Source-to-Image (S2I) プロセスのトラブルシューティング

1. ビルド設定の段階 で、ビルド Pod はベースイメージおよびアプリケーションのソースコードからアプリケーションコンテナーイメージを作成するために使用されます。
2. デプロイメント設定の段階 で、デプロイメント Pod はビルド設定段階でビルドされたアプリケーションコンテナーイメージからアプリケーション Pod をデプロイするために使用されます。デプロイメント Pod は、サービスやルートなどの他のリソースもデプロイします。デプロイメント設定は、ビルド設定が成功すると開始されます。
3. デプロイメント Pod のアプリケーション Pod の起動後 に、アプリケーションの障害が実行中のアプリケーション Pod 内で発生する可能性があります。たとえば、アプリケーション Pod が Running 状態であっても、アプリケーションは予想通りに動作しない可能性があります。このシナリオでは、実行中のアプリケーション Pod にアクセスして、Pod 内のアプリケーションの障害を調査できます。

1. ビルド、デプロイメント、およびアプリケーション Pod ステータスの監視
2. 問題が発生した S2I プロセスのステージの判別
3. 失敗したステージに対応するログの確認

手順

1. S2I プロセス全体での Pod のステータスを確認し、障害が発生するステージを判別します。

   $ oc get pods -w  

   1

   Copy to Clipboard Toggle word wrap

   1

   -w を使用して、Ctrl+C を使用してコマンドを終了するまで Pod で変更の有無を監視します。

2. 障害のある Pod のログでエラーの有無を確認します。

   • ビルド Pod が失敗する場合、ビルド Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-build

     Copy to Clipboard Toggle word wrap
     注記

     または、oc logs -f bc/<application_name> を使用して、ビルド設定のログを確認できます。ビルド設定のログには、ビルド Pod からのログが含まれます。

   • デプロイメント Pod が失敗する場合、デプロイメント Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-deploy

     Copy to Clipboard Toggle word wrap
     注記

     または、oc logs -f dc/<application_name> を使用して、デプロイメント設定のログを確認できます。これにより、デプロイメント Pod が正常に実行されるまで、デプロイメント Pod からログが出力されます。デプロイメント Pod の完了後に実行すると、コマンドはアプリケーション Pod からログを出力します。デプロイメント Pod の完了後も、oc logs -f pod/<application_name>-<build_number>-deploy を実行してログにアクセスできます。

   • アプリケーション Pod が失敗した場合や、アプリケーションが実行中のアプリケーション Pod 内で予想通りに動作しない場合、アプリケーション Pod のログを確認します。

     $ oc logs -f pod/<application_name>-<build_number>-<random_string>

     Copy to Clipboard Toggle word wrap

手順

1. 特定のアプリケーション Pod に関連するイベントを一覧表示します。以下の例では、my-app-1-akdlg という名前のアプリケーション Pod のイベントを取得します。

   $ oc describe pod/my-app-1-akdlg

   Copy to Clipboard Toggle word wrap

2. アプリケーション Pod からのログを確認します。

   $ oc logs -f pod/my-app-1-akdlg

   Copy to Clipboard Toggle word wrap

3. 実行中のアプリケーション Pod 内で特定のログをクエリーします。標準出力 (stdout) に送信されるログは OpenShift Logging フレームワークによって収集され、これは前述のコマンドの出力に含まれます。以下のクエリーは、標準出力 (stdout) に送信されないログにのみ必要です。

   1. Pod 内で root 権限なしにアプリケーションログにアクセスできる場合は、以下のようにログファイルを連結します。

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log

      Copy to Clipboard Toggle word wrap

   2. アプリケーションログの表示に root アクセスが必要な場合は、root 権限でデバッグコンテナーを起動し、コンテナー内でログファイルを表示できます。プロジェクトの DeploymentConfig オブジェクトからデバッグコンテナーを起動します。通常、Pod ユーザーは root 以外の権限で実行しますが、問題を調査するために一時的な root 権限で Pod のトラブルシューティングを実行することは役に立ちます。

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log

      Copy to Clipboard Toggle word wrap
      注記

      oc debug dc/<deployment_configuration> --as-root を -- <command> を追加せずに実行する場合、デバッグ Pod 内で root アクセスでインタラクティブなシェルにアクセスできます。

4. インタラクティブなシェルでアプリケーション機能を対話的にテストし、アプリケーションコンテナーで診断ツールを実行します。

   1. アプリケーションコンテナーでインタラクティブなシェルを起動します。

      $ oc exec -it my-app-1-akdlg /bin/bash

      Copy to Clipboard Toggle word wrap
   2. シェルからアプリケーションの機能を対話的にテストします。たとえば、コンテナーのエントリーポイントコマンドを実行して、結果を確認することができます。次に、ソースコードを更新し、S2I プロセスでアプリケーションコンテナーを再ビルドする前に、コマンドラインから直接に変更をテストします。

   3. コンテナー内で利用可能な診断バイナリーを実行します。

      注記

      一部の診断バイナリーを実行するには、root 権限が必要です。このような状況では、oc debug dc/<deployment_configuration> --as-root を実行して、問題のある Pod の DeploymentConfig オブジェクトに基づいて、root 権限でデバッグ Pod を起動できます。次に、デバッグ Pod 内から診断バイナリーを root として実行できます。

5. 診断バイナリーがコンテナー内で利用できない場合は、nsenter を使用して、コンテナーの namespace 内でホストの診断バイナリーを実行できます。以下の例では、ホストの ip バイナリーを使用して、コンテナーの namespace 内で ip ad を実行します。

   1. ターゲットノードのデバッグセッションに入ります。この手順は、<node_name>-debug というデバッグ Pod をインスタンス化します。

      $ oc debug node/my-cluster-node

      Copy to Clipboard Toggle word wrap

   2. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にホストの root ファイルシステムをマウントします。root ディレクトリーを /host に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。

      # chroot /host

      Copy to Clipboard Toggle word wrap
      注記

      Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.9 クラスターノードは変更できず、Operator を使用してクラスターの変更を適用します。SSH を使用したクラスターノードへのアクセスは推奨されず、ノードは accessed のテイントのマークが付けられます。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc 操作がその影響を受けます。この場合は、代わりに ssh core@<node>.<cluster_name>.<base_domain> を使用してノードにアクセスできます。

   3. ターゲットコンテナー ID を判別します。

      # crictl ps

      Copy to Clipboard Toggle word wrap

   4. コンテナーのプロセス ID を確認します。この例では、ターゲットコンテナー ID は a7fe32346b120 です。

      # crictl inspect a7fe32346b120 --output yaml | grep 'pid:' | awk '{print $2}'

      Copy to Clipboard Toggle word wrap

   5. ホストの ip バイナリーを使用して、コンテナーの namespace 内で ip ad を実行します。この例では、31150 をコンテナーのプロセス ID として使用します。nsenter コマンドは、ターゲットプロセスの namespace を入力し、その namespace でコマンドを実行します。この例のターゲットプロセスはコンテナーのプロセス ID であるため、ip ad コマンドは、ホストからコンテナーの namespace で実行されます。

      # nsenter -n -t 31150 -- ip ad

      Copy to Clipboard Toggle word wrap
      注記

      デバッグノードなどの特権付きコンテナーを使用している場合のみ、コンテナーの namespace 内でホストの診断バイナリーを実行できます。