Моніторинг Kubernetes через Prometheus та Grafana

Моніторинг Kubernetes має відповідати не лише на запитання «чи працюють pod». Потрібно бачити завантаження вузлів, запаси CPU та пам’яті, перезапуски контейнерів, стан Deployment, заповнення дисків, помилки застосунків і тенденції, які приведуть до інциденту через кілька годин. Prometheus збирає числові ряди, Alertmanager доставляє сповіщення, а Grafana перетворює метрики на зрозумілі dashboards.

У цьому матеріалі встановимо `kube-prometheus-stack` через Helm. Chart розгортає Prometheus Operator, Prometheus, Alertmanager, node-exporter, kube-state-metrics і Grafana з готовими Kubernetes dashboards. Потім додамо persistence, відкриємо UI через port-forward, підключимо метрики власного застосунку за допомогою ServiceMonitor і перевіримо базові PromQL-запити.

Перед початком потрібен робочий кластер, Helm 3, kubectl і storage class для PVC. Якщо кластер ще не підготовлений, спочатку виконайте практичне встановлення Kubernetes на Ubuntu 24.04. Також заздалегідь визначте, хто матиме доступ до Grafana і Alertmanager: ці інтерфейси не слід виставляти в інтернет без authentication, TLS та мережевих обмежень.

Що входить у kube-prometheus-stack і що перевірити

Prometheus Operator керує компонентами через CRD: `Prometheus`, `Alertmanager`, `ServiceMonitor`, `PodMonitor` і `PrometheusRule`. Сам Prometheus зберігає time series та виконує PromQL. node-exporter віддає системні метрики вузлів, kube-state-metrics описує стан Kubernetes-об’єктів, а Grafana вже отримує Prometheus як datasource.

Перевіримо контекст, версії й доступне сховище:

kubectl config current-context
kubectl version
helm version
kubectl get nodes -o wide
kubectl get storageclass

Перед встановленням оцініть retention і обсяг метрик. Частота scrape, кількість pod, cardinality labels та строк зберігання безпосередньо впливають на диск і пам’ять Prometheus. Значення «30 днів» саме по собі нічого не гарантує: кластер із тисячами активних series потребує значно більше місця, ніж невелике середовище.

Також перевірте, чи вже немає іншого Prometheus Operator або CRD. Два operator можуть конфліктувати, якщо їх selectors і watched namespaces перетинаються.

helm list --all-namespaces | grep -E 'prometheus|grafana' || true
kubectl get crd | grep monitoring.coreos.com || true
kubectl get prometheus,alertmanager --all-namespaces 2>/dev/null || true

У production варто окремо спланувати резервування dashboards, Alertmanager configuration та довготривале сховище. Локальний Prometheus добре підходить для оперативного retention, але для багатьох кластерів або тривалого зберігання потрібен remote write чи система на кшталт Thanos/Mimir.

Встановлення Prometheus і Grafana через Helm

Додамо community repository, оновимо індекс і переглянемо версії chart. Версію для реального середовища потрібно зафіксувати у deployment-конфігурації.

helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm repo update
helm search repo prometheus-community/kube-prometheus-stack \
  --versions | head

Збережемо типові values тієї версії, яку обрали:

helm show values \
  prometheus-community/kube-prometheus-stack \
  --version CHART_VERSION \
  > kube-prometheus-stack-default-values.yaml

Створимо `values-monitoring.yaml`. Приклад задає retention, PVC для Prometheus і Grafana та ресурси. Назву `storageClassName` потрібно замінити на клас із вашого кластера.

prometheus:
  prometheusSpec:
    retention: 15d
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
      limits:
        cpu: "2"
        memory: 4Gi
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: standard
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 50Gi

grafana:
  persistence:
    enabled: true
    storageClassName: standard
    size: 10Gi
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 1Gi

alertmanager:
  alertmanagerSpec:
    resources:
      requests:
        cpu: 100m
        memory: 256Mi

Встановимо stack у власний namespace. `--atomic` поверне release у разі невдалого встановлення, але CRD мають окремий життєвий цикл, тому перед major upgrade потрібно читати upgrade notes chart.

helm upgrade --install monitoring \
  prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --version CHART_VERSION \
  -f values-monitoring.yaml \
  --atomic \
  --wait \
  --timeout 15m

Перевіримо release, pod, PVC та CRD:

helm status monitoring -n monitoring
kubectl get pods -n monitoring -o wide
kubectl get pvc -n monitoring
kubectl get crd | grep monitoring.coreos.com
kubectl get prometheus,alertmanager -n monitoring

Якщо PVC залишається Pending, перевірте StorageClass, topology та режим доступу. Не запускайте Prometheus з ephemeral storage, якщо історія метрик потрібна після reschedule або перезапуску вузла.

Доступ до Grafana, Prometheus і базові PromQL-запити

Для першої перевірки використаємо port-forward, не створюючи публічний LoadBalancer. Назви Service можуть залежати від release, тому спочатку подивимося список:

kubectl get service -n monitoring

Відкриємо Grafana локально:

kubectl port-forward -n monitoring \
  service/monitoring-grafana 3000:80

Початковий пароль зберігається у Secret chart. Отримайте його локально й не додавайте результат до CI-логів або документації:

kubectl get secret monitoring-grafana \
  -n monitoring \
  -o jsonpath='{.data.admin-password}' | base64 -d

Для production замініть початкові credentials, інтегруйте SSO або керований identity provider та обмежте доступ через Ingress, VPN чи allowlist. Постійний UI-доступ має бути частиною загальної схеми моніторингу доступності та інфраструктури, а не випадковим відкритим Service.

