Краткая архитектура и компоненты

Для надёжного мониторинга Kubernetes обычно разворачивают: Prometheus (scrape + storage + recording rules), Alertmanager (уведомления), node-exporter (метрики ноды), kube-state-metrics (статус K8s-объектов), cAdvisor (через kubelet — метрики контейнеров), ServiceMonitors/PodMonitors (discovery), Grafana (дашборды) и опционально long-term storage/HA (Thanos/Cortex). Также часто подключают логирование и трэйсинг для полной картинки.

Установка (две популярные опции)

1. Prometheus Operator / kube-prometheus-stack — удобнее: CRD (Prometheus, ServiceMonitor, PrometheusRule, Alertmanager) и готовая интеграция с Grafana/Alertmanager.

2. Ручная — deploy Prometheus, настроить scrape_configs в prometheus.yml, разместить exporters и настроить Service/Endpoints.

Базовая последовательность развёртывания

1. Развернуть kube-state-metrics, node-exporter (DaemonSet) и убедиться, что у них есть Service/Endpoints.

2. Развернуть Prometheus с persistent volume и достаточной retention/ресурсами. В Operator-режиме создаёте CR Prometheus и указываете serviceMonitorSelector/podMonitorSelector.

3. Создать ServiceMonitor/PodMonitor для всех exporter’ов (node-exporter, kube-state-metrics, ingress-controller, приложения).

4. Настроить PrometheusRule для alert’ов и recording rules.

5. Развернуть Alertmanager и настроить routes/receivers.

6. Развернуть Grafana, добавить datasource → Prometheus и импортировать/сделать дашборды.

Примеры YAML (минимум)

ServiceMonitor для kube-state-metrics:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: ksm-sm
labels: { release: prometheus }
spec:
selector:
matchLabels: { k8s-app: kube-state-metrics }
endpoints:
\- port: http-metrics
interval: 30s
Recording rule + alert:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata: { name: k8s-rules }
spec:
groups:
\- name: node.rules
rules:
\- record: node:node_cpu_seconds:rate5m
expr: sum by (instance)(rate(node_cpu_seconds_total{mode!="idle"}\[5m\]))
\- alert: NodeMemoryPressure
expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15
for: 5m
labels: { severity: critical }
annotations:
summary: "Node memory available <15% on {{ $labels.instance }}"
Grafana datasource provisioning (ConfigMap):
apiVersion: v1
kind: ConfigMap
metadata: { name: grafana-datasources, labels: { grafana_datasource: "1" } }
data:
prometheus.yaml: |-
apiVersion: 1
datasources:
\- name: Prometheus
type: prometheus
access: proxy
url: http://prometheus-operated:9090
isDefault: true

Важные настройки и практики

• Scrape interval & retention: по умолчанию 15s, для node/ingress можно 15–30s; retention зависит от объёма и бюджета (например, 15d).

• Relabeling: удалить лишние лейблы с высокого кардинала (pod ip, уникальные id) чтобы не взорвать TSDB.

• Recording rules: вычислять p95/p99/агрегаты заранее — заметно снижает нагрузку на Prometheus и ускоряет дашборды/alerts.

• Alerting: классифицируйте severity, создавайте route’ы в Alertmanager и тестируйте с for/silences`.

• HA и long-term: для HA/ретенции используйте Thanos/Cortex (sidecar + object storage) или репликацию Prometheus (но учтите дублирование alert’ов).

• Scale: горизонтальная шардировка targets (несколько Prometheus с разными scrape-configs) или Remote_Write в удалённое хранилище.

• Безопасность: RBAC для доступов к endpoints; TLS для APIServer/kubelet если требуется; ограничьте доступ к Grafana/Prometheus UI через OIDC/ingress auth.

• Кардинальность метрик: избегайте label’ов с уникальными значениями (request_id, user_id) — они создают огромный метрик-кард.

• Мониторинг контрол-плейна: scrape apiserver, scheduler, controller-manager, etcd (экспортёры) отдельно, собрать их метрики и alert’ы.

Диагностика и поддержка

• Настройте Alertmanager с интеграциями (Slack/Email/PagerDuty).

• Дашборды: node (node-exporter), kube-state (deployments/pods), kubelet/cAdvisor (container usage), ingress/latency, apiserver health.

• Тестируйте правила симуляцией проблем (создать Pending pods, создать OOM, выключить node) чтобы проверить alert’ы и runbooks.

заканчивайте внедрение поэтапно: сначала раскрывать базовую видимость (инфраструктура), затем приложения, затем тонкая настройка recording/alerts и HA.