Kubernetes Eventsとは?
TL;DR:Kubernetes Eventsとは、クラスター内で状態変化やエラー、重要な動作が起きるたびに生成される、リアルタイムかつ短命なAPIリソースです。問題のデバッグやクラスター健全性の監査に活用できます。Eventsには、何が起きたか、どのオブジェクトが影響を受けたか、発生時刻、人間が読める簡潔な説明といった情報が記録されます。
主な特徴:
- 種類: 通常は
Normal(通常運用の範囲内の変化)またはWarning(バックオフループやスケジューリング失敗などの問題を示す)に分類されます。 - 保持期間: Eventsは一時的なリソースで、デフォルトでは
etcdに最大1時間だけ保存され、その後ガベージコレクションされます。 - 主な属性: 各イベントには
Last Seen、Type、Reason、Object(例:Pod/web-server)、状態遷移を説明するMessageが含まれます。
Eventsの確認方法:
標準の kubectl events コマンドを使えば、ターミナルから直接イベントを確認・監視できます。
- デフォルトnamespaceの最近のイベントをすべて表示:
kubectl events - 全namespaceのイベントを表示:
kubectl events --all-namespaces - 特定リソースのイベントをリアルタイムで監視:
kubectl events --for pod/<pod-name> --watch - 最近のイベントをYAML形式で表示:
kubectl events -o yaml
本記事は、Kubernetesのトラブルシューティングに関するシリーズの一部です。
この記事で扱う内容:
- Kubernetes Eventsの主な特徴
- Kubernetes Events、ログ、メトリクスの違い
- Kubernetes Eventsの確認方法
- Kubernetes Eventsの絞り込み方法
- 代表的なKubernetes Eventsの種類とReason
- Kubernetes Eventsを使ったトラブルシューティング
- Kubernetes Events活用のベストプラクティス
Kubernetes Eventsの主な特徴
1. 種類
Kubernetes Eventsは主に Normal と Warning の2種類に分かれます。
- Normalイベントは、Pod作成やコントロールプレーンによるスケジューリング成功など、想定どおりに完了した操作を示します。情報提供を目的としたもので、リソースの通常動作を追うのに役立ちます。
- Warningイベントは、スケジューリング失敗やイメージプルエラーなど、予期しない、あるいは問題のある状況を示します。サービス停止や大規模障害に発展する前に問題を素早く検知し、対応するうえで欠かせません。
どちらも役割は異なりますが、クラスターの可観測性においては同じくらい重要です。Normalイベントはリソースが意図どおりに動作していることを確認する手段になり、Warningイベントはエラーや設定ミスを早期に知らせる仕組みとして機能します。
2. 保持期間
Kubernetes Eventsはクラスターのetcdに保存されますが、無期限に残るわけではありません。デフォルトの保持期間は1時間で、APIサーバーの設定で変更できます。
この短い保持期間は、クラスターへのパフォーマンス影響を抑え、一時的・反復的なイベントデータでetcdが圧迫されるのを防ぐためのものです。一方で、さらに調査するためにイベントを分析・エクスポートしたい場合は、運用者が素早く動く必要があるということでもあります。
保持期間が限られているため、長期的な監査や事後分析をクラスター内のイベントストアだけに頼るのは推奨されません。長期的なイベント履歴が必要な環境では、外部のロギング・モニタリング基盤にイベントをエクスポートするのがベストプラクティスです。
3. 主な属性
Kubernetesの各イベントには、何がどこで起きたかを示すいくつかの主要な属性が含まれます。代表的なものは次のとおりです。
- 関連オブジェクト(PodやNodeなど)
- イベントタイプ(NormalまたはWarning)
- 原因を要約するreasonコード
- 人間が読めるメッセージ
- 最初と最後の発生時刻のタイムスタンプ
こうした構造化された属性のおかげで、他の可観測性データとの絞り込み・検索・相関付けが容易になります。属性を理解しておくことは、効果的なトラブルシューティングに欠かせません。たとえば reason と message フィールドは原因の手がかりをすぐに示してくれることが多く、タイムスタンプは関連イベントの順序を特定するのに役立ちます。関連オブジェクト参照を使えば、影響を受けたリソースまで掘り下げて調査できます。
Kubernetes Events、ログ、メトリクスの違い
Kubernetes Events、ログ、メトリクスは、クラスターの可観測性においてそれぞれ異なる役割を担います。
- Eventsは、PodのスケジューリングやPodの失敗など、Kubernetesリソースにおける上位レベルの状態変化や重要な動作を記録します。
- ログは、アプリケーションやシステムの動作をタイムスタンプ付きで詳細に記録し、コンテナやKubernetesコンポーネント内部で何が起きているかを深く把握するのに役立ちます。
- メトリクスは、CPU使用率やメモリ消費量など時系列で収集される数値データで、トレンドの監視やアラート発報に使われます。
Eventsはクラスターリソースのライフサイクル追跡や突発的な変化の原因特定に向いており、ログはアプリケーション挙動のデバッグや複雑な問題の診断に適しています。メトリクスは、運用者がリソースの健全性とパフォーマンスを大規模に追跡し、キャパシティプランニングやオートスケーリングを支える基盤になります。
Kubernetes Eventsの確認方法
Kubernetesでは、kubectl を使ってコマンドラインから直接イベントを確認する方法がいくつか用意されています。最も一般的なのは kubectl get events コマンドで、現在のnamespaceのイベント一覧を取得できます。出力にはイベントタイプ、reason、関連オブジェクト、メッセージなどが含まれます。
全namespaceのイベントを確認するには、--all-namespaces フラグを追加します。
kubectl get events
kubectl get events --all-namespacesイベントは時間に紐づく情報のため、トラブルシューティングではタイムスタンプ順に並べ替えると役立つ場面が多くあります。Kubernetesでは --sort-by オプションで作成時刻順にソートできます。これにより、障害やデプロイの問題が起きる直前の一連の動作を把握できます。
kubectl get events --sort-by=.metadata.creationTimestamp特定のリソースに関するイベントを確認するには、kubectl describe コマンドを使います。たとえばPodをdescribeすると、リソースの詳細とともに末尾に専用のEventsセクションが表示されます。スケジューリング失敗、コンテナクラッシュ、イメージプルエラーといった問題をいち早く特定できる、最も手軽な方法のひとつです。
kubectl describe pod my-pod本番環境では、Eventsを Elasticsearch、Loki、クラウドネイティブな監視ツールなどの統合的な可観測性プラットフォームに連携することが多くあります。これにより、長期保持、高度な検索、ログ・メトリクスとの相関分析が可能になり、大規模環境でのトラブルシューティングが格段に効率化されます。
Kubernetes Eventsの絞り込み方法
Kubernetes Eventsを絞り込めば、トラブルシューティング中でも本当に必要な情報に集中できます。クラスターは大量のイベントを生成するため、namespace、オブジェクト、タイプ、reasonで絞り込むと問題を素早く突き止められます。
1. 最もシンプルな方法は、特定のnamespaceに結果を絞ることです。
kubectl get events -n production2. フィールドセレクターを使えば、より高度な絞り込みが可能です。 関連オブジェクトの名前や種別、reason、イベントタイプで絞り込めます。たとえば次のコマンドは、通常は失敗や異常状態に関連する Warning イベントのみを表示します。
kubectl get events --field-selector type=Warning3. 特定のPodに関するイベントを表示するには、オブジェクト名で絞り込みます。
kubectl get events --field-selector involvedObject.name=my-podreasonによる絞り込みも、繰り返し発生する問題を診断する際に有効です。たとえば、クラスター全体のスケジューリング失敗を抽出できます。
kubectl get events --field-selector reason=FailedScheduling4. Kubernetes Eventsは --watch フラグを使えばリアルタイムでストリーミングすることも可能です。新しいイベントが発生するたびに表示されるため、デプロイ中やインシデント対応中に特に有用です。
kubectl get events --watchより高度な運用では、Eventsを監視・ロギングプラットフォームにエクスポートし、複雑なクエリ、ダッシュボード、アラートを組み合わせるのが一般的です。これによりインシデント検知を自動化し、Eventsをログ・メトリクスと相関付けて、より迅速に根本原因へたどり着けます。
代表的なKubernetes Eventsの種類とReason
Normalイベント
Normalイベントは、Kubernetesクラスター内で想定どおり、あるいは正常に完了した操作を表します。Podの作成、イメージプルの成功、Nodeのクラスター参加などがその例です。これらのイベントは、コントロールプレーンとリソースが意図どおりに機能していることを示してくれます。Normalイベントを確認すれば、デプロイやオートスケーリングといったワークフローがエラーなく進んでいるか、クラスターが正常に稼働しているかを把握できます。
重要性: 情報提供が中心とはいえ、Normalイベントもトラブルシューティングや監査に役立ちます。問題を調査する際、Normalイベントの有無を確認することで、どの時点で処理が想定パスから外れたかを特定できます。たとえばPod作成時に「Scheduled」イベントが見当たらない場合、警告が出ていなくてもスケジューリングに問題があると判断できます。
Warningイベント
Warningイベントは、Kubernetesクラスター内の問題や予期しない状況を示します。スケジューリング失敗、イメージプルエラー、リソース制約違反などがその対象です。コントロールプレーンや基盤コンポーネントが、すぐにはリソース障害につながらないものの注意が必要な状況に直面した際に生成されます。
重要性: Warningイベントを監視することは、プロアクティブなクラスター運用に不可欠です。通常動作からの逸脱を示すため、設定ミス、リソース不足、インフラ問題の最初のサインとなることが多くあります。
Kubernetes Eventsを使ったトラブルシューティング
1. PodがPendingのまま動かない
Podが Pending 状態のまま動かない場合、通常はKubernetesがPodをノードに配置できないか、起動前に必要な初期化ステップのいずれかを完了できていないことを示します。スケジューラーやkubeletからのフィードバックを直接得られるため、Eventsは根本原因を最も早く突き止められる手段であることが多いです。よくある原因には、CPUやメモリの不足、PersistentVolumeClaimの欠落、ノードのtaint、affinityルールの不一致などがあります。
Podに関連するイベントは次のコマンドで確認できます。
kubectl describe pod my-podEventsセクションには FailedScheduling などのメッセージが、適切なNodeが見つからなかった理由とともに表示されることがあります。たとえば、利用可能なリソースを持つノードがない、taintによりスケジューリングできない、といった内容です。これらのメッセージにより、スケジューラーログを深く調べなくても、トラブルシューティングの範囲を素早く絞り込めます。
クラスター全体のスケジューリングイベントを抽出する方法も有効です。
kubectl get events --field-selector reason=FailedSchedulingこれらのイベントを確認すれば、問題が単一のワークロードに限定されているのか、クラスター全体の複数Podに及んでいるのかを判断できます。Pending状態のPodを解消するには、クラスターリソースのスケール、リソース要求の調整、ストレージ依存関係の修正、スケジューリング制約の見直しなどが必要になります。
2. ImagePullBackOff または ErrImagePull
ImagePullBackOff や ErrImagePull イベントは、Kubernetesがレジストリからコンテナイメージをダウンロードできない場合に発生します。原因の多くは、イメージ名の誤り、タグの欠落、認証失敗、ネットワーク接続の問題です。Eventsはイメージプル失敗の理由を詳細に示すため、デプロイ問題の診断に欠かせません。
最も手早く調査するには、対象のPodをdescribeします。
kubectl describe pod my-podEventsセクションには、Failed to pull image や Back-off pulling image といったメッセージが表示されます。ここから、無効なイメージ参照、レジストリへのアクセス拒否、認証情報の欠落などのエラーが分かります。レジストリに認証が必要な場合、設定済みのimage pull secretが無効または利用できない旨が示されることもあります。
運用者は、Pod仕様のイメージ名とタグを確認し、レジストリへのアクセス可否、必要なsecretが正しいnamespaceに存在することをチェックする必要があります。問題が解消されれば、Kubernetesは自動的にイメージプルを再試行し、コンテナを正常に起動します。
3. CrashLoopBackOff
CrashLoopBackOff イベントは、コンテナは正常に起動するものの、その直後に繰り返しクラッシュしている状態を示します。Kubernetesはコンテナの再起動を試み続け、失敗するたびに再試行までの間隔を延ばしていきます。原因の多くは、アプリケーションエラー、設定の不備、依存関係の欠落、ヘルスチェックの失敗です。
Eventsから、再起動のパターンや関連する障害を把握できます。
kubectl describe pod my-pod出力には Back-off restarting failed container といったイベントが表示されることがあります。Eventsから再起動の挙動は分かりますが、クラッシュの詳細な原因はコンテナのログから把握するのが一般的です。
Events分析とログ確認を組み合わせるのが定石です。
kubectl logs my-pod再起動イベントが頻発する場合は、liveness probeの失敗や、Out-of-Memory killなどリソース枯渇の問題が起きている可能性もあります。その場合は、probeの設定とコンテナのリソース制限を見直すことが重要です。
4. FailedScheduling
FailedScheduling イベントは、Kubernetesスケジューラーが利用可能なノードのいずれにもPodを割り当てられない場合に発生します。本番クラスターで最もよく見るWarningイベントのひとつで、通常はリソース不足や厳しいスケジューリングルールが原因です。スケジューラーは、配置が失敗した理由を詳しく説明するメッセージを生成します。
スケジューリング関連のイベントは次のコマンドで確認できます。
kubectl get events --field-selector reason=FailedScheduling一般的なメッセージとしては、CPUやメモリの不足、ノードaffinityの不一致、taintとの競合、ボリュームトポロジー制約などがあります。たとえば、Podのリソース要求を満たすノードがない、あるいは全ノードにPodが許容できないtaintが付いている、といった内容が報告されます。
FailedScheduling は根本原因そのものではなく症状であるため、メッセージの内容を正しく理解することが重要です。問題解消には、クラスター容量の追加、リソース要求の変更、affinityルールの更新、tolerationの適切な設定などが必要になります。スケジューリング問題は多くのワークロードに同時に影響しうるため、これらのイベントを監視することで、クラスター全体のキャパシティや設定の問題を早期に検知できます。
Kubernetes Events活用のベストプラクティス
Kubernetesを運用するうえで押さえておきたい、イベント関連のプラクティスを紹介します。
1. トラブルシューティングの初動でイベントを確認する
クラスターやアプリケーションの問題を診断するとき、Kubernetes Eventsは最初に確認すべき情報源のひとつです。Eventsからは、最近の状態変化、障害、コントロールプレーンの動作を把握できます。
kubectl describe や kubectl get events --sort-by=.metadata.creationTimestamp といったコマンドを使えば、スケジューリング失敗、コンテナの再起動、イメージプルの問題が見えてきます。早い段階でイベントを確認すれば、問題がKubernetesインフラ、ワークロード設定、アプリケーション自体のいずれに起因するのかを切り分けやすくなります。
Eventsは時系列で並んでいるため、障害発生に至るまでの一連の動きを再構成するのにも役立ちます。デプロイ、ロールアウト、インシデント対応の場面で特に有用です。
2. Eventsをログ・メトリクスと組み合わせる
Eventsは文脈情報を提供しますが、ログやメトリクスと組み合わせることで真価を発揮します。EventsはKubernetesリソースレベルで何が起きたかを伝え、ログはアプリケーションやコンポーネントの詳細な挙動を明らかにします。メトリクスは、パフォーマンスやリソース使用率の時系列データを補完します。
たとえばCrashLoopBackOffイベントはコンテナの繰り返し再起動を示しますが、なぜクラッシュしたかを把握するにはアプリケーションログが必要です。メトリクスを見ると、メモリ枯渇やCPUスロットリングが障害の一因になっていることが分かる場合もあります。これらのシグナルを相関付けることで、症状の検知から根本原因の分析へとスムーズに進められます。
可観測性プラットフォームでは、Events・ログ・メトリクスを統合ダッシュボードで扱えるのが一般的です。これにより、スタックの複数レイヤーにまたがって問題を追跡できます。
3. Eventsをエクスポートして長期保管する
Kubernetes Eventsは設計上一時的なリソースであり、etcd上では通常短期間しか保持されません。この保持期間の制約により、インシデント発生後すぐに診断情報が失われてしまうことがあります。Eventsを外部システムにエクスポートしておけば、分析や監査のために履歴を残せます。
たとえば多くの組織が、Elasticsearch、Loki、Splunk、クラウドネイティブな監視サービスといった統合可観測性プラットフォームにEventsを転送しています。これらのシステムでは、より長期の保持、高度なクエリ、ダッシュボード、ログ・メトリクスとの相関分析が可能です。
イベント履歴を残しておくことは、事後分析や、繰り返し発生する運用パターンの特定にも役立ちます。
4. シグナルの強いイベントに絞ってアラートを設定する
すべてのKubernetes Eventsにアラートが必要なわけではありません。大規模クラスターでは膨大な情報イベントが発生するため、すべてにアラートを設定するとノイズが増え、アラート疲れにつながります。代わりに、運用上の問題やサービスリスクを示すシグナルの強いWarningイベントに絞ってアラートを設定しましょう。
例としては、繰り返される FailedScheduling、CrashLoopBackOff、ImagePullBackOff、ノード関連のWarningイベントなどです。イベントタイプ、reason、頻度、影響を受けるリソースで絞り込めば、不要な通知を減らせます。
効果的なイベントアラートでは、イベントの量そのものよりも、アクションにつながるシグナルを優先することが重要です。
5. イベントメッセージの文面に依存しない
Kubernetesのイベントメッセージは人間が読むことを前提に設計されており、Kubernetesのバージョンや実装によって変わる可能性があります。スクリプト、自動化、監視ルールでメッセージのテキストに依存すると、アップグレードやプラットフォーム変更後に動かなくなる脆いワークフローになりがちです。
メッセージ全文をマッチさせるのではなく、reason、type、関連オブジェクト、ラベルといった構造化フィールドを使いましょう。これらのフィールドは安定しており、プログラムによる絞り込みや自動化にも適しています。たとえばスケジューラーのエラー文字列を検索するよりも、FailedScheduling というreasonでマッチさせた方がはるかに信頼性が高くなります。
Eventsの先へ:PerfectScaleでKubernetesの問題を検知・解消する
Kubernetes Eventsは何が問題かを教えてくれますが、大規模環境でそれに対処しようとすると、結局は手作業のトリアージが延々と続きます。PerfectScale by DoiTはそのギャップを埋め、OOM kill、CPUスロットリング、エビクション、Podの繰り返し再起動など、Eventsが浮かび上がらせる回復性・パフォーマンス問題を自律的に検知・修復します。さらにワークロードのライトサイジングを継続的に行い、クラスターを安定稼働させ、最大99.99%の可用性を実現します。
PerfectScaleの主な機能:
- 問題の自動修復: Out-of-Memory kill、CPUスロットリング、エビクション、Pod再起動といった回復性リスクを即座に特定して修復し、稼働時間を最大化、レイテンシーを排除します。
- 設定エラーの未然防止: CPU・メモリのrequests/limits未設定、メモリリークの疑い、レプリカ数の上限に達したワークロードなどの設定ミスを、インシデント化する前に検知します。
- インフラの堅牢化: ノード全体を俯瞰的に可視化し、エビクションやスケジューリング失敗を引き起こすノードのオーバーコミットや不適切なaffinity・taintをプロアクティブに発見します。
- インパクト重視の優先順位付け: リアルタイムで問題をランク付けし、SLA・SLOに沿ったアラートを実現することで、サービスへの影響が最も大きい問題にチームが集中できます。
- アラートとチケットの統合: Slack、MS Teams、Datadogへ即時通知し、ワンクリックで任意の問題をチケットへエスカレーションできます。
PerfectScaleが Kubernetesの回復性とパフォーマンス をどのように自律的に高めるか、詳しくはこちらをご覧ください。