高度なトラブルシューティング: Kubernetesログ、イベント、メトリクスの詳細解説

Kubernetesのトラブルシューティングは、次の3つの質問を分離することで容易になります。コンテナは何を言ったか、コントロールプレーンは何をしたか、メトリクスは何を示しているか？ログ、イベント、メトリクスは、同じインシデントの異なる部分に答えます。

以下の例では、Podがクラッシュした場合、イメージがプルできない場合、ワークロードがスケジュールできない場合、またはサービスが正常に見えるが応答が遅い場合に、これら3つをすべて一緒に使用する方法を示します。

Kubernetesログ: デバッグの基盤

ログは、アプリケーションまたはシステムプロセスが何をしているかの詳細な記録です。Kubernetesでは、ログはPod内で実行されているコンテナによって生成されます。アプリケーションが期待通りに動作しない場合、最初に確認する場所であることがよくあります。

コンテナログへのアクセス

kubectl logsコマンドは、Podからログを取得するための主要なツールです。多用途で、いくつかの便利なオプションを提供します。

• Pod内の単一コンテナからログを取得する:

  kubectl logs <pod-name>
  

  Podにコンテナが1つしかない場合、このコマンドは直接機能します。

• マルチコンテナPod内の特定のコンテナからログを取得する:

  kubectl logs <pod-name> -c <container-name>
  

• クラッシュしたコンテナの以前のインスタンスのログを表示する: エラーによりコンテナが再起動した場合、--previousフラグを使用して再起動前のログを表示できます:

  kubectl logs <pod-name> --previous
  

• リアルタイムでログを追跡する: tail -fと同様に、-f（または--follow）フラグを使用すると、新しいログエントリが生成されるたびにストリーミング表示でき、ライブの問題のデバッグに非常に役立ちます。

  kubectl logs -f <pod-name> -c <container-name>
  

• 時間でログをフィルタリングする: 末尾から取得する行数（--tail）や、特定の期間からのログ（--since）を指定できます。

  kubectl logs <pod-name> --tail=100 # 最後の100行
  kubectl logs <pod-name> --since=1h # 過去1時間のログ
  

集中ログ管理ソリューション

kubectl logsは即時のデバッグには優れていますが、大規模で長期的なログ管理には実用的ではありません。本番環境では、集中ログ管理ソリューションが不可欠です。これらのソリューションには通常、以下が含まれます:

• ログエージェント: 各ノードでエージェント（例: Fluentd、Fluent Bit、Filebeat）を実行し、すべてのPodからログを収集します。
• ログストレージとインデックス作成: ログを中央リポジトリ（例: Elasticsearch、Loki、Splunk）に保存します。
• ログの可視化と分析: ログを検索、フィルタリング、可視化するためのインターフェース（例: Kibana、Grafana、Splunk UI）を提供します。

ロギングのベストプラクティス

• 構造化ロギング: ログを構造化形式（例: JSON）で出力し、集中ログ管理システムで簡単に解析およびクエリできるようにします。
• 適切なログレベル: 異なるログレベル（DEBUG、INFO、WARN、ERROR、FATAL）を使用してメッセージを分類し、詳細度を制御します。
• 機密情報を避ける: 機密データ（パスワード、PII）を直接ログに記録しないでください。

Kubernetesイベント: クラスターの語り部

Kubernetesイベントは、クラスター内で発生する状態変更と操作の記録です。これらは、希望する状態に対してKubernetes自体が何をしているか（または何をしていないか）に関する重要な洞察を提供します。イベントは、Podがスケジュールされない理由、イメージがプルされない理由、またはボリュームがマウントされない理由を理解する上で非常に役立ちます。

Kubernetesイベントへのアクセス

