Метрики инфраструктуры и Kubernetes: ноды, поды, кластеры, метрики Kubernetes

Ключ к устойчивому и предсказуемому ению современных облачных систем - детальная observability инфраструктуры Kubernetes. В этой главе рассмотрены архитектура сбора метрик, источники данных и практики работы с ними в рамках Grafana, Prometheus и сопутствующих инструментов. Особое внимание уделено тому, как ноды, поды и контрольplane Kubernetes генерируют метрики, как их агрегировать, хранить и визуализировать, а также как строить алерты и SLO, позволяющие управлять сложностью динамических кластеров и data platform на основе Kubernetes.

В современных архитектурах Kubernetes наблюдаемого поведения достигается за счет сочетания экспортёров на нодах, метрик API-сервера, kubelet и kube-state-metrics, а также грамотной интеграции с Prometheus и Grafana. Включение Loki и Tempo позволяет коррелировать метрики с логами и трасировками, что существенно повышает ценность наблюдаемости при инцидентах. Глава также охватывает практические сценарии мониторинга нод, подов, кластера, микросервисов и data platform в рамках единой панели Grafana.

Архитектура сбора метрик Kubernetes: источники, сборщики, Service Discovery, Prometheus Operator и роль Grafana.
Метрики нод, подов и кластера: что измерять, какие метрики собирать и как их интерпретировать.
Визуализация в Grafana: структура дашбордов, запросы PromQL, создание панелей для нод, подов и API-сервера.
Алерты и SLO: определение доступности и устойчивости контрольной плоскости, правила алертов, управление бюджетом ошибок.
Интеграция с Loki и Tempo: корреляция метрик, логов и трассировок для быстрой диагностики.
Практические сценарии: мониторинг микросервисов и data platform на Kubernetes, лучшие практики и типичные паттерны.

Архитектура сбора метрик Kubernetes и Grafana: от источников к дашбордам

Сбор метрик в Kubernetes опирается на три слоя: источники данных внутри кластерной инфраструктуры, механизм их аггрегации и хранение, а затем визуализация в Grafana. Архитектура должна обеспечивать надежную доставку данных, гибкое масштабирование и возможность быстрого отклика на инциденты.

Источники метрик включают node_exporter на узлах, kube-state-metrics для состояния объектов Kubernetes, metrics-server (и API-метрики kubelet), а также метрики контроллеров и API-сервера (scheduler, controller-manager, etcd). Дополнительно собираются метрики сети, дисков и ресурсов контейнеров через cAdvisor/который входит в node_exporter и напрямую в уровне контейнерной среды.
Сбор и агрегация осуществляются преимущественно через Prometheus. В средах Kubernetes особенно эффективен Prometheus Operator, который управляет CRD-ресурсами Prometheus, PrometheusRule, ServiceMonitor и PodMonitor. Это позволяет определить как автоматически ищущиеся цели, так и конкретные сервисы/поды для мониторинга с использованием ServiceMonitor/PODMonitor.
Поиск сервисов (Service Discovery) обеспечивает динамическое обнаружение целевых метрик по изменениям в Kubernetes: новые ноды, поды, услуги, при этом Relabel-правила позволяют фильтровать, трансформировать метки и прокидывать необходимые лейблы в Prometheus.
Архитектура Grafana focuses на источник Prometheus и, при необходимости, на long-term storage через remote_write. Grafana служит единым узлом для дашбордов по нодам, подам, кластерам, а также для коррелирования метрик с логами в Loki и трассировками в Tempo.
Безопасность и эксплуатационная устойчивость требуют правильной настройки RBAC для сервис-аккаунтов, ограничений network policies и минимальных прав для сервисов, которые экспортируют метрики. В продакшене рекомендуется размещать Prometheus в HA-режиме с хранением данных в центральном persistent volume или удаленной базе хранения, а дашборды Grafana - в изолированной зоне доступа.

Источники метрик

