В Kubernetes окрім метрик та логів з контейнерів ми маємо змогу отримувати інформацію про роботу компонентів за допомогою Kubernetes Events.
В евентах зазвичай зберігається інформація про статус подів (створення, Evict, kill, ready або not-ready статус подів), про WorkerNodes (статус серверів), про роботу Kubernetes Scheduler (неможливість запуску поду, тощо).
Зміст
Типи Kubernetes Events
В цілому, всі ці евенти можна поділити на такі типи:
- Failed events: коли виникає проблема з маніфестом або образом, з якого потрібно створити контейнер (
ImagePullBackOff
,CrashLoopBackOff
) - Eviction events: коли под видаляється, бо на WorkerNode мало ресурсів (Node-pressure Eviction), або ноду треба видалити, і автоскейлер (наприклад, Karpenter) виконує node drain (API-initiated Eviction)
- Scheduler events: проблеми с запуском поду на WorkerNode, наприклад – коли Scheduler не може знайти ноду з достатніми ресурсами, щоб задовольнити Pod requests
- Volume events: проблеми з підключенням PersistentVolume до поду (
FailedAttachVolume
,FailedMount
) - Node events: проблеми в роботі WorkerNodes (
NodeNotReady
)
Kubernetes Events та kubectl
Отримати евенти можемо просто з kubectl
– або зробивши kubectl describe pod <POD_NAME>
чи kubectl decsribe deploy <DEPLOY_NAME>
:
Або з kubectl get events
, якому можна додати параметр --watch
:
Також існує цікавий плагін podevents
, який додає час евенту.
Встановити можна з krew
:
$ kubectl krew install podevents
І запускаємо, передавши ім’я поду:
Kubernetes Events та Grafana Loki
Для роботи з евентами є багато рішень:
sloop
– активний, система візуалізації евентів з можливістю фільтрації та пошукуkspan
– активний, створює OpenTelemetry Spans з евентів, які потім можна перевіряти в системах типу Jaegerkubernetes-event-exporter
– активний, вміє відправляти евенти, мабуть, в усе, що взагалі існує – і AWS SQS/SNS, і Opsgenie, і Slack, і Loki – можливо, він буде наступний в моєму кластері, коли поточне рішення стане недостатнім- Grafana Agent (Grafana Alloy) – теж вміє працювати з евентами, і писати їх у вигляді логів в Loki
eventrouter
– в архіві з 2022kubewatch
– в архіві з 2022
Але, як на мене, то простіше всього їх мати у вигляді логів, і потім з Loki RecordingRules створювати метрики, а з них графіки в Grafana та/або алерти.
Для цього є дуже проста система max-rocket-internet/k8s-event-logger
, яка слухає Kubernetes API, отримує всі евенти, і записує їх у вигляді лога в JSON.
Встановлюється з Helm-чарту:
$ helm repo add deliveryhero https://charts.deliveryhero.io/ $ helm -n monitoring install k8s-event-logger deliveryhero/k8s-event-logger
Створить Pod, який власне і буде читати events:
$ kubectl -n ops-monitoring-ns get pods -l "app.kubernetes.io/name=k8s-event-logger" NAME READY STATUS RESTARTS AGE k8s-event-logger-5b548d6cc4-r8wkl 1/1 Running 0 68s
І писати їх у свій output:
$ kubectl -n ops-monitoring-ns logs -l "app.kubernetes.io/name=k8s-event-logger" {"metadata":{"name":"backend-api-deployment-7fdfbb755-tjv2j.17daa9e0264e6139","namespace":"prod-backend-api-ns","uid":"1fa06477-62c9-4324-8823-7f2801fc26af","resourceVersion":"110778929","creationTimestamp":"2024-06-20T08:43:07Z","managedFields":[{"manager":"kubelet","operation":"Update","apiVersion":"v1","time":"2024-06-20T08:43:07Z", ...
Який потім попаде в Promtail, а звідти в Loki:
В цілому, на цьому і все.
Тепер, маючи історію евентів, буде набагато простіше дебажити якісь проблеми з подами або нодами.