Red Hat OpenShift on IBM Cloud でのアプリのトラブルシューティング

仮想プライベートクラウド クラシック・インフラストラクチャー Satellite

以下のステップは、クラスター内のアプリケーションの問題をトラブルシューティングし、アプリケーション・エラーまたは問題の根本原因を見つけるのに役立ちます。

IBM Cloud の状況を確認します。

  1. IBM Cloud が利用可能かどうかを確認するには、 IBM Cloud のステータスページをご確認ください。
  2. Red Hat OpenShift on IBM Cloudコンポーネントのフィルタ。
  3. 制限事項と既知の問題に関する資料を確認します。
  4. IBM Cloud で利用されているオープンソースプロジェクトに関する問題については、「 IBM のオープンソースおよびサードパーティに関するポリシー 」をご覧ください。 例えば、 Red Hat OpenShift のBugzilla を確認してみるといいでしょう。

クラスターの状態と状況を取得し、一般的な問題を確認します。

  1. クラスターをリストし、クラスターの State を見つけます。

    ibmcloud oc cluster ls

  2. クラスターの State を確認します。 クラスターが Critical、Delete failed、Warning のいずれかの状態であるか、または長時間 Pending 状態のままである場合。 詳しくは、クラスターの状態を参照してください。

  3. 各ワーカー・ノードの状態を確認します。 詳しくは、ワーカー・ノードの状態を参照してください。

    ibmcloud oc worker ls -c CLUSTER

  4. ワーカーノードの問題をデバッグまたはトラブルシューティングするために、以下の情報を確認してください。

詳細を収集し、問題を文書化する

問題に関する詳細を文書化するときは、可能な限り具体的にしてください。 例えば、 Our app occasionally gets 502 Gateway errors when trying to retrieve transaction logs は具体的ではないため、役に立ちません。 文書化する前に、問題をできるだけ絞り込んでおくこと。 問題を文書化する際には、以下を含めてください。

環境アーキテクチャー
環境アーキテクチャを文書化し、関係するコンポーネントを理解していることを確認してください。 詳しくは、 環境アーキテクチャーの文書化 を参照してください。
エラー・メッセージおよびコンポーネントの詳細。
完全なエラー・メッセージを提供し、どのコンポーネントがエラーを生成しているかについての詳細を含めてください。 例えば、" clusterID ABCDEFの3つのアプリポッドすべてが、グローバルロードバランサーからのGET /transaction-logsへの HTTPS 呼び出しで、エラー HTTP 502 Gateway Error: Web server received an invalid response while acting as a gateway or proxy server..."で失敗することがある。
接続のソース IP、宛先 IP、ポート、およびプロトコル。
例えば、「 clusterID ABCDEF を持つ Kubernetes クラスター内の 3 つのすべてのアプリ・ポッド。 GLBに/transaction-logsをGETしようとすると、 HTTPS、「The source pod IP is 172.22.5.10 and destination IP is 150.40.40.35 port 433」というエラーで失敗することがある。 プロトコルは HTTPS。 他の 2 つの GLB IP 150.40.40.55 および 150.40.40.75" と同様に、他のポッドもこの IP アドレスを使用します。
問題の開始日、開始時刻、および頻度。
以下のメッセージ例を確認してください。
  • この問題は、すべての接続試行の約 2% に影響します。
  • この問題は、19:00 から 21:00 UTC の間にのみ発生し、その間はすべての接続試行の約 5% に影響します。
  • この問題は、ポッド ID XYZ からの接続時に発生します。 この問題は、 10/25/2023 で約 05:30 UTC に発生しました。
既に実行したアクションのトラブルシューティング。
これまでに試行されたことと、それらの試行の結果を文書化して、問題をさらに絞り込むことができます。

各コンポーネントをルール・インまたはルール・アウトするためのテストの実行

  1. 完全なアプリケーション・フローの外部で問題を再現してみてください。 これには、以下が含まれる場合があります。
    • 別のシステムまたはクラスター内のテスト・ポッドのいずれかで curl を使用してバックエンド・エンドポイントまたはサービスに接続し、クライアントが問題の原因である可能性があることをルール・インまたはルール・アウトします。
    • クライアントまたはクラスター内のテスト・ポッドから www.ibm.com などの既知のエンドポイントに接続しようとしています。 既知のエンドポイントは一貫して機能するが、実際のアプリ・エンドポイントは機能しない場合は、問題を絞り込むのに役立ちます。
  2. テスト・クラスターを使用して、テスト環境で問題を再現してみてください。
    • テスト・クラスターで問題を再現 できない 場合は、問題の考えられる原因として、テスト・クラスターと実際のクラスターの違いに焦点を当てることができます。
    • テスト・クラスターで再作成 できる 場合は、クラスター自体に問題がない可能性があります。 また、実稼働環境に影響を与えることなく、テストして問題をさらに絞り込むことができる環境もあります。

より多くのデータの収集

アプリのフロー、表示されている具体的なエラー、およびそのエラーの発生元が分かったら、関連するコンポーネントからより詳細なデータを収集できます。 これには、以下のログが含まれる場合があります。

  • 影響を受けるコンポーネントに関するポッドおよびプロセスのログ。
  • syslog や /var/log/messages などのクラスター・ノード・ログ。 Red Hat OpenShift on IBM Cloud の場合、ノードから直接 およびその他のログ syslog を取得できます。
  • パケット・トレース情報。 実行 tcpdump はパケットトレース情報を取得する一般的な方法である。

次のステップ

問題が解決しない場合は、サポートにお問い合わせください。 サポート Case を開きます。 ケースの詳細には、関連するログ・ファイル、エラー・メッセージ、またはコマンド出力を必ず含めてください。