Работа с событиями

В данном разделе описано, как устроена система оповещений в кластере Nova Container Platform, какие уровни важности используются, как работать со сработавшим оповещением и как разбирать отдельные правила на примерах.

1. Как устроена система оповещений в кластере

Система оповещений построена на связке Prometheus и Alertmanager. Схема работы:

Prometheus непрерывно собирает метрики с приложений, узлов и системных компонентов кластера.
Правила оповещений описаны декларативно в объектах PrometheusRule (Kubernetes CR). Каждое правило содержит PromQL-выражение (expr) и параметр for (время до срабатывания): если выражение истинно непрерывно дольше указанного времени, правило переходит в состояние срабатывания (firing).
Сработавшее правило Prometheus отправляет в Alertmanager вместе с метками (severity, namespace, alertname и др.) и аннотациями (summary, description) — это и есть оповещение.
Alertmanager группирует одинаковые и похожие оповещения, убирает дубликаты, применяет правила подавления и маршрутизирует уведомления получателям (электронная почта, Slack, Telegram, PagerDuty и т. д.) согласно дереву маршрутизации.

2. Уровни важности

Значение важности задаётся меткой severity:

critical (критический): Требует немедленной реакции: сервис недоступен, данные под угрозой, кластер деградирует. Обычно требует привлечения дежурного.
warning (предупреждение): Отклонение от нормальной работы, которое ещё не является аварией. Такое оповещение необходимо обработать в рабочее время, чтобы состояние не стало критическим.
info (информационный): Уведомление для отслеживания тренда или события, само по себе не требует действий.
без severity: Служебные правила (например, самодиагностика Prometheus или Alertmanager) — обычно рассматривают при разборе инцидента, а не как отдельное уведомление.

3. Жизненный цикл работы с оповещением

Если получили уведомление — просмотрите метки оповещения: alertname, severity, namespace, pod/node/instance. Они показывают, что именно и где нарушено.
Откройте Prometheus или Grafana и посмотрите график метрики, лежащей в основе выражения (expr) правила, за последние часы — это покажет, разовый ли это всплеск или устойчивая деградация.
Прочитайте разделы Что означает и Что делать (или аннотации summary/description исходного правила) — там объяснены суть условия и типовые шаги диагностики.
Оцените масштаб: один Pod или узел либо весь кластер, есть ли влияние на пользователей.
Устраните причину или передайте задачу ответственной команде. Критические оповещения — немедленно, предупреждения — в рабочем порядке.
Если оповещение ложное, слишком частое или дублирует другое — вместо игнорирования создайте в веб-консоли правило остановки оповещения (заглушение) с указанием причины и срока действия и заведите задачу на пересмотр самого правила.
После устранения проверьте, что оповещение погасло (resolved), и при необходимости зафиксируйте ход работ для критичных случаев.

Полный перечень оповещений кластера см. в Справочнике событий.

4. Примеры разбора конкретных оповещений

Ниже приведён сквозной разбор нескольких реальных правил из кластера: как читать условие и что делать при срабатывании.

4.1. KubePodCrashLooping

Важность: Предупреждение

Время до срабатывания: 15 мин.

Условие: kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} >= 1 (без остановки 5 минут)

Что означает: контейнер в Pod постоянно падает и перезапускается — Kubernetes переводит его в состояние CrashLoopBackOff, и это состояние держится не меньше 15 минут подряд.

Что делать: посмотреть логи контейнера (kubectl logs --previous) и события Pod (kubectl describe pod) — обычно причина в ошибке при старте приложения, нехватке ресурсов (OOMKilled) или неверном конфиге либо секрете.

4.2. NodeFilesystemAlmostOutOfSpace

Важность: Предупреждение

Время до срабатывания: 30 мин.

Условие: свободное место на файловой системе узла < 5% от общего объёма

Что означает: на конкретном диске конкретного узла осталось меньше 5% свободного места дольше 30 минут — риск полного заполнения диска и отказа сервисов на этом узле.

Что делать: найти узел и раздел из меток instance/device, проверить, что занимает место (логи, образы контейнеров, временные файлы), при необходимости расширить том или очистить данные.

4.3. etcdHighNumberOfLeaderChanges

Важность: Предупреждение

Время до срабатывания: 5 мин.

Условие: в среднем больше 5 смен лидера etcd за последние 10 минут

Что означает: etcd — хранилище состояния всего Kubernetes-кластера — слишком часто переизбирает лидера. Обычно это признак нехватки ресурсов (диск или сеть), высокой задержки сети между узлами etcd или перегрузки.

Что делать: это критичный для стабильности кластера компонент — проверить задержку и нагрузку ввода-вывода дисков под etcd, сетевую связность между узлами control-plane, ресурсы CPU и RAM. Частые перевыборы могут приводить к временной недоступности API Kubernetes.

4.4. CertificateExpiration7days

Важность: Критический

Время до срабатывания: 15 мин.

Условие: до истечения срока действия x509-сертификата осталось меньше 7 дней

Что означает: один из отслеживаемых TLS-сертификатов в кластере скоро истечёт. Метки сообщают его subject (владельца) и где он хранится — в Kubernetes Secret или файлом на узле.

Что делать: проверить, что продлением занимается cert-manager или другая автоматика и что она отрабатывает штатно; если сертификат выпущен вручную — переиздать заранее, не дожидаясь срабатывания CertificateExpiration1day.

4.5. KubeNodeNotReady

Важность: Предупреждение

Время до срабатывания: 15 мин.

Условие: условие Ready узла имеет статус false или unknown дольше 15 минут

Что означает: узел кластера более 15 минут не сообщает Kubernetes о своей готовности — вероятны проблемы с kubelet, сетью узла или его физическая либо виртуальная недоступность.

Что делать: проверить состояние узла (kubectl describe node), доступность по сети или SSH, статус kubelet и container runtime на нём. При подтверждённом отказе рабочие нагрузки будут переезжать на другие узлы, если на это хватает ресурсов и позволяют PodDisruptionBudget.