開始前に

オブザーバビリティ・サービスを使用してクラスターのデバッグを行う前に、以下の要件が満たされていることを確認してください。

• お使いのクラスタは、 IBM Cloud Monitoring インスタンスに接続されています。 クラスタを接続するには、「 Red Hat OpenShift on IBM Cloud のメトリクスの有効化 」を参照してください。
• お使いのクラスタは、 IBM Cloud Logs インスタンスに接続されています。 クラスタを接続するには、「 ロギングの有効化 」を参照してください。
• アカウント内の「 IBM Cloud Monitoring 」および「 IBM Cloud Logs 」のサービスインスタンスに対して、少なくとも 「Viewer」 権限を持っています。

以下のコマンドでワーカーノードのリソース使用状況を確認します。 IBM Cloud Monitoring

ワーカーノードが「 Critical 」または「 NotReady 」状態になるときは、CPU やメモリの使用率が高いことが一般的な原因となります。 IBM Cloud Monitoring の既成ダッシュボードを使用して、リソースへの負荷を迅速に特定します。

1. クラスタの「 IBM Cloud Monitoring 」ダッシュボードを開きます。

   1. IBM Cloud コンソールで、クラスタリソースページに移動し、該当するクラスタをクリックします。
   2. 「 統合 」の下にある「 モニタリング 」オプションを見つけて、「 起動 」をクリックします。 IBM Cloud Monitoring のUIが新しいウィンドウで開きます。