Ключевым источником метрик являются node_exporter и kube-state-metrics. node_exporter собирает системные метрики хоста: CPU, память, диск, сеть и другие показатели, специфические для ОС и аппаратной платформы. kube-state-metrics предоставляет состояние объектов Kubernetes: Deployment, DaemonSet, StatefulSet, Pod, ReplicaSet и т. д., позволяя видеть статус и желаемое состояние отрывочно от событий.

node_exporter охватывает базовую инфраструктуру: CPU- и memory-в usage, файловые системы, сетевые интерфейсы, загрузку и т. д.
kube-state-metrics консолидирует метрики состояния Kubernetes-объектов, что полезно для вычисления SLA по классам сервисов, анализу загрузки ReplicaSet и состоянию подов.

Сбор и агрегация

Prometheus собирает данные по Scrape-правилам, указывающим, какие эндпойнты и как часто опрашивать. В Kubernetes Prometheus Operator упрощает этот процесс:

ServiceMonitor позволяет определить набор сервисов как точки сбора.
PodMonitor захватывает показатели непосредственно контейнеров.
Relabeling обеспечивает единый набор лейблов, необходимый для группировки и фильтрации.
remote_write обеспечивает экспорт данных в долгосрочное хранилище (например, Cortex, Thanos, или VictoriaMetrics) для масштабирования и долговременной аналитики.

Поиск и обнаружение сервисов

Kubernetes Service Discovery обновляет список целей в Prometheus в реальном времени, учитывая масштабирование кластеров, рестарты подов и др. В составе решений Prometheus Operator применяется механизм CRD, который автоматически поддерживает актуальную конфигурацию мониторинга по мере изменений в кластере.

Архитектура Grafana и роль Prometheus Operator

Grafana читает данные из Prometheus (или из нескольких источников) и предоставляет мощные дашборды, алерты и шаблоны. В связке с Loki и Tempo Grafana может показывать логи и трассировки, связанные с конкретными узлами, подами или Namespace. Применение Prometheus Operator упрощает управление мониторингом на уровне кластера и снижает риск расхождений между источниками и отображением.

Безопасность и эксплуатационная устойчивость

RBAC: ограничение прав сервис-аккаунтов Prometheus и Grafana, чтобы они могли только осуществлять чтение метрик и конфигурировать ServiceMonitor.
Сетевые политики: ограничение доступа к API-серверу и эндпойнтам метрик.
HA и хранение: репликация Prometheus, использование внешнего хранилища для долговременного хранения, контроль обновлений и роллбеков.

Производительность и масштабирование

Настройка частоты сборов (scrape interval) и пагинации индикаторов. Для критических сервисов - более частые сборы, для менее важных - умеренные значения.
Период хранения и ретеншн: баланс между storage costs и скоростью доступа к данным.
HA-конфигурации и точка отказа: распределение экземпляров Prometheus и балансировка нагрузки Grafana.

Метрики нод, подов и кластера: что именно измеряем

Ключевые метрики инфраструктуры Kubernetes разбиваются на группы по объектам: ноды, поды и кластер в целом. В каждой группе - набор KPI, который позволяет обнаруживать проблемы на ранних стадиях, а также оценивает качество сервиса для бизнес-целей.

Метрики нод (node_exporter и связанные источники)

На уровне нод доступны данные об использовании CPU, памяти, дисков и сетевых ресурсах. Типичные метрики:

CPU usage: доля занятости процессорного времени.
Memory usage: доля занятой памяти; наличие утечек или переполнения.
Disk usage: заполнение файловых систем, IO-операции.
Network: пропускная способность и ошибки.

Примеры типичных запросов PromQL:

1. 100 * (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))

2. 100 * (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes))

3. 100 * (1 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}))

Эти выражения помогают выявлять перегрев CPU, нехватку памяти и исчерпание дискового пространства на узлах. В реальных кластерах полезно учитывать специфику рабочих нагрузок и архитектуры хостов (bare-metal vs облачные инстансы).

Метрики подов и контейнеров

