Настройка мониторинга Kubernetes кластера с Prometheus и Grafana с нуля

[Omoto]

Поднял кластер Kubernetes на трёх нодах, всё работает, но мониторинга ноль. Хочу видеть: загрузку CPU и памяти по подам и нодам, алерты если что-то падает или потребляет слишком много ресурсов, и дашборды с историей. Смотрю на Prometheus + Grafana, но там куча компонентов — kube-state-metrics, node-exporter, alertmanager. Есть ли простой способ всё это поднять разом?

[asynclover]

kube-prometheus-stack через Helm — это стандартный путь. Одна команда разворачивает весь стек: helm repo add prometheus-community https://prometheus-community.github.io/helm-charts && helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring --create-namespace. Получишь Prometheus, Grafana, Alertmanager, node-exporter и kube-state-metrics в одном флаконе. Grafana идёт с преднастроенными дашбордами для k8s.

[guardia]

После установки kube-prometheus-stack Grafana доступна через port-forward: kubectl port-forward svc/monitoring-grafana 3000:80 -n monitoring. Логин admin, пароль по умолчанию prom-operator (меняй через values.yaml: grafana.adminPassword). Дашборды с ID 315 и 6417 на grafana.com — отличные для обзора кластера, импортируются за секунды.

[carv]

Не забудь настроить PersistentVolume для Prometheus иначе при рестарте пода вся история метрик потеряется. В values.yaml: prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage: 50Gi. Ещё retention — по умолчанию 10 дней, можно увеличить: prometheus.prometheusSpec.retention: 30d.

[omnicrom]

Развёрнутая инструкция по алертингу. После установки стека создай свои алерты через PrometheusRule CRD. Пример правила для высокого CPU пода: apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: pod-alerts namespace: monitoring с alerting rules — выражение rate(container_cpu_usage_seconds_total[5m]) > 0.8 и severity: warning. Для алертов в Telegram или Slack настрой Alertmanager через секрет alertmanager-monitoring-kube-prometheus-alertmanager: в конфиге receivers указываешь slack_configs или telegram_configs с webhook URL. Для Telegram нужен бот — создаёшь через BotFather, получаешь токен и chat_id. Важные алерты которые стоит настроить сразу: PodCrashLooping (контейнер рестартует больше 5 раз за 10 минут), NodeMemoryPressure, PersistentVolumeFillingUp (заполнение PV > 85%), DeploymentReplicasMismatch (желаемое число реплик не совпадает с реальным). kube-prometheus-stack уже включает набор готовых алертов из kubernetes-mixin, изучи их прежде чем писать свои — скорее всего нужное уже есть.

[infern]

Для production советую сразу смотреть в сторону VictoriaMetrics вместо Prometheus — она потребляет в 5-7 раз меньше памяти при той же нагрузке и умеет горизонтальное масштабирование. Есть victoria-metrics-k8s-stack — аналог kube-prometheus-stack, совместим с теми же дашбордами и правилами.

[svelte88]

Если кластер managed (EKS, GKE, AKS) — у провайдеров есть встроенный мониторинг. CloudWatch Container Insights для EKS, Google Cloud Monitoring для GKE. Не всегда так гибко как Prometheus, но для начала можно сэкономить время на настройке.

[jbosco]

Поднимал ровно такой же стек на трёхнодовом кластере недавно. Один момент, который тут не прозвучал: свои приложения сами в мониторинг не попадут — для них нужен ServiceMonitor или PodMonitor с лейблом, который матчится селектором оператора. По умолчанию Prometheus Operator смотрит только на ресурсы с release-лейблом своего Helm-релиза, и народ потом часами ищет, почему метрики кластера есть, а метрик приложения нет. Это первые грабли после установки стека.

[ninja_marina]

@carv, дополню про retention: кроме retention: 30d стоит сразу задать retentionSize: 45GB при диске 50Gi. Иначе при всплеске кардинальности (кто-то добавил label с user_id в метрику — классика) диск забьётся задолго до 30 дней и Prometheus просто встанет. Лимит по размеру надёжнее лимита по времени, а вместе они дают предсказуемое поведение.

[merengue]

@infern, для прода с нагрузкой согласен, но человеку с тремя нодами и нулевым опытом я бы не советовал стартовать с VictoriaMetrics. У kube-prometheus-stack гигантское комьюнити, любая ошибка гуглится за минуту, все туториалы и примеры алертов написаны под него. Сначала понять модель Prometheus, PromQL и Alertmanager, а когда реально упрёшься в память — переехать на VM осознанно. Совместимость дашбордов как раз позволяет сделать это потом почти бесплатно.