Мониторинг Kubernetes-кластера должен объединять метрики состояния и ресурсов, health checks, алертинг и централизованное логирование. Одного контроля загрузки серверов недостаточно: Kubernetes управляет нодами, подами, Deployment, StatefulSet, Service, Ingress, PersistentVolume и компонентами control plane, а сбой на любом уровне может повлиять на пользовательский запрос.
Нода может иметь статус Ready, тогда как приложение внутри пода возвращает ошибки, не проходит readiness probe или не выдерживает входящую нагрузку. Обратная ситуация тоже возможна: отдельный контейнер перезапускается, но запас реплик сохраняет доступность сервиса. Поэтому наблюдение связывают с доступной нагрузкой, latency, ошибками HTTP и пользовательским SLO.
Рабочая схема обычно выглядит так: Kubernetes и приложения публикуют метрики, Prometheus собирает временные ряды, Grafana показывает их на дашбордах, Alertmanager группирует и доставляет уведомления, а централизованное логирование помогает найти причину сбоя. Health checks постоянно проверяют экземпляры и позволяют исключить нездоровый pod из rotation.
Что включает мониторинг Kubernetes-кластера
Кластер наблюдают по нескольким связанным уровням. Инфраструктурные метрики показывают состояние нод и емкость, метрики Kubernetes-объектов описывают желаемое и фактическое состояние workload-ов, а application metrics и black-box-проверки показывают реальный результат для пользователя.
Уровни наблюдения: кластер, ноды, workload-ы и пользовательский путь
| Уровень | Что контролировать | Какие проблемы обнаруживает |
|---|---|---|
| Control plane | API Server, etcd, scheduler, controller manager | Задержки запросов к API, проблемы создания и обновления объектов, потерю согласованности состояния |
| Worker-ноды | Ready, CPU, memory pressure, disk pressure, inode pressure, сеть и runtime | Недоступность узла, истощение ресурсов, ошибки диска, сбои kubelet или контейнерного runtime |
| Контейнеры и поды | Рестарты, OOMKilled, Waiting, Terminated, CrashLoopBackOff, потребление CPU и памяти | Ошибки приложения, неверную конфигурацию, нехватку памяти, проблемы с probes |
| Deployment и StatefulSet | Desired, current, updated и available replicas, rollout, состояние реплик и томов | Зависший rollout, нехватку доступных экземпляров, нарушение кворума или готовности StatefulSet |
| Service и Ingress | Endpoints, коды HTTP, latency, таймауты, TLS, DNS и backend-ы | Ошибки маршрутизации, недоступные backend-ы, перегрузку и сбои пользовательского пути |
| Хранилище и сеть | PersistentVolume, операции ввода-вывода, задержки, packet loss и retransmits | Зависшие поды, read-only файловые системы, потерю связи и деградацию I/O |
| Пользовательский сервис | Успешность критического сценария, latency и error budget | Нарушение SLO при формально работающих pod-ах |
Такая модель предотвращает узкий фокус на нодах или pod-ах. Например, статус Running сообщает, что контейнерный процесс запущен. Он не подтверждает корректность ответа приложения, наличие endpoints у Service, прохождение запроса через Ingress и доступность внешней базы данных.
Событие, симптом, алерт и инцидент
Событие Kubernetes фиксирует изменение: pod получил статус Pending, контейнер завершился, Deployment начал rollout. Симптом описывает наблюдаемое отклонение, например рост p95 latency или увеличение числа рестартов. Алерт формируется, когда выражение метрики нарушает условие заданное время и требует конкретного действия. Инцидент начинается при влиянии на доступность, производительность или SLO.
Перезапуск одного тестового pod-а может остаться информационным сообщением. Пять рестартов за 10 минут у всех экземпляров сервиса, сопровождаемые ростом HTTP 5xx, требуют уведомления дежурного. Такое разделение снижает шум и связывает уведомление с риском для пользователей.
Архитектура системы мониторинга Kubernetes
Систему собирают из источников, хранилища временных рядов, визуализации, алертинга и логирования. Перед установкой компонентов проверьте версию Kubernetes, способ развертывания control plane, используемый CNI, контейнерный runtime и права доступа к метрикам.
Prometheus и Grafana как базовый контур
Prometheus обнаруживает targets, периодически запрашивает endpoints метрик и хранит временные ряды с labels. Его зона ответственности: сбор, вычисление выражений, recording rules и alert rules. Для production заранее задают retention, лимиты диска и правила удаления, иначе рост числа series начнет конкурировать с workload-ами за ресурсы.
Grafana строит дашборды по данным Prometheus. На панели кластера полезно показывать текущее значение, динамику за 1, 6 и 24 часа, baseline, доступную емкость и объект Kubernetes, к которому относится сигнал. Один график загрузки CPU без requests, limits и числа реплик редко помогает принять решение.
Alertmanager принимает сработавшие правила, группирует их, подавляет зависимые уведомления и отправляет сообщения в нужный канал. Prometheus отвечает за факт срабатывания, Alertmanager за маршрутизацию, дедупликацию и эскалацию. Практическая последовательность настройки Prometheus, Grafana и Alertmanager приведена в пошаговом руководстве по мониторингу и алертингу Kubernetes.
kube-state-metrics, metrics-server и метрики kubelet
kube-state-metrics читает состояние объектов через Kubernetes API и публикует такие признаки, как число желаемых и доступных реплик, фаза pod-а, состояние Deployment, PVC и Job. Он не измеряет реальное потребление CPU или памяти контейнером.
metrics-server предоставляет оперативные значения CPU и памяти для команд вроде kubectl top и Horizontal Pod Autoscaler. Это короткий текущий срез, а не полноценное долговременное хранилище для анализа трендов и расследования инцидентов.
kubelet публикует сведения о работе узла и контейнеров. Источник cAdvisor внутри kubelet дает показатели контейнерного runtime: потребление CPU, память, сеть и файловую систему. Названия и доступность отдельных endpoints зависят от версии Kubernetes и конфигурации kubelet, поэтому их проверяют в конкретном кластере.
node exporter обычно запускают на каждой worker-ноде. Он дает сведения операционной системы: загрузку CPU, память, файловые системы, inode, сетевые интерфейсы и ошибки. Подробный пример сбора ресурсов через kube-state-metrics и node-exporter есть в руководстве по метрикам CPU, памяти, диска и сети Kubernetes.
Метрики приложений и black-box-проверки
Application metrics описывают работу сервиса: количество запросов, latency, число ошибок, длину очереди, время ответа базы данных и состояние бизнес-операций. Для HTTP-сервиса полезны счетчики запросов и ошибок, histogram для latency и labels с сервисом, методом и кодом ответа. Не добавляйте в labels user ID, request ID или другие значения с высокой кардинальностью.
HTTP health check или black-box probe отправляет запрос так, как его отправляет клиент. Проверка может контролировать код ответа, время ответа, TLS и наличие обязательного фрагмента результата. Внутренний probe pod-а не заменяет проверку Ingress, DNS и внешней зависимости.
ServiceMonitor и PodMonitor помогают автоматически находить endpoints приложений при использовании Prometheus Operator. Практические варианты наблюдения за Service и приложениями описаны в материале о мониторинге сервисов и приложений Kubernetes.
Мониторинг Kubernetes: ключевые метрики
Метрика полезна, когда у нее есть единица измерения, направление деградации, владелец и действие. Порог берут из baseline нагрузки, requests, limits, capacity ноды и SLO. Значение CPU 80 процентов может быть нормальным для batch-задачи и критичным для latency-sensitive API.
Метрики нод Kubernetes: доступность и ресурсы
| Группа | Метрики | Признак проблемы |
|---|---|---|
| Доступность | Ready/NotReady, heartbeat kubelet, время последнего обновления статуса | Нода NotReady, устаревший heartbeat или потеря связи с control plane |
| CPU | Использование CPU, load, allocatable и reserved capacity | Устойчивая загрузка выше baseline, CPU throttling у критичного workload-а, нехватка allocatable |
| Память | Used, available, working set, memory pressure и swap, если он разрешен | MemoryPressure, OOMKilled, вытеснение pod-ов или быстрый рост working set |
| Диск | Заполнение файловой системы, свободные байты, inode, disk pressure | Заполнение выше согласованного порога, нехватка inode, ошибки записи и read-only режим |
| Сеть | Receive/transmit bytes, errors, drops, retransmits и packet loss | Рост ошибок интерфейса, потери пакетов, увеличение сетевой задержки |
| Runtime | Состояние container runtime, количество контейнеров и ошибки операций | Невозможность создать, остановить или удалить контейнер |
Сравнивайте фактическое потребление с allocatable, а требования pod-а с requests и limits. Нода с 90 процентами свободной памяти может не принять новый pod, если свободная allocatable capacity не соответствует его request или действуют taints и affinity.
Порог для warning задают по историческому baseline, например при устойчивом заполнении файловой системы в течение 15 минут. Critical нужен, когда расчетное время до исчерпания ресурса меньше времени реакции команды или уже нарушается доступность. Одно мгновенное значение редко достаточно для алерта.
Метрики pod-ов и контейнеров
Для pod-а отслеживайте фазу, condition Ready, количество рестартов и причину последнего завершения контейнера. CrashLoopBackOff означает повторные неудачные запуски с увеличивающейся задержкой, а не конкретную причину. Причину ищут в поле reason, предыдущих логах и событиях.
- Рестарты: рост за 5 или 15 минут показывает нестабильность процесса.
- OOMKilled: подтверждает завершение из-за ограничения или давления по памяти, но требует проверки memory limit и реального потребления.
- Waiting и Terminated: помогают увидеть ImagePullBackOff, ошибку запуска и код выхода.
- CPU throttling: показывает, что контейнер часто упирается в CPU limit, даже если среднее потребление выглядит умеренным.
- Память: working set и RSS лучше сопоставлять с limit, requests и временем рестартов.
- Сеть: receive/transmit bytes и ошибки помогают отделить сетевую проблему от ошибки приложения.
Сопоставляйте временную шкалу рестартов с событиями, логами и изменениями Deployment. Одновременный рост рестартов и memory working set подтверждает ресурсную гипотезу сильнее, чем один статус pod-а.
Deployment, StatefulSet и доступная нагрузка
Для Deployment контролируйте spec.replicas, current replicas, updated replicas, available replicas и unavailable replicas. Полезны возраст последнего rollout, номер generation, condition Progressing и condition Available. Если updated replicas растет, а available остается ниже нужного числа 10 минут, rollout требует проверки.
Для StatefulSet добавьте порядок запуска, готовность каждой реплики, стабильность имен и состояние связанных PersistentVolume. Отсутствие одной реплики может нарушить кворум базы данных, хотя остальные pod-ы остаются Running. Для stateful-сервисов алерт связывают с минимальным числом здоровых реплик и состоянием томов.
Доступная нагрузка рассчитывается через число готовых реплик и их фактическую производительность. Четыре pod-а в статусе Running не гарантируют запас: readiness может исключить два экземпляра, а два оставшихся могут работать на пределе CPU. Сравнивайте available replicas, успешные запросы, latency и error budget.
Service, Ingress и пользовательский трафик
На уровне Service проверяйте наличие endpoints, число ready backend-ов и равномерность распределения запросов. Пустой список endpoints объясняет недоступность сервиса даже при статусе Running у pod-ов. Причиной бывают неверные labels, не пройденная readiness probe или selector.
Для Ingress и ingress controller собирайте requests per second, latency p50, p95 и p99, коды 4xx и 5xx, timeout, reset, TLS errors и ошибки DNS. Рост p99 при стабильном среднем времени ответа показывает проблемы с хвостом распределения, которые часто видят пользователи с медленными запросами.
Разделяйте источник ошибки: ingress controller, Service, endpoint, pod или внешняя зависимость. Для критичного маршрута задайте SLO, например долю успешных ответов и допустимую latency. Порог 5xx выбирают по трафику: пять ошибок при одном запросе в минуту и пять ошибок в секунду создают разный риск.
Control plane и кластерные сервисы
API Server контролируют по доступности, latency запросов, кодам ответа, доле ошибок и насыщению обработчиков. Задержки API проявляются как медленные команды kubectl, задержанные rollout-ы и невозможность создать или обновить pod.
Для etcd нужны метрики доступности участников, latency операций, ошибки записи и состояние свободного места. Потеря кворума блокирует запись состояния кластера. Scheduler и controller manager проверяют по доступности, ошибкам и задержкам обработки очередей.
CoreDNS контролируют по числу запросов, latency, SERVFAIL, NXDOMAIN и доступности pod-ов DNS. У сетевого плагина проверяют состояние agents, ошибки маршрутизации, packet loss и время доставки. Общая проблема control plane или DNS может породить десятки вторичных алертов в разных namespace.
Хранилище, сеть и емкость
Для PersistentVolume разделяйте доступность, емкость и производительность. Проверяйте фазу PV, binding PVC, ошибки монтирования, latency read/write, IOPS, throughput и заполнение тома. Заполненный PVC и медленный том создают разные сценарии восстановления.
Учитывайте три пространства: временную файловую систему контейнера, filesystem ноды и PersistentVolume. Заполнение любого из них может остановить приложение. Inode заканчиваются раньше байтов, если сервис создает большое число мелких файлов.
Для сети измеряйте latency, packet loss, retransmits, drops и ошибки интерфейсов между клиентом, Ingress, Service, pod-ом и внешней зависимостью. Емкость отвечает на вопрос, хватит ли ресурса. Производительность показывает скорость работы. Доступность подтверждает, что путь вообще функционирует.
Как проектировать алерты для Kubernetes
Алерт должен сообщать о риске, назначать владельца и подсказывать следующее действие. Причины нужны для диагностики, а дежурного будят подтвержденная деградация доступности, latency, capacity или SLO.
Правило алерта: сигнал, условие, окно и действие
Практическое правило содержит пять частей: выражение метрики, область действия, условие, окно for и действие. В labels задайте кластер, namespace, workload, service, owner и severity. В annotations укажите влияние, текущее значение, время начала, ссылку на дашборд и runbook.
| Сигнал | Пример условия | Действие |
|---|---|---|
| Нода недоступна | Ready имеет значение false в течение 5 минут | Проверить kubelet, сеть, runtime и перераспределение workload-ов |
| Недостаток реплик | available replicas ниже требуемого числа 10 минут | Проверить rollout, events, probes, scheduler и capacity нод |
| HTTP 5xx | Доля ошибок выше SLO в течение 5 минут | Разделить ingress, backend и внешнюю зависимость по latency и логам |
| Высокая latency | p95 или p99 выше целевого значения в течение согласованного окна | Проверить очередь, CPU throttling, сеть, базу данных и лимиты |
| Заполнение диска | Свободное место ниже порога с учетом скорости роста | Проверить логи, временные файлы, retention и расширение тома |
Время for выбирают по характеру сигнала. Для потери ноды достаточно нескольких минут, для краткого всплеска latency нужно окно, которое исключает обычные пики. Записывайте обоснование порога в runbook и пересматривайте его после инцидента.
Критический, предупреждающий и информационный уровень
Critical означает текущий ущерб пользователям или высокую вероятность его появления: недоступен API, потеряно требуемое число реплик, нарушено SLO, отсутствует кворум. Такое уведомление направляют дежурному с коротким временем реакции.
Warning показывает управляемую деградацию или риск исчерпания: свободный диск быстро уменьшается, rollout долго не продвигается, memory pressure приближается к критической зоне. Сообщение попадает владельцу сервиса или в рабочий канал.
Informational фиксирует состояние для обзора: изменился image, начался rollout, появился одиночный рестарт без влияния на SLO. Такой сигнал не должен будить дежурного.
Как убрать шум: дедупликация, группировка и подавление
Для дедупликации используйте стабильные labels. В них не должны попадать pod name, hash ReplicaSet или другой идентификатор, который меняется при каждом rollout, если алерт относится ко всему сервису.
Группируйте уведомления по cluster, namespace, service и owner. Inhibition временно подавляет вторичные симптомы. Например, недоступность control plane может подавить сообщения о задержке rollout-ов и отдельных объектах, потому что их причина уже известна.
Настройте задержку восстановления, чтобы краткий возврат сигнала не создавал пару сообщений для одного события. Группировка не должна скрывать разные критичные сервисы, если им нужны разные владельцы или действия.
Маршрутизация, эскалация и контекст
Маршрутизируйте alert по owner, namespace, сервису и severity. Critical направляйте дежурному, Warning владельцу команды, Informational в канал обзора. Для критичных сигналов задайте повторную доставку и эскалацию, если подтверждение не получено за согласованное время.
В сообщение включайте кластер, namespace, workload, симптом, текущее значение, время начала, SLO, ссылку на дашборд и runbook. Фраза «высокая нагрузка» бесполезна без названия ноды, периода, значения и команды для первой проверки.
SLO и доступная нагрузка вместо формального статуса pod
Статус pod-а описывает внутреннее состояние экземпляра. SLO показывает результат для пользователя. Поэтому критичное правило может объединять доступные реплики, долю успешных запросов, p99 latency и расход error budget.
Сервис с шестью Running pod-ами способен нарушать SLO, если каждый экземпляр перегружен или Ingress направляет трафик на медленную зависимость. И наоборот, один недоступный pod не требует срочной эскалации, если запас реплик сохраняет целевую доступность и latency.
Health checks и централизованное логирование
Health checks постоянно проверяют компоненты и помогают автоматически убрать нездоровый экземпляр из rotation. Логи дают контекст для поиска причины, когда метрика показывает факт, но не объясняет механизм сбоя.
Liveness, readiness и startup probes
livenessProbe отвечает на вопрос, нужно ли перезапустить контейнер. Проверка должна выявлять зависшее состояние процесса. Если включить в liveness обязательную внешнюю базу данных, краткий сетевой сбой вызовет каскад рестартов.
readinessProbe показывает, может ли pod принимать трафик. При ошибке Kubernetes убирает endpoint из Service, сохраняя контейнер запущенным для восстановления. Это основной механизм защиты пользователя от отправки запросов в неготовый экземпляр.
startupProbe дает медленно запускающемуся приложению время на инициализацию. Пока startup probe не прошла, liveness и readiness не должны преждевременно завершать процесс. Таймаут, period и failure threshold рассчитывают по фактическому времени запуска, а не по удобному круглому числу.
Слишком короткий timeout вызывает ложные сбои при пике нагрузки. Неверный endpoint маскирует рабочее приложение как нездоровое. Проверка, которая делает тяжелый запрос к нескольким зависимостям, сама может перегрузить сервис.
Централизованное логирование Kubernetes
Собирайте stdout и stderr контейнеров в единое хранилище. К каждой записи добавляйте namespace, pod, container, node, service, severity, timestamp и correlation ID или request ID. Без этих полей поиск причины распределенного сбоя превращается в ручное сопоставление файлов на нодах.
Известный паттерн централизованного логирования для Kubernetes, EFK, объединяет Elasticsearch, Fluentd и Kibana. Fluentd собирает и нормализует записи, Elasticsearch индексирует и хранит их, Kibana дает поиск и визуализацию.
Перед запуском определите retention, объем диска, правила удаления, RBAC и доступ к персональным данным. Индексация всех полей и бессрочное хранение быстро увеличивают стоимость и нагрузку. Для production задайте фильтры, sampling и отдельные правила для audit-логов.
Связь логов, метрик и событий
- Метрика обнаруживает отклонение, например рост доли HTTP 5xx.
- Событие Kubernetes уточняет изменение, например рестарт контейнера или неудачный mount PVC.
- Лог подтверждает механизм, например timeout внешней базы данных, ошибку конфигурации или OOM.
- Runbook связывает подтверждение с действием и критериями восстановления.
Рост 5xx вместе с рестартами pod-а и сообщением о недоступной зависимости дает связную гипотезу. Если 5xx растет без рестартов, сначала проверьте Ingress, Service, latency backend-а и внешние вызовы.
Сценарии диагностики инцидентов в Kubernetes
Начинайте с пользовательского симптома, затем проверяйте Ingress или Service, workload, pod, ноду, control plane и внешние зависимости. Каждый шаг должен подтверждать или исключать гипотезу через метрику, событие, лог или команду kubectl.
Pod в CrashLoopBackOff или с частыми рестартами
- Получите состояние и причины завершения через
kubectl describe pod. - Проверьте предыдущий запуск командой
kubectl logs --previous. - Изучите events: ошибки ImagePull, Secret, ConfigMap, mount и probes.
- Сопоставьте рестарты с memory working set, CPU throttling, limits и deployment-изменениями.
- Проверьте liveness, readiness, startup probe и доступность зависимостей.
OOMKilled подтверждает завершение по памяти. Проверьте, не растет ли потребление постепенно, не слишком ли низок limit и не вызвана ли проблема утечкой. При ошибке probe изучите timeout, endpoint и время запуска приложения.
Пошаговый алгоритм поиска причины через метрики CPU, памяти, сети и диска собран в руководстве по диагностике pod-ов и узлов Kubernetes.
Pod остается в Pending
Сначала выполните kubectl describe pod и прочитайте events scheduler. Частые причины: нехватка CPU или памяти, taints без tolerations, несовпадение nodeSelector, affinity, topology spread constraints, отсутствие подходящей ноды или проблемы с PVC.
Сравните requests pod-а с allocatable capacity каждой подходящей ноды. Свободное место по фактическому потреблению не гарантирует размещение, если requests уже зарезервировали емкость. Для PVC проверьте StorageClass, binding, zone и доступность узла хранения.
Нода Kubernetes переходит в NotReady
- Проверьте condition и последние events ноды.
- Изучите состояние kubelet, container runtime, сети, памяти и файловой системы.
- Проверьте memory pressure, disk pressure и inode pressure.
- Определите workload-ы, которые размещены на ноде, и число доступных реплик после ее потери.
- Убедитесь, что health checks исключили нездоровые экземпляры, а critical alert дошел до владельца.
Если остальные ноды не выдерживают requests потерянного узла, проблема capacity быстро превращается в пользовательский инцидент. После восстановления проверьте причины: сбой сети, заполнение диска, зависание runtime, нехватка памяти или проблема физического хоста.
Ingress отвечает медленно или возвращает 5xx
- Сравните p50, p95 и p99 latency, долю 4xx и 5xx, timeout и reset.
- Проверьте DNS, TLS и логи ingress controller.
- Убедитесь, что Service имеет нужные endpoints и readiness не исключила все backend-ы.
- Сопоставьте latency backend-ов с CPU, памятью, throttling и длиной очередей pod-ов.
- Проверьте внешние зависимости, database latency и сетевые retransmits.
Распределение по кодам HTTP помогает отделить ошибку клиента от ошибки сервера. Таймаут на Ingress при нормальном времени обработки pod-а указывает на сетевой путь, лимит прокси или разницу между внутренней и внешней проверкой.
API Server, DNS или кластерный сервис деградирует
При проблемах API Server проверьте доступность и latency запросов, ошибки, состояние etcd и задержку обработки control plane. Одновременные Pending, задержанные rollout-ы и ошибки команд kubectl могут иметь общий источник.
При сбое DNS проверьте CoreDNS, SERVFAIL, NXDOMAIN, latency резолвинга и сетевую доступность DNS pod-ов. Затем выясните, какие сервисы потеряли service discovery. Для CNI проверьте agents, маршруты, drops и packet loss.
Используйте группировку алертов. Первичный сигнал по API Server или DNS должен помочь отделить причину от десятков вторичных ошибок приложений.
Заканчивается место на диске или PersistentVolume
- Разделите node filesystem, ephemeral storage контейнера и PersistentVolume.
- Проверьте свободные байты, inode, disk pressure и скорость заполнения.
- Изучите ошибки монтирования, I/O latency, read-only состояние и ошибки записи.
- Проверьте retention логов, временные файлы и рост данных приложения.
- Оцените время до исчерпания и согласуйте очистку, расширение или перенос данных.
Низкая latency при заполненном томе не отменяет риска: приложение может перестать записывать данные после достижения лимита. И наоборот, свободный объем не исключает деградацию, если устройство отвечает медленно или возвращает ошибки.
Подготовка мониторинга Kubernetes к production
Карта критичности сервисов и зависимостей
Для каждого сервиса зафиксируйте owner, namespace, критичный пользовательский путь, SLO, зависимости, допустимое время реакции и последствия недоступности. В карту включите общие компоненты: control plane, Ingress, DNS, registry, CNI и хранилище.
Критичность определяет набор метрик и канал уведомления. Для платежного API нужны SLO, p99 и ошибки бизнес-операций. Для batch-задачи важнее задержка завершения, очередь и доступность хранилища.
Кластер для нового проекта можно разместить в облачной инфраструктуре с Kubernetes, VDS, базами данных и хранилищем, например у Timeweb Cloud. При выборе площадки заранее проверьте доступность метрик провайдера, резервирование, зоны отказа, сетевые лимиты и способ доступа к control plane.
Минимальный набор дашбордов
- Обзор кластера: доступность нод, состояние control plane, общая capacity, активные critical и warning.
- Ноды: CPU, память, pressure conditions, filesystem, inode, сеть и runtime.
- Workload-ы: replicas, rollout, рестарты, OOMKilled, requests, limits и throttling.
- Ingress и приложения: requests per second, p50, p95, p99, 4xx, 5xx и SLO.
- Хранилище: PVC, PV, свободная емкость, I/O latency, IOPS и ошибки.
- Алерты: состояние firing, владелец, длительность, severity и время последнего изменения.
Каждый график должен отвечать на вопрос: что сломалось, когда началось, кого затронуло и какое действие требуется. Для сравнения используйте baseline за рабочий день, неделю или сезонный период, если нагрузка меняется по расписанию.
Проверка алертов через контролируемые сценарии отказа
Проверяйте систему на тестовом workload-е с теми же probes, requests, limits и маршрутами, что у production-сервиса. Создайте контролируемые сценарии: удаление pod-а, превышение memory limit, недоступность backend-а, потеря тестовой ноды, рост latency и заполнение тестового тома.
Для каждого теста измерьте время обнаружения, доставки, подтверждения, реакции и восстановления. Проверьте, что сообщение содержит cluster, namespace, workload, текущее значение, ссылку на дашборд и runbook. После теста верните конфигурацию и убедитесь, что алерт перешел в resolved.
Аудит качества мониторинга и алертинга
Ежемесячно анализируйте количество алертов, долю ложных срабатываний, время до реакции, время до восстановления, повторяемость и отключенные правила. Удаляйте сигналы без владельца и действия. Для каждого critical alert проверяйте актуальность labels, источника метрики, порога, окна и runbook.
После изменения Kubernetes, exporters, CNI или ingress controller сверяйте названия метрик и labels. Rollout новой версии может изменить доступные endpoints или формат labels. Мониторинг считают рабочим только после повторного теста уведомлений.
Чек-лист перед включением мониторинга
- Метрики собираются со всех нод и нужных namespaces.
- Покрыты control plane, Ingress, DNS, CNI, registry и хранилище.
- Проверены CPU, memory, disk, inode, сеть, рестарты, OOMKilled и replicas.
- Readiness, liveness и startup probes соответствуют фактическому поведению приложений.
- Логи попадают в централизованное хранилище с namespace, pod, container и request ID.
- Заданы retention, RBAC, фильтры и лимиты хранения.
- Critical, Warning и Informational идут в разные каналы.
- Для каждого уведомления, которое будит дежурного, существует runbook.
- Проведены тестовые отказы, проверены эскалация и восстановление.
- Пороги сверены с baseline, requests, limits и SLO.
Вопросы и ответы о мониторинге Kubernetes
Какие метрики Kubernetes нужно настроить в первую очередь?
Начните с доступности нод, Ready и pressure conditions, CPU и памяти, заполнения диска и inode. Для workload-ов добавьте рестарты, OOMKilled, CrashLoopBackOff, available replicas и rollout. Для пользовательского пути нужны HTTP latency, 5xx, доступность endpoints, API Server, DNS, storage и SLO.
Минимальный набор расширяйте после инвентаризации критичных сервисов. Batch, stateful-база и публичный API требуют разных сигналов.
Достаточно ли Prometheus и Grafana для мониторинга?
Prometheus и Grafana покрывают сбор, хранение и визуализацию метрик. Для состояния объектов нужны kube-state-metrics и другие подходящие exporters, для текущего потребления и autoscaling нужен metrics-server, для уведомлений нужен Alertmanager. Поиск причин обычно требует Kubernetes events и централизованных логов.
Почему pod работает, но сервис недоступен?
Статус Running не подтверждает readiness, наличие endpoints и корректность ответа. Проверьте readiness probe, selector Service, endpoints, Ingress, DNS, NetworkPolicy, коды HTTP, нагрузку backend-а и внешние зависимости. Black-box-проверка показывает фактический результат для клиента.
Как избежать устаревших правил и неправильных порогов?
Проверяйте версии Kubernetes, Prometheus Operator и exporters, названия метрик и labels. Стройте baseline по реальной нагрузке, учитывайте requests, limits, capacity и SLO. После каждого значимого изменения анализируйте ложные срабатывания, отключенные правила и историю инцидентов, затем корректируйте выражения и окна.