Контейнеры предоставляют динамические показатели: использование CPU и памяти на уровне контейнеров, количество перезапусков, время жизни Pod’ов и статус контейнеров. Взаимодействие с kube-state-metrics дополняет картину состоянием объектов.

Метрики CPU и памяти контейнеров (container_cpu_usage_seconds_total, container_memory_usage_bytes).
Под-подсчёт статуса контейнеров и подов (kube_pod_status_phase, kube_pod_container_status_restarts_total).

Понимание этих метрик позволяет обнаруживать проблемы в конкретных контейнерах (например, перелив памяти, деструктивные утечки) и в самом поде (CrashLoopBackOff).

Метрики кластера и контроллера

Контрольная плоскость Kubernetes (API-сервер, scheduler, controllers, etcd) - критически важная область для наблюдаемости. Метрики здесь используются для измерения доступности API и времени отклика, задержек операций и состояния кластера.

Latency и throughput API-сервера: kube-apiserver_request_duration_seconds, kube_apiserver_request_size_bytes.
Задержки внутри планировщика и очередей: scheduler_schedule_duration_seconds.
Метрики etcd: запросы к базе метаданных, задержки, пропускная способность.

Примеры запросов:

histogram_quantile(0.95, sum(rate(kube_apiserver_request_duration_seconds_bucket[5m])) by (le))

sum(rate(etcd_server_proposals_sent_total[5m]))

### Метрики Kubernetes API и состояния компонентов

kube_pod_owner и kube_pod_status_phase: корреляция подов с их владельцами и фазами.
kube_deployment_status_replicas_available: сколько реплик Deployment доступны.
kube_node_status_condition: состояние нод, включая Ready, OutOfDisk, MemoryPressure.

Эти метрики позволяют быстро увидеть дисбалансы между желаемым и текущим состоянием кластера и определить узкие места в планировании ресурсов.

Архитектура сбора и связь с Grafana

Графика по нодам, подам и кластерам строится на основе прометеевых наборов метрик, связанных через лейблы namespace, node, pod, container и т. д. В Grafana можно использовать переменные (templating) для фильтрации по namespace, node, меткам подов и т. д., чтобы поддерживать одну систему дашбордов для разных команд.

Визуализация метрик в Grafana: структура дашбордов и примеры PromQL

Графана функционирует как единая точка доступа к метрикам, логам и трейсам при взаимной корреляции. В контексте Kubernetes дашборды строятся по нескольким уровням: узлы, поды, кластер, а также по конкретным компонентам (API-сервер, etcd). Основной принцип - понятная организация панелей, возможность быстрого переключения между Namespace и узлами, а также возможность быстрого выявления аномалий.

Структура дашбордов: узлы - загрузка CPU/memory, детальная сетка по каждому узлу; поды - доля состояний, число перезапусков; кластер - состояние API-сервера, очередь планирования, нагрузка на etcd.
Взаимодействие с PromQL: создание панелей на основе стандартных запросов, использование агрегаций по лейблам и по временным окнам, настройка alert wrap для отображения критических порогов.
Генерация алертов прямо в Grafana или через Prometheus/Alertmanager: принципы разделения тревог по критичности и време.
```
1. Пример панели: загрузка CPU по узлу
```
avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))
```
2. Пример панели: использование памяти в процентах
100 * (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes))
```
```
3. Пример панели: лаги API-сервера
histogram_quantile(0.95, sum(rate(kube_apiserver_request_duration_seconds_bucket[5m])) by (le))
```
Важно помнить, что для больших кластеров следует инкрементально добавлять панели и фильтровать данные по Namespace, Node или Label, чтобы не перегружать дашборды ненужной информацией. В контексте микросервисной архитектуры такие панели помогают отфильтровывать проблемы на уровне конкретного сервиса или команды разработки.

Алерты и SLO: стратегия мониторинга инфраструктуры

Эффективная система мониторинга должна не только собирать данные, но и вовремя уведомлять о проблемах. Алерты строятся на основе реальных бизнес-требований и SLO, которые задают цели доступности и производительности. В Kubernetes особенно важны алерты по доступности API сервера, состоянии нод и подов, а также по задержкам системных компонентов.