2. [ Kubernetes > 「 Nodes 」のプリビルドダッシュボードに移動し、ノードごとのCPUおよびメモリ使用状況を確認します。

   • CPU使用率またはメモリ使用率が80% を超えるノードを探してください。 この閾値以上にあるノードは、過負荷になるリスクがあり、新しいポッドのスケジューリングに失敗し始める可能性があります。
   • 過去1時間または1日の間に、CPUやメモリの使用率が急激に上昇した、あるいは一貫して高水準にあるノードを探してください。 これにより、その問題が一時的なものか、それとも継続的なものかを判断するのに役立ちます。

3. 特定のノードを調べるには、ダッシュボード上のノード名をクリックして、すべてのチャートをそのノードに絞り込んでください。 以下の指標を確認してください：

   • CPU使用率（%） — 90%を超える状態が持続する場合は、CPUが飽和状態にあることを示します。
   • メモリ使用率（% ） — この値が常に85%を上回っていると、メモリ不足（OOM）が発生するリスクが高まります。
   • ネットワークの入出力バイト数 — 予期せぬトラフィックの急増は、ワークロードの暴走やネットワーク攻撃を示している可能性があります。

4. ノード上でどのポッドが最も多くのリソースを消費しているかを確認するには、 Kubernetes > 「 Pods 」ダッシュボードに移動し、対象のノードでフィルタリングしてください。 CPU やメモリの使用率が常に高いポッドがあれば、その名前をメモしておいてください。これらは、ワーカーノードの不安定性の原因となっている可能性が高いからです。

以下のコマンドでポッドのステータスと再起動回数を確認します。 IBM Cloud Monitoring

クラッシュループに陥ったり、頻繁に再起動したりするPodは、OOMによる強制終了やレディネスプローブの設定ミスなど、アプリケーションレベルの問題があることを示す一般的な兆候です。 oc get pods を繰り返し実行することなく、これらのポッドを特定するには、IBM Cloud Monitoring を使用してください。

1. IBM Cloud Monitoring のUIで、 Kubernetes > 「 Pods pre-built」ダッシュボードに移動します。

2. 「 コンテナの再起動 」パネルを確認してください。 過去15分間に再起動回数が0より大きいポッド、またはより長い期間にわたって再起動回数が急増しているポッドを探してください。

   • 再起動回数が繰り返し増加している場合は、クラッシュループが発生していることを示しています。 後続のログ調査の手順で必要となるため、ポッド名とネームスペースをメモしておいてください。
   • 再起動回数がゼロであるにもかかわらず、ステータスが「 保留中 」または 「不明」 となっている場合は、アプリケーションの障害ではなく、スケジューリングまたはノードの接続に関する問題があることを示しています。

3. 今後のPod再起動イベントに対するアラートを設定するには、 IBM Cloud Monitoring のUIにある「 アラート」 アイコンをクリックし、「 kubernetes.pod.restart.count 」メトリックに対してメトリックアラートを作成してください。 任意のポッドについて、5分間に再起動が2回を超えた場合にトリガーされるよう、しきい値を設定します。 これにより、クラッシュループがシステムに支障をきたす前に、早期の警告を発することができます。 アラートの設定に関する詳細については、以下を参照してください。 IBM Cloud® Monitoring のアラート設定

コンテナのログを調査するには、 IBM Cloud Logs

ポッドが再起動した場合やノードで問題が発生した場合、根本原因を特定するにはコンテナのログを確認することが不可欠です。 IBM Cloud Logs は、コンテナの再起動後に oc logs では確認できない過去のログデータを保持しています。

1. IBM Cloud Logs ダッシュボードを開きます。

   1. IBM Cloud コンソールで、クラスタリソースページに移動し、該当するクラスタをクリックします。
   2. 「 統合 」の下にある「 ロギング 」オプションを見つけて、「 起動 」をクリックします。 IBM Cloud Logs のUIが新しいウィンドウで開きます。

2. 問題が発生した期間を含むように、時間範囲を設定してください。 問題が継続している場合は、範囲を過去1時間に設定してください。 過去の出来事を調査する場合は、具体的な開始時刻と終了時刻を設定して、検索結果を絞り込んでください。

3. 影響を受けているポッドまたはネームスペースを検索します。 UIの上部にある検索バーを使用して、ログを絞り込んでください。 たとえば、 default ネームスペース内のすべてのポッドのログを表示するには、次のクエリを入力します

   kubernetes.namespace_name:"default"
   

   名前で特定のポッドに検索結果を絞り込むには、次のように指定します：

   kubernetes.pod_name:"MY_POD_NAME"
   

4. ログ行を調べて、エラーレベルのエントリを確認してください。 一般的な故障モードを示す以下のパターンのいずれかに注意してください：

   • OOMKilled または「 out of memory 」— コンテナがメモリ制限を超過したため、カーネルによって終了させられました。
   • CrashLoopBackOff — コンテナが繰り返し再起動しています。多くの場合、起動時のアプリケーションエラーが原因です。
   • failed to pull image または ImagePullBackOff — ノードがレジストリからコンテナイメージを取得できません。
   • Connection refused または「 context deadline exceeded 」— アプリケーションが依存するサービスまたは Kubernetes APIサーバーに接続できません。

5. OOMに関連するログエントリが見つかった場合は、そのタイムスタンプをメモし、 IBM Cloud Monitoring Kubernetes > Pods ダッシュボードで、同じ時間枠を確認し、再起動の直前にその Pod のメモリ使用量が上限に達していたことを確認してください。

Kubernetes のイベントは、以下で確認できます。 IBM Cloud Logs

Kubernetes イベントには、ポッドのスケジューリング失敗、ノードの状態、ボリュームのマウントエラーなど、クラスタの重要なアクティビティが記録されます。 IBM Cloud Logs はこれらのイベントを自動的に取り込み、過去のイベントを検索・フィルタリングできるようにします。これに対し、 oc get events は現在のセッションにおける直近のイベントのみを表示します。

1. IBM Cloud Logs のUIで、クラスタ全体にわたるすべての Kubernetes の警告イベントを表示するには、次のクエリを使用します

   kubernetes.event.type:"Warning"
   

2. 特定のワーカーノードにイベントを絞り込むには、クエリにノード名を追加します。 NODE_NAME を、影響を受けるノードの名前に置き換えてください：

   kubernetes.event.type:"Warning" AND kubernetes.event.involvedObject.name:"NODE_NAME"
   

3. イベントログのエントリにある「 Reason 」フィールドを確認してください。 ワーカーノードやワークロードの問題をデバッグする上で、以下の理由が最も重要となります

NodeNotReady

そのノードは、 NotReady という状態を報告しています。 このイベントは、多くの場合、ワーカーノードが Critical 状態に入る前に発生するか、またはその状態に入るのと同時に発生します。

OOMKilling

カーネルは、メモリ不足のため、そのノード上のプロセスを終了させました。

FailedScheduling

スケジューラは、利用可能なノードのいずれにもポッドを配置できませんでした。 メッセージ欄には通常、その理由（CPUやメモリの不足、ノードセレクタの不一致など）が説明されています。

BackOff

コンテナがクラッシュループに陥っています。 このイベントは、 kubelet がコンテナを再起動する前にバックオフを行うたびに発生します。

FailedMountまたはFailedAttachVolume

永続ボリュームをポッドにマウントまたはアタッチできなかったため、ポッドが起動できません。

1. 関連がありそうなイベントについては、 involvedObject.name および involvedObject.namespace の値をメモし、それらを用いて、前のセクションで収集したログデータやメトリックデータと照合してください。

次のステップ

• リソース不足に陥っているワーカーノードを特定した場合は、 そのワーカーノードの再読み込みや交換、あるいはそのノード上で実行されているポッドのリソース要求量や上限の調整を検討してください。
• OOMキルによりポッドがクラッシュループに陥っている場合は、影響を受けているコンテナのメモリ制限を引き上げるか、メモリを大量に消費するワークロードを、より大きなノードを持つワーカープールに移動してください。
• ログにイメージの取得失敗が記録されている場合は、 イメージ取得用のシークレット を確認し、ワーカーノードがコンテナレジストリにアクセスできることを確認してください。
• ここで収集した情報では解決できない問題については、「 サポートケースのためのデータ収集 」を参照し、サポートチケットを開くために必要な情報を収集してください。

関連リンク

• クラスターの正常性のモニタリング
• はじめに IBM Cloud Monitoring
• はじめに IBM Cloud Logs
• Critical または NotReady の状態にあるワーカーノードのトラブルシューティング
• IBM Cloud® Monitoring アラートのセットアップ