k8s eventsログ

Kubernetesは events というリソースを持っており、GKEではCloud Loggingsで

logName="projects/MY_PROJECT_NAME/logs/events"

とフィルタすることで全イベントを見ることが出来ます。

Podのschedule, Imageのpull、ContainerのStartといったライフサイクルや、NodeのScaleIn/ScaleOutなどk8s内の動きをいろいろと見ることができます。

GKEではmaster nodeのログなどを直接見ることは出来ませんが、eventsログが代わりの有益なヒントにもなります。

events監視

AI・機械学習チームでは各種バッチ、APIがCronJobやDeploymentとしてGKE上で動いています。

このうちAPIについてはレスポンスのステータスコードや応答レイテンシでの監視、CronJobについては所定の時間内に完了したかどうかのSLOでの監視をしています。

（SLO監視についてはこちらの記事で紹介しています）

www.m3tech.blog

これらにより、最終防衛ラインとして「最低限サービスが稼働していること」の監視は出来ていますが

OutOfMemoryでContainerがrestartされた
PodがEvictされた
docker imageの指定が間違っていてDeploymentが新しいバージョンにrolling updateされていなかった

など内部的な異常には気づくことができません。

そのため、eventsログの監視も併せて行っています。

f:id:yokomotod:20211203085038p:plain — eventsログ監視の流れ

Logs RouterでeventsログをPub/Subに飛ばし、それをトリガにして自作のCloud Functionsで通知するという構成で

logName="projects/MY_PROJECT_NAME/logs/events"

(jsonPayload.reason="Evicted"
OR jsonPayload.reason="BackoffLimitExceeded"
OR (jsonPayload.reason="Failed" AND NOT (jsonPayload.message:"Error: cannot find volume" OR jsonPayload.message:"\" not registered"))
OR (jsonPayload.reason="ScaleDown" AND resource.type="k8s_pod" AND NOT jsonPayload.involvedObject.namespace="kube-system")
OR (jsonPayload.reason="OOMKilling" AND NOT ("k8s_metadata" OR "google-fluentd" OR "otelsvc")))

というLogs Routerのフィルタ条件でアラートを通知しています。

フィルタの内容は

reason:BackoffLimitExceeded
- = CronJobが backoffLimit まで失敗・リトライしきった
reason:OOMKilling
- = OutOfMemory
- たまにkube-system系のPodがOOMすることがあり、対応が難しく実影響がないため泣く泣く除外
reason:Evicted
- = schedulerによって別NodeにPodが移動させられた
reason:ScaleDown AND type:k8s_pod
- = NodeのScaleDownによってPodが移動させられた
reason:Failed
- 名前の汎用性のとおり、多岐にわたるタイミングで発生
- 例：イメージのpull失敗
- cannot find volume などは正常であってもPod起動時に発生することがあるようで、泣く泣く除外