Определение SLO для контрольной плоскости: например, 99.95% времени API-сервера должен отвечать в пределах заданной задержки.
Правила алертов: по нодам с Ready=false, по подам в статусе CrashLoopBackOff, по API-серверу с высоким временем отклика.
Эскалация: предупреждения на инженеров уровня SRE, оперативная смена стратагемы-перераспределение нагрузки, переразвертывание кластера, масштабирование.
Роли и ответственности: команды DevOps/Platform, Release Engineers, SRE отвечают на инциденты, обновляют дашборды и правила.

Пример правила алертов (PrometheusRule для Prometheus Operator):

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: node-not-ready-alerts
spec:
  groups:
  - **name**: node.rules
    rules:
    - **alert**: NodeNotReady
      expr: kube_node_status_condition{condition="Ready", status="false"} == 1
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Node {{ $labels.node }} is NotReady"
        description: "Node {{ $labels.node }} has been NotReady for more than 5 minutes."

Пример правила алертов по задержкам API-сервера:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: api-server-latency
spec:
  groups:
  - **name**: apiserver.rules
    rules:
    - **alert**: APIServerHighLatency
      expr: histogram_quantile(0.95, sum(rate(kube_apiserver_request_duration_seconds_bucket[5m])) by (le)) > 0.5
      for: 10m
      labels:
        severity: critical
      annotations:
        summary: "APIServer latency is high"
        description: "95th percentile API latency exceeds 0.5s for more than 10 minutes."

Управление бюджетом ошибок (Error Budget) - ключ к балансировке между скоростью изменений и надежностью. В контексте Kubernetes это означает:

Определение Target Availability: например, 99.95% доступности Control Plane.
Расчет Error Budget: 0.05% пропусков доступности за заданный период.
Наблюдение: сравнение фактической доступности с бюджетом в реальном времени и автоматизированные уведомления.

Интеграция с Loki и Tempo: корреляция метрик, логов и трассировок

Глубокая observability требует возможности связывать метрики с логами и трассировками. Grafana поддерживает интеграцию с Loki (лог-файлы) и Tempo (trace данные), что позволяет быстро переходить от инцидента к причине и обратно.

Loki обеспечивает сбор и поиск логов на уровне подов и нод, что упрощает поиск ошибок, связанных с конкретными контейнерами или Namespace.
Tempo предоставляет распределенные трассировки, позволяя увидеть путь запроса через микросервисы и выделить узкие места по задержкам.
Корреляция между метриками и логами/трассировками достигается через общие идентификаторы, такие как pod_name, namespace, container_name, node, и временные метки, что позволяет фильтровать логи и трассировки вокруг событий, регистрируемых в метриках.

Практические рекомендации:

Унифицируйте теги: обеспечьте единый набор меток для метрик, логов и трассировок (namespace, pod, app, instance).
Используйте доли времени и окна: сопоставляйте пики задержек в трассировках с аномалиями в метриках и синхронизируйте логи вокруг происшествий.
Автоматизация: Prometheus Alerting для триггеров, которые сопровождаются запросами к Loki/Tempo для быстрого расследования.
```
# Пример PromQL для корреляции с Tempo
sum(rate(http_request_duration_seconds_sum[5m])) by (service, pod, namespace)
```
Ключевые принципы корреляции:
Согласование временных окон между метриками и логами.
Сопоставление по идентификаторам (pod/namespace) и контексту (имя сервиса, окружение).
Визуальное перекрестное исследование в Grafana: дашборд, где на основном уровне показываются метрики, а отдельные панели позволяют открывать логи в Loki и трассировки в Tempo по той же временной метке.

Практические сценарии мониторинга для data platform и микросервисов

Мониторинг микросервисов и data platform на Kubernetes требует адаптации к особенностям рабочих нагрузок. Рассмотрим три сценария: типичный микросервис, высоконагруженная обработка данных и data platform в Kubernetes.