Prometheus UI також зручно перевіряти через port-forward:

kubectl port-forward -n monitoring \
  service/monitoring-kube-prometheus-prometheus 9090:9090

У Grafana готові dashboards зазвичай уже показують nodes, namespaces, workloads і pod. Для ручної перевірки виконайте кілька PromQL-запитів:

sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) by (namespace)

sum(container_memory_working_set_bytes{container!=""}) by (namespace)

sum(kube_pod_container_status_restarts_total) by (namespace, pod)

1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m]))

PromQL потрібно перевіряти на ваших labels та exporters. Порожній результат не завжди означає відсутність проблеми: метрика могла мати іншу назву, target може бути Down, або selector dashboard не відповідає labels кластера.

Підключення метрик застосунку через ServiceMonitor

Припустимо, застосунок віддає Prometheus metrics на `/metrics` і порті `8080`. Service повинен мати іменований port, тому що ServiceMonitor посилається саме на ім’я порту Service, а не на числовий containerPort.

apiVersion: v1
kind: Service
metadata:
  name: api-metrics
  namespace: application
  labels:
    app: api
spec:
  selector:
    app: api
  ports:
    - name: metrics
      port: 8080
      targetPort: metrics

Створимо `ServiceMonitor`. Label `release: monitoring` потрібен типовому selector release, встановленого з таким ім’ям. Якщо у values змінені `serviceMonitorSelector` або `serviceMonitorSelectorNilUsesHelmValues`, узгодьте labels із фактичною конфігурацією Prometheus.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api
  namespace: application
  labels:
    release: monitoring
spec:
  selector:
    matchLabels:
      app: api
  namespaceSelector:
    matchNames:
      - application
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s
      scrapeTimeout: 10s

Застосуємо ресурси й перевіримо selector, endpoints та ServiceMonitor:

kubectl apply -f api-service.yaml
kubectl apply -f api-servicemonitor.yaml
kubectl get service,endpointslice,servicemonitor \
  -n application
kubectl describe servicemonitor api -n application

В Prometheus UI відкрийте Status → Targets і знайдіть target застосунку. Якщо його немає, спочатку перевірте, чи Prometheus вибрав ServiceMonitor, потім labels Service, ім’я port і RBAC для namespace. Якщо target є, але Down, перевірте мережеву доступність і відповідь endpoint зсередини кластера.

kubectl run metrics-check --rm -it \
  --restart=Never \
  --image=curlimages/curl \
  -n application -- \
  curl -fsS http://api-metrics:8080/metrics

Метрики застосунку повинні мати контрольовані labels. Не додавайте user ID, request ID, повні URL або інші значення з необмеженою кількістю варіантів: висока cardinality швидко збільшує споживання пам’яті та диска Prometheus.

Alerts, retention і типові помилки

kube-prometheus-stack містить набір готових PrometheusRule для Kubernetes. Перевірте завантажені правила та стан Alertmanager:

kubectl get prometheusrule -n monitoring
kubectl get alertmanager -n monitoring
kubectl get pods -n monitoring \
  -l app.kubernetes.io/name=alertmanager

Сповіщення мають бути дієвими. Alert без owner, runbook і зрозумілого порога створює шум. Почніть із доступності API, стану nodes, заповнення дисків, OOM/restarts, недоступних replicas і помилок критичних сервісів. Після цього налаштовуйте routing, grouping, inhibition та часові інтервали Alertmanager.

Перша типова помилка — ServiceMonitor створено, але його labels не відповідають selector Prometheus. Друга — у `endpoints.port` записано число або ім’я container port замість імені порту Service. Третя — Service selector не знаходить pod, тому EndpointSlice порожній.

Четверта проблема — відсутність PVC або замалий диск. При переповненні storage Prometheus може втратити стабільність, тому потрібні alerts на місткість і прогноз заповнення. П’ята — бездумне збільшення retention без оцінки active series. Шоста — публічна Grafana зі стандартним паролем або без SSO.

Під час upgrade зафіксуйте версію chart, прочитайте notes і перевірте зміни CRD. Helm 3 не завжди оновлює CRD так само, як звичайні шаблони. Спочатку виконуйте dry run і перевіряйте staging:

helm upgrade monitoring \
  prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --version NEW_CHART_VERSION \
  -f values-monitoring.yaml \
  --dry-run=server \
  --debug

Версії values, dashboards і alert rules варто зберігати разом із deployment-кодом та застосовувати через DevOps-послуги й керований release-процес, щоб ручна зміна в UI не стала єдиним джерелом правди.

Висновок

Практичний Kubernetes monitoring починається з цілісного ланцюжка: exporters створюють метрики, Prometheus Operator формує scrape-конфігурацію, Prometheus зберігає series та виконує правила, Alertmanager маршрутизує події, а Grafana дає контекст для аналізу. Встановлення chart — лише початок; корисність системи визначають retention, labels, targets, alerts і процес реагування.

Робочий мінімум включає окремий namespace, зафіксовану версію `kube-prometheus-stack`, PVC для Prometheus і Grafana, безпечний доступ до UI, перевірені Kubernetes dashboards та ServiceMonitor хоча б для критичних застосунків. Після цього потрібно контролювати cardinality, місткість диска, стан усіх targets і доставку тестового alert.

Коли базова схема стабільна, наступними кроками стають remote write для тривалого зберігання, централізація кількох кластерів, SLO dashboards, recording rules і runbooks. Головна мета — не зібрати максимальну кількість графіків, а помічати деградацію раніше за користувачів і давати інженеру достатньо даних для швидкого рішення.