• クラスター全体のイベント:

  kubectl get events
  

  このコマンドは、現在のネームスペース内のすべての最近のイベントを表示します。--all-namespacesを追加すると、クラスター全体のイベントを表示できます。

  典型的なイベント出力は次のようになります:

  LAST SEEN   TYPE      REASON      OBJECT                         MESSAGE
  3m21s       Normal    Scheduled   pod/my-app-789c6f66-abcde      Successfully assigned default/my-app-789c6f66-abcde to node01
  3m20s       Normal    Pulling     pod/my-app-789c6f66-abcde      Pulling image "example/my-app:1.2.3"
  2m58s       Warning   BackOff     pod/my-app-789c6f66-abcde      Back-off restarting failed container app
  

• 1つのオブジェクトのイベント:

  kubectl describe pod <pod-name>
  

  下部のEventsセクションは、単一のPodのスケジューリング、プル、マウント、再起動の問題を確認する最も速い方法であることがよくあります。

• 作成時刻でイベントを並べ替える:

  kubectl get events --sort-by=.metadata.creationTimestamp
  

イベントが通常教えてくれること

イベントは存続期間が短いレコードであるため、最近の障害に最適です。以下の一般的な理由を探してください:

• FailedScheduling: スケジューラーがPodを配置できませんでした。ノードセレクター、テイント、トレランス、リソース要求、利用可能な容量を確認してください。
• ImagePullBackOff または ErrImagePull: Kubernetesがイメージをプルできませんでした。イメージ名、タグ、レジストリアクセス、イメージプルシークレットを確認してください。
• FailedMount: ボリュームをマウントできませんでした。PVCバインディング、ストレージクラス、ノード権限、CSIドライバーの健全性を確認してください。
• BackOff: コンテナが失敗し続けています。イベントをkubectl logs --previousと組み合わせてください。

Kubernetesメトリクス: リソースビュー

メトリクスは、クラスターにワークロードに十分なCPU、メモリ、容量があるかどうかを示します。また、アプリケーションのバグとリソースのプレッシャーを分離するのにも役立ちます。

metrics-serverによるクイックチェック

metrics-serverがインストールされている場合は、kubectl topを使用します:

kubectl top nodes
kubectl top pods
kubectl top pod <pod-name> --containers

コンテナの制限に近い高いPodメモリは、多くの場合OOMKilled再起動と一致します。高いノードCPUは、Podログが正常に見えてもレイテンシを説明できます。

Prometheusによる詳細メトリクス

本番環境では、PrometheusとGrafanaが通常、kubectl topに欠けている履歴ビューを提供します。有用なシグナルは次のとおりです:

• 経時的なコンテナ再起動。
• CPU制限が低いコンテナのCPUスロットリング。
• 制限と比較したメモリワーキングセット。
• ネームスペースごとの保留中のPod。
• APIサーバーのリクエストレイテンシとエラー率。
• ノードのディスクプレッシャー、メモリプレッシャー、ネットワーク飽和。

ログ、イベント、メトリクスの関連付け

時間枠を使用し、症状から原因へと進みます:

1. Podの状態を確認:

   kubectl get pod <pod-name> -o wide
   kubectl describe pod <pod-name>
   

2. 現在および以前のログを読む:

   kubectl logs <pod-name> -c <container-name>
   kubectl logs <pod-name> -c <container-name> --previous
   

3. 最近のネームスペースイベントを確認:

   kubectl get events --sort-by=.metadata.creationTimestamp
   

4. リソース使用量を比較:

   kubectl top pod <pod-name> --containers
   kubectl top node
   

例えば、CrashLoopBackOff状態のPod、メモリ不足エラーで終了する以前のログ、メモリが制限に近いことを示すメトリクスは、メモリ制限またはアプリケーションメモリの問題を示しています。FailedSchedulingイベントと低いノード容量でPending状態のままのPodは、コンテナのバグではなく、スケジューリングのプレッシャーを示しています。

まとめ

Kubernetesを1つのシグナルだけでデバッグしないでください。ログはアプリケーションの動作を説明し、イベントはコントロールプレーンの決定を説明し、メトリクスはリソースのプレッシャーを説明します。これらを時間とオブジェクト名で並べると、根本原因を症状から分離するのがはるかに容易になります。