Микросервисы: основной фокус** - стабильность и производительность API, обработка очередей и устойчивость к сетевым задержкам. Мониторинг включает: доступность Pod, долю времени в статусе Running, задержки ответа API, число перезапусков контейнеров и продолжительность сборок в контейнерной среде. Важна корреляция между метриками контейнеров и состоянием подов.
Data platform: мониторинг компонентов, таких как Presto/Trino, Spark, Hive и прочие компоненты data lake. Важны метрики JVM, CPU и память исполнителей, задержки запросов к данным и пропускная способность сети, а также затраты на место в хранилище. Логика алертов - по перегрузке узлов и задержкам в обработке запросов.
Инфраструктура Kubernetes: контрольная плоскость, сеть и хранилища. Необходимо следить за задержками API-сервера и состоянием etcd, чтобы обеспечить высокий уровень доступности кластера и согласованность конфигураций.

Подход к визуализации для этих сценариев может включать:

Глобальные дашборды для кластера с KPI: узлы, поды, API-сервер, сеть и диск.
Дашборды для конкретного сервиса: метрики пода, контейнера, ReplicaSet, качество ответов, задержки, количество ошибок.
Дашборды для data platform: загрузка JVM, GC-активность, задачи Spark и их статус, задержки доступа к данным.

Key takeaways

Метрики Kubernetes строят профессиональные архитектуры мониторинга на основе компактной связки Prometheus, node_exporter, kube-state-metrics и Prometheus Operator, обеспечивая динамическое и маштабируемое наблюдение.
Ноды, поды и кластеры являются базовыми уровнями: используйте PromQL для вычисления KPI по CPU, памяти, диску, сети и состоянию объектов Kubernetes.
Grafana обеспечивает единый ресурс для визуализации, позволяя соединять метрики с логами в Loki и трассировки в Tempo для эффективной корреляции и быстрого расследования инцидентов.
Алерты и SLO должны соответствовать бизнес-целям и бюджету ошибок; формальные правила и PrometheusRule помогают внедрить их на уровне кластера.
Стабильность мониторинга требует грамотной архитектуры: репликации Prometheus, управление конфигурациями PrometheusOperator, RBAC и сетевые политики.
Включение Loki и Tempo позволяет объединить метрики, логи и трассировки и облегчает диагностику в случаях инцидентов.
Практические сценарии охватывают как микросервисы, так и data platform на Kubernetes, что подчеркивает необходимость адаптивности дашбордов и метрик под конкретные нагрузки.

FAQ

Что такое node_exporter и какие метрики он предоставляет?

node_exporter - это экспортёр метрик уровня хоста, который публикует показатели CPU, памяти, дисков, сети и прочих характеристик операционной системы. Он служит основой для понимания того, как аппаратная платформа и ОС влияют на работу контейнеров и сервисов на узле. Метрики генерируются в формате Prometheus и доступны через HTTP-эндпойнт на целевых нодах. Это позволяет анализировать производительность и выявлять узкие места на уровне инфраструктуры.

Как выбрать между Prometheus Operator и «классическим» Prometheus в Kubernetes?

Prometheus Operator автоматизирует развёртывание и обновление экземпляров Prometheus, а также CRD-ресурсов типа ServiceMonitor, PodMonitor и PrometheusRule. Это упрощает масштабирование, упрощает управление конфигурациями мониторинга и обеспечивает согласованность в больших кластерах. В условиях динамических кластеров с частыми изменениями сервисов и подов Operator обычно предпочтительнее, поскольку снижает риск рассинхронизации между целями сбора и конфигурацией.

Какие метрики полезно мониторить на уровне кластера?

Полезные группы включают: API-сервер (latency и throughput), etcd (команды, лидеры, latency), scheduler (время планирования), kubelet (состояние нод и контейнеров), сеть и диск, а также общую картина по ресурсам в Namespace и по состоянию подов. Важно видеть как желаемые состояния (например, Desired replicas) соответствуют фактическим (Available, Ready) для обеспечения SLO на уровне приложения.

Как связать метрики с логами и трассировками?

