IBM Cloud Kubernetes Service でのアプリケーションのトラブルシューティング

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

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

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

  1. IBM Cloud が利用可能かどうかは、 IBM Cloud のステータスページで確認できる
  2. Kubernetes Service コンポーネントでフィルタリングします。
  3. 制限事項と既知の問題に関するドキュメンテーションを確認します。
  4. IBM Cloud で使用されているオープンソースプロジェクトにおける問題については、 IBM オープンソースおよびサードパーティのポリシーを参照してください。 例えば、 Kubernetes の 未解決問題をチェックすることができる。

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

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

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

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

    ibmcloud ks 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 などのクラスター・ノード・ログ。 IBM Cloud Kubernetes Service の場合、ノードから直接 およびその他のログ syslog を取得できます。
  • パケット・トレース情報。 実行 tcpdump はパケットトレース情報を取得する一般的な方法である。

Slack で連絡を取るか、ユーザー・フォーラムで同様の問題を検討する

  1. Kubernetes Service Slack に投稿します。
    • 外部ユーザーの場合は、#general チャネルに投稿します。
  2. Kubernetes Service ヘルプや Stack Overflow などのフォーラムを参照して、同じ問題を経験したユーザーが他にいないか調べます。 フォーラムで質問する際には、IBM Cloud 開発チームによって認識されるように、質問にタグを付けてください。
    • IBM Cloud Kubernetes Service を使用したクラスタやアプリの開発やデプロイに関する技術的な質問がある場合は、 Stack Overflow に質問を投稿し、 ibm-cloudcontainers のタグを付けてください。
    • フォーラムの使用について詳しくは、ヘルプの取得を参照してください。

次のステップ

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