Связку обеспечивают общие идентификаторы (namespace, pod, service, container) и синхронизация времени. В Grafana можно строить панели, где выбор пода или Namespace демонстрирует одновременные лаги в логах (Loki) и временные трасы (Tempo). Это позволяет быстро локализовать инциденты: например, задержки в API, задержки в микросервисе, место, где произошел crash, или задержки в доступе к данным.

Что учитывать при настройке алертов для Kubernetes?

Нужно определить пороги, представляющие истинную бизнес-ценность: например, 99.95% доступности API-сервера, предельная загрузка CPU нод выше 80%, или длительное время отклика сервисов. Важно избегать дублирующих и ложных алертов, а также внедрять эскалацию и временные задержки (for) чтобы исключить шипы шума. Применение PrometheusRule в сочетании с Alertmanager позволяет гибко управлять уведомлениями.

Какие практические выгоды даёт интеграция Loki и Tempo?

Логи и трассировки дают контекст для метрик и упрощают диагностику инцидентов. С Loki можно быстро найти логи, относящиеся к конкретному поду или контейнеру, что позволяет детально понять причины деградации сервиса. Tempo обеспечивает трассировки запросов, позволяя увидеть путь между microservices, что помогает локализовать задержки и проблемы на уровне цепочки вызовов.

Как организовать мониторинг data platform на Kubernetes?

Data platform в Kubernetes требует мониторинга JVM/баз данных, worker и driver-процессов, объёмов памяти и CPU, задержек запросов к данным, загрузки кластера и дискозадач. Рекомендуется разворачивать отдельные наборы dashboards и алертов под типовую компонентику data platform (например, Spark, Trino, Hive), а также поддерживать общие панели для кластера и подов, чтобы видеть связь между функциональными компонентами и инфраструктурными метриками.

Какие подходы эффективны для масштабирования мониторинга в больших кластерах?

Эффективное масштабирование достигается за счёт HA-режимов Prometheus, использования внешнего хранилища и оптимизированного сбора (например, разграничение scrape-интервалов для критических сервисов и менее важных). В крупных кластерах полезны несколько экземпляров Prometheus, разделение по Namespace или по набором сервисов через ServiceMonitor, а также централизованный доступ к Grafana и унифицированная политика RBAC.

Какие практические шаги можно предпринять для перехода на метрическую observability в Grafana?

Начать с архитектуры сбора метрик: выбрать Prometheus Operator, определить набор источников (node_exporter, kube-state-metrics, metrics-server), настроить ServiceMonitor и PrometheusRule. Затем построить базовые дашборды: узлы, поды, кластер. Постепенно добавить логирование в Loki и трассировки в Tempo, чтобы улучшить корреляцию. Наконец - внедрить алерты и SLO, связывая их с бизнес-целями и бюджетом ошибок.

Какие открытые решения стоит упомянуть как примеры в рамках курса?

Prometheus и Prometheus Operator для мониторинга Kubernetes.
node_exporter и kube-state-metrics как источники метрик.
Grafana для визуализации и алертов.
Loki для логов и Tempo для трассировок для корреляции метрик, логов и трассировок.
В рамках ограничений на количество примеров, можно сосредоточиться на Prometheus Operator как основной подход к мониторингу Kubernetes и на Grafana как единый центр визуализации.

Эта глава охватывает широкий спектр аспектов: архитектуру сбора и агрегацию метрик, конкретные метрики нод и подов, методы визуализации в Grafana, создание алертов и SLO, а также интеграцию с Loki и Tempo для полной observability Kubernetes в рамках Grafana. Важно помнить: целью является не просто сбор данных, а создание управляемой карты состояния кластера, позволяющей быстро диагностировать инциденты, поддерживать бизнес-цели и обеспечить устойчивую работу data platform и микросервисов в условиях динамичной среды Kubernetes.

← Предыдущая статья

Методы расчета SLO: формулы, доверительные интервалы и кросс-системные зависимости

Следующая статья →

Мониторинг микросервисов: зависимости и maps service graphs